[Release] VariableMasslock v1.1

[Anonymissimus]

I wonder whether this change lets this addon conflict with other addons which modify the scanner colors though !?
For instance, the police iFF scanner colors offenders/fugitives differently; if both are installed, then this addon would undo the effect of that one ? In which "order" are addons applied ? Imagine some offender just came into range, but is still out of masslock range, in which way is he displayed ?

EDIT
Also, please check whether rock hermits do masslock as well (as opposed to ordinary asteroids). I once jumdrived into a hermit while docking with this already installed, after accidentally hitting that key. Press space commander.

[Redspear]

Apologies if the following borders on thread derailment but it is at least relevant to this oxp...

Varying masslock based on mass seems very logical, satisfyingly so, but I wondered if there was a way to discriminate with the emphasis placed firmly on gameplay.
The ins and outs of the masslock 'issue' have been discussed at some length elsewhere, so I'll try to be brief.

When is masslock at its most frustrating?

• When theres another ship in front of you that's headed in the same direction as you (especially if it's of similar speed to your own ship).

When is masslock at its least frustrating?

• When it's a precurser for aggression or when the other ship is headed in the opposite direction to you.

So rather than ship mass, what if heading relative to the player were the means of discrimination?
Well, like most proposals around this issue, there are a few questions to be answered.

In Elite, I seem to remember a great many of the ships encountered heading away from the main station, so many that I wondered why when I never seemed to have reason to. Less realistic perhaps but more satisfying from a gameplay point of view in that masslocks tended to be shorter. In oolite there are potentially more reasons for ships to be headed 'outwards' and yet (because it simulates 'realistic' traffic) fewer seem to do so.

Who's most likely to be headed to the station?

• Traders and their escorts.

Who's most likely to have a reason to head the other way?

• Police (patrols); pirates (fleeing those patrols or 'catching' oncoming traders); bounty hunters (after said pirates).

There are exceptions of course but I'll try to cater for those below.

When would masslock activate?

• As in the standard game

So how would it be different?

• If no other vessel is headed in the opposite direction to you (and condition remains yellow) then torus is re-enabled after 10 (or similar) seconds.

Why the time delay?

• It prevents 'insta-skipping' of encounters (in which case it could be argued that they may as well not be there in the first place).
• It grants pirates or aggressors headed in the same direction as you the opportunity to target you and prevent your use of the torus drive.
• Each masslock, independant of heading, remains an unknown where anything could happen.

What about being released from target lock if an aggressor switches target?

• A means to escape masslock that a player might be able to fish for? Why not?
  Or, if that's really a problem, then disable it whilst any combat is occurring on scanner (too dangerous with ships zipping about everywhere).

What happens when you pass/overtake a ship? Their relative heading has now changed in relation to your ship.

• In relation to your ship, yes, but in relation to your heading, no.
  The question then becomes why can't I now just torus away from the ship that just flew past me?
  Perhaps now the countdown begins (for torus reactivation) or perhaps not on the grounds that they should be off scanner soon anyway.

How is this any better than the default game?

• The longest and most tedious masslocks would be limited to 10 seconds in duration (subject to there not being overlapping masslocks), even if you're overtaking an Anaconda in... an Anaconda.
  The ten second delay could even be (if the duration was balanced just right) a point of dramatic tension if you know or suspect pirates/police to be present.

Is anything lost?

• Still unsure of intentions of those masslocking you? Check.
  Time for aggressors to target you? Check (10 seconds might not be the best value for this but something short in any case).
  Still get to admire/experience other traffic? Check.

What could be the 'real world' reasons for it to work this way?

• Safety - ships headed in the opposite direction present more dangerous risks of collision than those headed away from you. Stationary objects (asteroids etc) are generally much more predictable than mobile objects headed away from you (which can turn). Torus near a main station is disabled on the grounds of this being a busy area where ships are launching as well as docking.
• Once disabled by cut-out (i.e. masslock) a short period could be required for re-calibration (similar to the hyperspace countdown perhaps) and/or for adjusting your ships heading to avoid any upcoming hazards.
• Red alert disables the torus because combat is not only highly unpredictable but a hit on an active torus drive could be catastrophic.

So rather than find a method to reduce masslock based around it's own (admittedly very good) 'handwavium', it would be a reason to reduce masslock based around the 'issues' of masslock.

[Norby]

Redspear made a tweak which use ship role instead of mass to make green alert and allow torus travel near traders and similars, like friendly ships wilfully cover their drives with a disturbance reductor.

I see the following either-or possibilities to combine mass and role:

