Regular crashes are back with 1.73.4 :(

[Kaks]

However, since that worked, I found a new bug in trunk

Screet

Well, don't keep us guessing! What is it, and what is the fix?

[Screet]

However, since that worked, I found a new bug in trunk

Screet

Well, don't keep us guessing! What is it, and what is the fix?

I wrote about that immediately afterwards...maybe NOT a bug, considering how further observation turned out, but very strange. This energy bouncing while my ship was cloaked (down to almost empty, then up around one bar, then down, then up again and so on)...might be the MASC and a too high recharge rate. Guess next thing I'll try is to add energy use for player turrets

Screet

[Kaks]

Ok, say no more about that 'bug'. However, I'm very much interested in

I identified the source of the slowdown and when I tried to fix that as good as possible by cutting away parts, I apparantly also cured Oolite from the remaining crashes

I'm assuming it was some oxp script or .plist setting. It'd be really useful for us to know what it was, so we can put fixes in place to avoid the same kind of problem. A 'before' & 'after' snapshot of the crashy code would be brilliant. If it's too long to post, maybe zip & PM the link?

TIA!

[Screet]

I'm assuming it was some oxp script or .plist setting. It'd be really useful for us to know what it was, so we can put fixes in place to avoid the same kind of problem. A 'before' & 'after' snapshot of the crashy code would be brilliant. If it's too long to post, maybe zip & PM the link?

That massive OSE plist for worldscript was causing many problems for me, both concerning FPS (maxed out without it, around 20 with it in the current version) and crashes. When I cut it to only a few lines for the player station I bought (helps with maintenance cost) it still did massively affect FPS, but in a reduced amount to the full script...and crashes were gone.

Since that script is so entirely huge, it'd be difficult to find out what exactly caused the remaining crashes.

However, the slowdown might be an interesting thing to look at, although the script will soon be in javascript

This version of OSE-XML.plist is safe, but still slowing down the game noticeably:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>


      <key>Stations_owned_show_ABD</key>
        <array>
        <dict>

        <key>conditions</key>
        <array>
              <string>mission_playerstation_ABD equal 1</string>
        </array>

        <key>do</key>
        <array>
              <string>setMissionDescription: Station_ABD_owned</string>
        </array>

        </dict>
        <dict>

        <key>conditions</key>
        <array>
              <string>mission_playerstation_ABD undefined</string>
        </array>

        <key>do</key>
        <array>
              <string>clearMissionDescription</string>
        </array>

        </dict>
        </array>




        <key>Stations_owned_income_ABD</key>

        <array>
        <dict>

        <key>conditions</key>
        <array>
              <string>status_string equal STATUS_EXITING_WITCHSPACE</string>
              <string>mission_playerstation_ABD equal 1</string>
        </array>

        <key>do</key>
                  <array>
                     <string>awardCredits: 4000</string>
                  </array>

        </dict>
        </array>



</dict>
</plist>

Screet

[Kaks]

Thanks! It all makes sense now.

And hopefully pmw57's js script will be available pretty soon!

[Lestradae]

It all makes sense now.

It does, indeed?

So what is causing the massive slowdown, also in the supersmall snippet that Screet published above?

Is the difference between java script and XML scripts that extreme, or is there something specific in the above snippet that slows everything down?

I would like to know, if you "got it" I would like to know what to avoid in the future.

Cheers

L

[Kaks]

The difference between XML and js is that extreme.

There used to be a lot of 'optimisation' tricks used with old style scripting, based on exactly how you nest the various conditions you're testing for, but it's a bit of a lost art...

The bottom line is that the best optimised .plist script will still slow down Oolite much more than the slowest equivalent js script.

[Lestradae]

The difference between XML and js is that extreme.

OK, all hail pmw57 then, the hero of java script and may he get a lot of free drinks whereever he goes

Had I known that ... well, now I do.



L

[Screet]

OK, all hail pmw57 then, the hero of java script and may he get a lot of free drinks whereever he goes

Had I known that ... well, now I do.

Guess many OXPers who used plist would react that way...I'm currently missing the overview, but maybe it would be good if oolite would write a notification about this in the log for every XML script? That would also help to easily find existing OXPs which could be enhanced massively without checking every single OXP for XML scripts manually.

Screet

[Diziet Sma]

The difference between XML and js is that extreme.

Then I guess.. thanks to the hex that Cmd. Cheyd put on me, I'd better start learning some javascript.. <sigh>

[Screet]

GRRRR.

I just had a crash....in the instant time when my scoops should have activated. I can scoop...so the question is, what happened? Coincidence or something special with the cargo container or a script which did fill it?

I also had several ships which did not like to fight. Their AI state revealed this:

Code: Select all

  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: interceptAI.plist
    [dumpState.ai]: Current state: ATTACK_SHIP

IDLE and ATTACK SHIP sound like they should never be active together?!?

Very wierd: Although I did not get any new source code and did build as usual (make clean, make debug=no) this executable suddenly runs MUCH faster (even with several ships around) than any version I tried up to now. I fail to understand this.

BTW: turret energy consumption can REALLY simply be added *SMILE* I just wonder which values I should apply there...but it's working already!

Screet

[Eric Walch]

...I'm currently missing the overview, but maybe it would be good if oolite would write a notification about this in the log for every XML script? That would also help to easily find existing OXPs which could be enhanced massively without checking every single OXP for XML scripts manually.

As kaks already wrote, will re-ordering the plist-scripts structure already helps much. Nesting of conditions within other conditions. This prevents that the engine must check every used condition in the script over and over again. I changed a lot old scripts that way in the past.

I always was convinced it saved time but never could measure it. With the arrival of JS I managed to write a script that could log the real time before and after legacy script execution. Svengaly used this timer on the random hits script. before and after he re-ordered it a bit.
It is long ago and I do not know the exact values anymore. That code ran more than 10 times faster afterwards. Much more that I would have expected.

Converting to JS will be even better but is much more work. The re-ordering I did in the past was nothing more than a C&P job of code blocs in an intelligent way.

[Kaks]

Why don't you try and PS.spawn() the pod that crashed your scoop (with js debug console, of course)? Once we know which one constantly reproduces this crash, we should be able to look at it & fix the Oolite code.

About flagging up legacy scripts in the log, it's a really good idea, I don't yet know how easy it's going to be to implement, though!

[Eric Walch]

I also had several ships which did not like to fight. Their AI state revealed this:

Code: Select all

  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: interceptAI.plist
    [dumpState.ai]: Current state: ATTACK_SHIP

IDLE and ATTACK SHIP sound like they should never be active together?!?

It happens with AI bugs when a ship that already had lost a target still goes into attack mode. With the release versions that normally resulted in doing a perform_attack without target. Depending on which attack-mode it used it could eventually result in a TARGET_LOST message. In 1.73 this even works better than before.

With the trunk version I now also noticed ships in BEHAVIOUR_IDLE while in the ATTACK_SHIP state. I have no idea how it is possible but something is setting it to idle without sending a TARGET_LOST or TARGET_DESTROYED.

Problem with AI is that some generated messages are cached and only evaluated during UPDATE. e.g. my change of the pirateAI in trunk currently contains a bug for which I see no easy solution:

When in LURK state it finds the player it generates a checkGroupOddsVersusTarget command. When that command generates a "ODDS_GOOD" message and the player cloaks during the same update period, there is both a "ODDS_GOOD" and a "TARGET_LOST" message cached.

When it reads in the TARGET_LOST first is switch to the TRAVEL_TO_LURK_AREA state. But during that travel I also want to scan for Merchantmen and that state also needs to check for ODDS_GOOD. And there was still a ODDS_GOOD in the cache so it ends up in attack mode without a target.

This exception can only be avoided by adding an intermediate state were we can "loose" any cached messages. The new DROP_MESSAGES: command can't be used because it does not remove messages from the current cache but only for the cache that is being build for the next update.

So I am now experimenting with a complete other approach: let the command performAttack check if it has a valid target. If not, that command also generates a "TARGET_LOST". Because, even when I fix all the exceptions in the AI, there will be dozens similar around that can bug in a similar way.

Your example of interceptAI is probably different. It is possible for a script to send an escort with a groupAttack command into this interceptAI and than again in this AI with a deployEscorts. When the target is killed it falls back to the previous interceptAI. In the past the ship came back in perform attack (without target). Since 1.73 it comes back in performIdle on losing the target. For this it is easiest to add a RESTART message to interceptAI in case it were two nested interceptAI's.

[Eric Walch]

About flagging up legacy scripts in the log, it's a really good idea, I don't yet know how easy it's going to be to implement, though!

Any script name in the list that is shown on startup that has no version number is likely a plist script. So you can easy recognise them already.
(It is possible to add versions to a script.plist but I never noticed that be used outside Oolite)