Masslock Compensator OXZ

[Redspear]

A simple little expansion to make masslocks less time consuming.

It works by recognising two types of masslock:

Passive Masslocks - These are how typical masslocks begin: the player is masslocked by an entity that has no wish to delay the player. In game this is the situation during yellow alert.
Active Masslocks - This is where an entity actively hinders the player's escape from masslock, typically to engage in combat. In game this is the situation during red alert.

During passive masslocks, the player ship's masslock compensators will be activated granting extra speed (x2) to assist in escaping masslock.
During active masslocks, the same compenstors will be disabled by 'jamming' from enemy vessels.

Pros: The slower player ships are less tedious to pilot and masslocks generally are less mind-numbing.
Cons: Like the torus drive itself, it's another player-only concession.

Rationale: (This is up to the player of course but here's one to consider...)
Assuming (for sake of argument) that non-player ships actually had torus drives, it becomes highly likely that masslocking ships meet one of the following three conditions:

• They are heading in the opposite direction
• They are slower than the player ship (torus drive based on ship max speed)
• They are somehow dawdling or have only just started up their torus drive

Each of these conditions provides (IMHO) a reasonable argument for the player to be travelling faster than the masslocking vessels. So it could further be argued that this oxp creates a simulation of torus-slowing rather than torus-breaking in a way that isn't obviously player centric. A player can be masslocked from behind of course but (for me at least) this is a very rare ocurrance considering that there is typically a good deal of space that the player has already torus-driven through.

There are other conditions in which masslock can occur but they typically don't involve a tedious spacelane 'race' to overtake or evade other vessels.

Future Considerations:

• Speed boost could be reduced or increased but x2 seems about right to me
• There could be an equipment item to gran a further boost for slower vessels (x3 perhaps)
• It could be disabled within the aegis of stations

Meanwhile, if masslocks are getting you down then this little thing should make things much more tolerable without significantly changing gameplay.

Available from the download manager.

[Disembodied]

A good idea! The Torus drive already requires the player to turn a blind eye to the fact that no other ships possess one, so this sort of workaround to avoid traffic jams doesn't really break any immersion for me.

Does it take any time to kick in? I think it probably should, if only so that any potentially hostile ships have the chance to make up their mind as to whether or not they're going to attack the player (the handwave could be that it takes 5 or 10 seconds for ships to "align their torus fields" to compensate for a masslock).

I think a total masslock should definitely apply within the station aegis - and probably within masslock range of any sufficiently large body, e.g. a planet or star. Would this complicate things, though?

[Redspear]

You're right of course that any aggressors need adequate opportunity to missile lock the player. There is no activation delay at present but the main reason is that early testing appeared to indicate that it simply wasn't necessary.

Prior to testing this thing I've been missile locked even when using fuel injectors to power through masslocks (they just didn't have time to catch me). So if that was at ×7 then ×2 should be ok.

As a quick note for anyone interested on the maths here: ×2 doesn't mean you overtake twice as fast, rather it depends on the proportional change in relation to any other ship's speed.
e.g. a cobra III overtaking a moray is normally 0.35 vs 0.3 meaning masslock is escaped at a very slow 0.05. With a ×2 bonus however, it's 0.7 vs 0.3 meaning masslock is escaped at a much improved 0.4 (actually 8 times faster than in the standard game).

As for complicating things, disabling near a star is probably important for sun-skimming and it seems reasonable that a station might auto-jam any vessels in the vicinity. I think I know how to code those changes but I'll consider further before implementing them.

Thanks for the feedback

[Nite Owl]

Gave it a try and would have to agree that it should be disabled when in and around anything that you might dock with. The problem one has if it is not disabled in such a situation is that your speed while trying to dock is definitely affected. The slightest increase in thrust while approaching the docking port gains much more speed then one is accustomed to which could result in a nasty bump. Sure, over time one would learn to compensate but not all thrust adjusters are created equal, keyboard, joystick, flight stick, whatever else there might be. Many of these devices are just a little too finicky to have your thrust suddenly jump much more then you are accustomed to it doing for a given amount of thrust adjuster movement. Great idea for avoiding long drawn out masslocks while traversing open space though.

