Time Acceleration Not Functioning

[Disembodied]

May I just point out that everyone plays the game differently. Not everyone wants a fast-paced non-stop action-fest getting to "Elite" with a gadzillion credits in an evening of gameplay.
Might as well just play an arcade shooter for all the immersion that provides (IMHO).

Personally I quite enjoy a serene convoy in towards a planet in company with a couple of traders. I -never- go off-lane to torus (and even if I did, Deep Space Pirates would slow me down anyway). I -very rarely- use injectors except to avoid hard-head missiles.
Am I the average player? Probably not. Do I get immersed in the game? You -betcha-!

Absolutely. Some days I just want to cruise, and sightsee, and wave to passing traffic; other days, I have things to do, places to be, people to kill ... The thing is, with a TAF, everyone who wants to can poke along in convoy, and those who want to buzz on through can do that too. With masslocking, you have to poke along in convoy, or overhaul/manoeuvre around any traffic. With a TAF you could pilot a slow hauler and not bother about the fact that there are traders in Cobra IIIs leaving you in their wake; with the torus, if you're flying a Python and you catch up on and get masslocked by a Cobra III, you'll never overtake it without using injectors.

I don't use the TAF in the game, except on a few very rare occasions when I've been testing something. I'm happy enough with the game as it is, with the torus drive. But a properly functioning TAF, replacing the torus drive and without causing masslocks, would increase the number of ways players can play the game. To me the single biggest advantage it would have is that it would make slower ships playable for everyone, regardless of their style of play.

[Kaks]

As a non-average player too, I'm kind of puzzled, too: as standard you're given a fast ship, and a way to skip the 'boring bits' using the torus drive. Then you can buy fuel injectors to skip the 'too interesting bits' during a space fight.

To me, the game is the 'mildly interesting bits' that you get at all other times, and a game I chose for myself: I don't have deep space pirates - in my Ooniverse they've got no reason whatsoever to concentrate where no ship normally goes, so torus drive is more than enough speed. And for me too, the only reason I ever use TAF is to test stuff.

Somehow I didn't even think of the potential 'learning mode' option that sdrubble is using, but it's something I'll bear in mind if we get another 'docking is too difficult' topic...

[Fatleaf]

For me the only time (get the boring joke there ) I use TAF is when I'm stuck in interstellar space and need to scoop some fuel. Without TAF it would take far too long. I would end up hacking the script of the fuel collector!

[Micha]

Somehow I didn't even think of the potential 'learning mode' option that sdrubble is using, but it's something I'll bear in mind if we get another 'docking is too difficult' topic...

I've actually made a 'precise controls' patch for keyboard (since I'm a keyboard Commander) for my own use - I can clean it up & submit it after MNSR if there's interest.

[sdrubble]

... a TAF and AIs which can work under that TAF – i.e. which will very quickly destroy a player foolish enough to try to activate the TAF during combat.

<*me* raises hand>.

If I understood it right from a number of posts in this thread and also in other threads, NPC's have their AI botched when the player is using a high TAF like 8 or 16 (in the current game version).

But what NOBODY has said yet, is what happens to the enemy's AI when sdrubble - who's seemingly the only player this side of Riedquat which enjoys the slow-motion drug-enhanced combat awareness - enters combat with TAF < 1.0 . Does the NPC AI work just as well - OR will it bear down more easily on the player - OR it gets just as botched as when TAF > 1.0 ??

I'd really like to learn a bit about the codemasters' view on this.

Somehow I didn't even think of the potential 'learning mode' option that sdrubble is using, but it's something I'll bear in mind if we get another 'docking is too difficult' topic...

Well that's an interesting point.

Actually, IIRC, I can dock manually with TAF=1.0... slowing TAF for docking makes it only marginally easier for me. Maybe my difficulty with combat and TAF comes from my using yaw a LOT for targeting. When docking I'm likely to use pitch and roll exclusively, and these I find easier to handle at normal TAF.

And yes, I KNOW that most pilots here don't use yaw a lot (if at all). But for me yaw plays an important role, mainly for the final millimeters of locking a target. It's possibly my particular combination of jumpy yaw & coarse joystick & heavy fingers that drives me towards a lower TAF in combat.

As a side note (and also a funny one) - has anyone actually managed to manually dock at a Navy Station, while rolling with a joystick and precision mode turned ON ?

Cheers

[sdrubble]

I've actually made a 'precise controls' patch for keyboard (since I'm a keyboard Commander) for my own use - I can clean it up & submit it after MNSR if there's interest.

Count me in Micha... as a not-so-satisfied joystick user I might consider going back to using a keyboard exclusively if a precision level could be added to the keyboard.

May I suggest...? MULTIPLE precision levels if possible (P1 - - - > P9), which is not practical to have on a joystick but I don't think it would be too complex to achieve for the keyboard...

Cheers and thanks

[Switeck]

I still think removing TAF is a mistake - I don't believe in the Torus Drive - I've always used TAF, this way I'm on a level playing field with NPCs - if TAF goes - I definitely won't be upgrading to future versions of Oolite.

I agree! In a future MNSR, the "Torus Drive" could be the debugging tool accessible only while paused, TAF could be the "time acceleration key" meant for regular use. (J for faster, shift+J for slower)

