Weird spinning behavior of a station and fuel station.

[maaarcooose]

Hmm think I've just provoked another incident of the subentities going weird.



I'll keep it paused, just tell me what commands you'd like me to run in the debug console and I'll give you the results.

!m!

[cim]

I'll keep it paused, just tell me what commands you'd like me to run in the debug console and I'll give you the results.

Commands and expected values below

PS.target.subEntities

Code: Select all

[[Ship "Anaconda" position: (0, 0, 0) (subentity)], [Ship "Anaconda" position: (0, -4.6514, 73.9893) (subentity)]]

PS.target.subEntities[0].orientation
PS.target.subEntities[1].orientation

Code: Select all

(1 + 0i + 0j + 0k)

[maaarcooose]

> PS.target.subEntities
[[Ship "Anaconda" position: (0, 0, 0) (subentity)], [Ship "Anaconda" position: (0, -4.6514, 73.9893) (subentity)]]

> PS.target.subEntities[0].orientation
(0.947285 - 0.245128i - 0.158779j + 0.131728k)

> PS.target.subEntities[1].orientation
(0.947285 - 0.245128i - 0.158779j + 0.131728k)


Anything else?

!m!

[maaarcooose]

Just for some background.

This is after jumping, then following a trader through it's wormhole.
His engine then suffered a provoked fatal explosion, followed by me taking on around 5 pirates. I splashed them all, got their cargo and then flew in system. This is where I encountered the weird Anaconda.

!m!

[cim]

Thanks

Anything else?

I can't think of any other useful information that the console would provide. The values are wrong (though normalised), the change to them appears to have been a one-off event that's already happened, but it does rule out the oddity being a display problem.

It looks like there's a serious (but occasional) buffer overrun somewhere, and either it's not there on Windows/Linux, or the memory layout is different so it isn't overwriting anything important there.

[cim]

Well, I had a look on Linux with valgrind. Mainly what I discovered is that the dependency libraries are not that tightly written, though mostly harmlessly, and that my computer isn't powerful enough to run Oolite under valgrind very well. Still, I found a couple of strange cases, none of which had anything to do with this.

Maybe someone with a Mac could try it (or I think Xcode has a similar runtime memory debugger). Catch is that it makes the game ridiculously slow so waiting for this bug to appear might take days. On the other hand the underlying problem might be obvious sooner than that from the error reports.

[Commander McLane]

Another instant of dislocated subentities: This DW-Cobra was in the middle of a fight with a SuperCobra. I was just closing in and concentrating on the SuperCobra when something caught my eye about its victim. So I closed in and discovered this:


The target inspector shows nothing unusual:

(except that the brave DW-Cobra was actually the attacker, not the attacked).

It gets interesting in the console:

Code: Select all

> PS.target.subEntities
[[Ship "booster" position: (15, 0, 0) (subentity)], [Ship "booster" position: (-15, 0, 0) (subentity)], [Ship "booster guard" position: (0, 0, 0) (subentity)], [Ship "right vent" position: (0, 0, 0) (subentity)], [Ship "left vent" position: (0, 0, 0) (subentity)], [Ship "sensor" position: (-8, 0, 0) (subentity)], [Ship "sensor" position: (8, 0, 0) (subentity)], [Ship "sensor" position: (-10, 0, 0) (subentity)], [Ship "sensor" position: (10, 0, 0) (subentity)], [Ship "left landing gear" position: (0, 0, 0) (subentity)], [Ship "right landing gear" position: (0, 0, 0) (subentity)], [Ship "front landing gear" position: (0, 0, 0) (subentity)], [Ship "landing flat" position: (0, 0, 0) (subentity)], [Ship "landing flat" position: (0, 0, 0) (subentity)], [Ship "landing flap" position: (0, 0, 0) (subentity)], [Ship "antenna" position: (-50, 0, 0) (subentity)], [Ship "antenna" position: (50, 0, 0) (subentity)], [Ship "antenna" position: (0, 0, 0) (subentity)], [Ship "cockpit" position: (0, 0, 0) (subentity)], [Ship "small booster" position: (-38.6, 0, 0) (subentity)], [Ship "small booster" position: (38.6, 0, 0) (subentity)]]

