Oolite Bulletins

Recently there have been a couple of instances posted of people accidentally and unknowingly hitting the Time Acceleration Factor keys while paused, with the usual predictably 'interesting' results..

Would it be a good idea to make the TAF arrow keys only functional when the Framerate display is active? Since the TAF function is really only usable in conjunction with it, there shouldn't be any real problem with that.. I for one would never be totally sure if I'd pressed the key 3 times or 4, without the framerate display to confirm things.. same when reverting to 1:1 time.

It may not totally stop accidental keypresses, but at least it would give the player a chance to notice the setting has changed, before disaster strikes..

Another possibility might be to display a warning notice on-screen when the TAF keys are pressed.. "Warning: Time Acceleration now set to 16:1!"

For that matter, the Oolite Reference Sheet really ought to be updated to include the TAF controls, they've been in the game long enough now..

Diziet Sma wrote:

For that matter, the Oolite Reference Sheet really ought to be updated to include the TAF controls, they've been in the game long enough now..

And may well be out of the game for the next stable release. TAF(both keyboard and scriptable) is still AFAIK considered a 'debug / development' tool rather than a bona-fide end user feature, so will be unavailable if the next stable release is built in 'release' format (which I understand is the plan, although a developer release will also be available with the debug features still active). There are good reasons, one being the AIs don't work very well at high TAF. However I for one would still like it to be available via script, it's a handy tool if used with care, and is used by a fair few OXPs

My main use of it is during long runs to do some sun-skimming (I use Sensible Suns) if I'm playing with limited RL time available..

It also comes in really handy when trying to get certain screenshots, or when gameplay slows to a crawl in overcrowded systems..

A possible OXP idea related to TAF, and I must admit that this idea is not actually my own - I read about it in the Oolite fiction "Deadly Designs" (Davidtq), but in that story, the main character had some sort of awareness heightening drug administered to himself during the heat of battle. In effect his perception was accelerated so that events transpired more slowly (i.e. TAF < 1).

So the idea is a piece of purchasable equipment that simulates this effect by slowing the TAF in response to the ship going critical. This effect can be balanced by including a 'hangover' effect where time acceleration is slightly elevated after the initial drug hit wears off.

Here's how I envisage this device...

In the heat of battle, the ship is taking heavy hits and enemy laser fire is eating deeply into the energy banks. Once a predetermined level has been reached, TAF drops to 0.5 for 30 seconds. The drug starts wearing off and after a minute plateaus at about 1.15 (this is the hangover), then after another 15 or 30 seconds, returns back to normal.

For this to look right, TAF would need a smooth gradient rather than fixed speeds...but finally we would have a use for the 35T of Narcotics that we've all hauled around at one point or another.

Hmm.. most interesting idea, Bugbear.. <gears start ticking over>

Sell the über-ship you've been flying and buy something cheap and go sun-skimming. Then you'll be gagging for the TAF. Without it, Oolite has all the excitement of a submarine simulation: hours of bugger all happening.

IMHO, it's supposed to be a game, which means fun, not a flight simulator, which means tedium for most people.

Me using my keyboard and my slow PC with its 4 FPS frame-rate needed the TAF to be able to fly the ship at all in combat. And since its an emulation of a 1980s game, "Buy a new PC" is not an acceptable message to newbies who want to try the game.

My current Cobra Mark I takes ages to get to the sun in some systems, so much so that I am posting on here and IRC and web browsing. Ditto when mass-locked all the way to the main station. The TAF is needed in these cases.

Early on, I too got caught out by activating the TAF by accident but that was because I didn't know it existed and did not know it was set. The solution is:
• to document its existence
• to document how to set it
• to alert the user to its having changed, e.g. have a message appear briefly on-screen when it is changed:

← pressed: Slow-down set to 1/2
← pressed: Slow-down set to 1/4
→ pressed: Slow-down set to 1/2
→ pressed: Speed set to normal
→ pressed: Speed-up set to x2
→ pressed: Speed-up set to x4
↑ pressed: Speed set to normal

