Split: Difficulty for new players

[Norby]

giving some npcs a limited torus

It can be done with an OXP using repetitive ship.position updates in FCB. A Pirate Interceptor ship with this feature can be very effective: if launch from the empty space with correct calculations then can masslock his far target (relayed from another pirate who almost lost an escaping ship) with good chances.

discontinuous jump is much better than torus because it's not mass-locked.

I definitely also want to be "mass-locked" if I have a TAF-like feature and my alert turn into red to be able to respond an attack of enemies, else I can "press space" only. In yellow alert maybe a slower jump can be available where I must to be able avoid collisions.
I learned this once when I made a crater into the Rock Hermit what I approached with torus.

each mini-jump took ~15 seconds to wind up

I think the opposite: torus give advanced speeds where a starting delay can be justified with technical reasons (spin up engines need some time) but a delay before turning on a time acceleration function can not. Make balances without good background is a last resort weapon, we can find better solution imho.

Laying a net wold be a lot easier than blockading a witchpoint

I continued the net idea in this topic. I do not want blockading witchpoints, but I want surrounding these.

[Zireael]

I definitely want to be "mass-locked" if I have a TAF-like feature and my alert turn into red to be able to respond an attack of enemies, else I can "press space" only. In yellow alert maybe a slower jump can be available where I must to be able avoid collisions.

I suggested mass-locking be changed into mass-locking on red alert only earlier.

[Disembodied]

The "disjointed" bit can be easily solved by a) giving the NPCs a variation on the existing torus b) making it not only limited to certain roles, but also pretty rare

The disjointed sense would be - for me, anyway - more to do with the player's experience. I worry that a series of static jumps would detract from the sense of travelling a long distance, or even of being in the same system: it would be like jumping from one box of space to another box of space with a slightly bigger planet in the background.

Accelerated NPCs would, I imagine, run into the same sorts of problems that NPCs encounter under the TAF.

What might be possible, to resurrect (or at least run a few thousand volts through) my previous suggestion about tying the torus to the compass ...

1) Ignore the sun exploit. It won't work every time, anyway, because the sun might not be in the right place. In fact, if desired, it could be fiddled to place the sun, more often than not, within a few degrees of the planet-witchpoint axis.
2) Allow the player the chance to create navigation points in any direction, by coming to a complete halt, aiming the ship in one direction, and generating a nav point situated X scanner radii in that direction ("plotting a course", for want of a handwave: perhaps the longer you "plot", the further away the nav point is placed). This nav point will last for Y minutes and can then be torused towards. This nav-point plotting could require a separate piece of equipment (Astrogation console?). It wouldn't even need another key: the plotting could be initiated by pressing "j" with the compass in "Astrogation" mode (or by pressing shift-J, even).

It's more complexity - more faff, to be honest. But: the faff would only happen on certain, relatively rare and special, occasions, and might be worth it.

Of course, it still lacks the simplicity and elegance of just leaving everything well alone ...

[cim]

The disjointed sense would be - for me, anyway - more to do with the player's experience. I worry that a series of static jumps would detract from the sense of travelling a long distance, or even of being in the same system: it would be like jumping from one box of space to another box of space with a slightly bigger planet in the background.

Keeping the maximum jump distance small, I think, would help with that. If you see a fast ship fly off ahead, make a jump, get into a fight on exit, and then see that same ship come in to the region again, it should feel okay. The visual appearance of the jump (inside and outside) could also help make it look continuous.

Accelerated NPCs would, I imagine, run into the same sorts of problems that NPCs encounter under the TAF.

The big technical problem with giving NPCs a torus drive as currently implemented is that an exhaustive scan for entities which might mass-lock them is relatively expensive, especially since they don't have the optimisations for that scan the player does. (And a practical problem that most NPCs which might need to move fast also might need there to be more than one of them reaching the destination)

1) In fact, if desired, it could be fiddled to place the sun, more often than not, within a few degrees of the planet-witchpoint axis.

Somewhat annoying for sunskimming, I think.

[Zireael]