Wondering if the speed increase would have any effect on random encounters such as those provided by Space Crowds or Deep Space Pirates. Did not run into any of those encounters during my brief test run. Once the thrust around docking ports problem is solved will give it a further workout to see what effect it might or might not have on such randomness.

The only other minor problem is the constant comm messages popping up. Given that encounters with this OXZ installed happen at a much quicker frequency than before the comm messages are constantly popping up every few seconds, or so it seems. Perhaps one message on launch from a station that the system is active would be enough. The ultimate prize would be a HUD light, green when active, red when inactive, but that may be going a bit too far.

[Redspear]

Thanks for your thoughts Nite Owl.

Re: thrust, max speed is increased but thrust is unaltered. Therefore acceleration/deceleration should be no more 'twitchy' than before, it would just take slightly longer to go from max to min speed. You can test this by opening up the oxz and editing the *2 to *5 or *10. It should then be very obvious that thrust has been unaffected by the change in max speed as you now have to start slowing down much earlier in order to stop. Disabling within the aegis however is likely to happen in the next update so this should be a non-issue in future.

Re: comms, I put them in to make clear what was happening and (indirectly) why. The HUD I'm using at the moment displays such messages in relatively small text in a bottom corner of the screen and so it's less jarring for me than it may be for others. The messages aren't strictly necessary of course and so I'll consider reducing/dropping them.

Random encounter generating oxps were not part of my early tests however the main issue, with any encounter, is where it first appears on the scanner. This tends to be between then 'ten to two' position on the clockface. Any such encounter in such a position should have sufficient opportunity to masslock the player. Occasionally ships pop up on the sides of the scanner but even in normal play their scanner time can be very brief, giving them no real chance to engage. I'd be interested to hear any more feedback on this but I'm not anticipating problems at present.

The HUD light is a nice idea but not only is it a HUD dependant element (i.e. I'd need to override the player's HUD choice) but most of the time (all of the time in this version) it would match the (already present) status light - green: no masslock, yellow: passive masslock, red: active masdlock.

[Redspear]

Update's nearly ready.

• Deactived compensators in the aegis of main stations, planets and stars.
• Other stations don't have an aegis IIRC and so they do not deactivate the compensators at present (and to be honest, I think I prefer it that way).

Is it still the case that the only place you can save game is docked at a main station?
If not then I'll have to find a workaround for saving outside of an aegis...

Testing is normally a bit of a chore but this has been quite fun
Got masslocked by a python and its escorts at approx 3 o'clock near the edge of the scanner (headed in opposite direction). They still had time to masslock me and the sidewinder meant that I couldn't escape them entirely. Once I was tageted of course, the speed bonus from this oxp is disabled (red alert).
Not too shabby

The cobra III no longer needs its 0.05 bonus to speed (which I strongly suspect was added simply to reduce masslock fatigue) nor does the moray need its identical bonus in order to be playable. However, without any alerations there is a pleasing correlation with the original elite game.

• Speed at which Masslock is escaped
  
  .......................... Elite (vs. python) ... / ... Oolite (vs. python) ... / ... MLC oxz (vs. python)
  
  Cobra Mark III ....... 0.3 (+ 0.2 = 0.5) .... / ... 0.35 (-0.2 = 0.15) ... / .... 0.35 (*2 - 0.2 = 0.5)
  
  Moray Starboat .... 0.25 (+ 0.2 = 0.45) ... / .... 0.3 (-0.2 = 0.1) .... / ..... 0.3 (*2 -0.2 = 0.4)
  
  Adder .......... .... 0.24 (+ 0.2 = 0.44) ... / .... 0.24 (-0.2 = 0.04) .... / .. 0.24 (*2 -0.2 = 0.28)

I've included the adder to because it's a popular start choice for some and also because it has a similar speed to the original moray.

