[RELEASE] WildShips OXP

[Gimi]

For the NVidia users with CTDs. Please check the threading optimization. If it's on turn it off and try again.

@Thargoid: The stations are looking great.

Nope, that didn't work. This is so frustrating, and why am I the only one seeing the CTD on Windows. Ahrgh.

[Gimi]

I have been pulling out OXPs (I have a lot in there) to see if there is some sort of OXP conflict. If I pull out a lot (30+) things seem to stabilize. However I can't identify any particular OXP that conflicts with WildShips, at least not yet. I did get a somewhat more useful backtrace result just now, so I'll post it, hoping someone can make sense of it.

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x67848335 in objc-1!get_imp () from d:\myoolite\trunk\oolite.app\objc-1.dll
(gdb) Error: dll starting at 0x77450000 not found.
Error: dll starting at 0x76db0000 not found.
Error: dll starting at 0x77450000 not found.
Error: dll starting at 0x77780000 not found.
warning: Lowest section in C:\Program Files\NVIDIA Corporation\nview\nvwimg.dll is .rdata at 10001000
warning: Lowest section in C:\Program Files\NVIDIA Corporation\nview\nvwimg.dll is .rdata at 10001000
warning: Lowest section in C:\Program Files\NVIDIA Corporation\nview\nvwimg.dll is .rdata at 10001000
bt
#0  0x67848335 in objc-1!get_imp ()
   from d:\myoolite\trunk\oolite.app\objc-1.dll
#1  0x6484594b in gnustep-base-1_20!GSPrivateStrAppendUnichars ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#2  0x648457d4 in gnustep-base-1_20!GSPrivateStrAppendUnichars ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#3  0x005f1008 in -[GameController performGameTick:] (self=0x16b60b8, 
    _cmd=0x6d1b28, sender=0x14e606d0) at src/Core/GameController.m:325
#4  0x64922590 in gnustep-base-1_20!GSUnregisterCurrentThread ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#5  0x648fd8af in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#6  0x648f9d1f in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#7  0x648fa8a3 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#8  0x648f9682 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#9  0x005f0c59 in -[GameController applicationDidFinishLaunching:] (
    self=0x16b60b8, _cmd=0x6d2fa8, notification=0x0)
    at src/Core/GameController.m:269
#10 0x005f4c98 in SDL_main (argc=1, argv=0x1646e08) at src/SDL/main.m:120
#11 0x006411df in console_main (argc=1, argv=0x1646e08)
    at ./src/main/win32/SDL_win32_main.c:246
#12 0x006413bd in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x1105c44 "", 
    sw=10) at ./src/main/win32/SDL_win32_main.c:382
#13 0x00640bbc in main ()
(gdb) 

[Kaks]

Confusing, that stack trace seems to say oolite didn't even get a chance to start... it looks like you found another bug, possibly triggered by a 'wrong' plist setting, and totally unrelated to wildships...

[Gimi]

Confusing, that stack trace seems to say oolite didn't even get a chance to start... it looks like you found another bug, possibly triggered by a 'wrong' plist setting, and totally unrelated to wildships...

This is strange. All these crashes I have occur after launch from the main station. Anything from 5 seconds to about 60 seconds. I always see the planet and regain control of the ship after launch before Oolite goes down.

Most of the backtraces are of this kind though.

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x775b7074 in ntdll!RtlTraceDatabaseLock () from C:\Windows\system32\ntdll.dll
(gdb) Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x75670000 not found.
Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x76ca0000 not found.
warning: Invalid parameter passed to C runtime function.

warning: Invalid parameter passed to C runtime function.

#0  0x775b7074 in ntdll!RtlTraceDatabaseLock ()
   from C:\Windows\system32\ntdll.dll
#1  0x750740ef in ?? ()
#2  0x00000000 in ?? ()
(gdb) bt

Should we move this discussion to Testing and Bug reports?

[Gimi]