All subentities appear to be correctly positioned, but:

Code: Select all

> PS.target.orientation
(0.16688 + 0.790491i + 0.588927j - 0.0209761k)
> PS.target.subEntities[0].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[1].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[2].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[3].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[4].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[5].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[6].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[7].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[8].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[9].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[10].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[11].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[12].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[13].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[14].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[15].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[16].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[17].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[18].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[19].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[20].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)

So again, the problem is the misaligned orientation.

Now I removed the hostile ships and switched the DW-Cobra to dumbAI, it starts spinning and offers me a good look from every angle.

Now I try to re-orientate the subentities according to the main entity's orientation, and this is where it gets really weird:

Code: Select all

> PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[0].orientation
(-0.0214874 + 0.927808i + 0.272647j + 0.253721k)
> PS.target.subEntities[0].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[0].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[1].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[2].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[3].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[4].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[5].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[6].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[7].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[8].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[9].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[10].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[11].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[12].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[13].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[14].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[15].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[16].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[17].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[18].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[19].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[20].orientation=PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)

Everything should be aligned correctly now, but here's what it looks like:

The result is worse, not better. Note how the subentities are no longer at least aligned with each other. There are several distinct groups with different orientations. Although on paper:

Code: Select all

> PS.target.orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[0].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[1].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[2].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[3].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[4].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[5].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[6].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[7].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[8].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[9].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[10].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[11].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[12].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[13].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[14].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[15].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[16].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[17].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[18].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[19].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
> PS.target.subEntities[20].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)

This is all while paused. Now I unpause briefly and pause again:

Code: Select all

> PS.target.orientation
(0.805943 - 0.463431i - 0.0575594j - 0.363832k)
> PS.target.subEntities[0].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)
...

Interesting. Again unpause and pause:

Code: Select all

> PS.target.orientation
(0.944846 - 0.0992824i + 0.0661629j - 0.305009k)
> PS.target.subEntities[0].orientation
(0.51807 + 0.804546i + 0.284204j + 0.0594676k)

The subentities do rotate with the ship in front of my eyes. But their orientation as exposed to JS doesn't change at all.

Only now I understand: their orientation is relative to the main entity (just like their position). So:

Code: Select all

> PS.target.subEntities[0].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[1].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[2].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[3].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[4].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[5].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[6].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[7].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[8].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[9].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[10].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[11].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[12].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[13].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[14].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[15].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[16].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[17].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[18].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[19].orientation=[1,0,0,0]
[1, 0, 0, 0]
> PS.target.subEntities[20].orientation=[1,0,0,0]
[1, 0, 0, 0]

And everything is back to normal.

So the problem is that they somehow got another orientation than [1,0,0,0] in the first place, with the additional problem that the same misorientation on paper did not mean the same misorientation as viewed in the game, while the correct orientation on paper translates to the correct and same orientation for all subentities.

EDIT: a couple of minutes later I come across a Griff BCC with a misaligned exhaust:

Code: Select all

> PS.target.subEntities
[[Ship "Boa Class Cruiser" position: (0, 0, 0) (subentity)]]
> PS.target.subEntities[0].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)

The exact same values as initially for the DW-Cobra.

And again the same for an Inter-system ferry:

Code: Select all

> PS.target.subEntities
[[Ship "?" position: (-13.5, 7.2, -64.5) (subentity)], [Ship "?" position: (13.5, 7.2, -64.5) (subentity)]]
> PS.target.subEntities[0].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[1].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)

In this case I try removing and restoring the subentities. The newly spawned subentities are correctly oriented.

An Iguana:

Code: Select all

