Messing about with Jump Ranges...

[Redspear]

Meddling around with the source code again and wanted to experiment with altering the maximum jump range of the player ship.

Found Player_Max_Fuel in PlayerEntity.h (if memory serves) and so now have the desired fuel capacity but a bit more is required to actually make those jumps within the game.

Could anyone in the know provide a bit of signposting please?

Thanks.

[another_commander]

It must be related to the methods used in planet distances calculations and rounding that takes place in order to match the original Elite calculations.

What happens if you substitute every call to distanceBetweenPlanetPositions with a call to accurateDistanceBetweenPlanetPositions (which does not do any rounding)?

[Redspear]

I'll investigate.

Thanks.

[kanthoney]

I think you'd need to change the MAX_JUMP_RANGE constant in src/Core/Entities/ShipEntity.h

[Redspear]

I think you'd need to change the MAX_JUMP_RANGE constant in src/Core/Entities/ShipEntity.h

That worked a treat, thanks!

Now for the cosmetics.

Trying to get the shortrange chart to display appropriately

• For the jump range circle to exceed 7.0LY (up to 9.0 in this case)
• For the 'zoomed in' size of the chart to provide sufficient room to display the above

Been looking in GuiDisplayGen but it's escaped me thus far.

[kanthoney]

Ah. Yes. There's been a touch of short-sightedness on my part there, I'm afraid.

If you look at line 108 in src/Core/Entities/PlayerEntity.h:

Code: Select all

#define CHART_MAX_ZOOM			(256.0/CHART_WIDTH_AT_MAX_ZOOM)

This is the zoom level for the long range chart. If I'd thought about it I'd have included a line

Code: Select all

#define CHART_MIN_ZOOM 1.0

right next to it. Then all you'd have had to do is change the 1.0 to 1.3 or something and you'd be away. Unfortunately, I didn't think anyone would want to tweak the zoomed-in value so it's hardcoded as 1.0 everywhere. And looking at the code it's hardcoded as 1.0 in an awful lot of places.

I guess to start with you could add the CHART_MIN_ZOOM line above, then try changing the following lines. In src/Core/Entities/PlayerEntity.m, line 1050,

Code: Select all

chart_zoom = [dict oo_floatForKey:@"chart_zoom" defaultValue:1.0];

Change the default zoom value to CHART_MIN_ZOOM. Then likewise, in the same file, lines 1080-1082 and 1930-1932:

Code: Select all

chart_zoom = 1.0;
target_chart_zoom = 1.0;
saved_chart_zoom = 1.0;

Then in src/Core/Entities/PlayerEntityControls.m, line 1891

Code: Select all

if (target_chart_zoom < 1.0) target_chart_zoom = 1.0;

change both 1.0's.

Those changes should set the default zoom level, although it'll still let you zoom in further to the usual zoom level if you try. If you want to stop that happening, you need to look through the files src/Core/Entities/PlayerEntity.m and src/Core/Entities/PlayerEntityControls.m for any place that chart_zoom or target_chart_zoom or something is set to or compared with 1.0 and change that to CHART_MIN_ZOOM.

[Redspear]

Thanks Kanthoney, all the stuff before the last paragraph (not tried it yet) worked great

As for the jump range circle, that is indeed set in GuiDisplayGen.m and changing line 1886 to the following seemed to do the trick:

Code: Select all

GLDrawOval(x + cu.x, y + cu.y, z, NSMakeSize(0.5*(float)([player fuel]*hscale), (float)([player fuel]*vscale)), 5);

That was for a chart zoom value of 1.3 rather than 1.

[Redspear]

I may well be doing something foolish here but changing line 2369 in GuiDisplayGen.m to:

Code: Select all

float jumpRange = MAX_JUMP_RANGE * [PLAYER dialFuel];

Alters the Advanced Navigation Array as follows -

The background mesh of possible routes is now based on current fuel rather than maximum jump range.

Benefits -

• works much better with hyperdrives.oxp
  the mesh continues to be relevant in any situation where you might have less than full fuel capacity (although the standard fuel circle does most of that work)

Disadvantages -

• I can't see any given that the route planning appears to be unaffected

[Redspear]

Apologies to anyone trying this out for themselves but those last two code alterations I listed should have diiferent line numbers...

Code: Select all

GLDrawOval(x + cu.x, y + cu.y, z, NSMakeSize(0.5*(float)([player fuel]*hscale), (float)([player fuel]*vscale)), 5);

Should be line 1877.

Code: Select all

float jumpRange = MAX_JUMP_RANGE * [PLAYER dialFuel];

Meanwhile, should be line 2360 (I think...)

[another_commander]

I think that the ANA should have a fixed reference for route calculation and that fixed reference is a full tank. If you just let it plan routes based on fuel remaining, then your routes could change based on whether you refuelled during your last stop or not. For example, you have 3.4LY remaining, you view your ANA proposed routes, then fill up and launch. Thing is, if you don't remember to look again at your ANA, the routes you saw earlier may now be different.

Since you are playing with the Windows trunk though, you could probably incorporate your proposed change relatively seamlessly. For a few revisions now, we've had the ability (unused so far and unfortunately not available on Macs yet) to track the status of the Caps Lock key, so you can use that as an easy way to set the routes display mode relative to jump range. You can keep things as they are and change them to what you propose if Caps Lock is active. To check for Caps state, you only need to check the result of the [gameView isCapsLockOn] method.