After having a chat with PhantorGorth on IRC about this issue, he suggested that I should pull out all OXP's that use frame callback except WildShips. I did, and Oolite still crashed/froze, but the backtrace gave a much more verbose result. Hopefully this will help.

The oxps I pulled out were:
BGS, BuoyRepair, CCL, Dredgers, Escort_Contracts, Explorers_Club, Liners, Sniper Sight and YAH Mobile

Backtrace

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x67848408 in objc_msg_lookup () from d:\myoolite\trunk\oolite.app\objc-1.dll
(gdb) Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x75670000 not found.
Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x76ca0000 not found.
bt
#0  0x67848408 in objc_msg_lookup ()
   from d:\myoolite\trunk\oolite.app\objc-1.dll
#1  0x005a9360 in -[OOScriptTimer compareByNextFireTime:] (self=0x112f19b8, 
    _cmd=0x6b7ca8, other=0xabababab) at src/Core/Scripting/OOScriptTimer.m:245
#2  0x005df427 in PQCompare (a=0x112f19b8, b=0xabababab, comparator=0x6b7ca8)
    at src/Core/OOPriorityQueue.m:99
#3  0x005df8de in -[OOPriorityQueue(Private) bubbleDownFrom:] (
    self=0x13ef82f8, _cmd=0x6c9e08, i=3) at src/Core/OOPriorityQueue.m:440
#4  0x005dfbae in -[OOPriorityQueue(Private) removeObjectAtIndex:] (
    self=0x13ef82f8, _cmd=0x6c9da8, i=0) at src/Core/OOPriorityQueue.m:529
#5  0x005df55b in -[OOPriorityQueue removeNextObject] (self=0x13ef82f8, 
    _cmd=0x6b7ce0) at src/Core/OOPriorityQueue.m:361
#6  0x005a905c in +[OOScriptTimer updateTimers] (self=0x6b7b40, _cmd=0x658138)
    at src/Core/Scripting/OOScriptTimer.m:177
#7  0x00425365 in -[PlayerEntity update:] (self=0xc6b82b0, _cmd=0x6e3a60, 
    delta_t=0.033999979496002197) at src/Core/Entities/PlayerEntity.m:1641
#8  0x00627a6d in -[Universe update:] (self=0x38af468, _cmd=0x6d1b10, 
    inDeltaT=0.033999979496002197) at src/Core/Universe.m:5159
#9  0x005f1133 in -[GameController doPerformGameTick] (self=0x2fa3e38, 
    _cmd=0x6d1b08) at src/Core/GameController.m:344
#10 0x005f0fe2 in -[GameController performGameTick:] (self=0x2fa3e38, 
    _cmd=0x6d1b28, sender=0x1434b8d8) at src/Core/GameController.m:323
#11 0x64922590 in gnustep-base-1_20!GSUnregisterCurrentThread ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#12 0x648fd8af in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#13 0x648f9d1f in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#14 0x648fa8a3 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#15 0x648f9682 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#16 0x005f0c59 in -[GameController applicationDidFinishLaunching:] (
    self=0x2fa3e38, _cmd=0x6d2fa8, notification=0x0)
    at src/Core/GameController.m:269
#17 0x005f4c98 in SDL_main (argc=1, argv=0x2f46f70) at src/SDL/main.m:120
#18 0x006411df in console_main (argc=1, argv=0x2f46f70)
    at ./src/main/win32/SDL_win32_main.c:246
#19 0x006413bd in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x1226224 "", 
    sw=10) at ./src/main/win32/SDL_win32_main.c:382
#20 0x00640bbc in main ()
(gdb) 

Edit: Turns out I still had BGS Buoy repair in, which uses frame callbacks.
When I pulled that one out as well, things worked better, took about 5 min before Oolite froze.
Frame callbacks are back in the suspect box.

[Gimi]