For all three ships, masslock duration is considerably reduced (and by an approximately similar proportion). The adder could even overtake an asp whilst in masslock (albeit slowly - however at 0.24 *2 = 0.48 it would still overtake at 0.08, which is twice as fast as it would a python in the standard game!)

In the interests of clarity, the numbers given for oolite are for ships headed in the same direction as you (impossible in elite unless you changed your course mid-masslock). In elite, I'm almost certain that the scanner was smaller too (at least in some incarnations) and so masslocks are not always as brief as in the 1984 game.

[phkb]

Is it still the case that the only place you can save game is docked at a main station?
If not then I'll have to find a workaround for saving outside of an aegis...

You can save the game at any station that has been added to the system via the system populator functions, with the "deterministic:true" property set. Here's an example from the Free Trade Zone OXP:

Code: Select all

		var posFTZ = Vector3D(0, 0, -0.3).fromCoordinateSystem("wpu");
		system.setPopulator("ftz", {
			callback: function(pos) {
					if (system.countShipsWithRole("free_trade_zone") == 0) {
						var ftz = system.addShips("free_trade_zone", 1, pos, 1)[0];
						if (ftz.script.shipDied) ftz.script.$ftz_ovr_shipDied = ftz.script.shipDied;
						ftz.script.shipDied = worldScripts.FTZ_Core.$ftz_shipDied;
					}
				},
			location:"COORDINATES",
			coordinates:posFTZ,
			deterministic:true
		});

[Redspear]

Thanks phkb.

So if I'm using,

Code: Select all

this.shipLaunchedFromStation = function()

Would,

Code: Select all

if (isMainStation = true)

be a valid way to distinguish?

[phkb]

Well, it would look more like this:

Code: Select all

this.shipLaunchedFromStation = function(station) {
	if (station.isMainStation === true) {
		...
	}
}

[Redspear]

That's what I meant

Thanks

[Redspear]

Version 1.1 now available.

Changes:

• Disabled in station aegis
• Disabled in close vicinity of star
• Console messages limited to indicating the above exceptions

[Redspear]

v 1.2 available

Only change is that slower vessels are granted a minimum bonus as if they had a speed of 0.3LM.
Therefore every player ship should be able to overtake every non-oxp ship at a reasonable rate when in yellow alert.

[Damocles Edge]

After trying masslock compensator I thought I report back on some behaviour which I found unsettling (but not sure whether it was intentional or not).
Basically I'm flying an anaconda with an escort deck and whilst I normally have a max speed of 140 m/s (which I've kinda got used to now), I became startled when my normal flight speed (not torus) had shot up to 600 m/s.
This was alarming when rapidly gaining on an FDL travelling at only 100 m/s (it has to be said that an anaconda hurtling along at 600 m/s comes to a graceful and composed stop in the same way that a house brick hurled at fine porcelain ornament does).


Like I say I'm not sure if this is intentional or not, if it is not then I have kept the Latest.log in the hope that it may yield some help.

Cheers

[Redspear]

Like I say I'm not sure if this is intentional or not,

It's entirely intentional and explicitly stated in my previous post
i.e. normal max speed < 300, therefore when compensators active treat as 600 (as the whole point of this oxp is to double speed in yellow alert).

If the anaconda's speed were only doubled as before then here's a list of core ships that it could be bogged down by when in yellow alert:

• Moray
  Gecko
  Boa Cruiser
  Cobra III
  Krait
  Viper
  Asp II
  Fer de Lance
  Mamba
  Viper Pursuit
  Sidewinder
  Viper Interceptor

And it could only crawl past the following:

• Adder
  Cobra I
  Boa

One of the key characteristics of the Anaconda is that it is slow so this might seem odd (I explained a rationale upthread) but consider that should that FdL decide to attack the anaconda then it's max speed will promtly return to 140 as the masslock compensators are disabled when in red alert.

I've considered making the minimum value 250 rather than 300 but those viper interceptors are awfully fast...

[Damocles Edge]

That all makes sense

Thank you for clearing up my misunderstanding