The big technical problem with giving NPCs a torus drive as currently implemented is that an exhaustive scan for entities which might mass-lock them is relatively expensive, especially since they don't have the optimisations for that scan the player does. (And a practical problem that most NPCs which might need to move fast also might need there to be more than one of them reaching the destination)

That's one of the reasons why mass-locking should be replaced by 'off on red alert'.

[cim]

The big technical problem with giving NPCs a torus drive as currently implemented is that an exhaustive scan for entities which might mass-lock them is relatively expensive, especially since they don't have the optimisations for that scan the player does. (And a practical problem that most NPCs which might need to move fast also might need there to be more than one of them reaching the destination)

That's one of the reasons why mass-locking should be replaced by 'off on red alert'.

Then you can virtually never get mass-locked. At 11km a second you can probably get in and out of scanner range in under 5 seconds, which is about how often they check their scanners. It does also give easy options to flee from big fights - once nothing is specifically targeting you then you can vanish at high speed.

The other purpose of mass-locking is of course to avoid exposing just how bad the collision detection can be at torus speeds - especially at lower frame rates you'll be able to fly straight through anything smaller than an asteroid.

[Norby]

I suggested mass-locking be changed into mass-locking on red alert only earlier.

Sorry, then I also (corrected above).

same sorts of problems that NPCs encounter under the TAF

Please tell me more about this problems. I imagine very small jumps (position updates) in every frame where these looks like a continuous movement. If jumps are not allowed in red alert then no serious aiming problems at least.

Allow the player the chance to create navigation points

I still missing a good reason why these directions are allowed only. A reason if there are visible  Jump Gates at these locations.

an exhaustive scan for entities which might mass-lock them is relatively expensive

The new ship.checkScanner() looks like handy to detect masslocks until no FPS drop due to the many jumping NPCs.
My idea is some intercepting pirates, I think the checks of these will fit into without problems, for example to keep traders in lanes. But the presence of GalCop also can be more effective in lanes with some jumping ability.

The other problem is more hard: we want to player can arrive to far bases sooner but without a "NPCs left behind" cheat.

1. If it is solved by accelerated time then all existing ships need checks at the same time so FPS can drop easily and absolutely need optimized core improvements which will not be available in a stable release within a year imho.

2. If it is balanced by giving torus to NPCs then a few ship will use it at the same time which can fit into an OXP solution also which can be ready at basic level in weeks. Then we can start make advanced torus-capable AIs. I think the game will be more interesting with these new AIs than with a simple time acceleration. For example if player just escaped with torus then his enemy can follow him sometimes.

If anybody ask me then I choose no. 2.

Torus restrictions (navpoints/gates/etc.) is another question where any decision should be equally effect both the player and NPCs. The original idea is to use these to reduce the gap between the player and NPCs who can not use it at all is never be perfect due to perfect mean if NPCs has no torus then player has not also. I think better if we change both side equally (navpoints? ok if NPCs can jump to these also) and much like into the direction of improvements than restrictions.

For example jumps of trader NPCs are handled in Thargoid's  Gates OXP, but if it will be extended to more general usage and player can use these to follow an escaping NPC then an attacking NPC also should track the player through gates else players can use these as safe escape routes.

[Cody]

For the record, jump gates and/or navigation points do not appeal to me at all.

[Redspear]

The big technical problem with giving NPCs a torus drive as currently implemented is that an exhaustive scan for entities which might mass-lock them is relatively expensive, especially since they don't have the optimisations for that scan the player does. (And a practical problem that most NPCs which might need to move fast also might need there to be more than one of them reaching the destination)

That's one of the reasons why mass-locking should be replaced by 'off on red alert'.

Then you can virtually never get mass-locked. At 11km a second you can probably get in and out of scanner range in under 5 seconds, which is about how often they check their scanners. It does also give easy options to flee from big fights - once nothing is specifically targeting you then you can vanish at high speed.

The other purpose of mass-locking is of course to avoid exposing just how bad the collision detection can be at torus speeds - especially at lower frame rates you'll be able to fly straight through anything smaller than an asteroid.

