Got another CTD.

[Fatleaf]

Found this in the log, Oolite development version 1.75.4.4623


16:33:27.479 [gnustep]: 2011-11-15 16:33:27.479 oolite[6052] src/Core/Entities/ShipEntity.m:9322 Assertion failed in ShipEntity(instance), method coordinatesForEscortPosition:. Invalid parameter not satisfying: idx < MAX_ESCORTS

16:33:27.480 [exception]: ***** Exception during [update:entity [<ShipEntity 0x19739700>{"Thargoid Thorgon Cruiser" position: (1.00399e+006, 1.00227e+006, 1.00169e+006) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSInternalInconsistencyException : src/Core/Entities/ShipEntity.m:9322 Assertion failed in ShipEntity(instance), method coordinatesForEscortPosition:. Invalid parameter not satisfying: idx < MAX_ESCORTS *****

Hope it helps.

[Kaks]

Looks like the Thargoid Thorgon Cruiser is trying to set too many escorts.

I haven't checked the coordinatesForEscortPosition: method, but it's likely it's a thargoid escort trying to attach itself to the Cruiser after the Cruiser itself has already got the maximum number of escorts (16 escorts max)

Will see if we can unbreak it!

Edit: do check the same situation with rev4649. It should now be ok.

[Eric Walch]

Just yesterday I noticed an oddity that could be related:

I had tharglets that would not die when mom was killed. Examining them, they showed to be in an interceptAI.plist. The only way they could get there, was when they were part of the escort group and mom issued a deployEscorts command. The puzzling thing for me was, how they could become part of an escort group.

One possible way: When mom has two other thargoids as escort, those escorts go into the escort group of mom. But, On the level of the escorts, their group is a main group. When those escorts launch tharglets, they go into the main group of the launching ship. For the escort that is the main group, but on the level of the mother ship that is an addition to the escort group and mom will see them as her escorts.

I have no idea how that happens with me as the only escorted thargoids have thargoid_terrorisers as escort and they don't launch tharglets, but I now see a way to add unwillingly to many escorts to mom. (Must look into this further, as this was just a first idea that just sprung into my mind)

[Kaks]

That could well be what caused fatleaf's too many escorts CTD... definitely worth investigating further!

[Eric Walch]

It is definitely a weak point. With the console it is very easy to take an escort of a ship and add it to the escortGroup of another ship. I just added an escort of a boa to the escort group of an anaconda. Now the escort was on the escort list of both mothers and both were updating the escort position. Funny, sometimes he obeyed one mother for a while, and than he obeyed the other mother for a while. In the meantime the escort had an 'interesting' flight pattern.

The anaconda had now 7 escorts. One more than the defined maximum. Its surprisingly easy to bypass the internal checks this way.

Just for fun, I gave a worm an escortGroup and added a patrolling police to that group. The worm now started to send escort positions to the police and the police started to fly to those positions. (This only worked because the police was in a performFlyToDestination behaviour). But because the police never did a "escortCheckMother" he was never expelled from the group.

There definitely must be a check added somewhere.

[Kaks]

Hmm, at least 2 checks, I reckon:
- is the ship already escorting someone else? 'Warning: ship XYZ cannot escort 2 different ships, was not added to escort group ZYX.'
- is the group a full escort group? 'Warning: mothership HJK can only accept a maximum of X escorts. Ship XYZ was not added to escort group ZYX'

Re-hmm, we do need to differentiate between generic (pirate, thargoid, police, oxp defined) and escort groups...

[Kaks]

Ok, we were already keeping tabs on which group was an escort group and which one wasn't. I think I got it sussed, but will do a bit more testing...

If everything goes ok, the fix should be in trunk later on this evening.

[Fatleaf]

Just for further info as to the conditions when the CTD occurred. I was fighting Thargoids in interstellar space. there were three or four warships a Thorgon Cruiser and a Terrorizer frigate. I destroyed the Terrorizer frigate and it was when I destroyed the last Warship did the crash happen.

[Eric Walch]

Ok, we were already keeping tabs on which group was an escort group and which one wasn't. I think I got it sussed, but will do a bit more testing...

Do we? In principe a JS script can make a copy of an "escortGroup" and rename it so the real origin can become obscure. For the mother the group becomes the escortGroup property but for escorts that group is assigned to the group property.

I was thinking in adding an extra property to the group object. That could either be
-A) a maxMembers property. By default undefined but set to 1 when creating an escort group and set to escort number by the escort related commands of a mother.
- B) a write permission flag. For escort groups, only leaders may add ships to such groups.

[Kaks]

As long as the group group stays associated to the mother - renamed or not - we can still figure out it's the escort group - at least inside obj c, where we need to generate the warnings!

It seems to be working ok so far. I'll commit my code soon, so you can test to see if I've missed some edge cases.

[Switeck]

is the group a full escort group? 'Warning: mothership HJK can only accept a maximum of X escorts. Ship XYZ was not added to escort group ZYX'

Does this also take into account the reduction of escorts in "safe" systems?

Also, because of the odd way Thargons are handled, do they have an upper limit for a single Thargoid? (My Switeck's Shipping OXP does weird things with them...)

[Kaks]

I should be back to the grind this evening, but I thought I'd commit what I've done so far - some stuff is handled much better, but there seems to be an exceedingly large amount of exceptions to take into account, and no doubt I've missed one or three.

Anywho, I had my share of extra dumbness - I did waste an hour or two without setting ship.escort = yes; inside logcontrol.plist, and I did have a bit of a funny turn just before committing, so there might well be some last minute breakages in that part of the code now.

Hopefully not for long: I should have enough free time this evening to catch up with all the loose ends.

OK, RL calls. See you later.

[Eric Walch]

I should be back to the grind this evening, but I thought I'd commit what I've done so far - some stuff is handled much better, but there seems to be an exceedingly large amount of exceptions to take into account, and no doubt I've missed one or three.

It fixed the abuse by JS methods. It still missed the one situation that started the problem. Firing missiles by an thargoid escorter. Back before 1.73, when the group class was added, all fired missiles went into the group of the firing ship. There I immediately noticed bugs with real missiles becoming part of the group. So I changed it that only missiles of thargoid class (= tharglets) are added to the group.

This also needs an exeption when fired by escorts. I just created an escorted thargoid and let one of the escorts fire a big amount of missiles. The group size went up to 22 and when looking in the log, I got masses of:

Code: Select all

[system] *** Assertion failure in -[ShipEntity coordinatesForEscortPosition:], /Users/ericwalch/Oolite/trunk/src/Core/Entities/ShipEntity.m:9381
[exception] Universe.m:5279: ***** Exception during [update:entity [<ShipEntity 0x121e31200>{"Thargoid Warship" position: (-22377.3, 65657.5, 273086) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSInternalInconsistencyException : Invalid parameter not satisfying: idx < MAX_ESCORTS *****

At least it does no longer crash things. I think this is the second-last occasion were things can go wrong. The last thing would be when the escort would also contain a "thargoid-mother" role. In that case, thargoids that loose their mother could take such a thargoid as mother and add themself to the group.
(That was why I thought at a new group property to fix this at a low level and ignore all the different reasons why ships could add to groups).

[Kaks]

Meh, I knew I'd forgotten something!

Them thargoids should be fixed in rev4654, and the current nightly.

More tests on .group.addShip() to follow, though.

[Eric Walch]

Meh, I knew I'd forgotten something!

Them thargoids should be fixed in rev4654, and the current nightly.

More tests on .group.addShip() to follow, though.

I have also been busy. One thing was creating the CrashingThargoids.oxp that magnifies what probably happened with Fatleave. (I even fixed the problem locally but will compare my changes with yours. (Who are probably much better )

NB only a testing oxp that tries to break things with the old builds.