I look forward to seeing an illustration of Cousin Digby's pile on Digebiti.
More like a castle than a manse, sorry.
It's those Mountain Seoids, you see. They can do a lot of damage to a manse. Something more defensive has a better chance to protect those inside. As happened a century back - Duke Dorian and his entourage were then attacked by one in the castle and survived the experience. The castle survived too, just needing some pointing and a repaint of the inside of the drawing room.
It's a simple matter to prevent a player buying a commodity at a station (set market quantity to 0) but is there a simple way to prevent a player from selling a commodity at a station?
I'm trying to simulate a no demand situation without just lowering the market price significantly.
I want to not only discourage the player from selling but to actually prevent them from doing so without confiscation.
It's a simple matter to prevent a player buying a commodity at a station (set market quantity to 0) but is there a simple way to prevent a player from selling a commodity at a station?
I'm trying to simulate a no demand situation without just lowering the market price significantly.
I want to not only discourage the player from selling but to actually prevent them from doing so without confiscation.
I’ve always used the playerSoldCargo world event, and just reversed the effects of the passed parameters. If I remember I’ll post a code snippet doing this later this morning.
It's a simple matter to prevent a player buying a commodity at a station (set market quantity to 0) but is there a simple way to prevent a player from selling a commodity at a station?
I'm trying to simulate a no demand situation without just lowering the market price significantly.
I want to not only discourage the player from selling but to actually prevent them from doing so without confiscation.
Set capacity to 0. And, see the market script in this, for my experiments:
I’ve always used the playerSoldCargo world event, and just reversed the effects of the passed parameters. If I remember I’ll post a code snippet doing this later this morning.
That would still be of interest if not inconvenient for you.
//-------------------------------------------------------------------------------------------------------------
// stop the player from selling cargo (in this case, slaves)
this.playerSoldCargo = function (commodity, units, price) {
var p = player.ship;
var stn = p.dockedStation;
if (commodity === "slaves") {
var refund = units;
// take credits off player
player.credits -= ((price / 10) * refund);
// give commodity back to player
p.manifest[commodity] += refund;
// take commodity away from station
stn.setMarketQuantity(commodity, stn.market[commodity].quantity - refund);
// Market Observer interface - make sure this doesn't impact on it's data
if (worldScripts.market_observer3) {
this._sale = {
commodity: commodity,
units: units,
price: price
};
this._mo_timer = new Timer(this, this.$reverseMOSale, 0.25, 0);
}
}
}
//-------------------------------------------------------------------------------------------------------------
this.$reverseMOSale = function $reverseMOSale() {
var mo = worldScripts.market_observer3;
mo.playerBoughtCargo(this._sale.commodity, this._sale.units, this._sale.price);
this._sale = {};
}
I wish to restrict a laser to a particular mounting (e.g. fore).
I further wish to test if a mounting is empty and (once a certain item is installed on the player ship) deny access to it.
*BUMP* Redspear's question remains of interest. And now, mine:
Apart from the ghost of Svengali leaving a terse note in Latest.log, what actually happens if one creates a new global object in Oolite's javascript environment? Will it explode? Run slower? Report one to the FBI?
Does the newly-minted object become addressable and modifiable, well, globally? Or is there like um, you know, a whole procedure to follow, lest it just hang around doing nothing but wasting space?
"Must keep this response efficient to preserve remaining context."
I think the only way to restrict where a laser can be mounted is to capture the purchase event to an item that is not actually a laser, show a custom mission screen with the limited choices on offer, and then do the install of the actual laser item at that point.
There will be a lot of breaking points, though. Laser Arrangement allows you to move a laser to any mount. Equipment storage allows you to store lasers and then put them back in any position. There’s probably a couple of others as well. Just so you know.
Checking for an empty laser mount should be checking for EQ_WEAPON_NONE in the equipment key for the position (ie. player.ship.aftWeapon.equipmentKey)
what actually happens if one creates a new global object in Oolite's javascript environment? Will it explode? Run slower? Report one to the FBI?
Does the newly-minted object become addressable and modifiable, well, globally? Or is there like um, you know, a whole procedure to follow, lest it just hang around doing nothing but wasting space?
I think it's (a) the potential for confusion if two scripts attempt to create the same global object, or of core code changes adding global objects and breaking things; and (b) it's just bad programming practice to put things into global that don't need to be there.
I think the only way to restrict where a laser can be mounted is to capture the purchase event to an item that is not actually a laser, show a custom mission screen with the limited choices on offer, and then do the install of the actual laser item at that point.
Thanks phkb. I was afraid it might be somewhat clunky (esp given other oxp involvement as you mention). The above does make sense however and could work well in isolation. Hmm...
this.playerBoughtNewShip = this.playerReplacedShip = function _sc_playerReplacedShip(ship) {// player ship only
var wsc = worldScripts["Shield Cycler"];
this.ship = player.ship;
// sell shieldcycler equipment if still present and reset settings
if (this.$sc_settings.version !== 0) {
log(this.name, "Player's got a new ship, removing Shield Cycler equipments");
if (this.$sc_settings.manual_version !== 0)
wsc._sc_remove_manual();
wsc._sc_remove_shield_cycler();
wsc._sc_update_status();
}
}
The equivalent code in Sc 1.x (by me ) uses the full value instead of a var .
Is there an execution advantage for using a var to call worldscripts or is this cosmetic/style related ?