• have the current setting visible in the "Save/Load/New Game/Exit" screen:

Quick-Save
Save Commander
Load Commander
Begin New Game

Game Options...

Rules: Oolite balanced (OXPs enabled)
Speed: ← set to Normal →

Exit Game

• Oh, and it needs to be settable when docked, too.

Its downsides for me are:
• should it auto-disengage from fast to normal when attacked (for the benefit of the AI)?
• should it auto-disengage from fast to normal when a target appears in the cross-hairs (to prevent splatting onto asteroids etc.)?

SandJ wrote:

• to alert the user to its having changed, e.g. have a message appear briefly on-screen when it is changed:

← pressed: Slow-down set to 1/2
← pressed: Slow-down set to 1/4
→ pressed: Slow-down set to 1/2
→ pressed: Speed set to normal
→ pressed: Speed-up set to x2
→ pressed: Speed-up set to x4
↑ pressed: Speed set to normal

• have the current setting visible in the "Save/Load/New Game/Exit" screen:

Its downsides for me are:
• should it auto-disengage from fast to normal when attacked (for the benefit of the AI)?
• should it auto-disengage from fast to normal when a target appears in the cross-hairs (to prevent splatting onto asteroids etc.)?

Mmm, The on screen messages on manual adjustment can be done via script easily enough, as can an auto reset (to a player decided threshold) when there is anything at all interesting within scanner range. And/or perhaps a shiftN/N activated TAF controller that allows it to be set without pausing? Is that something worth making? I think so - where shall I put in on my to do list....?

Diziet Sma wrote:

Would it be a good idea to make the TAF arrow keys only functional when the Framerate display is active? Since the TAF function is really only usable in conjunction with it, there shouldn't be any real problem with that..

That sound a good idea as its only useful to set with FPS displayed and seems very effective against accidental changing the TAF during normal play. I just added this limitation for activation in my build and if more feel that way, I'll add it to trunk.

I agree with SandJ and Bugbear.

Zireael wrote:

I agree with SandJ and Bugbear.

So is that a yay or a nay on the poll? I notice you didn't vote yet..

I drive-by skimmed this thread, and very much agree with having variable TAF only active when FPS is showing.

In addition to that, I'm thinking that we could have takeSnapShot() only work if there's a connectcted js console, thereby clarifying - yet again - the debug-only nature of those two!

By for now!

(Work, work work! )

Recently bought a Python, and the TAF helps avoid longer boring flights, though the full FPS information does clutter that corner of the screen. If the FPS isn't being displayed, could we have the TAF changeable but show the current TAF multiplier if it isn't currently x1?

Storm wrote:

... though the full FPS information does clutter that corner of the screen. If the FPS isn't being displayed, could we have the TAF changeable but show the current TAF multiplier if it isn't currently x1?

It is only the change of TAF that needs a FPS display. After changing you can turn off FPS display again, just as you have to un-pause to continue. This change will just ensure that its not changed accidentally. Accidentally changes happen often to me. I know what causes it now, but new users might get problems. Specially because its mend as a developers tool and therefore is not mentioned in the oolite reference sheet.

And, to meet the request of letting js know "what's going on", a new property will be added to the global environment, called 'debug': in future TAF (and another debug only js feature - takeSnapShot) - will be accessible to js through the new debug property.

Diziet, TAF has been a part of the debug features for a long time, but never quite part of the game. It is mentioned, though - or so I believe - together with other debug features.

Kaks wrote:

Diziet, TAF has been a part of the debug features for a long time, but never quite part of the game. It is mentioned, though - or so I believe - together with other debug features.

Yep.. I do get that.. but as several people have testified here, it is quite a valuable tool for players who want to maximise limited gameplay time, still be able to dogfight on a suddenly bogged-down computer, or who feel, quite rightly IMO, that playing Oolite isn't supposed to be like watching paint dry..

Therefore, I'd like to see it become more of an accepted, mainstream part of the game, and not just a debug tool..