But if TAF was to become a game feature, I think there needs to be a lot of testing done to ensure you can't warp through stuff and whatnot. Probably also have to automatically flip to "real-time" on Condition Red and suchlike.

How about restricting TAF from 0.25x to 4x when in "mass-lock" conditions? The NPC AI seems to work ok even from TAF 0.06x to 4x on my computer.

May I just point out that the plan has always been to also provide a debug verision. The debug version (intended for oxp makers) will provide basic-debug.oxp & will also provide all the existing debug functions including TAF, exactly as it works now.

Even the betas and major versions need testing...which can be done quicker with TAF. Adding special OXPs for testing may seem the answer, but they can also trigger problems. Case in point, my combination of a wormhole-making quick-jump OXP with a hacked stupidly fast ship OXP with cloaking in-use.

Some problems may only appear under debug or non-debug versions of the game. The fewer code differences there are, the better...such as both versions having TAF and shift+F information.

My issue here is, that I can only really play Oolite by frequently setting TAF=0.5. When TAF=1.0, I find it very hard (and un-joyful) to match any object to the crosshairs. That applies even to a floating container right in front of me when I'm at a dead stop.

This is a bug, even if it's due to computer limitations or other outside issues.

I use TAF <1 sometimes (in combat, while docking, and while scooping cargo), especially when piloting an Adder that is way too twitchy when using the keyboard. I should be fighting enemies, not the game's controls. I definitely could use a 'precise controls' patch for keyboard! Using a less maneuverable ship like an Anaconda isn't a solution.

The greater harm in removing TAF is it will encourage heavier use of the game-imbalanced player-only Torus Drive and faster OXP ships just to make traveling the space lane or convoying more tolerable.

[Zireael]

How about restricting TAF from 0.25x to 4x when in "mass-lock" conditions? The NPC AI seems to work ok even from TAF 0.06x to 4x on my computer.

Good idea.

[Micha]

How about restricting TAF from 0.25x to 4x when in "mass-lock" conditions? The NPC AI seems to work ok even from TAF 0.06x to 4x on my computer.

Good idea.

Well, that is precisely the problem. The faster your computer, the higher the TAF at which AI will (sortof?) work, and vice-versa.

How would Oolite calculate the threshold TAF beyond which AI becomes 'broken'? It probably -can- be done, but it -will- take quite a bit of effort to get it to work 'properly' across all machines.

[cim]

It wouldn't be too hard to give NPC's (at least the core roles) a torus like ability via script. But it might change the game play a lot.

It certainly would, especially if players and NPCs masslock each other – you'd have nothing but a long traffic jam from witchpoint to station. The torus/masslock combination is a great game mechanic but it only works if the player's the only one with it. If we want to equalise things between players and NPCs, then the masslock has to go, for the sake of gameplay. However, if the masslock goes, then that's the game out of the window, because nobody would ever have to stop and fight.

What about the torus/masslock mechanic from the Escort Contracts OXP? Two (or presumably more) ships can torus together without problems if they fly in close-enough formation and synchronise their drives. So, to widen that idea a bit, lets say that there's a setting on the drives that lets them synchronise or break synchronisation. (J=torus on/off, Shift+J=toggle torus sync)

Traders usually keep their drives on synchronised, as do their escorts, so none of them mass-lock each other. Pirates might hang around on the spacelane with desynchronised drives waiting for someone to come along and get mass-locked, or they might sync up their drives and charge in on torus. Police and bounty hunters would probably use synchronised drives for patrol, and desynchronised to attack.

You could still keep some of the current mass-lock behaviour by having drives just coming into range of each other automatically interfere with synchronisation for a few seconds as the torus computers recalculate synchronisation patterns - so you'd drop out of torus at that point, but you both could reactivate it without having to actually fly past/around each other - provided neither commander intentionally hits the 'desync' button, of course.

[Kaks]

Hmm, Ok, let me rephrase things: the reason TAF is going to be disabled in non-debug, non-test versions is: 'we haven't got a good way to make AIs react properly at higher speed than 1x' and 'the faster things move, the more erratic collision detection becomes'.

The whole point of the torus drive working as it does is that when you've got to interact with AIs - and with fairly substantial objects - you're forced back to a speed where the engine works well enough, as opposed to just 'kind-of-works-but-not-quite'.


No matter what type of accelleration you use, taf or torus drive or whatever, those problems are still the same. As Micha says, the faster the computer, the less problematic things are, but determining what's the fastest safe speed is going to be 'a lot of fun' if we try and do this kind of stuff.
About the Escort Contracts, they don't need to interact with the player or anything else when the torus drive is engaged, so everything does work ok.

[Switeck]

So this is at most something to "look at" after the MNSR.
However, what about the separate bug?
...Where even at TAF 1x the Adder (and similar twitchy ships) is almost impossible to precisely aim at a non-moving target using the keyboard.

[sdrubble]

Well, looking at this announcement , it seems now that we'll have one more round of still-working TAF on released code - no more need, at the moment (for me at least...) to fiddle with compiling stuff on Windoze just to re-enable TAF !!!

The version number in Oolite's source code tree has been rolled to 1.76. [ . . . ] the MNSR will be published as Test Release and not as Deployment configuration as was intitally planned. [ . . . ] As a result, all game and debug features that have been present in the latest test releases will remain also in v1.76.

Cheers