Trunk: Sub Entites of Sub Entities are not drawing,

[Thargoid]

I sincerely hope not, considering the complexity of the collision code, ...It's likely to be something as simple as the collision boxes of subentities not being properly oriented, rather than them being to big.

Could be. I know the GRS station has two external docking structures defined. One not rotated and the other 90 degree rotated. When going into bounding box display mode one has the right size and the other is much larger drawn.

And for other ships: turrets are mostly added in all kind of orientations, while most other subs are attached not rotated. So maybe it looked like a turret problem while it was in fact a rotation problem.

A test there could be to check the bounding boxes of a HammerHead when loaded and unloaded, plus one of its cargo sleds in free-flight. The loaded sleds are rotated sub-ents, and given the size of the overall structure it should be very obvious if you're onto something with the rotation idea.

[Frame]

an even simpler test in regard to the rotation aspect is to view the Coriolis station in debug mode... launch at lave and activate the debug mode..

I always wondered why only the bounding box for one of the arc details shows the bounding box...

Now I Know, when the arc details are rotated, its bounding box is not being rotated likewise.

This is interesting but when I look closer I can see the octree collision bricks being properly drawn, at the correct places... However I presume correct placement of bounding boxes is crucial for the correct working of the collision code as the way most collision code works is to first check if the bounding box has been intersected.

if I look at the docking port of the Coriolis station, I can see its bounding box is not only not correctly rotated, it is also not, correctly positioned.. its in the Center of the Coriolis station when in fact it has been moved about 500 units in the up/z direction.

