[RELEASE] WildShips OXP

[cim]

I believe I've found the solution to the crashing problems - nothing wrong with Wild Ships itself, of course: it just uses more timers than most OXPs and so exposed an Oolite bug. See this post for a patch against current trunk - that will hopefully fix the remaining crashing.

[JD]

Very well done cim. I'm sure this bug hunt has seemed a bit tough for Thargoid, but for someone lurking on the sidelines (ie me) watching you and others searching for this has been better than an episode of Poirot. Nice going everyone.

[Thargoid]

You now used a complex way to give each subentity a script that releases 0-20 pieces each.

Alternatively you could do everything in shipData for each subentity define:

Code: Select all

cargo_type = CARGO_CARRIED;
cargo_carried = 'liquor/wines';
max_cargo = 150;

That will release 0-15 pieces each. And you can define the content per subentity.

I must say, I never thought of it doing it this way, but I now just tried it with a ship. And it is working. If I shoot of one of the subs, it released the cargo. Same when killing the main ship.

An interesting solution. The only problem is it will only use cargo from the trunk itself, which isn't quite what I want. The more complex solution currently in place (a version of Kaks' code from Kestrel & Falcon) goes via the role "cargopod", hence the stuff from Cargo & Wrecks and Pods etc are also included.

But for more general usage, it's an interesting alternative. Anyway now we may have a fix for at least part of this ongoing issue, I'll look at the dat files and then maybe issue a 1.02 version.

[Eric Walch]

Cim, a good find of the bug in Oolite that apparently didn't correctly clean up loose timers.

And for current Oolite:

Found it! In Scripts/wildShips_kiota.js
......
Adding those two lines prevents the crash, for me.

Cleaner would be to add the handler:

Code: Select all

this.entityDestroyed = function ()
{
    if (this.liftTimer) {this.liftTimer.stop()};
    if (this.missileTimer) {this.missileTimer.stop()};
}

That way you are sure the timers never fire after the entity has been removed.

[Thargoid]

I've just updated the kiota script with that very modification (plus a clean-up for the frame callback too). I'm going now to look at the reported problems with the .dat files, and will then issue v1.02 with all the mods (plus the streamlining of the populator script too).

Should be out later tonight.

[Eric Walch]

An interesting solution. The only problem is it will only use cargo from the trunk itself, which isn't quite what I want. The more complex solution currently in place (a version of Kaks' code from Kestrel & Falcon) goes via the role "cargopod", hence the stuff from Cargo & Wrecks and Pods etc are also included.

I just realised yesterday that it should be possible to add cargo in subs. But the method will use the pods from Cargo & Wrecks and Pods as the method itself will randomly select pods with role "cargopod" and fill it with the specified cargo, as long it didn't select a scripted pod. And when you don't want to fill it with specific goods, you can always use the more general "SCARCE_GOODS" or "PLENTIFUL_GOODS" to fill them up.
The only limitation is a maximum of 15 pods that are released.

[Thargoid]

Some of them (at least from Pods) are scripted, so won't get picked.

In this case I think I'll leave the scripting in place as it's one of the things in the OXP that actually works. But useful for future implementation, thanks!.

[Thargoid]

OK, I just uploaded v1.02.

• Script optimised to close off all timers and callbacks as neatly as possible.
• Using the built-in pseudo-random number generator rather than the script one in the populator (and the chances tweaked slightly).
• All textures are now as small as possible to still look OK.

I looked at the .dat files too - it seems that the errors are thrown up due to the use of two textures within the entity rather than the normal one (if I remove one, the error goes). But as that error also only shows up with detailed logging on, I don't think there's anything to be done about it at the moment.

And also just to add my thanks to cim for the excellent bug-hunting on all of this saga.[/color]

[Gimi]

And thank you to Thargoid for an excellent OXP and for exposing a bug in Oolite which would have come back to hunt us at a later stage if he had not exposed it now.

Thank you.

[Gimi]

I have checked out and compiled trunk rev 4836. So far Oolite is running fine with WildShips 1.02 and all my other OXPs back in. I have tested for about 30min so far. Thank you all and especially Thargoid and cim. Is there any reason to test with WildShips 1.0 or 1.01 to make sure this bug is thoroughly squashed. I suspect not, but thought I would ask just in case.

I submitted this bug to Berlios as [ Bug #18552 ] 1.77 trunk rev 4833 & wildships.oxp causes CTD/Freeze
Could one of the devs please update it.

[Thargoid]

Thanks. No there is no real need to test with v1.00 or v1.01, at least from my side.

The main update of v1.00 was the correction of the shader, and stopping all the timers correctly (although that wouldn't fully help the bug just fixed, from my understanding) and shrinking down the textures to 512x512 and 1024x1024 for ships and stations respectively.

v1.02 was mainly a tidy-up and a few minor corrections - again nothing much that would affect this bug in particular.

The only remaining bit is the deep texture error from the ships due to using two textures (perhaps), but that's a separate issue.

[Kaks]

All's well that ends well! Thanks cim for the great work!

@Gimi: aha, so it was you who submitted a trunk bug!
Trunk - by definition - is expected to have bugs...
Anyway, I'm curious about the Kaks maintenance bugfix you mentioned. Which one were you referring to?

[Gimi]

All's well that ends well! Thanks cim for the great work!

@Gimi: aha, so it was you who submitted a trunk bug!
Trunk - by definition - is expected to have bugs...
Anyway, I'm curious about the Kaks maintenance bugfix you mentioned. Which one were you referring to?

I was referring to the Ignoring Timer Exception thing you mentioned earlier. You were expecting that to turn up in the log. It just struck me that I'm not sure if you had ported that fix to maintenance at the time.

Also, I am aware that trunk is expected to have bugs, but I was having similar problems in both 1,76 and trunk, but not in 1.76.1 at the time. It was rather confusing. Since I could do a backtrace in trunk, I referred to trunk. I think I was actually finding different bugs and mixing the two. Should have been more clear. Sorry.
I should check out 1.76 and do a debug build just to verify. (I'm probably in over my head here, so maybe not).

[Kaks]

Hmm, strange. Both 1.76 & maintenance did have the same wrong bits, and I haven't ported my previous tentative fix...
I've ported cim's fix to maintenance now, so there shouldn't be any of those errors in maintenance for real. That there weren't any when you tested looks like it was more of a happy coincidence than anything else...

[Gimi]

Hmm, strange. Both 1.76 & maintenance did have the same wrong bits, and I haven't ported my previous tentative fix...
I've ported cim's fix to maintenance now, so there shouldn't be any of those errors in maintenance for real. That there weren't any when you tested looks like it was more of a happy coincidence than anything else...

Well, I was doing a lot of testing, with different versions and different peoples fixes, so it may well be that I got things mixed up.