1. Use mass for traders and full scanner range (25.6km) at others.
2. Use fixed masslock range (17km) for traders and mass-based for others.
3. Use mass-based range on all ships but deduct a fix amount like 5km at traders.
4. Cut the mass-based range to 2/3 at traders (Anaconda 17km, Adder 11km).

I like the last but do not know what players think.

[Redspear]

I see the following either-or possibilities to combine mass and role:

Glad you're interested

Does #4 still include mass-based range for police/pirates et.al.?

I seem to remember a discussion where some 'game-breaking' possibilities were mentioned with regards to this oxp.
May I ask what those worries were please?

[Norby]

Does #4 still include mass-based range for police/pirates et.al.?

Yes.

what those worries were please?

I don't remember.

[Redspear]

OK, thanks.

The reason I ask (well, one of the reasons) is that I worry about pirates and police not having enough time to target you when they have their mass-lock range reduced.
Although not truly 'game-breaking' it could make the game considerably easier and also potentially make some missions more problematic.

[Redspear]

I don't remember.

Could it be this?

[Redspear]

Hi Norby,

After reading your post here would it be posiible to have AIs that also recognise the original (saved) scan class?

So if you were to arrive in the middle of a battle you wouldn't prevent other ships from being targeted if they were on the edges of your scanner.
Instead, the AI would recognise the saved scan class and behave as in the standard game.

Just food for thought.

[Norby]

would it be possible to have AIs that also recognise the original (saved) scan class?

Yes, just not worth the work imho. The oolite-priorityai.js would need many cautious changes and tests and the improvement is minor, affect a few seconds only while no ship within the modified masslock range nor lock on the player causing red alert and masslock. The already exising target locks are not touched nor the secondary targets in the defense lists, moreover other ships outside the scanner are normal so the fights should not change so much. When must seek another target then probably prefer the player as the only valid target which instantly solve the problem via red alert.

[Redspear]

The already exising target locks are not touched nor the secondary targets in the defense lists

OK, so it's not as bad as I imagined. Behaviour might be a little different but not appear obviously 'wrong'.

Thanks for taking the time to explain

[alaric of rothestes]

Whilst testing Torus Field Monitor comparability, I've noticed a small problem with this OXP.

If I head directly toward a ship, it will lock instantly once in scanner range. I can then re-engage the torus drive until it hits the reduced mass-lock. This only seems to happen if I head more-or-less straight toward the object; if it appears on the periphery of the scanner it behaves as it should. I'm guessing that Oolite is determining mass-lock before the frame callback is called and VML has had a chance to change the scan class. This explains why I can re-engage the torus, and rounding errors may explain why objects off to the sides don't suffer from this problem.

I suggest a solution may be to increase the range at which you alter the scan class. If you increase the range by something like (player.ship.speed / 20), this should allow you to change scan classes in time at playable frame-rates. Of course, this means you would lose the efficiency of being able to use checkScanner().

regards,

alaric.

[Norby]

If I head directly toward a ship, it will lock instantly once in scanner range. I can then re-engage the torus drive until it hits the reduced mass-lock.

It is a feature, as the wiki say: "Torus will turn off when a new ship arrive into scanner range but you can engange it again until your alert level is green." This help to check the arrived ship early and not after sliding near to a maybe dangerous one.

The exception what you found probably caused by a timing problem, but this is less disturbing and maybe imaginable in reality so I do not thinking on a fix of these.

To be honest this is the easier way, my code do no nothing to prevent masslock of an arriving ship, just free up after it is in the scanner. At that time a momentary masslock already happened so the player slow down regardless of the alert level will be green again in the next frame.

The behaviour what you assumed would require the change of scanClass over scanner range to be neutral at the moment when a ship arrive into the scanner. I have an idea where I plan to use this way on friendly ships but this worth another oxp. First time I mentioned it here and meantime I realized that it will be better without any slowdown and "j" presses.

[stranger]

Tweak simulating stealth mode - see https://bb.oolite.space/viewtopic.php?f= ... &start=225

[pleiadian]

If such a thing is possible (and it seems to be), new equipment could be seeded into a future version of Oolite, enabling some sort of stealth to the pilot, like a cloaking device. I'd impose the limitation of the cloak having to be disabled in order to engage Torus - or at least there being a delay of about 5 to 10 seconds... it has to remain fair. And at some point, the cloak would disable, like a ship very close, or being near a station (GALCOP regulation for ships fitted with cloak devices maybe?)

I like Variable Masslock btw.

[stranger]

Yes, cloaking distance is limited. Adder may close distance to 17 km being undetected - still beyond beam laser hit range. Moreover, any large ship or station reveals all cloaked ships in scanner range. It is fair play I think.