To summarize a bit:
I have rolled back to a known stable nVidia graphics driver.
I have done a fresh checkout of trunk.
I have pulled out all OXP's that use frame callbacks except WildShips.
If I disable wildShips_kiota.js in WildShips things work fine.

Oolite now freezes after about 3-5 minutes with only WildShips using Frame Callbacks.

Backtrace from last crash (I'll stop spamming this thread for a while now):

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x67848335 in objc-1!get_imp () from d:\myoolite\trunk\oolite.app\objc-1.dll
(gdb) Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x75670000 not found.
Error: dll starting at 0x76ef0000 not found.
Error: dll starting at 0x76ca0000 not found.
bt
#0  0x67848335 in objc-1!get_imp ()
   from d:\myoolite\trunk\oolite.app\objc-1.dll
#1  0x6484594b in gnustep-base-1_20!GSPrivateStrAppendUnichars ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#2  0x648457d4 in gnustep-base-1_20!GSPrivateStrAppendUnichars ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#3  0x005f1008 in -[GameController performGameTick:] (self=0x2db3e38, 
    _cmd=0x6d1b28, sender=0x1504e9b8) at src/Core/GameController.m:325
#4  0x64922590 in gnustep-base-1_20!GSUnregisterCurrentThread ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#5  0x648fd8af in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#6  0x648f9d1f in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#7  0x648fa8a3 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#8  0x648f9682 in gnustep-base-1_20!NSRangeFromString ()
   from d:\myoolite\trunk\oolite.app\gnustep-base-1_20.dll
#9  0x005f0c59 in -[GameController applicationDidFinishLaunching:] (
    self=0x2db3e38, _cmd=0x6d2fa8, notification=0x0)
    at src/Core/GameController.m:269
#10 0x005f4c98 in SDL_main (argc=1, argv=0x2d56f70) at src/SDL/main.m:120
#11 0x006411df in console_main (argc=1, argv=0x2d56f70)
    at ./src/main/win32/SDL_win32_main.c:246
#12 0x006413bd in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0xef6224 "", 
    sw=10) at ./src/main/win32/SDL_win32_main.c:382
#13 0x00640bbc in main ()
(gdb) 

[Capt. Murphy]

Hi Gimi,

Interesting. Out of interest what are the results on a 1.76 build or a 1.76-maintenance build?

svn co http://svn.berlios.de/svnroot/repos/oolite-linux/branches/1.76-mainten
ance

cd 1.76-maintenance

make debug=yes

[Thargoid]

Ahem, I suppose there's always the option of reconverting the .dats to .objs, check for problems inside wings3D (a non-triangular face perhaps?) & convert them to .dat once again after fixing the mesh itself... in any case Thargoid is in Easter Mode at the moment - and therefore unavailable for a while...

