Oolite Bulletins

No, that's not what I meant. Sorry, I haven't been clear...

The first line should change from *2 to *8. The second one remains at *3.
Min torus speed has gone from *32 to * 256, so min decelleration needs to increase by the same factor i.e. *8.

Yes, Aegis appears a little smaller. When I shrunk scanner by a third it was smaller again. There's probably a way around this but it's not a major issue IMO.

Re pirates: were you still mass-locked with them off scanner? If so, that is not desired behaviour. Otherwise, yes, I think that's the missiles.

Redspear wrote:

No, that's not what I meant. Sorry, I haven't been clear...

The first line should change from *2 to *8. The second one remains at *3.
Min torus speed has gone from *32 to * 256, so min decelleration needs to increase by the same factor i.e. *8.

Ok.. well, it seems ok, if barely, at 2 and 4 respectively.. maybe some more testing is called for.

Redspear wrote:

Re pirates: were you still mass-locked with them off scanner? If so, that is not desired behaviour. Otherwise, yes, I think that's the missiles.

No.. I wasn't mass-locked.. just surprised that when they were off-scanner, I was still at condition red.

Thanks for the enthusiastic (and seemingly rigorous) testing Dizzy

Redspear wrote:

seemingly rigorous testing

Flying around playing the game counts as rigorous testing? Kewl!

Actually, I should thank you for getting me back to playing Oolite.. I haven't hardly touched it for a couple of months..

Ok.. now for some rigorous testing..

To explore the effects of changes to the Torus Drive deceleration, I've compiled 5 otherwise identical executables, with slightly different deceleration settings, and uploaded them to my box.com account in order that others can test them as well. Note that these are for Windows 64-bit, only. I am hoping to be able to build some for Linux as well later, but the build environment is somewhat more complex to set up, if they are to be able to run on any Linux computer, rather than just my own.

The baseline executable is the one I compiled yesterday new, with multiplier settings of 2 and 4 4 and 4 respectively. Preliminary testing shows this one will slow down at just barely safe distances from planets, and seems to pull up rapidly enough, at least most of the time, when ships are encountered..

The others leave the "4" setting alone, but use multipliers of 6, 8, 12 and 16 for the first value.


The test regime is as follows:

For each executable, on arrival at the witchpoint beacon, aim directly at the center of the planet, and Torus all the way, checking to see at what altitude above the planet the ship pulls up. En-route, note if any masslocks fail or succeed in stopping the ship before the masslocking ships/objects disappear from the scanner. If successful, of interest is whether the ship pulls up when the objects are ahead, to the side, or to the rear of the ship.

Next, Torus to the center of the local star, to check the altitude at which the ship pulls up above the star. Again, note any masslocks that occur en-route.

Repeat each test at at least 3 different systems before proceeding to the next executable.


To use the supplied executables, as another_commander mentions above, you will need to have Oolite Trunk installed alongside your normal Oolite install, and it must be updated to the current version. If you don't already have it installed, you can obtain the current nightly build here. Make a copy of the existing oolite.exe file, and save it somewhere, so you can put it back later, if desired. Then replace it with each of the testing executables in turn. For the purposes of the test, I highly recommend that you use the NumericHUD, as the altitude gauge is the most precise of any HUD, reading down to 1% of Planetary Radius (the PPR gauge on the HUD), enabling accurate comparisons to be made between the executables. Also recommended is Norby's LogEvents OXP.

Please remember that at the current state of Oolite Trunk, any game-save you use for testing will not load correctly under Oolite 1.80. If you wish to use your current Commander rather than starting a new test-Commander, be sure to use a renamed copy. If you start a new Commander, you may want to hack the save file to provide sufficient credits for whatever equipment you prefer to use during the test.. at minimum you will probably want injectors, so as not to be constantly sidetracked by pirates and masslocks.

The zipped set of four five executables (28Mb) can be downloaded here:
https://app.box.com/s/c51o4xvtg1hoecy55qri

