Is there a way to switch which dictionary entry applies to an existing object on the fly?
No.
docwild wrote:
If not, what is the effect of removing and replacing an entity which the player is docked at?
Probably quite messy.
docwild wrote:
Finally, I'm sure I read somewhere that it's possible, using the debug OXP and jScript console, to reload a worldscript on the fly. I can call the startup method which restarts the script already in memory, but is it possible to edit the script, and reload from within the game using the python debug console on linux?
Nope. You can, however, change the script’s handlers in memory:
Is there a way to switch which dictionary entry applies to an existing object on the fly? If not, what is the effect of removing and replacing an entity which the player is docked at? I could use the shipWillDockWithStation () handler to switch before the ship docks or is it possible to create a station, switch the player to it before removing the original? Can it be switched during the shipWillLaunchFromStation() handler. I know there is a dockPlayer method (or something like that) but does it immediately dock the player or does it engage autopilot docking to said station?
If a station is destroyed whilst a player is docked in it then the player is automatically launched iirc. So presumably if it is script-removed the same would apply. Hence as soon as you try you'd possibly end up sat outside the new version of your station.
dockPlayer does just that - displays the docking rings and then the status screen. Basically the same as insta-docking (shift-D by standard keyboard mapping) when within the main station aegis (but can be used with any dockable entity). So probably not quite what you're looking for (a few extra ring sequences).
Looking at the trunk logs there may be a way to do this in 1.75 (something I plan to check when I get chance), but as a follow-up question, is there any reason the beacon code has to be read-only and not read-write settable (and removable) from script?
Editted to add - scratch the 1.75 thing, didn't work (beacons on sub-entites don't show up on the ASC).
as a follow-up question, is there any reason the beacon code has to be read-only and not read-write settable (and removable) from script?
As far as I know, it's the same reason that you cannot select/deselect specific missiles, or change player speed from script: the player needs to be - at least nominally - in control of its ship. If you play around with these things via script, the feeling of being in control tends to disappear fairly quickly... I wasn't around at the time, but I've got the feeling it probably was a bit touch and go for a while over making player.ship position & orientation modifiable by script...
Eh? How does being able to turn the broadcast beacon on and off on an NPC entity affect the player ship? Especially given it can be worked around by removing and replacing an entity to do it in a rather messy fashion?
Maybe I misunderstood the question, but the beacon can be used (and I personally use it) in combat, and being able to switch it off at will does personally feel a step too far scriptwise... if the targeted entity is destroyed, and a similar one is put in its place, fair enough I suppose...
Not that I'm too confortable with the concept, mind.
If we consider the beacon display as a gps, changing the 'address' you want to go to under the player's feet does - again - feel like quite an underhand move too.
Physically destroying the 'address' and creating a new 'identical' one does at least reset the target, alerting the player that something is amiss... Anyway, these are my own personal opinions, don't really know what other devs think about it, etc...
I tend to think of a beacon as a broadcast on a specific frequency, I can imagine that turning off the main station beacon via script would be a pain but perhaps a separate class of OXP beacons could be script controllable. At the moment it is fairly clunky, having to remove and replace entities on the fly to achieve the proper effect, making sure to store their stats (rotation, position, energy) before doing so. It isn't a vital thing nor is it particularly difficult to overcome, but it is one of those idiosyncrasies.
this.updateBeacons = function ()
{
if(this.playerClaimedMines.length > 0)
{
log(this.name, "UPDATEBEACONS");
var mineEntity = system.shipsWithRole("slaveMine");
//asteroids have been placed, now the owned ones need replacing
for(var i = 0; i < mineEntity.length; i ++)
{
log(this.name, "updateBeacons: i = " + i);
for(var n = 0; n < this.playerClaimedMines.length; n++)
{
var displayName = this.playerClaimedName[n];
var position = Vector3D(this.playerClaimedPositions[n]);
if(position.distanceTo(mineEntity[i].position) < 5)
{
//this is likely the one :P
mineEntity[i].remove();
var mineEntity2 = system.addShips("slaveMineOwned", 1, position, 1);
if(mineEntity2)
{
mineEntity2[0].displayName = displayName;
log(this.name, "replaced station n = " + n + " mineEntity2 = " + mineEntity2);
}
break;
}
}
}
}
}
A potential problem that’s been bothering me for some time is that there’s no distinction between custom properties/methods on scripts and ones used by Oolite. This means that any new event handlers might conflict with some OXP’s private methods.
I’d like to suggest a convention (not an enforced rule) to get around this: custom properties on script objects intended for internal use or as APIs for other scripts should be prefixed with dollar signs. For instance, in the built-in Nova mission script, this.endTheMission would become this.$endTheMission and this.cleanUp would become this.$cleanUp.
custom properties added to anything other than your own script objects should still have an OXP-specific prefix.
Unless someone has a particular objection against this, I’ll be updating the built-in scripts accordingly soon.
Hmm, I'd use _ instead of $ as the suggested prefix for custom properties/methods myself.
The _ prefix is already fairly common for internal properties/methods, and the $ prefix is already fairly common - as far as js namespaces are concerned - to identify properties & methods from external libraries (jquery & prototype spring to mind).
Using $ for internal properties might well cause unnecessary confusion for any OXP maker already used to js...
Underscores are used for a variety of identifiers with special meanings to the interpreter. Well, OK, double underscores. But single underscores lead to double underscores, and eventually someone will think __count__ is a good name for a private property, and then the universe will explode in their face.
OK, so I’m a bit paranoid about namespaces. Somebody has to be.
Wait, if I understand the gist of what you're saying you'd rather confuse experienced js programmers because there's the remote possibility that non-js programmers could get confused by 'one _ at the front' and decide it actually means 'two _ at the front and two _ at the back', and - by pure chance - they come up with a name identical to an internal js property?
I'm happy to agree that someone confusing '_name' with '__name__' is a tiny bit more likely than confusing '$name' with '__name__', but either case is very, very unlikely, and would be 'a bit' of a stretch for them to say 'but Ahruman told me to write this property this way'.
And if the universe explodes because they use __count__ instead of the perfectly acceptable _count, well, they need to to take responsibility for their own actions.
I do think going against estabilished namespace practices is very counterintuitive, rather than paranoid, but hey, what do I know!
.
We need other sources to sell our buoys.
