Trunk nightly

[cim]

...that would be because I changed the default keyconfig to check that the numpad bugfix was working, and forgot to change it back again. Oops.

[Cody]

<chuckles> It was sheer force of habit that made me update trunk and launch it this morning. I was intending to take a break from test-flying trunk, and simply fly the 1.80 deployment build for a while. I blame Getafix and his oh-so-simple-to-use Windows Oolite nightly updater.

[Diziet Sma]

Beats the hell out of the old "Dizzy's Nightly Builds" days, eh?

[Cody]

Ha! Your name does appear in the credits at the start of the updater thingy, Diz - never forgotten!

[Diziet Sma]

If the "required_oolite_version" of the OXZ in the manifest.plist is 1.81, then 1.80 won't try to load it. There is also "maximum_oolite_version" for reversed checks, though that's perhaps less necessary.

Could 1.81 now be added to the drop-down menu of the manifest.plist generator at oolite.org, please? This would simplify creating new trunk-only manifests..

[Diziet Sma]

Could 1.81 now be added to the drop-down menu of the manifest.plist generator at oolite.org, please? This would simplify creating new trunk-only manifests..

Thanks for doing this..

[Cody]

This popped up while running the V-Sync test .exe with the latest trunk nightly:

Code: Select all

01:31:08.502 [script.javaScript.unrootedTimer]: ----- WARNING: Timer <OOJSTimer 0x11aacd70>{nextTime: 586.937, one-shot, running, function: anonymous} is being garbage-collected while still running. You must keep a reference to all running timers, or they will stop unpredictably!

[Cody]

Another one:

Code: Select all

18:19:43.417 [script.javaScript.unrootedTimer]: ----- WARNING: Timer <OOJSTimer 0x33ece240>{nextTime: 115.792, one-shot, running, function: anonymous} is being garbage-collected while still running. You must keep a reference to all running timers, or they will stop unpredictably!

[cim]

Fixed if it was what I think it is, but it's hard to tell with those errors.

[Cody]

Launching from a planet-facing rock hermit in the Veed system, the planet (Povray) was unlit for 2-3 seconds before its texture appeared.

[Tricky]

Launching from a planet-facing rock hermit in the Veed system, the planet (Povray) was unlit for 2-3 seconds before its texture appeared.

Not sure if it the same bug, when a ship is launching it isn't fully lit until it has left the dock.

[Tricky]

Fixed if it was what I think it is, but it's hard to tell with those errors.

Is it possible to expand on the error message so that there is more of a clue as to the cause?

[cim]

Is it possible to expand on the error message so that there is more of a clue as to the cause?

Not as far as I can tell - the function: anonymous would probably give a decent indication if it hadn't been an anonymous function, and the message only appears once the thing it was attached to is no longer usable.

In practice it'll almost always be a timer attached to a ship script, which is usually easy enough to find.

[JensAyton]

This is why a lot of functions in built-in scripts are named even though they’re never called by name. :-)

[Cody]

Would asking for docking clearance, being told to wait, cancelling then asking again confuse station control? The one at Veed seemed to be all over the place, at first saying I was #2, then #4, then #9 (with simple 'wait' messages in between) - but only one ship eventually launched, and only two other ships were in the aegis.