What I will do tomorrow is to compare Lestradae's recently uploaded code with Screets. Any differences between them will be incorporated/ignored/queried/thrown to the winds, and I will upload the updated timer-related scripts tomorrow, before continuing on with the rest of the scripts.
Very good, I think this might be the way forwards. Perhaps Screet, could you wait with the rework until pmw57 publishes his version? Just so that working in tandem becomes possible without the other's work going out the window?
When they are ready I'll put a big invitation to all oxp-makers who's scripts might be in OSE if they want to have a look at their (Screet- + pmw57-) reworked java scripts, if they find some use with them?
That may be the way to go, is there agreement? T, does this cover your suggestion to involve or at least invite oxp'ers who's scripts are altered here?
When they are ready I'll put a big invitation to all oxp-makers who's cripts might be in OSE if they want to have a look at their (Screet- + pmw57-) reworked java scripts, if they find some use with them?
To assist, I will also summarise significant issues that come to attention with these scripts, as has been posted in this thread recently.
I will attempt to fix of them what is reasonable to do so, however in some cases the addition of the initially missing functionality may well affect the overall balance of the script.
Regardless, fixes will be notified here, as and when they occur.
Last edited by pmw57 on Wed Oct 14, 2009 12:23 pm, edited 1 time in total.
A trumble a day keeps the doctor away, and the tax man;
even the Grim Reaper keeps his distance.
-- Paul Wilkins
(3) The code doesn't make sense anyway, and I am surprised that it actually works. this.playerWillEnterWitchspace is an event handler exclusively for ship scripts. It doesn't make any sense in a world script. And the only case in which you need to delete a timer, if the player leaves the system, is for timers inside ship scripts. However, Planetfall.js is not a ship script. It is a world script. So you just have to completely delete your addition, and everything will be fine.
I think you're mixing up this.shipWillEnterWitchspace (which is a ship script event) with this.playerWillEnterWitchspace, which is a worldscript one.
Sorry, but in this case it is you who is mixing it up (like pwm57 in his script example).
shipWillEnterWitchspace is a world script event, which fires when the player enters witchspace.
Therefore my words are still standing. And I am still surprised that playerWillEnterWitchspace even does anything at all in a world script. And still there is no need to delete or remove world script timers when the player enters witchspace. Especially if these timers are to be started again when he exits witchspace (just look at the script snippet in question). You can't start a timer which you just before have deleted.
You may need to clarify this information here. You seem to be saying that the first occurs when the player leaves the system by going into witchspace, and that the second occurs when the player leaves the system, presumably by going into witchspace as well.
A trumble a day keeps the doctor away, and the tax man;
even the Grim Reaper keeps his distance.
-- Paul Wilkins
I haven't tested the updated scripts yet, Im still reading the threads, its just that Im helping another company, with beta testing, so I will test the scripts later, I have turned on DEP, so when I test Oolite I will know if there is a DEP problem or not, just can't test at the moment
You may need to clarify this information here. You seem to be saying that the first occurs when the player leaves the system by going into witchspace, and that the second occurs when the player leaves the system, presumably by going into witchspace as well.
Please just read what I wrote.
Yes, both handlers are called when the player leaves a system by going into witchspace (how else should he leave the system????). But the first one, as I explicitely wrote, is used in the world script. Whereas the second one, as I explicitely wrote, is used in ship scripts only. It has no place whatsoever in a world script. That it seems to do anything in a world script, as your example seems to suggest, is—if anything—a bug.
Do you want me to explain in detail the difference between a world script and a ship script? I assumed you would know that already. Other than that my statement is crystal clear.
then the player leaves a system by going into witchspace (how else should he leave the system????).
That's what I thought, but just in case the difference in phrasing may have inferred a difference in behaviour, the clarification was sought.
Commander McLane wrote:
But the first one, as I explicitely wrote, is used in the world script. Whereas the second one, as I explicitely wrote, is used in ship scripts only. It has no place whatsoever in a world script. That it seems to do anything in a world script, as your example seems to suggest, is—if anything—a bug.
My hazy understanding is that worldscripts are loaded from the appropriately named plist, while ship scripts are loaded from shipdata when the ship is created spawned.
Corrections and extensions to that understanding are welcome.
A trumble a day keeps the doctor away, and the tax man;
even the Grim Reaper keeps his distance.
-- Paul Wilkins
And a ship script relates only to the ship it's attached to (and so multiple examples of the same ship type will each have individual and distinct copies of the same script).
A worldscript does similar, but essentially is a ship script for the player ship (in practical terms), although it can be referenced by any other script. Only one example of the worldscript will exist in the game.
World scripts are the JS equivalent of the legacy script.plist. In very layman's terms: the world script contains the set of actions centred around the player. All the events recorded in a world script are focused exclusively on the player's behaviour: The player docks or launches, the player leaves a system or arrives in a new system, the player kills somebody or gets killed, the player reaches or leaves a certain distance from a planetary body, the player is low on energy or has his energy replenished, the player visits different screens while docked, etc., etc., etc. Many of the events defined for world scripts don't have the word "player" in them, but "ship" instead, because it is the very premise of a world script that it is about the player. Therefore it is of course his ship that docks, or is launched, or enters witchspace, or whatever.
Everything in a world script is about the player, and the player only.
Ship scripts on the other hand side have nothing to do with the player. A ship script is attached to a NPC ship. It determines the behaviour of this particular ship, regardless if the player is anywhere near. Events defined in a ship script are therefore centred around the NPC ship "owning" the ship script: the NPC ship docks or launches, the NPC ship leaves the system or comes out of a wormhole, the NPC ship is created or dies, the NPC ship is damaged or gets killed, etc., etc., etc. All of this has nothing to do with the player. The ship script of a certain NPC ship get executed even if the player in his ship is currently docked, or he is at the other end of the system and looks into the opposite direction.
Ship scripts exist completely independently of any world script. Of course they can interact in various ways, but even if the world script moves competely away, the ship script continues to exist and to do be executed. One specific example which made us a headache is the case of a ship script using a timer. This timer only exists inside the ship script. It has nothing to do with the actions performed in a world script. Therefore, even if, according to the world script, the player has jumped out of system A and arrived in system B, all timers started by ship scripts in system A still exist. The ships and ship scripts they belonged to have been deleted, they don't exist anymore. But the timer doesn't know that the script which started it doesn't exist anymore. Therefore, the next time it has completed a cycle and wants to start a certain action, this action is no longer defined. And this is what produces an error.
For this very reason a special event was defined for ship scripts: playerWillEnterWitchspace. This event informs all ship scripts of all ships in system A that the player is no longer there, and after a split second all of them will cease to exist. So it is the task of each ship script to react to this event by taking certain actions. One of these actions (and probably the only necessary action) is that they should delete all timers they have been using before. Note that by far not all ship scripts have even used a timer. So in most cases no action has to be taken at all. But in those rare cases where a ship script has created a persistent, repeating timer, this one has to be deleted.
Bottom line: If no timer was used in a ship script, there is no need for using the event playerWillEnterWitchspace in that specific ship script. And there is no use whatsoever, never ever, for the event playerWillEnterWitchspace in a world script.
All clear now?
Last edited by Commander McLane on Fri Oct 16, 2009 7:21 am, edited 1 time in total.
Bottom line: If no timer was used in a ship script, there is no need for using the event playerWillEnterWitchspace in that specific ship script. And there is no use whatsoever, never ever, for the event playerWillEnterWitchspace in a world script.
All clear now?
But you must admit that the name playerWillEnterWitchspace is very inconsistent chosen. It is only a few weeks back that I added all missing handlers to that page. On doing that I noticed that this particular one has an exception in its name. All other handlers starting with player are worldscript-only except this one. To be consistent it should have started with something else than player or ship. e.g. npcDetectedPlayerWillEnterWitchspace.
An other inconsistency was with alertConditionChanged. To be consistent is should start with ship as all other handlers starting with ship can be used both in ship- as in world scripts: shipAlertConditionChanged
I think the main inconsistency we have now is that about half of the player-centred handlers for world scripts have "player" in their names, and the other half "ship", but are meant for the player anyway.
I think this is because we started with "ship" only, but later some were added and/or renamed.
And of course, some of the world script events can be used for ship scripts as well (like shipDied), so "ship" is the more general term. But still there are inconsistencies, because there are others with "ship", that can only be used in world scripts, not in ship scripts (like the aegis messages, or shipWillLaunchFromStation; I don't think they would work in ship scripts).
Would it make sense to have two completely independent sets of events for world scripts and ship scripts? So that playerBeingAttacked would be for world scripts only, and shipBeingAttacked would be the equivalent for ship scripts?
Or would that be an overkill? At the end of the day it is the responsibility of each scripter anyway, to know the methods, and to know where to use them and to what end, and what an equally named event will do in a world script or in a ship script.
Would it not be simpler just to envisage ship scripts as a kind of restricted subset of world scripts, ie a worldscript is a ship script (applying to the player ship) plus a few extra bits as it's the player not an NPC.
Therefore things that are for ships (designed for NPCs) then affect everyone, and those that are referencing the player in NPC scripts are equally applicable in a player ship script (aka a worldscript), but semi-redundant due to duplication. So playerWillEnterWitchspace and shipWillEnterWitchspace in that specific case are actually the same thing, as here player = ship. It's only in the NPC case when the two have different meanings, as we're talking about distinct ships (player one and NPC one).
To me, this is a perfect example of what we need to sort out before removing the -test status!
Quite a lot of js events, methods & properties are fairly consistent now, but it looks like we'll need to do some more work on consistency before we can finally get the next Stable Release out, at least as far as the js interface is concerned.
Or just use the engineering approach. If it works in a worldscript then it's a worldscript event, if it works in a ship script then its a shipscript event, and if it works in both stop complaining and use the damn thing.
.