If I move an subentity via the debug console and ship.subentity[#n].position = ([x,y,z]), I also know for a fact that its bounding box does not follow, but not so, the octtree collision "bricks" too.

As if the collision data is not recalculated after being rotated, which makes sense for when you do dynamic moves, but not when you do static moves, while of course the static moves only has a fault in regard to bounding boxes of sub entities

[Eric Walch]

A test there could be to check the bounding boxes of a HammerHead when loaded and unloaded, plus one of its cargo sleds in free-flight. The loaded sleds are rotated sub-ents, and given the size of the overall structure it should be very obvious if you're onto something with the rotation idea.

An other test could be to remove the rotation part of the turret placement for the problem ships, instead of removing them all. It will probably look bad but if this improves collision, you have a clue to proceed in bug-hunting.

[Thargoid]

@Frame - we may be testing two slightly different things there between your test and mine (and Eric's too).

To my understanding the issue is not sub-entities of a rotating entity (such as the Corliolis) but subentities that are themselves rotated in respect to their mother entity (ie have their z-axis re-oriented and pointing in a different direction from their mother's) such as turrets usually are to make them point in the right direction.

Not to say your observations aren't also relevant and valid inputs to the problem, but just to be clear exactly what is under test in the proposal.

[Eric Walch]

Has anybody checked to see what happens when an AI ship with turrets goes through, say, a Fuel Station? While they don't normally do that, I'm sure that they could be forced to for testing purposes.

You must be writing special code to let ships do that.

Does it also happen with racing rings? In that case there is an easy test for this. Inside oolite itself there is a special AI that lets NPC ships race the rings: "fttAI.plist"

- Install a version of ringpod
- Spawn your testing ship with a "fttAI.plist" AI.

It will start racing the pods.

When you have installed version 1.1.1 of my JS translation of this oxp you will notice that also some traders and police ships will try to run the course.

[Thargoid]

With a bit of tweaking you could also use that AI to make them use a fuel station (or at least fly through one) as it uses much the same concept as the rings.

[Eric Walch]

With a bit of tweaking you could also use that AI to make them use a fuel station (or at least fly through one) as it uses much the same concept as the rings.

By changing the AI a bit ("targetFirstBeaconWithCode: f") or by giving the fuelstation the same beacon code of the first ring (= "1-TRB")

The AI uses the undocumented commands: "targetFirstBeaconWithCode: tr", "targetNextBeaconWithCode: tr", setRacepointsFromTarget and performFlyRacepoints.

Looking at the AI these commands explain themselves.

EDIT: I just documented those commands on the wiki-AI page.

[JensAyton]

This is interesting but when I look closer I can see the octree collision bricks being properly drawn, at the correct places... However I presume correct placement of bounding boxes is crucial for the correct working of the collision code as the way most collision code works is to first check if the bounding box has been intersected.

As has been mentioned before, the bounding boxes are not used in collision detection. Still, that’s an interesting regression (although I’m pretty sure that when the subentity problem manifested the bounding boxes were drawn in the right place).

[Eric Walch]

I just tested it by downloading the latest version of caduceus.oxp, giving the ship the following AI:

Code: Select all

{
    GLOBAL = {
        ENTER = (
			"setSpeedFactorTo: 0.5",
			"targetFirstBeaconWithCode: fuel"
		);
	"TARGET_FOUND" = (
			setDestinationToTarget,
			"setSpeedFactorTo: 1.0",
			"setDesiredRangeTo: 5000",
			performFlyToRangeFromDestination
		);
	"DESIRED_RANGE_ACHIEVED" = (
			"setStateTo: PASS_THRU_RING"
		);
	"NOTHING_FOUND" = (exitAI);
    }; 
    "PASS_THRU_RING" = {
        ENTER = (
			"setSpeedTo: 225",
			setRacepointsFromTarget,
			performFlyRacepoints
		);
        "ENDPOINT_REACHED" = (
			"setStateTo: NEXT_RING"
		);
    }; 
    "NEXT_RING" = {
        ENTER = (
			"setSpeedFactorTo: 0.0",
			"targetNextBeaconWithCode: fuel"
		);
	"TARGET_FOUND" = (
			"setStateTo: PASS_THRU_RING"
		);
	"LAST_BEACON" = (exitAI);
    }; 
}

and spawning near a fuelstation. It flew the NPC version of the caduceus through the fuelstation without any problems and repeated it several times without crashes.
So it looks like the problem is player only. I just cant imagine that collision works different for player of NPC. (or is it the -w component?)

EDIT:
Now I took the player ship and crashed while flying through. Last test was remove the orientation of all 6 turrets. The turrets itself stayed on the ship. With this ship I could fly through without problems. So the problem is very likely in the subentity orientation for a player-ship and not in turrets itself.

[Screet]

Now I took the player ship and crashed while flying through. Last test was remove the orientation of all 6 turrets. The turrets itself stayed on the ship. With this ship I could fly through without problems. So the problem is very likely in the subentity orientation for a player-ship and not in turrets itself.

Please test with a neocaduceus - that one also has problems with turrets disabled, for as long as other subentities are still existent. The old caduceus does only have turret subentities.

Screet

[Eric Walch]

Please test with a neocaduceus - that one also has problems with turrets disabled, for as long as other subentities are still existent. The old caduceus does only have turret subentities.

It also works with that ship. I changed the subentities to:

Code: Select all

		<key>subentities</key>
		<array>
			<string>cenginea -4.5 -0.5 -60.5 1 0 0 0</string>
			<string>cengineb 4.5 -0.5 -60.7 1 0 0 0</string>
			<string>cmount 0.0 -2.6 26.0 1 0 0 0</string>
			<string>cmount 0.0 -2.6 13.0 1 0 0 0</string>
			<string>cmount 0.0 -2.6 0.0 1 0 0 0</string>
			<string>caduceusturret 8.0 -2.7 26.0 1 0 0 0</string>
			<string>caduceusturret 8.0 -2.7 13.0 1 0 0 0</string>
			<string>caduceusturret 8.0 -2.7 0.0 1 0 0 0</string>
			<string>caduceusturret -8.0 -2.7 26.0 1 0 0 0</string>
			<string>caduceusturret -8.0 -2.7 13.0 1 0 0 0</string>
			<string>caduceusturret -8.0 -2.7 0.0 1 0 0 0</string>
		</array>

Take note that two non-turret entities had a complete wrong quaternion defined. The last 4 numbers of a subentity describe the orientation. The addition of the square of all individual numbers should always be "1". If not the system is normalising it for you on loading. But two had a value of 0 0 0 0. A bit of undefined quaternion as this can't be normalised. Should probably be 1 0 0 0. Anyhow it still crashed with the 0 0 0 0 values and not anymore with the 1 0 0 0 value. All turrets and subs present!

[Screet]

Take note that two non-turret entities had a complete wrong quaternion defined. The last 4 numbers of a subentity describe the orientation. The addition of the square of all individual numbers should always be "1". If not the system is normalising it for you on loading. But two had a value of 0 0 0 0. A bit of undefined quaternion as this can't be normalised. Should probably be 1 0 0 0. Anyhow it still crashed with the 0 0 0 0 values and not anymore with the 1 0 0 0 value. All turrets and subs present!

Argh...the turrets did look OK to me before. Now they don't...and I gave it a try: Yes, the fuel stations work, but the turrets all shoot now to the front of the ship, thus anything approaching it is being shot down instantly by a massive amount of plasma. Interestingly they have a much better aiming chance now. It was like acquiring a target and losing it a second later to a big explosion.

I tried to read up on german wikipedia about these things, but math just isn't my language

So...please, how to properly fix
a) the neocaduceus to keep proper turret orientation without causing crashes
b) oolite to report quarternion errors in the log so that oxp authors will notice when they do something wrong

and possibly also c) fix oolite to not cause crashes in such circumstances?

Screet

[Eric Walch]

Argh...the turrets did look OK to me before. Now they don't...and I gave it a try: Yes, the fuel stations work, but the turrets all shoot now to the front of the ship,

I never said it improves orientation of subentities. (They even should look wrong by definition now) Above changes only show that it is the orientation of subs that leads to crashes and not the presence itself.
And letting a problem ship flying through the fuel station as NPC ship does not lead to crashes. So the problem must be in something that is different for the player ship and a npc ship. The only thing that springs in my mind is the w-component of the quaternion. That is inverted for the player.

So I dare to bet that the bug is in a not inverted w-component for the player during collision test leading to calculate with wrong values for rotated player subs.

Finding the bug itself is an other story as the collision detection is quite complex. But at least will this narrow down the search.

[Commander McLane]

@ a_c and DH: Thanks for the nice welcome back!

Although for the time being I can't promise any continuous presence. RealLife™ taking its toll.

And I hadn't even posted here, if I hadn't in a rare free minute asked myself "what are he guys doing" and made a quick jump to the board, where I for some reason ended up in this thread and thought "hey, I can say something short and helpful here".

Anyway, for all of you who have missed me: I am still alive and kicking, although a little on the busy side right now.