1.73 and the suicide ships

Screet · Post by **Screet** » Wed Apr 08, 2009 4:51 pm

Hi,

I've just had another encounter with a Juggernaut launching and then directly crashing itself into the nav buoy. This time I got a log report right before the crash:

Code: Select all

[dumpState]: State for <StationEntity 0x1b781808>{"Navy Juggernaut Courier" "Navy Juggernaut Courier" ID: 274 position: (-68373.9, 20401.5, 559396) scanClass: CLASS_POLICE status: STATUS_ACTIVE}:
  [dumpState.entity]: Universal ID: 274
  [dumpState.entity]: Scan class: CLASS_POLICE
  [dumpState.entity]: Status: STATUS_ACTIVE
  [dumpState.entity]: Position: (-68373.9, 20401.5, 559396)
  [dumpState.entity]: Orientation: (0.89684 - 0.0498353i - 0.41185j + 0.15354k)
  [dumpState.entity]: Distance travelled: 8069.7
  [dumpState.entity]: Energy: 1712 of 1712
  [dumpState.entity]: Mass: 1.88235e+009
  [dumpState.entity]: Owner: <StationEntity 0x1b781808>{"Navy Juggernaut Courier" "Navy Juggernaut Courier" ID: 274 position: (-68373.9, 20401.5, 559396) scanClass: CLASS_POLICE status: STATUS_ACTIVE}
  [dumpState.entity]: Flags: isShip, isStation, hasMoved, hasRotated, isSunlit
  [dumpState.shipEntity]: Name: Navy Juggernaut Courier
  [dumpState.shipEntity]: Display Name: Navy Juggernaut Courier
  [dumpState.shipEntity]: Roles: <OORoleSet 0x1c49d2e0>{military militarycarrier militarycourierjuggernaut police}
  [dumpState.shipEntity]: Primary role: police
  [dumpState.shipEntity]: Script: <OOJSScript 0x1c4a2830>{"oolite-default-ship-script" version 1.73}
  [dumpState.shipEntity]: Subentity count: 35
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (-76377.1, 18545.2, 550281)
  [dumpState.shipEntity]: Other destination: (-71300.8, 21275.2, 556725)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 190
  [dumpState.shipEntity]: Escort count: 255
  [dumpState.shipEntity]: Fuel: 1000
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 50
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: planetPatrolAI.plist
    [dumpState.ai]: Current state: GO_TO_COORDS
    [dumpState.ai]: Next think time: 59.502
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 12266.3
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100042
  [dumpState.shipEntity]: Spawn time: 3.68 (53.071 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: isFrangible, canFragment
  [dumpState.stationEntity]: Alert level: green
  [dumpState.stationEntity]: Max police: 8
  [dumpState.stationEntity]: Max defense ships: 3
  [dumpState.stationEntity]: Police launched: 0
  [dumpState.stationEntity]: Max scavengers: 3
  [dumpState.stationEntity]: Scavengers launched: 0
  [dumpState.stationEntity]: Docked shuttles: 0
  [dumpState.stationEntity]: Docked traders: 0
  [dumpState.stationEntity]: Equivalent tech level: 13
  [dumpState.stationEntity]: Equipment price factor: 0.95
  [dumpState.stationEntity]: Flags: none
[Wreckage]: scaling factor 36.7847 with mass 3979.17

Sadly, I could not get any position data on the nav buoy, because it was destroyed too quickly. The shift-h report was from less than a second before the crash, but there was no collision warning flag set!

I also tried different values for some collision variables during this test, thus I find it astonishing that there was no collision warning flag set:
#define PROXIMITY_WARN_DISTANCE 100.0
#define PROXIMITY_WARN_DISTANCE2 250.0
#define PROXIMITY_AVOID_DISTANCE 100.0

The original values were 10 instead of 100 and, IIRC, 100 instead of 250. Those values appeared much too rigid to me and interestingly no pirate did crash itself to death while approaching my ship on this flight. Maybe I solved that annoying problem...but I'll need to fly more before I could be sure about that.

One strange thing with the trunk version: sometimes it just closes the program, but there's NO log entry and NO stderr entry to be seen. Ideas?

Screet

Post by **another_commander** » Wed Apr 08, 2009 5:06 pm

Screet wrote:
One strange thing with the trunk version: sometimes it just closes the program, but there's NO log entry and NO stderr entry to be seen. Ideas?

Yep. Run the game through gdb, wait for it to crash and then type bt at the gdb prompt to get the stack backtrace and the actual location of the crash. It is advisable that you rebuild the entire project first doing a

Code: Select all

make clean
make debug=yes

or you may experience difficulties with your debugging due to optimizations that take place when you build with debug=no.

Screet · Post by **Screet** » Thu Apr 09, 2009 8:12 pm

another_commander wrote:
Screet wrote:
One strange thing with the trunk version: sometimes it just closes the program, but there's NO log entry and NO stderr entry to be seen. Ideas?
Yep. Run the game through gdb, wait for it to crash and then type bt at the gdb prompt to get the stack backtrace and the actual location of the crash. It is advisable that you rebuild the entire project first doing a
Code: Select all
make clean
make debug=yes
or you may experience difficulties with your debugging due to optimizations that take place when you build with debug=no.

Seems to be this one:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x77795844 in ntdll!RtlFreeThreadActivationContextStack ()
(gdb) bt
#0  0x77795844 in ntdll!RtlFreeThreadActivationContextStack ()
#1  0x07400020 in ?? ()

Doesn't help much though

I'm not really sure if it's that one, but it just happened at the same time...I went to a new planet and where the trunk version did simply close I got this crash. With the debug version it was several times possible to do that problem jump though...strange.

Screet

Post by **another_commander** » Fri Apr 10, 2009 6:01 am

Can you post the entire backtrace? We are interested to see the first line referring to Oolite itself. The crash you posted seems to come from one of the system dlls, but the actual error should originate from an earlier call within Oolite.

Screet · Post by **Screet** » Fri Apr 10, 2009 6:21 am

another_commander wrote:
Can you post the entire backtrace? We are interested to see the first line referring to Oolite itself. The crash you posted seems to come from one of the system dlls, but the actual error should originate from an earlier call within Oolite.

That's, sadly, all I got!!! It's complete! Furthermore, I had it a second time with identical result.

In between I had an attempt where no such thing happened, but stderr had two entries about an exception handling problems (handler not on top of stack, removed).

Screet

Post by **another_commander** » Fri Apr 10, 2009 6:24 am

Well, c**p. Just one question: Do you have the procedural planets enabled in the Options screen? If yes, can you disable and see if it continues to crash?

Screet · Post by **Screet** » Fri Apr 10, 2009 6:30 am

another_commander wrote:
Well, c**p. Just one question: Do you have the procedural planets enabled in the Options screen? If yes, can you disable and see if it continues to crash?

Can do...had them enabled and will miss them extremely. They're sooo nice!

Oooh. There was something...when switching in debug mode to the system info it took ages until the planet was shown. I never observed that with procedural planets in the release version, but it seemed to be the utmost slowest part of the program in debug mode, even much slower than loading my save file (which contains dozens of dead trumbles, they're gone, but still in the save file).

Screet

Screet · Post by **Screet** » Fri Apr 10, 2009 7:18 am

Hmm. That didn't make the problem go away.

However, it did lead me to find another bug

When procedural planets are disabled before jump and then enabled later on, switching to the planet info (probably also while not docked and viewing the planet) leads to some very interesting result. Similar to a crystal planet

Ohhh...and since I made the above mentioned changes to warning distances, I have never again been rammed by kamikaze ships!!! I'll keep an eye open, but if that really solves that problem, I suggest to change the trunk versions to the values I mentioned!

Screet

Post by **another_commander** » Fri Apr 10, 2009 10:39 am

Screet, I have emailed you a test exe. If you can repeat the test and it works, great. If not, can you send me the backtrace from that?

Post by **Kaks** » Sat Apr 11, 2009 2:31 pm

Screet wrote:
When procedural planets are disabled before jump and then enabled later on, switching to the planet info (probably also while not docked and viewing the planet) leads to some very interesting result. Similar to a crystal planet

I see how that could happen, the planet was generated with x vertices, but F7 expects a different number of vertices if you change the detailed planets to another setting. Once you make a jump to a new system, everything looks ok again.

In other words, atm the detailed planets setting doesn't redraw the main planet immediately, but F7 thinks it did. Will change the code to redraw main planets immediately! RL has been a bit of a b£$%h the last couple of weeks, but I'm on the case!

stanley1100 · Post by **stanley1100** » Sun Apr 12, 2009 5:55 pm

Sorry, but at the top:

[dumpState.shipEntity]: Frustration: 0
[dumpState.shipEntity]: Escort count: 255

Is it me or is that a lot of escorts! Or are they all the escorts in the area....
And frustration? What does that refer to?

Screet · Post by **Screet** » Sun Apr 12, 2009 6:25 pm

stanley1100 wrote:
Sorry, but at the top:
[dumpState.shipEntity]: Frustration: 0
[dumpState.shipEntity]: Escort count: 255
Is it me or is that a lot of escorts! Or are they all the escorts in the area....
And frustration? What does that refer to?

Wow, didn't notice that...looks like a lot, but that ship did not have any escorts at all?!? Maybe it has to do with the pending escorts bug in the trunk version?

Screet

Screet · Post by **Screet** » Tue Apr 21, 2009 3:18 pm

OK, another juggernaut just launched and then ran over the stations N buoy. I've got position on the buoy before the crash, which turned out NOT to be the destination of the juggernaut. Thus I guess that it's an AI bug:

Code: Select all

 [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (-115480, 13027.9, 788381)
  [dumpState.shipEntity]: Other destination: (-108031, 15783.3, 791798)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 150
  [dumpState.shipEntity]: Escort count: 255
  [dumpState.shipEntity]: Fuel: 1000
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 50
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: planetPatrolAI.plist

...and, yes, this one also has such a strange entry for escort count.

However, I do wonder if the planetPatrolAI ignores obstacles and thus leads to the behaviour of running over the buoys...any ideas on how to verify or, if necessary, fix that one?

Screet

Screet · Post by **Screet** » Sun Apr 26, 2009 10:41 am

Hmmm. I've had another encounter with a ship crashing into a YAH ad. I managed to shift-h it directly before the crash and the ship did NOT get a collision warning by then.

Could it be that those buoys are not included in the list of objects that can create a collision warning? If so, any suggestions where in the code to look for that?

Screet

Solas · Post by **Solas** » Mon Apr 27, 2009 8:51 am

non-player ships seem to have this problem with Nav Buoys, Stations and YAH ads

ships launch from station and fly into the Nav Buoy
http://developer.berlios.de/bugs/?func= ... up_id=3577

Cmdr James "I do see quite a few ships crash into the station"
https://bb.oolite.space/viewtopic.php?p= ... ght=#74957

It's strange that warning distances need to be increased.
do the Devs know what could have changed to require this ?

Oolite Bulletins

1.73 and the suicide ships

1.73 and the suicide ships

Re: 1.73 and the suicide ships

Re: 1.73 and the suicide ships