Oolite trunk, strange stuff

[Micha]

Modern gdb includes a reasonable amount of support for ObjC these days, in particular you can

find out what type an ObjC object is:
whatis object

print an ObjC object:
po object

set an ObjC breakpoint:
break [class function]

If the function takes parameters you need to use:
break [class function:]


Combined with Insight or similar it's quite good.

[Screet]

Hi,

thanks for the replies concerning the debugging - I'll need to have some quiet look at those options!

What I found out is that the method in question is called by setUpOneSubentity

That method does this check:
type = [subentDict stringForKey:@"type"];
return [self setUpOneStandardSubentity:subentDict asTurret:[type isEqualToString:@"ball_turret"]];

For all turret models I could see, the type is "ball_turret", but for the Caduceus, it's "standard".

I now have to find out where this does come from - as the turret definitions in shipdata don't use a key "type" and I also tried to set such a key with type "ball_turret" for the Caduceus turrets without any change to the reported "standard".

Screet

[another_commander]

I think I know what is going on, but more testing is needed:
It looks like the setup_actions are not inherited through like_ship. If I take the setup_actions = "initaliseTurret" from the caduceusturret-npc entry and copy it to the caduceusturret one, then not only do I get the turrets working, but I also don't see the weird parts of the ship in the port and starboard views. This also explains why the Boa and Falcon turrets always worked, as they are not like_ship'd to anything.

Why exactly this happens is to be investigated. However, I think we should be much closer now to fixing this than where we were at this morning.

[Screet]

I think I know what is going on, but more testing is needed:
It looks like the setup_actions are not inherited through like_ship. If I take the setup_actions = "initaliseTurret" from the caduceusturret-npc entry and copy it to the caduceusturret one, then not only do I get the turrets working, but I also don't see the weird parts of the ship in the port and starboard views. This also explains why the Boa and Falcon turrets always worked, as they are not like_ship'd to anything.

Why exactly this happens is to be investigated. However, I think we should be much closer now to fixing this than where we were at this morning.

Yes, definitely. My log additions just did show that the setup actions for the caduceus turrets are empty!

Furthermore, the other turreted ships I've seen so far use the alternate plist format...

Screet

[Screet]

Got it...

The test for turrets is done by checking for initialiseTurret. This is done before the like_ship references are resolved!!!

EDIT: Just exchanged the lines from OOShipRegistry.m to

Code: Select all

	// Resolve like_ship entries.
	if (![self applyLikeShips:result])  return;

	// Clean up subentity declarations and tag subentities so they won't be pruned.
	if (![self canonicalizeAndTagSubentities:result])  return;

as a test. Now the turrets do work!

However, that would cause the canonicalize to run twice for like_ships...I'm not sure if it's safe to do this.

Screet

[Lestradae]

Hi Screet,

good to see you bugsquashing for the Oolite core!

I am very interested in the like_ship turret setup issue to be resolved - for OSE, I intend to use (actually already am using) up to triple like_ship'ped ships with turrets from a common template. If this doesn't work, I could bury everything I'd done so far!



L

[Screet]

good to see you bugsquashing for the Oolite core!

I'm not too sure yet if this exchange of lines is really OK.

I have not seen any issues from the log, however I felt up to copy my normal commander to the trunk folder and continue there - now I'm suffering a very often happening instant death experience.

Not sure if that's from the test change I made or some other bug. On most jumps, I'm dead after exiting witchspace (different YAH behaviour? maybe those ads should not replace the nav buoys but be shown a few km from there towards the planet, also allowing for better visibility?)...but when I manage to exit witchspace without death, I often just hear a bang and I'm dead - without knowing what did happen *GRRR* On the other hand - maybe it has to do with the extremely big explosions I can see?

Screet

[Screet]

Hmmm.

That's bad. I thought the fuel stations were safe now...but obviously that had to do with Caduceus turrets being turned into standard subentities

At least I just tried to fly in and when I was almost there *BANG* ship gone.

Even worse, directly following "press space" oolite did close:

Code: Select all

ERROR: Removing exception handler that is not on top of the stack. (You probably called return in an NS_DURING block.)

Could all this be because I caused like ship to be run before the other method checking for turrets, or are these different bugs just kicking in, waiting to be found?

EDIT: another attempt with the enabled Caduceus turrets and the fuel station - instant KABOOM and then exit of Oolite with the above mentioned std.err entry, thus that's reproducible.

Screet

[Kaks]

And so it begins...

'joy'

You've got my sincerest best wishes for your bug hunt.

[Screet]

And so it begins...

'joy'

You've got my sincerest best wishes for your bug hunt.

Interesting. I just went back to the trunk version (undoing my changes) and did place the "initialiseTurret" also to the like_shipped version of the turrets.

