wrongly assigned subentities?

Commander McLane · Post by **Commander McLane** » Fri Jun 06, 2008 10:34 am

During an epic battle with a Thargoid Carrier (revising the OXP right now) I got the following messages in my logfile. I don't really understand them, but I hope the code-monkeys can make something of it:

[ship.subentity.sanityCheck.failed.details]: Attempt to set subentity taking damage of <StationEntity 0x1847000>{"Thargoid Carrier"} to <ShipEntity 0x1e77600>{"Imperial Courier Engine" ID: 0 position: (-69, -12.4, 0) scanClass: CLASS_NOT_SET status: STATUS_INACTIVE}, which is not a subentity.
[ship.subentity.sanityCheck.failed]: Attempt to set subentity taking damage of <StationEntity 0x1847000>{"Thargoid Carrier"} to (null), which is not a ship.

Commander McLane · Post by **Commander McLane** » Sat Jun 07, 2008 2:30 pm

Got it again. This time I wasn't part of the fight, or even present:

[ship.subentity.sanityCheck.failed.details]: Attempt to set subentity taking damage of <ShipEntity 0x1ebf400>{"GalCop Viper"} to <ShipEntity 0x1eb8800>{"Arc Detail" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_INACTIVE}, which is not a subentity.
[ship.subentity.sanityCheck.failed]: Attempt to set subentity taking damage of <ShipEntity 0x1ebf400>{"GalCop Viper"} to (null), which is not a ship.

Frame · Post by **Frame** » Fri Jun 20, 2008 10:29 am

Scrutening the errors seems as if the roles got switched, the police viper became a subentity when damage was dealt, however it is a ship, therefore the code segfaults... and the Arc detail which is a subentity of the the coriolis station is trying to take damage as if it where a ship, but it is not, it is a ship...

My guees is that your shipdata.plist is faulty somewhere, so that ships sometimes gets to be subentities, and vice verca...

edit:

fetching a cup of coffee, i think there should be visual errors as well , if my speculation case is right...

Try exterior viewing of the imperial courier, and try and see if the coriolis station got all its four arcs...

Commander McLane · Post by **Commander McLane** » Fri Jun 20, 2008 10:37 am

Don't know. Hasn't happened since. I'll keep my eyes open.

JensAyton · Post by **JensAyton** » Mon Jul 07, 2008 6:31 pm

Hmm. This is the game getting confused about what ship owns a give subentity. It is a bug in the game, not a shipdata.plist problem. The second message in each case is a bug in the error-reporting code.

It would be helpful to have the version of the OXP which is apparently triggering the problem.

Frame · Post by **Frame** » Mon Jul 07, 2008 9:42 pm

Ahruman wrote:
It would be helpful to have the version of the OXP which is apparently triggering the problem.

I think the OXP in Question is Thargoid Threat
since

Commander McLane wrote:
"During an epic battle with a Thargoid Carrier (revising the OXP right now)"

JensAyton · Post by **JensAyton** » Mon Jul 07, 2008 10:35 pm

Frame wrote:
Ahruman wrote:
It would be helpful to have the version of the OXP which is apparently triggering the problem.
I think the OXP in Question is Thargoid Threat
since
Commander McLane wrote:
"During an epic battle with a Thargoid Carrier (revising the OXP right now)"

Yes. And I assume it’s not the generally-available version
since

Commander McLane wrote:
"(revising the OXP right now)"

;-)

Frame · Post by **Frame** » Tue Jul 08, 2008 12:40 am

To much sun and BBQ and BeeR!!!!.. naaah, just me..

Commander McLane · Post by **Commander McLane** » Wed Jul 09, 2008 8:35 am

Frame wrote:
Ahruman wrote:
It would be helpful to have the version of the OXP which is apparently triggering the problem.
I think the OXP in Question is Thargoid Threat
since
Commander McLane wrote:
"During an epic battle with a Thargoid Carrier (revising the OXP right now)"

That's a somehow correct assumption, as the Thargoid Carrier has nothing to do with Thargoid Threat (which is - by the way - called "Thorgorn Threat"), but the more so with Thargoidcarrier.oxp. And this is indeed what Selezen is revising (and I was helping with the scripting part of that).

But, as you already said:

To much sun and BBQ and BeeR!!!!

@ Ahruman: Hi! Long time no see!

I PM you the download link.

JensAyton · Post by **JensAyton** » Wed Jul 09, 2008 1:13 pm

Frame wrote:
Scrutening the errors seems as if the roles got switched, the police viper became a subentity when damage was dealt, however it is a ship, therefore the code segfaults...

Incidentally, where’d you get the segfault from? Oolite is quite capable of noticing that something’s wrong and complaining about it without crashing. Sometimes. :-)

Frame · Post by **Frame** » Wed Jul 09, 2008 1:15 pm

Ahruman wrote:
Incidentally, where’d you get the segfault from? Oolite is quite capable of noticing that something’s wrong and complaining about it without crashing. Sometimes.

More Beer!!!!

Commander Mysenses · Post by **Commander Mysenses** » Sun Jul 13, 2008 10:25 am

Dunno if this has anything to do with this, but I just came across a Tharg carrier in witchspace launching GalCop Vipers. I took a gap in the launches as an opportunity to dock with the beast. Nice of them to let me refuel and buy a few baubles, is this some kind of alien chivalric code?

To my suprise, when I relaunched, I found the big bugger had brought me back to the system I misjumped from... hmmm?

Seemed to be behaving more like a Behemoth than a Tharg.

Commander McLane · Post by **Commander McLane** » Mon Jul 14, 2008 5:11 am

Commander Mysenses wrote:
To my suprise, when I relaunched, I found the big bugger had brought me back to the system I misjumped from... hmmm?

That's a feature in Oolite's docking code. You may dock with whatever in interstellar space, but as soon as you leave it, it will always have jumped into one of the adjacent systems. That's the reason why it wouldn't be a good idea to script a dockable station in interstellar space. If the player would dock and launch again, the whole station would have mysteriously moved into normal space.

And by the way: The upcoming release of Thargoidcarrier.oxp won't allow the player to dock anymore.