Edit: Don't bother with the "2 and 4" build. This one just doesn't cut it. See below for details.

Edit2: The "2 and 4" build has been removed, and "12 and 4" and "16 and 4" builds added instead, all recompiled using make debug=yes. Download link remains the same.

Diziet Sma wrote:

Ok.. now for some rigorous testing.. [snip]

You have been a busy Dizzy! I'm far too busy with other stuff, which is probably just as well - that lot would confuse me no end!
I once had four different executables sitting in one build - that became confusing, right enough!

Diziet Sma wrote:

Ok.. now for some rigorous testing..

To explore the effects of changes to the Torus Drive deceleration, I've compiled 4 otherwise identical executables, with slightly different deceleration settings, and uploaded them to my box.com account in order that others can test them as well. Note that these are for Windows 64-bit, only. I am hoping to be able to build some for Linux as well later, but the build environment is somewhat more complex to set up, if they are to be able to run on any Linux computer, rather than just my own.

Dizzy... How awesome are you?
Thank you once again

...And watch out for asteroid fields too; some of those settings will make them more hazardous should you try to stop rather than avoid.

What really needs this level of testing is sun-skimming. I spent more time testing that than anything else and I'm almost certain that it could be made better...

I'd like to post a list of recommended oxps that help to take advantage of the new (larger) environment and some to take care with too. This is a non exhaustive list (and may be added to) but has helped me to enjoy the rescaling more.
A testing environment is perhaps not suited to a great many oxps but...

For pure fun:

• Additional Planets
  Not just because I was involved but because spara encoded BIG gas giants in there. Download a texture pack with gas giants and check 'em out
  Recommended with the smaller moons tweak explained here.
• System Features: Rings
  Thanks to the changes, the rings should now be visible from much, much further away than before.
  I recommend DGill's tweak here (or else every main planet will have rings).
• Stations for Extra Planets
  Go explore!
• Planetfall
  Not tested this much but the approach to the surface should be more impressive now (if taking longer).
• Distant Suns
  It's space, it's big, why not? Also helps to make systems look more variable.

Proceed with caution:

• Breakable Torus Drive
  Unless you've got hours to spare just drifting through space...
• Ships and Shipsets
  Unless they've been rescaled, they might look a little odd, size-wise.
• Weapons
  Ranges will likely be three times further than intended. This may not be desirable.

Edit: added distant Suns to the list.

Test Report #1

My earlier more-or-less successful testing with the "2 and 4" build was done with an Adder. This time, I determined to test with a Cobra MkIII and an Anaconda as well.. starting with the Cobby. Things definitely did not go as expected.

Test #1
Jumped to Tionisla. Had 9 encounters with other ships whilst inbound. Wide spread of stopping positions, mostly depending on how far to port/starboard from the center-line they were positioned, which is to be expected. Overall, not too bad.

Arrived Tionisla on Torus. Only saved by quick reactions. Came to a full halt at just 1% of PPR.

Torus to star: halfway there, I was suddenly at Red Alert. Nothing seen on scanner, and was still moving at Torus speeds. 5 seconds later, whilst I was still wondering just what the hell had happened, shields began dropping steadily, still on Torus, and 15 seconds later the ship underwent Total Existence Failure.

Conclusion: "2 and 4" just doesn't cut it. Further testing of this build abandoned. No idea what destroyed the ship, logs are empty. Considering enabling full logging via the special logging OXP*, when I can find where I put it. Also should build debug versions, rather than standard builds, in future.

*Edit: I think I must have accidentally deleted it, but some searching turned up that it was Norby's LogEvents OXP that I was after. Other testers might find it handy to have as well..

Following the less than satisfactory events described above, I've dumped the "2 and 4" executable, recompiled the rest using make debug=yes, and added similar executables for "12 and 4" and "16 and 4".

Download link for the 5 new versions is the same as above.

Now I'm off to attempt to re-create the spontaneous self-destruct event using a debug version of "2 and 4", along with Norby's LogEvents OXP, to see if I can discover what went wrong.

