Hyperdrives OXZ

[Redspear]

v0.5

• separated jump limit from fuel limit
  (if you're jumping less then no need to also be injecting less, plus it looks much better with HUD gauges)

v0.4

• standardised base range for all ships = 5.0 LY

v0.3

• changed oxp category to 'Mechanics' as suggested by Norby.
   Hyperdrives page added to the wiki.
  restructuring of behaviour according to ships' 'size' and 'tech'.

v0.2

• fixes a bug re fuel availability
  changes equipment bonuses to plus one each but that bonus may not exceed +2

v0.1 now available:

This oxp limits the fuel capacity (and therefore the hyperdrive range) of the player ship according to an assigned base value plus modifiers according to equipment purchased.

• Base value of 5.5LY:
• Boa Cruiser

• Base value of 5LY:
• Cobra Mk III; Anaconda; Boa

• Base value of 4.5LY:
• Adder; Moray; Fer-de-Lance; Python

• Base value of 4LY:
• Cobra Mk I; Viper Interceptor; Constrictor

• Base Value of 3.5LY:
• Asp Mk II

• For oxp ships the formula used is:
• recharge rate + (cargo capacity /50)

• Equipment bonus of +0.5LY:
• Energy Unit; Galactic Hyperdrive

• Equipment bonus of +1LY:
• Wormhole Scanner

Does nothing to the functioning of the advanced navigation array (at least you can still hitch-hike through wormholes), or to non-player ship ranges.

- - - - - - - -

I've been working on something that cim posted last year when asked about limiting a ship's jump range.

Code: Select all

this.playerBoughtEquipment = this.shipScoopedFuel = this.playerStartedJumpCountdown = function()
{
 var fuelLimit = 5;
 if (player.ship.fuel > fuelLimit) { 
   player.ship.fuel = fuelLimit; 
 }
}

I tinkered with the above to get...

Code: Select all

this.startUp = this.playerBoughtNewShip = this.playerBoughtEquipment = this.shipScoopedFuel = this.playerStartedJumpCountdown = function()
{
	var fuelLimit1 = player.ship.maxSpeed / 50;
	var fuelLimit2 = player.ship.extraCargo / 5;
	var fuelLimit = fuelLimit1 + fuelLimit2;
	
	if (player.ship.fuel > fuelLimit)
	{player.ship.fuel = fuelLimit;}
}

Which worked nicely to limit jump range according to ship but still left a number of minor issues, some expected, some not...

I haven't even tried using it with the navigation array yet...
The typical hud display will make it look a little strange that the indicator is never full for some ships.
The fuel price is for a full 7LY tank, no matter how much you actually get.
But the one that's proving the most frustrating so far is that fuel is always offered for sale even after you've just filled your tank. So you can just keep buying it indefinitely until you run out of money.

This situation would appear to make sense in that the above code is actually removing fuel, rather than limiting the amount for sale.

So...

I thought a condition script might be able to stop fuel being offered when your tank's full, however my coding experience is very limited and the below attempt isn't working...

Code: Select all

this.allowAwardEquipment = function(eqKey)
{	
	if (eqKey == "EQ_FUEL")
	{	
		this.var fuelLimit1 = player.ship.maxSpeed / 50;
		this.var fuelLimit2 = player.ship.extraCargo / 5;
		this.var fuelLimit = fuelLimit1 + fuelLimit2;
	
		if (player.ship.fuel == fuelLimit)
		{
			return false;
			} else {
			return true;
		}
	}
	return true;
}

Any advice please?

[Norby]

You must copy the fuel part from oolite.app/Resources/Config/equipment.plist to your equipment.plist and change the condition_script line to your script.

[Wildeblood]

If you can't get the condition script approach to work for whatever reason, plan B would be to use guiScreenChanged: if to is F3 screen, check fuel level, and if it's at or over your limit, increase it to 7ly; then change it back down again if from is F3.

[Redspear]

You must copy the fuel part from oolite.app/Resources/Config/equipment.plist to your equipment.plist and change the condition_script line to your script.

Yeah, I think I did that but I also left in the "oolite_conditions" line because of a certain mission...
I suppose fuel's a special case as a 'piece' of equipment'...

If you can't get the condition script approach to work for whatever reason, plan B would be to use guiScreenChanged: if to is F3 screen, check fuel level, and if it's at or over your limit, increase it to 7ly; then change it back down again if from is F3.

I'll look into that as it seems like a clever work-around.

Thanks guys...

[Redspear]

OK, I got it to work as a condition script (this.var should have been var and the 50 value should be 100 for a noticeable effect).

Rather than making it compatible with Equipment by Ship Class I just used that framework as a basis for a formula for the hyperspace range of the core ships and came up with this:

4 - 5 LY

• Adder

4.5 - 5.5 LY

• Cobra Mk I, Moray

5 - 6 LY

• Asp Mk II, Python, Viper Interceptor

5.5 - 6.5 LY

• Anaconda, Fer de Lance

6 - 7 LY

• Boa, Cobra Mk III, Constrictor

6.5 - 7 LY

• Boa Cruiser

The range of each is extendable by up to 1 LY by purchasing certain equipment. Rather than add a bunch of Hyperdrive units to the game (which sounded cool but contributed to clogged F3 and F5 screens), I thought that a couple of core equipment items could boost hyperspace range. Currently chosen for this role are the energy unit (+ 0.5 LY) and the galactic hyperdrive (+ 0.5 LY).

This is all working nicely apart from integration with the Navigation Array (been avoiding this one so far) and contributes to my desire for the game to 'open up' as I slowly upgrade my way through various ships. I realise that there are potential issues with mission compatability and may chose to up LY ranges by another 0.5.

For those who stick with the Mk III, I thought it might be interesting to have a reason to install the galactic hyperdrive besides switching galaxy, and be fun if a ship with equipment damage could lose some of it's hyperspace range temporarily.

So, this thing still has an issue or two but is coming along quite nicely.

[Layne]

4 - 5 LY

• Adder

4.5 - 5.5 LY

• Cobra Mk I, Moray

5 - 6 LY

• Asp Mk II, Python, Viper Interceptor

5.5 - 6.5 LY

• Anaconda, Fer de Lance

6 - 7 LY

• Boa, Cobra Mk III, Constrictor

6.5 - 7 LY

• Boa Cruiser

With all due respect to your idea, I think this is the opposite of how the jump ranges need to be worked out. The model Frontier used is a better guidepost, in my opinion-- jump range decreases with mass. The larger a ship, the /smaller/ the jump range should be. Bigger ships get the advantage of better defenses, more weapons and missile pylons; smaller ships get the advantage of being faster. It just seems to be a better way to balance the tradeoffs of size. If we start with the Cobra III as the 'baseline' with a jump range of seven LY (per canon), then any ship smaller in mass should have a larger jump radius, and any ship larger than a Cobra III a smaller jump range. The problem, of course, comes with having some systems becoming impossible to reach with smaller jump ranges.

[Redspear]

The larger a ship, the /smaller/ the jump range should be. Bigger ships get the advantage of better defenses, more weapons and missile pylons; smaller ships get the advantage of being faster. It just seems to be a better way to balance the tradeoffs of size. If we start with the Cobra III as the 'baseline' with a jump range of seven LY (per canon), then any ship smaller in mass should have a larger jump radius, and any ship larger than a Cobra III a smaller jump range. The problem, of course, comes with having some systems becoming impossible to reach with smaller jump ranges.

Well, that's certainly one way to do it but I think there are some other problems with that approach. Apologies if you're well aware of these...

• I believe it is still the case that there is a hardcoded limit of 7LY for any jump, so with the MkIII being one of the larger ships then there's not much room for manouver
• Certain missions assume both a 7LY reach and limit. Players can possibly hitch a 7LY jump even if they can't make one themselves, but jumping above 7LY really is a game changer
• The Cobra III being the default ship means that 7LY (or the capability for 7LY) is both expected and desirable
• For those who like an 'adder start' or similar then the idea of trading up and losing jump range (below 7LY) is probably undesirable

But please, if there are other ways of doing it (or if I've misinterpreted your suggestion) then feel free to 'throw them in the pot', I'd love to find a better way to do this.

Thanks.

[mohawk]

The problem, of course, comes with having some systems becoming impossible to reach with smaller jump ranges.

Perhaps this could be worked around if there was a new hyperspace technology that allowed to target an unreachable system in more than one step.
so if the ship can only jump 5 LY it can jump in the witchspace 5 LY away from the starting system, and then jump 2LY to the final destination (after dealing with the dangers of the witchspace of course)
that would mean of course that the jump ranges would have to be independent of the ships fuel, (it could be restricted by the mass and the mambo jumbo physics and technology handwavium) after all I never understood why an anaconda can not carry 100 tons of fuel an jump to the other side of the galaxy!

This of course would make it very easy to reach the unreachable systems, so I don't know.... just throwing thoughts around
maybe as a trade of a lot of pirates could lurk in the witchspace at the known distances, waiting for the ships to appear.
maybe there could be some short of jump supercharger like the galactic jump drive that allows you to target an off range system and perform a multi jump travel.

[Layne]

[*]For those who like an 'adder start' or similar then the idea of trading up and losing jump range (below 7LY) is probably undesirable[/list]

You gain cargo space and missile pylons and laser mounts in exchange. No, you can't-- and shouldn't-- have everything on one ship. Every ship should be viable for an entire career, though not necessarily the same career. There should never be any ship which is 'uber', it should always be a matter of trade-offs of speed, jump range, cargo space, weapons capacity, maneuverability, etc. If you plan to trade up to a larger ship and want better cargo space, then you sacrifice jump range. Sadly, I see no way around the Cobra III bottleneck; canon establishes it as having a seven LY range, which is why it's a hard-coded limit in the game. Ideally, ships smaller than that should be able to jump farther in a single bound.

Again, that's the Frontier paradigm for balancing ships-- it wasn't Elite's, nor is it necessarily Oolite's, unless you choose to make it so. Just tossing the thought out there.

[Redspear]

Perhaps this could be worked around if there was a new hyperspace technology that allowed to target an unreachable system in more than one step.
so if the ship can only jump 5 LY it can jump in the witchspace 5 LY away from the starting system, and then jump 2LY to the final destination (after dealing with the dangers of the witchspace of course)

There are oxp options out there (extra fuel tanks comes to mind) but I could also code a way for some ships to be able to jump up to twice the distance normally possible with their remaining fuel (still subject to 7 LY limit but would enable more jumps on one tank).

that would mean of course that the jump ranges would have to be independent of the ships fuel, (it could be restricted by the mass and the mambo jumbo physics and technology handwavium) after all I never understood why an anaconda can not carry 100 tons of fuel an jump to the other side of the galaxy!

There's also Injector Burn Rate to consider as a means of rebalancing any alteration in fuel capacity.
As for the anaconda, I suppose a possible analogy would be that I can carry a bucket of water but my body can't process it all at once, at least not without most of it passing straight through...

just throwing thoughts around

Please, continue

No, you can't-- and shouldn't-- have everything on one ship.
... There should never be any ship which is 'uber', it should always be a matter of trade-offs of speed, jump range, cargo space, weapons capacity, maneuverability, etc.

Whilst "can't" might be a bit strong I'd basically agree with you there but I'd also add economy to that list. We have some options there besides ship cost: there's also fuel and repair costs and we also the aforementioned injector burn rate. Perhaps smaller ships have a shorter hyperspace countdown duration.

There's also the idea of superceded / outdated models (consider the Krait and the Python as listed in the elite manual).

Sadly, I see no way around the Cobra III bottleneck; canon establishes it as having a seven LY range, which is why it's a hard-coded limit in the game. Ideally, ships smaller than that should be able to jump farther in a single bound.

That seems to be very much at the heart of it.

I based my thinking around my work on Equipment by Ship Class which used 3 criteria for each ship, of which size was only one. So should high-tech ships have longer ranges? Should military spec ships have longer ranges than service grade ships? Is size different a boon for service vessels but not for civilian ones? I could certainly have a rethink on how the three categories (as I see them) should interact.

The smallest core ships don't have a hyperdrive of course, so there's that to consider too.

Just tossing the thought out there.

And it's very much appreciated

[Layne]

I based my thinking around my work on Equipment by Ship Class which used 3 criteria for each ship, of which size was only one. So should high-tech ships have longer ranges? Should military spec ships have longer ranges than service grade ships? Is size different a boon for service vessels but not for civilian ones? I could certainly have a rethink on how the three categories (as I see them) should interact.

Is the base speed of a Witchspace jump also hard coded? As in, how long in game time does it take to jump two LY, four LY, six LY, a-plenty? I know there's a formula for it, but is that alterable? Or barring that, can the game clock itself be ker-jiggered and mildly befuddled? What if the advantage in speed for smaller craft were coded into their jump itself? Smaller ships take less game time to go the same distance in light years? There are a couple of potential problems with this, too, namely escorts and convoys becoming separated if they use multiple wormholes with different arrival times. But if the effect could be tied to the ship that opened the wormhole, then the arrival time would be determined by the lead ship. Of course, then there's the question of why would they use the lead ship to open the wormhole if a smaller ship can create one that's quicker? Musing, amusing, rattling around mental pebbles. Perhaps if there's a mass limit on wormhole size, too, but that opens up many more cans of worms than I have hooks to bait.

[Redspear]

Is the base speed of a Witchspace jump also hard coded?...

I believe so. Some events do alter the ships's clock however, so that might be do-able.

Perhaps if there's a mass limit on wormhole size, too, but that opens up many more cans of worms than I have hooks to bait.

A potentially interesting variation lies with wormhole duration. I believe it is hardcoded by ship mass but imagine if it only lingered very briefly for small ships. So escaping from a pirate pack in a python might be tricky but in an adder it's likely that you'd at least lose most if not all of them by making a hyperspace jump.

Again, certain missions could be affected...

[Redspear]

Thinking some more about the 'to every ship its role' idea, one idea that would appear to be consistent with canon would be with regards to planetfall.

Now this is an OXP of course but even in the core game it is implied that transporters and shuttles make their way from the station to the planet. These ships are relatively small, so perhaps such a role is impractical for larger vessels. A special ability of the adder (according to the elite manual) was planetary landing (sidewinders were also 'atmosphere capable' if I remember). Maybe the largest ships can't land under normal circumstances, medium sized ships can land on planets but only the smallest ships can land on moons (again, an oxp thing). 'Normal circumstances' would allow for exceptions (specialised landing areas etc.) and therefore potential mission 'immunity'.

I've started oolite careers before in an adder, a worm and even a shuttle (no weapons) and a big part of the appeal was what lay ahead. That future reward lay not just in equipment and missions anymore; it was fun to fly past a Cobra III and think, "one day..."

Uber without the uber, nerfing without the nerf, it's possible with a bit of creative thinking but tricky to get right. A good thing about this little project is that assigning ranges up to 7LY is the easy part, if I can get everything else to work then folks can assign them however they want.

[Layne]

I've started oolite careers before in an adder, a worm and even a shuttle (no weapons) and a big part of the appeal was what lay ahead. That future reward lay not just in equipment and missions anymore; it was fun to fly past a Cobra III and think, "one day..."

Uber without the uber, nerfing without the nerf, it's possible with a bit of creative thinking but tricky to get right. A good thing about this little project is that assigning ranges up to 7LY is the easy part, if I can get everything else to work then folks can assign them however they want.

I do agree; the size of a vessel should make a difference regarding planetary landing. Worms and shuttles are /designed/ to operate in atmospheres, and that makes sense given their in-game story. A big freighter like an Anaconda probably shouldn't have the same capability. Medium ships may be somewhere in between, requiring some extensive upgrades for it (hence the fitting costs in the Planetfall OXP).

My own experience with Oolite lay in the opposite direction from you-- I started with the standard Cobra III and saw the tiny nimble ships darting about like elegant kites and thought, 'Heck, that looks way more fun to fly!' It's all in what the player wants out of the game!

I find your speculations on the utility of wormhole duration to be a very interesting direction to take. Smaller ships have faster jump times, but the wormhole is prone to collapse quickly, hence, not very safe for convoys or escorts. Larger ships create more stable wormholes that take longer to reach their destination. The trade-off seems reasonable.

Also, the Nerf Über, coming this holiday to a very dull toy store near you.

[Redspear]

My own experience with Oolite lay in the opposite direction from you-- I started with the standard Cobra III and saw the tiny nimble ships darting about like elegant kites and thought, 'Heck, that looks way more fun to fly!'

One difference is that starting with the ol' Mk III, you can trade for a smaller ship right from the start (unless you want the Asp of course...)

It's all in what the player wants out of the game!

Totally agree.

I find your speculations on the utility of wormhole duration to be a very interesting direction to take. Smaller ships have faster jump times, but the wormhole is prone to collapse quickly, hence, not very safe for convoys or escorts. Larger ships create more stable wormholes that take longer to reach their destination. The trade-off seems reasonable.

Looking into it a bit more, it seems that some of that is already in game. If I understand correctly, wormholes can be 'collapsed' by a large enough ship entering them and this is adjustable via ship density (although not without altering collision behaviour).


Thinking of the EbSC model again, perhaps ship grade would be the most relevant to hyperdrive range.

• Military ships up to medium size are likely to have carriers to move them any significant distance and so their own hyperdrive range is likely to be limited.
• Civilian vessels would require a degree of range in order to be flexible/commercialy appealing
• Service vessels might be required to deliver significant cargoes over great distances

Equipment that might boost range could include: galactic hyperdrive, wormhole scanner, extra energy unit.
The advanced navigation array might be another option but it would need to cooperate with the various ranges first (i.e. anything other than 7LY).