Weird spinning behavior of a station and fuel station.

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

User avatar
maaarcooose
---- E L I T E ----
---- E L I T E ----
Posts: 394
Joined: Sun May 29, 2011 9:36 pm
Location: Devon, UK
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by maaarcooose » Sun Mar 17, 2013 8:19 pm

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

Image

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!
Trading computers and writing stuff....
Website: http://www.theramist.co.uk/
OOliteInfo: http://www.theramist.co.uk/ooliteinfo/oo.php

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Weird spinning behavior of a station and fuel station.

Post by cim » Sun Mar 17, 2013 8:25 pm

maaarcooose wrote: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)

User avatar
maaarcooose
---- E L I T E ----
---- E L I T E ----
Posts: 394
Joined: Sun May 29, 2011 9:36 pm
Location: Devon, UK
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by maaarcooose » Sun Mar 17, 2013 9:09 pm

> 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!
Trading computers and writing stuff....
Website: http://www.theramist.co.uk/
OOliteInfo: http://www.theramist.co.uk/ooliteinfo/oo.php

User avatar
maaarcooose
---- E L I T E ----
---- E L I T E ----
Posts: 394
Joined: Sun May 29, 2011 9:36 pm
Location: Devon, UK
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by maaarcooose » Sun Mar 17, 2013 9:16 pm

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!
Trading computers and writing stuff....
Website: http://www.theramist.co.uk/
OOliteInfo: http://www.theramist.co.uk/ooliteinfo/oo.php

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Weird spinning behavior of a station and fuel station.

Post by cim » Sun Mar 17, 2013 9:21 pm

Thanks
maaarcooose wrote: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.

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Weird spinning behavior of a station and fuel station.

Post by cim » Mon Mar 18, 2013 10:29 pm

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.

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by Commander McLane » Tue Apr 02, 2013 8:20 pm

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:
Image

The target inspector shows nothing unusual:
Image
(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:
Image
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.

:idea: 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.

User avatar
maaarcooose
---- E L I T E ----
---- E L I T E ----
Posts: 394
Joined: Sun May 29, 2011 9:36 pm
Location: Devon, UK
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by maaarcooose » Thu Apr 04, 2013 8:59 am

cim wrote: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!
Trading computers and writing stuff....
Website: http://www.theramist.co.uk/
OOliteInfo: http://www.theramist.co.uk/ooliteinfo/oo.php

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Weird spinning behavior of a station and fuel station.

Post by cim » Thu Oct 10, 2013 9:02 pm

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?

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by Commander McLane » Fri Oct 11, 2013 10:02 am

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.

User avatar
Mad Dan Eccles
Deadly
Deadly
Posts: 193
Joined: Tue Sep 07, 2004 8:54 pm
Location: The Greatest City in the Ooniverse
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by Mad Dan Eccles » Fri Oct 11, 2013 10:30 am

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...
Master of Mayhem

"The name's derived from Object Oriented eLite so you could say "Oh! Oh! Leet!", but that might sound too much like g33k sex."

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Re: Weird spinning behavior of a station and fuel station.

Post by Eric Walch » Sat Oct 12, 2013 7:51 am

Commander McLane wrote: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.

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Weird spinning behavior of a station and fuel station.

Post by Commander McLane » Sat Oct 12, 2013 8:10 am

Eric Walch wrote: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! :D

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! :D

LRGH
Poor
Poor
Posts: 4
Joined: Sun May 18, 2014 5:28 pm

Re: Weird spinning behavior of a station and fuel station.

Post by LRGH » Sun May 18, 2014 5:29 pm

cim wrote: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.

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Weird spinning behavior of a station and fuel station.

Post by cim » Sun May 18, 2014 10:03 pm

Thanks. Would you be able to try out the Mac nightly build - http://aegidian.org/bb/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?

Post Reply