Just popping in briefly from a borrowed PC - I can make the dat files available if needed next week (this isn't my dev machine) and/or have a look, but they are quite simple models. Plus in any case I thought Wings triangulated any non-triangular face anyway?

With thanks to McLane and Eric for their comments by PM - I'll roll the inbuilt pseudo-random function into the next script update as that's non-vital by now. And @McLane - I always thought given the size of the system environment that they were rather empty of stations (given how they are described in the original canon literature), hence why the Kiota are quite so "common". But it's a simple tweak in the populator script to make them less so, as I'm sure you already have done.

[Gimi]

Hi Gimi,

Interesting. Out of interest what are the results on a 1.76 build or a 1.76-maintenance build?

svn co http://svn.berlios.de/svnroot/repos/oolite-linux/branches/1.76-mainten
ance

cd 1.76-maintenance

make debug=yes

Things have been running stable on 1.76-maintenance with WildShips installed for about 20min now. Got some nice screenshots. (I'm flying around and looking at all the Kiota stations.)
I'm going to give it another 10-15 min and then start putting back the OXP's I have taken out.

Edit: 45min and no CTD/freeze.

@Thargoid.
I love this OXP. Looks great. I think your next step with this one should be hybrids. Two struts with solar panels and two factory struts and so on. A factory needs power. A factory could use biological material (bio/factory). You get the idea. This really is too good to not build upon further.

[Commander McLane]

And @McLane - I always thought given the size of the system environment that they were rather empty of stations (given how they are described in the original canon literature), hence why the Kiota are quite so "common". But it's a simple tweak in the populator script to make them less so, as I'm sure you already have done.

I guess I'm rather used to the relatively empty systems. Anyway, I've experimented with some values. Currently I'm on

Code: Select all

0.92 + (system.countShipsWithRole("wildShips_kiota") / 20)

for all probabilities. This still gives one Kiota in about half the systems I have visited so far. Haven't encountered a system with two Kiotas since I made the change, so perhaps I'll make the 20 still bigger.

[Gimi]

I feel like I'm spamming this thread.

I have been running 1.76-maintenance for over an hour now, all my usual OXP's in place, and everything seems fine. I'm getting a lot of errors in the log though, in particular a lot of these which I think is down to Kaks' earlier fix:

Code: Select all

12:45:56.745 [script.javaScript.timeLimit]: ***** ERROR: Script "(nil)" ran for 0.514025 seconds and has been terminated.
12:45:56.746 [script.javaScript.stackTrace]:  0 (YAH_mobileTractor.js:34) <anonymous function>
12:45:56.746 [script.javaScript.stackTrace]:     this: [Script "YAH_mobileTractor.js" version 1.0]
12:45:56.746 [script.javaScript.timeLimit]: ***** ERROR: Script "(nil)" ran for 0.514618 seconds and has been terminated.
12:45:56.746 [script.javaScript.stackTrace]:  0 (YAH_mobileTractor.js:34) <anonymous function>
12:45:56.746 [script.javaScript.stackTrace]:     this: [Script "YAH_mobileTractor.js" version 1.0]
12:49:03.993 [script.javaScript.timeLimit]: ***** ERROR: Script "(nil)" ran for 0.44715 seconds and has been terminated.
12:49:03.993 [script.javaScript.stackTrace]:  0 (wildShips_kiota.js:110) <anonymous function>
12:49:03.993 [script.javaScript.stackTrace]:     this: [Script "wildShips_kiota.js" version 1.0]
12:49:03.993 [script.javaScript.stackTrace]:     listCounter: 1

And these:

Code: Select all

12:13:41.579 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x171d9b58>{"wildShips_duma.dat", 42 vertices, 88 faces, radius: 87.4643 m normals: per-face}

The whole log is available here: http://www.box.com/s/6dae56f71a8c4390502a

[Commander McLane]

BTW: The Tembos are irresistible. They're releasing so much cargo.

[Thargoid]

BTW: The Tembos are irresistible. They're releasing so much cargo.

Think of them as the Oolite version of the white van - a Foord Transoot if you will...

[Eric Walch]

BTW: The Tembos are irresistible. They're releasing so much cargo.

Think of them as the Oolite version of the white van - a Foord Transoot if you will...

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.

[Thargoid]

@Thargoid.
I love this OXP. Looks great. I think your next step with this one should be hybrids. Two struts with solar panels and two factory struts and so on. A factory needs power. A factory could use biological material (bio/factory). You get the idea. This really is too good to not build upon further.

Thanks. I must admit I did ponder those, and indeed I have had a few in my ooniverse on occasions. In some cases though they don't look as nice as the symmetrical ones, as they're more unbalanced. But doing them is trivial with the existing OXP (as all of the bits on the arms are sub-ents), and it may well be something I come back to later.

The main reason I popped back here is I've been thinking about the log errors from the ships. For at least some (and maybe all) of them I did use the datscale.py script to resize them. I wonder if that could be why the errors are popping up? Has it corrupted or altered them incorrectly somehow perhaps?