Diziet Sma wrote:

Torus to star: halfway there, I was suddenly at Red Alert. Nothing seen on scanner, and was still moving at Torus speeds. 5 seconds later, whilst I was still wondering just what the hell had happened, shields began dropping steadily, still on Torus, and 15 seconds later the ship underwent Total Existence Failure.

That sounds like you hit an atmosphere at high speed and your ship overheated. At those speeds it wouldn't need to be a visibly detectable atmosphere, but the ALT and CT should have read something... not to mention planets tending to be quite visible things.

cim wrote:

Diziet Sma wrote:

Torus to star: halfway there, I was suddenly at Red Alert. Nothing seen on scanner, and was still moving at Torus speeds. 5 seconds later, whilst I was still wondering just what the hell had happened, shields began dropping steadily, still on Torus, and 15 seconds later the ship underwent Total Existence Failure.

That sounds like you hit an atmosphere at high speed and your ship overheated. At those speeds it wouldn't need to be a visibly detectable atmosphere, but the ALT and CT should have read something... not to mention planets tending to be quite visible things.

Umm.. if there's atmosphere floating around, midway between the planet and star, we're in big trouble.. because that's where this took place. (and I have no additional planet/moon OXPs installed) ALT and CT showed nothing out of the ordinary.. NumericHUD won't let you ignore such things, either.. they flash in a big red blob if they're at dangerous levels. It was almost like coming under constant laser fire, except there was no sound, no laser beams, and I can't see how that could happen anyway whilst continuing to move at Torus speeds.

Almost forgot.. both fore and aft shields dropped at the same rate, near as I could tell.

Dizzy, you probably know this but just in case...

There are two factors operating here to increase decelleration. First there is the one I added (recommended start point of *8) and then there's the one that was already present @ *3 (I think you've got it at a constant *4).

If I understand correctly then the two work slightly differently in that the former is always applicable but the latter only applies when mass-locked. So with *8 increased min torus speed, *8 and *3 would appear a logical place to start. However, with the scanner having been shrunk to half of its normal size, drift during decelleration becomes more significant, so there is also a case for increasing the *3 (since that is 'bonus' decelleration for thinks that 'should' deactivate the torus i.e. mass-locks).

Ok.. mystery solved, I think.

It's a bug within the Planetfall OXP, and only seems to occur under certain circumstances. I could narrow things down more, but after an afternoon and evening of flying the same mission over and over, I've had enough, and want to get on with play-testing.

It seems that if you approach very close to the planet, but don't land, then leave the atmosphere and Torus away, at some point later on, which can vary from a single planetary diameter away, to halfway to the sun, your ship goes into overheat mode, even though the temperature gauge won't rise, the shields will fail, and then your ship will burn up.

I'm guessing that perhaps a flag or property is getting set by Planetfall, then not being cleared/reset after flying back out to space.. at some point later, the code logic is falling through to someplace it shouldn't, and a faux overheating condition arises. Possibly, Planetfall is assuming that once you get a certain distance from the planet, you are definitely going to land.. when landing is then aborted, it gets confused.

So.. back to the testing!

Redspear wrote:

Dizzy, you probably know this but just in case...

There are two factors operating here to increase decelleration. First there is the one I added (recommended start point of *8) and then there's the one that was already present @ *3 (I think you've got it at a constant *4).

If I understand correctly then the two work slightly differently in that the former is always applicable but the latter only applies when mass-locked. So with *8 increased min torus speed, *8 and *3 would appear a logical place to start. However, with the scanner having been shrunk to half of its normal size, drift during decelleration becomes more significant, so there is also a case for increasing the *3 (since that is 'bonus' decelleration for thinks that 'should' deactivate the torus i.e. mass-locks).

Thanks.. that was pretty much my thinking on things too.. though following the logic through, it may be necessary to increase that *3 to *6 by way of compensation.

Further to which, going by the above, the "8 and 4", "12 and 4" and "16 and 4" builds are likely to be the most promising..