> PS.target.subEntities
[[Ship "Iguana spike" position: (0, 0, 0) (subentity)], [Ship "Iguana spike" position: (0, 0, 0) (subentity)]]
> PS.target.subEntities[0].orientation
(0.978792 - 0.168456i - 0.113129j + 0.0281087k)
> PS.target.subEntities[1].orientation
(-0.0281087 - 0.113129i + 0.168456j + 0.978792k)

Interesting. This time it's a permutation. Same numbers, other places. (That's just because the correct positions are 1 0 0 0 and 0 0 0 1.)

And finally, I also found a Kiota Station with its subentities misoriented all by the same amount. It also went undead when I put it out of its misery.

[maaarcooose]

Well, I had a look on Linux with valgrind. Mainly what I discovered is that the dependency libraries are not that tightly written, though mostly harmlessly, and that my computer isn't powerful enough to run Oolite under valgrind very well. Still, I found a couple of strange cases, none of which had anything to do with this.

Maybe someone with a Mac could try it (or I think Xcode has a similar runtime memory debugger). Catch is that it makes the game ridiculously slow so waiting for this bug to appear might take days. On the other hand the underlying problem might be obvious sooner than that from the error reports.

I'll have a go at setting up OOlite to run on my mac in xcode and leave it running that way.
I'll probably need a lot of handholding when I actually provoke the error though. I'll have a good read of the compiling thread.


!m!

[cim]

Question: have any of our Mac users noticed this continue to happen with the 1.77.1 release? We did fix a couple of memory-related bugs since 1.77, so I'm hoping it's been dealt with (and/or our other theory, that it has been fixed by upgrading the compiler). Or is this still there, now and then?

[Commander McLane]

I haven't come across the issue again, but I also didn't specifically check for it.

After your reminder I'll try to keep my eyes open when I meet a ship with many subentities.

[Mad Dan Eccles]

um, haven't played for a while but think it's still there. Doesn't bother me so much as I've got docking computers now...

[Eric Walch]

The target inspector shows nothing unusual:

Off-topic:
To get a nice screen shot from a single window on the mac, you don't cut out a part of a bigger screen, but:
- type: cmd-shift-4 (the cursor changes to cut out a part of the screen)
- than hit spacebar (the cursor turns into a camera symbol)
- Now click on any window.

This way you get a screenshot of that window with a nice shaded and partly transparent border around it.

[Commander McLane]

To get a nice screen shot from a single window on the mac, you don't cut out a part of a bigger screen, but:
- type: cmd-shift-4 (the cursor changes to cut out a part of the screen)
- than hit spacebar (the cursor turns into a camera symbol)
- Now click on any window.

This way you get a screenshot of that window with a nice shaded and partly transparent border around it.

Sweet!

I was using the "Screen Shot" application, and the "capture window" function inside that (with the "hide cursor") option activated. So it wasn't a cropped shot of the complete screen. But that function doesn't produce a border around the shot. And the short cut is of course also faster than browsing to the application and opening it.

Thanks!

[LRGH]

Question: have any of our Mac users noticed this continue to happen with the 1.77.1 release? We did fix a couple of memory-related bugs since 1.77, so I'm hoping it's been dealt with (and/or our other theory, that it has been fixed by upgrading the compiler). Or is this still there, now and then?

I currently have this issue with 1.77.1
No OXP installed.

[cim]

Thanks. Would you be able to try out the Mac nightly build - https://bb.oolite.space/viewtopic.php?f=10&t=7648 - and confirm that the bug is still there, please? (Back up your save games before running a nightly build, as 1.77.1 might not open a game saved on the nightly build correctly)

Assuming it hasn't disappeared in the current code as mysteriously as it arrived, I think we'll need someone with a Mac, a compiler and a fair bit of patience to do a 'git bisect' between commits 0078af5183 (last one of 1.77) and e7076105a3 (first one after 1.76) to try to figure out where the problem was first introduced. (That's fewer than 1024 commits, so it should narrow down on the one which introduced the bug in 10 build/test cycles) Any volunteers?