In which case, how about mass-locking occuring as normal but there is then a small time-window (a la hysperspace jumps) until it can be used again (whether within mass-lock distance or not)? Should the player be targeted or go into a state of red-alert within this time window then the torus drive is disabled.

Upon re-engaging the torus-drive (after the time-limit), all present mass-locking entities could (assuming this is not problematic from a coding perspective) be discounted in terms of any subsequent mass-locks.
In other words: an entity that stays within scanner range can only mass-lock you once.

In 'game world' thinking this would mean the torus drive stopping when near potential collisions in order to allow the pilot to re-consider his/her course but only halting that course for a few moments (should the pilot choose to re-engage the torus). That sounds a reasonable 'safety feature' to me. Should the player be targeted the torus drive is disabled on the grounds that incoming craft/missiles/fire is present which may damage the ship with disasterous results at torus-speeds.

This could mean getting mass locked by those with no wish to engage you would be less time consuming, whilst getting mass-locked by pirates (or police if you're naughty ) would work almost as before.

Of course the duration of the proposed time-window is crucial here, but if it were two or three times longer than that for hyperspace then it would still save me plenty of time overtaking planet-bound traders.

Well? Have I missed something?

[metatheurgist]

The disjointed sense would be - for me, anyway - more to do with the player's experience. I worry that a series of static jumps would detract from the sense of travelling a long distance, or even of being in the same system: it would be like jumping from one box of space to another box of space with a slightly bigger planet in the background.

Never enjoyed the sometimes half-hour flights from witchpoint to station in the original game. They were interesting the first few times but then they just became routine. I supposed that's kind of realistic, but not very fun. In Oolite I will deliberately choose short jumps just so I can burn all the way in on injectors, when that fails I rely on the fact that I bought a fast ship.

What's the lore reason for mass-lock anyway? I assume it's dangerous to do? If that's the case why not penalise the player for trying a jump when locked? Maybe you suffer damage? Enough to reduce shields to 0 and damage equipment and lose cargo (with a quirium cascade being the ultimate consequence)? Maybe you have to follow the nearest "safe" trajectory to pull one off (which still might damage the ship), and ends up putting you in a safe place but with a longer flight home since you are now off the lane (since the "safe" trajectory will probably be random). Maybe flying the "safe" trajectory will not be a given if pirates are getting in your way.

[Falcon777]

I personally like things how they are. The torus drive doesn't get you anywhere instantly, but it still gets you where you are going quickly. It also seems more realistic and fun than the original jump drive.

As a side note, I'm gonna go back to the original post and see what was being discussed at first, because if I remember correctly it wasn't specifically targeting the torus drive, but rather beginner difficulty vs accomplished player ease.

[cim]

same sorts of problems that NPCs encounter under the TAF

Please tell me more about this problems. I imagine very small jumps (position updates) in every frame where these looks like a continuous movement. If jumps are not allowed in red alert then no serious aiming problems at least.

Combat is the major problem. Assuming your hardware normally manages 60 FPS, then at TAF16, you're effectively getting about 4 FPS, which has a range of effects:
- the beam laser goes from being five times as powerful as the pulse laser, to being only twice as powerful (it can't fire more than once a frame)
- the NPCs can control their aim at 4 FPS a bit better than the player can, but probably still not enough to hit anything
- escort ships will regularly lose their position and have to loop around
- docking becomes less reliable
- collision detection gets worse
- there are a large number of more subtle dependencies on the frame rate, too.
If you weren't getting 60FPS to start with, then it gets even worse - if you normally get 20FPS (which is normally just about playable), then at TAF 16 you're only getting one update every second, more or less, which is unusable.

Now, you can say "disallow if not at red alert", but what you actually have to do is "disallow if anyone is at red alert" - say the player is rushing to help in a battle. If the outcome of the battle depends on whether they rush there at TAF 1 or TAF 16 (and it often will), then there's a problem.

an exhaustive scan for entities which might mass-lock them is relatively expensive

The new ship.checkScanner() looks like handy to detect masslocks

Not entirely. If you use the poweredOnly option, then a rock hermit targeting the NPC (which should cause red alert) won't be picked up. If you don't use it, then a single powered ship hiding in a dense debris field won't reliably masslock. That function is designed for getting a quick - rather than exhaustive - assessment of the nearby objects: as it says, it's limited to 32 objects returned, and it's still not designed to be run every frame.

[Disembodied]

As Cim points out, there are technical problems with giving NPCs a torus drive:

The big technical problem with giving NPCs a torus drive as currently implemented is that an exhaustive scan for entities which might mass-lock them is relatively expensive, especially since they don't have the optimisations for that scan the player does. (And a practical problem that most NPCs which might need to move fast also might need there to be more than one of them reaching the destination)

There is also a gameplay issue: if NPCs get a torus drive subject to masslock, then we will get a great big masslocked traffic jam in every system. Every new arrival will zoom in until they bump into the back of the previous ship, and so on. The torus-and-masslock is a great game mechanic to let the player encounter ships, but it only works if it's player-only. However, in Oolite, we now have "the spacelane problem". In the original game, new ships were automagically created in front of you, in whatever direction you flew. That doesn't happen in Oolite, and so we get spacelanes and the ability to avoid them.

My tentative idea about tying the torus to the compass would keep the torus player-only, but would prevent new players wandering off the spacelanes until they bought an ASC. Perhaps - if this is what is desired, to keep players on the lanes, at least to begin with - this is the simplest solution: until you buy an ASC, the torus will only work from WP to planet to station. Once you buy an ASC, you can use the torus in any direction you want.

[spara]

There is also a gameplay issue: if NPCs get a torus drive subject to masslock, then we will get a great big masslocked traffic jam in every system. Every new arrival will zoom in until they bump into the back of the previous ship, and so on.

That's why there would be need for a new AI that would make a 90 degree turn to get out of the mass lock and then turn to the correct heading and torus, just like a player might do.

[Disembodied]

There is also a gameplay issue: if NPCs get a torus drive subject to masslock, then we will get a great big masslocked traffic jam in every system. Every new arrival will zoom in until they bump into the back of the previous ship, and so on.

That's why there would be need for a new AI that would make a 90 degree turn to get out of the mass lock and then turn to the correct heading and torus, just like a player might do.

All the technical problems aside, I think the gameplay effects of NPCs with torus drives would be so large that it would require a lot more than that.

Two pirates lurk on the lane: a Cobra III and an Asp. Along comes the player, and is masslocked. The pirates attack. As the fight begins, a Boa with three escorts arrives at the WP, hits its torus (which has been fiddled with to allow escorts, which is something else to keep track of - who's in what group, who masslocks who and who doesn't), and bumps into the back of the fight. They turn 90° and start to move away. And then an Anaconda convoy arrives, turns 90° in another direction, and begins to slowly move away. The fight, meanwhile, moves back and forth across the lane. A lone Python trader arrives. The player zaps the Cobra III, which spills some canisters, attracting the scavenging attentions of the Python. Then a Viper patrol arrives, who all dive in and attack the Asp. Outnumbered, the Asp tries to flee, in another direction. There's now a large and expanding cloud of ships, all masslocking each other, spread across the spacelane. A Cobra III trader arrives, toruses in, gets masslocked, and also gets interested in the canisters. And so on. Ships will arrive far faster than they can get away. Eventually (possibly quite quickly) the masslock jam stretches all the way back to the WP, which is now surrounded by a big ball of ships all moving at 90° to the spacelane. At the other end, meanwhile, another big masslocked ball begins to form as some ships start to arrive at, and get masslocked by, the station. Of course, this can be mitigated by drastically reducing the volume of system traffic - which is a major gameplay change.

The question for any gameplay change should be, "Is this more fun?" If it's not more fun, then it shouldn't be changed. The torus drive is a wangle designed to allow the human player to cross large distances of space without expiring from boredom, and the masslock is a wangle designed to prevent the player from using their torus to scoot away from anything they don't want to meet. There is no need to give these player-only features to NPCs.

Would it be more immersive - more fun - if players and NPCs existed on a more level playing field, rather than the player having a magic drive that the NPCs don't? Perhaps: the only good answer to this, though, is a fully functioning TAF, which is a major technical problem.