In case you are trying to increase fuel capacities of ships (I see you are trying to extend the fuel range circle to beyond 7LY), be aware that the ShipEntity method - (OOFuelQuantity) fuelCapacity, which is used as input for PlayerEntity's - (GLfloat) dialFuel, which is used for jump range calculations, returns a fixed result of 70 (7.0LY) at the moment, so you will probably have to tweak that too.

[Redspear]

What I'd really like to do is to make max_jump_range and player_max_fuel determinable by shipdata.plist. Although I have ships that can jump up to 9.0LY I also want ones that can jump 7, 5 or even less - I want a situation with greater variety than the current 7 or nothing. Hyperdrives.oxp is a fudge to have ranges below 7 and my tinkerings above have been to achieve ranges above 7.

I actually like the idea of an ANA that is more responsive to your current situation (and fuel) but I take your point that this requires a little more vigilance on the part of the user. With the adjustments above however, the ANA still has a constant of max_jump_range, only the the grey mesh of planetary routes changes with fuel capacity.

be aware that the ShipEntity method - (OOFuelQuantity) fuelCapacity, which is used as input for PlayerEntity's - (GLfloat) dialFuel, which is used for jump range calculations, returns a fixed result of 70 (7.0LY) at the moment, so you will probably have to tweak that too.

Thanks, I'll need to check that out and the Caps Lock thing may well be something I'm tempted to try too

[Redspear]

Big problem with a larger jump range of course is that it can make the 'galaxies' feel smaller.
Whilst Pleb has illustrated before that bigger galaxies are possible, they aren't exactly huge as things stand; so a bigger galaxy without the extended jump ranges is probably preferable to one with.

The way that travel time is calculated means that more numerous, shorter jumps are encouraged for any player running contracts, and so by association exploration of some of the less obvious player destinations is also encouraged. Whilst a shorter hyperdrive range would also necessitate this it doesn't really add it to the game. What it does add however is 'roadblocks' so that the route becomes more important. Reduce by too much and you can't travel very far at all, with any significant reduction making some systems unreachable.

So, is there another way to create such obstacles? System government performs some of this role by making some places much riskier than others but if you have sufficient fuel you can jump to any system within range. What if there were occasionally another requirement? It might be as simple as no system being connected to more than four other systems or two systems beginning with letters more than 13 places apart in the alphabet not having a hyperspace route.

Maybe some routes are just more problematic and so require double fuel and/or double time. Maybe some are available only some of the time or are much more prone to Thargoid intervention. Perhaps some jumps are only availble from the witchpoint or near the sun or are only one-way jumps. There's also ship maintenance level and some routes could have stricter requirements than others. Could a Corporate system make jumps from the nearby Anarchy system illegal?

I don't consider complexity desirable but simple strategy or even just choices with consequence can be. I also don't feel like I have a satisfactory method for this idea yet (and it could play havoc with contracts) but I do like the idea of risky/prohibited jumps. Hmmm....

[Disembodied]

I don't consider complexity desirable but simple strategy or even just choices with consequence can be. I also don't feel like I have a satisfactory method for this idea yet (and it could play havoc with contracts) but I do like the idea of risky/prohibited jumps. Hmmm....

Interesting possibilities ... maybe systems which are "plagued by unpredictable solar activity" could have tricky jump conditions?

[Redspear]

I like that idea as it's making more of something that's already in game.

Perhaps the most obvious quirk would be to give a jump a small chance to be random (in terms of destination) but that's probably just as annoying as it is interesting. A less severe variant of that would be to make it random but only to a nearby system - like when you hitch a ride through a wormhole where the destination is unknown. More risk than 'roadblock' though. Connecting it to solar activity might make it both rare enough and predictable enough to still be strategic.

I quite like the idea of routes being closed for political reasons but given that you can jump from almost anywhere, how might that work? Perhaps the witchpoint beacon is the key - maybe it needs to send a signal to nearby systems in order to facilitate travel from those systems. Were there to be sanctions/safety concerns re nearby systems that signal could be scrambled or otherwise selective. Those priorities could be abandoned or unpredictable in the case of events such as civil war (again, in game).

[Disembodied]

Perhaps the most obvious quirk would be to give a jump a small chance to be random (in terms of destination) but that's probably just as annoying as it is interesting. A less severe variant of that would be to make it random but only to a nearby system - like when you hitch a ride through a wormhole where the destination is unknown. More risk than 'roadblock' though. Connecting it to solar activity might make it both rare enough and predictable enough to still be strategic.

I like your earlier ideas about jump duration (it might take longer than normal, by some factor, to enter, or leave, a system with "solar activity"), and fuel use (maybe there's a strong chance of a fuel leak, as solar radiation denatures your quirium fuel). Alternatively, it might just be impossible to leave a system during a solar storm: if the "weather" is bad, the player would just have to wait it out. Any effects would have to be flagged up to the player, though: for solar "weather", there would need to be a forecast, and alerts on launching (perhaps pre-launching, with an option to wait - perhaps for days - for the all-clear?).