Results:
1) Turrets work
2) Fuel stations blow up the Caduceus
3) The game crashes upon "press space" with the abovementioned error
4) The graphics bugs while viewing left and right out of the Caduceus, which were gone with my change, did reappear!

Thus I now know that my change wasn't that bad, as it fixed quite some bugs at once and that the crash and fuel station problem resides anyway, as soon as the turrets are active.

Grrrr.

Redoing my changes...and a few more bugs on the list to hunt...

EDIT: just did so...and got this upon my second witchspace exit

Code: Select all

.:70: element dict: validity error : Element dict content does not follow the DTD, expecting (key , (array | data | date | dict | false | integer | real | string | true))*, got (key real key real key array key string key string key integer key string key string key real key string key real key string key integer key string key real key real key real key real key integer string key key string key integer key string key string key string key real key string key string key string key string )
		</dict>
		       ^
.:85: element array: validity error : Element array content does not follow the DTD, expecting (array | data | date | dict | false | integer | real | string | true)*, got (key integer key integer key string string string )
				</array> 
				        ^
ERROR: Removing exception handler that is not on top of the stack. (You probably called return in an NS_DURING block.)
ERROR: Removing exception handler that is not on top of the stack. (You probably called return in an NS_DURING block.)
ERROR: Removing exception handler that is not on top of the stack. (You probably called return in an NS_DURING block.)

Screet

[Screet]

Even worse.

I just tried BOTH versions (as in trunk with Caduceus modified turrets and the modification from me for like_ship with original turrets) with the same crash upon launching from a whoopy casino. I also flushed the cache on both attempts, as the modification I made does make the cache invalid because it changes what's written to the cache. Thus, it's not from there...stderr reports:

Code: Select all

.:70: element dict: validity error : Element dict content does not follow the DTD, expecting (key , (array | data | date | dict | false | integer | real | string | true))*, got (key real key real key array key string key string key integer key string key string key real key string key real key string key integer key string key real key real key real key real key integer string key key string key integer key string key string key string key real key string key string key string key string )
		</dict>
		       ^
.:85: element array: validity error : Element array content does not follow the DTD, expecting (array | data | date | dict | false | integer | real | string | true)*, got (key integer key integer key string string string )
				</array> 
				        ^

Either the game closed (as mentioned before) or hung up...any idea how I could identify the source of this one?

Screet

[Kaks]

It's a plist parser problem, most likely than not you've got some nesting errors, and probably not even in the exact line numbers mentioned.


Try verifying all oxps you modified to get the name of the plist these problems are in. From the command line (run>cmd):

Code: Select all

cd C:\GNUstep\Local\oolite\trunk\oolite.app
oolite -verify-oxp ..\AddOns\name-of-oxp-to-test.oxp

then look inside Latest.log

[Screet]

Strange. That plist problem is simply GONE before I could find what was causing it.

Anyway, I still have the problem that I hear bangs of something crashing into my ship while the scanner is empty, and most often I don't only take shield damage, but experience a press space moment.

I'm not sure if this from the log has to do with such things:

Code: Select all

[ship.subentity.sanityCheck.failed.details]: Attempt to set subentity taking damage of <ShipEntity 0x1c87fd08>{"Sentinel Satellite"} to <ShipEntity 0x18687a90>{"Error: Sub-Entry in the wrong role!" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_INACTIVE}, which is not a subentity.
[ship.subentity.sanityCheck.failed.details]: Attempt to set subentity taking damage of <ShipEntity 0x1c87fd08>{"Sentinel Satellite"} to <ShipEntity 0x18687a90>{"Error: Sub-Entry in the wrong role!" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_INACTIVE}, which is not a subentity.
[ship.subentity.sanityCheck.failed.details]: Attempt to set subentity taking damage of <ShipEntity 0x1c87fd08>{"Sentinel Satellite"} to <ShipEntity 0x18684488>{"Error: Sub-Entry in the wrong role!" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_INACTIVE}, which is not a subentity.

Screet

[LittleBear]

I know them! They're subentries of a Seedy Space Bar. It looks like a Sentinal Satilate has collided with a bar, possibley due to another ship hitting it and knocking it into the bar. Not sure though why a subentriey is being reported as a normal entry.

[Screet]

I know them! They're subentries of a Seedy Space Bar. It looks like a Sentinal Satilate has collided with a bar, possibley due to another ship hitting it and knocking it into the bar. Not sure though why a subentriey is being reported as a normal entry.

I'm using a modified version which does first resolve like_ship before it tries to evaluate an entity - I did that because in the new trunk version the Caduceus turrets became unusable (probably because of these lines being ordered the other way around compared to 1.72.2).

I've seen such reports as that above several times...thus I don't believe it's from a collision of a satellite with a bar due to another ship, that would be too unlikely. Maybe exchanging those lines to make the Caduceus turrets work again did introduce some bug in that case

Screet