Page 2 of 7
Posted: Wed Feb 27, 2008 8:09 pm
by Timm74
Hi.
I did not mess up a mission, thats why the counter is on -140. anything below zero should be fine.
Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...
Seems to be two errors cancelling each other out..
Cheers!
Timm
Posted: Sun Mar 02, 2008 10:08 am
by Dr. Nil
Timm74 wrote:
Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...
Glad to hear that it worked out. The seven stations sounds strange
Posted: Sun Mar 02, 2008 4:52 pm
by Ark
Dr. Nil wrote:Timm74 wrote:
Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...
Glad to hear that it worked out. The seven stations sounds strange
Not to me
Posted: Sun Mar 02, 2008 5:22 pm
by Dr. Nil
Hmm. Probably due to running some experimental release instead of the last stable release (1.65).
Errors with the experimental releases should be reported in Testing and Bug reports.
Code: Select all
{ "Pi-Forty-Two Con stores" = (
{ conditions = ("systemGovernment_number greaterthan 0", "systemPopulation_number greaterthan 40", "status_string equal STATUS_EXITING_WITCHSPACE", "planet_number greaterthan -1");
do = ("addShipsAt: constore 1 pwu 0 0 1.05" ); }
); }
Script actions that test for Status_Exiting_Witchspace should only happen once each time you exit witchspace - at least that's how it used to work. If this has changed then it will cause problems with a lot of oxps.
Posted: Sun Mar 02, 2008 5:25 pm
by Ark
It is the ringpod oxp in 1.70 version (remember)
Posted: Sun Mar 02, 2008 5:30 pm
by JensAyton
Dr. Nil wrote:Script actions that test for Status_Exiting_Witchspace should only happen once each time you exit witchspace - at least that's how it used to work.
That’s the intended behaviour. Off the top of my head, the most likely cause for it happening more than once is
scriptActionOnTarget: being used in
STATUS_EXITING_WITCHSPACE. I think the scripting system can be manipulated to avoid this, by judiciously lying to scripts.
Posted: Sun Mar 02, 2008 5:35 pm
by Dr. Nil
Ahruman wrote:I think the scripting system can be manipulated to avoid this, by judiciously lying to scripts.
...
Huh...
Posted: Sun Mar 02, 2008 6:30 pm
by JensAyton
A rather important question is which states are expected to be seen only once per event, and which should be substituted? I believe the following is about right, but I’m sure Eric will see something I completely failed to think of. :-)
STATUS_DOCKING -> STATUS_IN_FLIGHT
STATUS_ENTERING_WITCHSPACE -> STATUS_IN_FLIGHT
STATUS_EXITING_WITCHSPACE -> STATUS_IN_FLIGHT
Edit: STATUS_LAUNCHING -> STATUS_IN_FLIGHT
I’ve also made
scriptActionOnTarget: print a deprecation warning. It is evil. Do not use.
Incidentally, in testing this stuff I rediscovered a useful tool: the
script.trace setting in
logcontrol.plist. If it is set to
yes, the name of each world script is printed before it is run, which is rather useful for finding out which script is causing a problem. (Under Mac OS X with the
Debug OXP, you can set this at run time with the Debug->Log Message Classes->Other… menu command. To do: it should be possible to fiddle with log messages at runtime with the JS console.)
Posted: Sun Mar 02, 2008 9:02 pm
by Eric Walch
Ahruman wrote:
I’ve also made scriptActionOnTarget: print a deprecation warning. It is evil. Do not use.
Maybe alter the command totally. Giles probably introduced it to set missionvariables and to immediately react on it. But I don't know any OXP that needs this behaviour. Remove the
checkScript from the command. This way a script will not react on changes in mission variables immediately but only at the next tickle. That means at the most a delay of 10 seconds. I used it is some occasions in UPS but it was never essential that the mission variables were read out immediately. The same is valid for Random Hits. That also needs the values not sooner than on docking.
Remove the
checkScript from
scriptActionOnTarget: and make it a separate command. Probably there will be a oxp that will suffer from this, but than the
checkScript command can be added after the
scriptActionOnTarget:.
As Ahruman says: Now, when a ship hyper-spaces it appears in an other system with a message RESTARTED. a scripter can at this point set a system variable with
scriptActionOnTarget:. this way forcing to run all scripts twice on EXITTING_WITCHSPACE.
Actually the script itself should catch double additions by counting the ships first before adding. In the case of a station you not only want it to be there when jumping, but also when launching after a just loaded game. And on launching you always need the check if it was already there so why not doing it on witchspace jumping. But I agree: I would not have thought it could run twice but it can. I just think there is not yet a OXP that does it right now?
---
In this case I think it is just oolite 1.70 that is to blame. It has done more strange things. Sometimes when I blow up a ship, there is no debris, but several large asteroids from asteroid storm. An when I put randomHits in, I regularly see parts of the spacebar floating through space. Or today a asteroid crying for help. And a few days ago I shot down such an asteroid and the police started chasing me.
I think adding 7 stations belongs in this category errors not script behaviour.
Posted: Mon Mar 03, 2008 12:00 pm
by JensAyton
You’ve got a point, but I don’t want to mess about with existing script methods (like I’d ever do that…). I guess I can add a quickScriptActionOnTarget: or some such.
Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.
Posted: Mon Mar 03, 2008 1:22 pm
by Eric Walch
Ahruman wrote:Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.
This is not a bad bug that will get published. Such a recursion will be so bad that it will crash oolite on first use. I don't think it will get an opportunity to get published. The current situation were this command is hidden in an other command is worse as it now get used without knowing it.
Posted: Mon Mar 03, 2008 7:38 pm
by JensAyton
Hey, with a proper exit condition it could work. Just very badly.
Anyway, I’ve added safeScriptActionOnTarget: which skips the checkScript, and it’s mentioned in the deprecation warning for scriptActionOnTarget:.
Posted: Tue Mar 04, 2008 6:04 am
by Commander McLane
Eric Walch wrote:Ahruman wrote:Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.
This is not a bad bug that will get published. Such a recursion will be so bad that it will crash oolite on first use. I don't think it will get an opportunity to get published. The current situation were this command is hidden in an other command is worse as it now get used without knowing it.
Forgive me my ignorance, but wasn't it you who suggested to me to use
checkScript in an AI in order to make
STATUS_ENTERING_WITCHSPACE working?
Anyway, it is implemented in Anarchies, in
anarchiesCheckscriptAsteroidAI.plist, which has the sole purpose of, errm..., well, I think the name speaks for itself.
So,
if the world as we know it comes to an end soon, will I be the one to blame???
Posted: Tue Mar 04, 2008 6:20 pm
by JensAyton
I think I’m going to have to start randomly renaming methods just to keep Eric away from them. :-) (Seriously, don’t call checkScript. Just don’t.)
Posted: Tue Mar 04, 2008 9:37 pm
by Eric Walch
Ahruman wrote:Anyway, I’ve added safeScriptActionOnTarget: which skips the checkScript, and it’s mentioned in the deprecation warning for scriptActionOnTarget:.
The
scriptActionOnTarget: command without further documentation was a bad idea of Giles. The main purpose of the command was setting variables and immediately running the installed scripts. I think Giles introduced it for the racing rings in ringpod.oxp. In that OXP he uses the command intensively to send points and timings from the rings to the player script.
the command is as killing a rabbit in your garden with a cruise missile. The target will be death, but it does a lot more than you would wish for.