Split: Re-scaling experiment

[Redspear]

On ambient light. It seems to be the case that without shader influence, the extent to which the dark side of the planet is visible is also the extent to which the dark side of a ship is visible. So a value like 0.6 for example has the quality of being too much for a planet surface yet still falling short for a ship surface.
Fairly obvious I suppose but perhaps worth spelling out.

Now that I've got more freedom to scale things independantly of each other (and somewhat surprised by how close that mk3 was on the scanner) I'm going to try the following:

Scanner x1
Fighters & multi-role x2 (incl. cargo pods etc but not thargons)
Freighters and stations x4

This, however, is a lot of fun

I've tweaked it slightly to these values:

• Scanner & Thargons x1
• Fighters x2
• Multi-Role x3
• Freighters & Stations x4

If you want to try it then you'll likely need to increase the nav-buoy distance in oolite-populator.js or some of the larger vessels will have trouble docking.

• Combat is both a little easier and much more visually exciting.
• 3-4 pirates can still be enough to take down a combat rusty (but experienced) pilot armed with a beam laser and some missiles. Some I won, some I lost.
• At x3 the mk 3 will have to match rotation again in order to dock - it won't have to match it particularly well but it will at least need to consider it (at x2 it can almost ignore it).
• You see the ships much more clearly so they're more often identifiable and much prettier in game rather than just via screenshots.
• Some of the freighters might be identifiable on the edge of the scanner but they're still small at that range.
• The km distances given by the scanner targeting enhancement seem even more improbable than they used to but not sure that's a significant casualty.

No speed or laser range changes required for the above test but nearly every item has been rescaled.
And in case it isn't already obvious to anyone: if you don't scale planets, suns and distances at the same time then it will look a bit ridiculous. Fun but ridiculous

[Redspear]

OK, so two different builds are emerging here. Firstly a more conservative, oxp friendly, cosmetic build. Secondly, a radical, oxp unfriendly, test build.

The cosmetic possibilities have been mentioned at some length already I think. Adjusting laser ranges disproportionately to the scanner has been discussed and that's an example of more radical adjustment.

Suppose ships were twice as big as before:

Weapon range: more useful (easier to target)
Combat: easier

Now suppose ship speeds were twice as fast:

Weapon range: less useful (less time to exploit)
Combat: harder

If you combine both size and speed then they can cancel each other out (I did this in reverse when I was scaling around the station in earlier versions - ship sizes and speeds halved). So if they balance each other then where is the advantage?

Mass lock : double speed means double speed difference between ships. Therefore somebody clears scanner range faster and mass lock duration is generally halved.

Escaping combat : again, speed difference is the key, so as long as the scanner has not also increased in size then escape times are halved.

Visuals : ship design and detail is clearer simply because they appear twice as big at any given range.

So, to be more oxp friendly, why not just shrink the scanner and the laser ranges instead? Well, there appear to be many assumptions around those two elements that are hardcoded into the game. Whilst I could try (and have at least partially managed) to address them all, it's easier to get odd ship behaviours as a result of missing something. Worse: what that something might be isn't always obvious.

This time however, if I'm not also adjusting laser ranges then there will be more of a dogfighting look to the game but I suspect that weapon range will be disadvantaged slightly (bigger target is good but less time hampers the more accurate pilots). However, both of those changes could be good. Needs testing of course.

Can anyone tell me where the 'km' for the target scanner enhancement is set please? With bigger ships it should probably register as 'hm' or (given that hm is uncommonly used) just divided by 10.

[another_commander]

Can anyone tell me where the 'km' for the target scanner enhancement is set please? With bigger ships it should probably register as 'hm' or (given that hm is uncommonly used) just divided by 10.

It is in HeadUpDisplay.m, hudDrawReticleOnTarget function. Look for the comment // add text for reticle here - it's two or three lines below that.

[Redspear]

Once again, thank you

[Redspear]

New build seems to be working as hoped. I actually forgot to adjust the lane width so there were too many encounters but encouragingly they didn't seem so bad due to the new speeds.

• Masslocks in opposite direction* clear 4 times as fast
• Masslocks in the same direction* clear 2 times as fast

* i.e. other ship(s) heading.

Got into a combat or two and dificulty seemed similar, although switch to dogfighting occured much sooner (as predicted). Everything else seemed to work. Docking traffic was a bit high again along with encounter rate but I now know how to adjust both of those.

Planets and stars were at x10 this time so as not to lose the benefits of the earlier build

• WP-Planet & Largest Asteroids x20
• Planets & Stars x10
• Stations & Freighters x4
• Multi-Role* & Thargoids x3
• Fighters & Launched/Scooped items x2
• Thargons & Smallest Asteroids x1

* including Vipers

Also switched km to hm which was quite funny as even though I know what hm are and I also know all of the scaling 'tricks' I've pulled, I'm just not used to gauging measures in hm. The delay in my brain was sufficient for it not to jarr in the way that km do

Something I didn't realise however, is that when you double your speed you also double launch and hyperspace effect speeds (not in game duration).

Anyway, I'm loving this version so far and although Oolite is still brutal, I think this could be the most beginner friendly version of the game (opinion subject to change )

[Redspear]

• Masslocks in opposite direction* clear 4 times as fast
• Masslocks in the same direction* clear 2 times as fast

* i.e. other ship(s) heading.

This is, of course, nonsense. They're both at x2 (as speed difference is the critical factor).

Anyway, I plan to post the first of the two builds I've been working on here soon, before I forget the numbers as I switch my focus to the more experimental build. I think stations and freighters could be at 1.5 rather than 2. The cobra 3 is very big but it's also rather flat and 1.33 has been enough to work in the newer build (as x4 vs x3).

Might need one last tweak re masslocking but that build is essentially done.

[Redspear]

Apologies for the delay folks.
Working on the new build is highlighting the odd tweak that I can incorporate in the more conservative version.

For example, I'd factored in increase in planet size and lane length when normalising docking traffic. Up the scale to x10 however and it no longer works as well, rather it seems to be the square of planet size that does the trick. Applying this to the simpler build should work better than my earlier calculations as I am able to refine the formula in order to get more useful 'answers'.

With increased speeds, missiles are pretty dangerous. For that reason I've increased their speed to 150% rather than 200% (fast enough to catch anything in the core game). I think collision speed is also a factor in damage and so I've tweaked misile damage accordingly (adjusting for faster missile speed, not faster ship speeds as they could be running away from as well as into a missile).

Greater planet size ups the entity count significantly and so that can take a toll on processing times. Latest trial has been:

• Planets x8
• Stations & Freighters x4
• Multi-Role x3
• Fighters x2

That shaves over 100 off the entity count compared with planets at x10.

There must be a way to reduce the entity count independantly but with spacelanes working as they do, that would require careful adjustment. A longer spacelane that isn't also wider could be easier to stray from, especially with ship speeds at x2.

With planets effectively at x2 compared to stations, the larger background stars are just big enough to disguise that the station is still very large relative to the planet (although much improved compared to the standard game and so planets at x8 may even be preferable to planets at x10). Again, the same thinking could be applied to the conservative build but I should probably test it with a torus station or something similarly huge...

[Redspear]

Ok, so it turns out that the speed x2 builds are fun but a little buggy. A shame but still useful in terms of understanding scale.
Tried a compromise build to see if any of it's advantages could be maintained (speed at 1.5 and scanner at 0.75) and it seems to work great.

One perennial issue however, remains docking traffic.

Code: Select all

double range2, nearest2 = SCANNER_MAX_RANGE2 * 1000000.0;

This line in ShipEntity.m has been key to earlier fixes but seems to do little or nothing with recent attempts. Even removing SCANNER_MAX_RANGE2 * seems to have no effect.

If the player has docking protocol disabled then it's not really a problem but otherwise long docking queues are likely.
I've fixed this before however so I'm trying to understand why it's not responding as hoped...

Planets are back to x 6.6, for both builds now. Stations at x3 (previoulsy x2) are maybe just small enough to make a good compromise between in game visibility and planet size appearing reasonable (will need to test with smaller planets). The mk 3 however would be at x2 which makes oxp compatibility an issue but the increased speeds (x1.5) and reduced scanner (20km rather than 25.6km) do require a lot less patience from the player.

[Redspear]

Seems that the problem was that once you scale stations above x3 then docking goes a bit wobbly.
Rather than recalculate the docking code, I think setting stations at x3 is easier.

Also, the issues at speeds x2 seem to be avoidable (thus far) at speeds x1.5. Consequently there remains just enough room for maneuver to progress with both builds.

Even better, it may be possible to have the 'improved' build as an oxp option (i.e. one build that accommodates both possibilities). Only additional core requirement would be shrinking the scanner to 20km rather than 25.6km

There's an interesting tweak that can be made when shrinking the scanner. if you don't also adjust scanner scale then you effectively have two scanner ranges:

• Short - Medium Range : as normal
• Long Range :entities appear but do not masslock

Something I've been havng fun with is a scanner that is effectively 30km but only masslocks at 20km.
There are some considerations of course, chief of which is that the boundary distance should be marked or else it could add more confusion than anything else.

[gizmo]

Is there a (preferrably Linux) build of your modifications available?

[Redspear]

Only on my PC at present.

Lots of chopping and changing while I work things out, so it's a bit premature for posting code.

Having said that, if no more probems emerge then I'd expect to be in a position to post my changes some time this month. By then they should be at least sufficiently robust to enable aggressive testing. Fingers crossed...

[Redspear]

Getting very close now...



Only real issue with making one build instead of two is the compulsory alteration to the scanner (from an effective 25.6km to 20km). I think it's worth it however as it contributes to halved masslock times with the suggested values and even shaves a quarter off times with the familiar values. Better yet, it means other values can be tweaked to each player's taste.

I'll post some comparison pics in the screenshot thread shortly but if something is too big / too small for anyone's preference then there'd be room to tinker. There are a few considerations however as I haven't come to these values purely on a whim.

• Freighter pilots are not the most spatially aware when it comes to docking (Boa pilots appear especially challenged in this regard - likely on account the expanded 'bottom' of such vessels). Scaling the worst offenders to a lesser value than the station seems to help
• If speeds exceed fighter sizes then combat can get a whole lot more challenging
• If speeds get up to x2 then be prepared for the occasional accident upon launching
• If stations get above x3 then freighters occasionally have trouble navigating around the buoy, never mind docking

There are a few other things to consider when tweaking the above but all seems to be working and docking traffic is manageable again.


I said I'd been working on a new scanner...



Undoubtedly a bit rough around the edges but functional and fun.

Easiest way to read it is to consider the brighter area in the centre as the scanner we're familiar with, whilst the outer area displays 'lollipops' as normal but they won't be able to masslock you from there. For example the left and righmost ships displayed on the scanner cannot masslock the player in their current positions.

An obvious concern might be that it could be confusing to occasionally torus past some ships at great speed and yet not others. I think the inner circle actually makes that rather clear. In fact, I find it causes less confusion when something masslocks the player on the very edge of the scanner and yet once the player has stopped it has drifted off the edge, with this scanner however, there's another 10km worth of display area for within which it can be located.

Inner area 20km
Outer area +10km

More scanner, less masslock: me likes

To be clear this is just a fun idea that I consider worth posting. It does relate to the rescaling in that it fits well with the reduced scanner I'm using but (unless surprisingly well received) it won't be in the build.

[Redspear]

Ambient light wasn't really doing what I wanted it to and so I tried this:

You can try introducing exposure in the default ships' fragment shader in order to make things a bit more visible.

It certainly helps with visibility but in terms of ship surfaces in shadow it just highlights some edging. To be fair, that's probably exactly what it should do but at close range I'd like to see a little more. Combining exposure of 2.5 (default is 1) with an ambient level of 0.2 is where I'm at presently but it remains to be seen for how long...

Inner area 20km
Outer area +10km

More scanner, less masslock: me likes

Another perk I forgot to mention is that 20+10 = 30km = range of military laser.

Harsh if non-player ships couldn't respond but I could give them longer ranged scanners too. At speed x1.5 they'd also cover the distance faster than in the standard game and without masslock at that range it's a situation the player would usually have to create rather than one that would near constantly present itself.
More of an exploit for pirate players perhaps...

[Redspear]

OK, I think I've done it.

Please note:
Not all of the following may appear to make sense. Beyond considering the size that things should be there were also factors such as how they should appear and under what circumstances would they be seen. Some things may even appear contrary but it is with concern for fun over realism that a certain amount of smoke and mirrors have been employed.

To play this in a way that makes the most of all of the adjustments, you will need one of the oxps that I expect to release very soon. The first will have just enough tweaks to enjoy the new scales (e.g. bigger stations and freighters) while the second will be designed to 'improve' gameplay in other ways, such as greater ship visibility and reduced masslock duration, all effected by use of scaling.

So this post contains the hard work if you like, of changes to the source code. Testing was far from exhaustive and so I reserve the right to change values or even strategies later. The main advantage of an expanded range of scale is, to my mind, that things can be hidden in space. Black Monk stations not visible from the witch point, Coriolis stations that can't be found easily without the use of the compass, Planets that don't loom enormously in the rear view as you approach a star and fighters that aren't half the size of the freighter they escort.

This then, is the latest of several incarnations of this experiment, each one of which was playable but also less well tuned than this version IMHO. There are further tweaks I have emplyed for my own game (once again enabled by tinkering with scale) but many things are a matter of taste and so I present most but not everything.

I hope some enjoy it as much as I do.


OOPlanetEntity.m

line 120 - make planets bigger

Code: Select all

collision_radius = radius_km * 100.0;

lines 196, 200 & 204 - adjust rotational velocity

Code: Select all

_rotationalVelocity = [dict oo_floatForKey:@"rotational_velocity" defaultValue:0.01f * randf() / 10];

Code: Select all

_rotationalVelocity = [planetInfo oo_floatForKey:@"rotation_speed" defaultValue:0.005f * randf() / 10];

Code: Select all

_atmosphereRotationalVelocity = [dict oo_floatForKey:@"atmosphere_rotational_velocity" defaultValue:0.01f * randf() / 10];

OOStellarBody.h

line 52 - adjust reach of atmosphere

Code: Select all

#define ATMOSPHERE_DEPTH	2500.0

line 53 - prevent planet size from looking silly on f7

Code: Select all

#define PLANET_MINIATURE_FACTOR	0.000185

Universe.m

line 117 - adjust encounter rate for increased traffic

Code: Select all

#define LANE_WIDTH	143100.0

line 894 - increase WP to planet distance

Code: Select all

planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:15];

line 1153 - bring station proportionally closer to planet

Code: Select all

stationPos = HPvector_subtract(stationPos, vectorToHPVector(vector_multiply_scalar(vf, 1.25 * planet_radius)));

Entity.h

line 47 - make things visible from greater distances

Code: Select all

#define ABSOLUTE_NO_DRAW_DISTANCE2	(25000.0 * 25000.0 * NO_DRAW_DISTANCE_FACTOR * NO_DRAW_DISTANCE_FACTOR)

lines 51 & 52 - reduce scanner to 20km

Code: Select all

#define SCANNER_MAX_RANGE	20000.0

Code: Select all

#define SCANNER_MAX_RANGE2	400000000.0

HeadUpDisplay.h

line 42 - define scanner scale

Code: Select all

#define SCANNER_SCALE	200

ShipEntity.m

line 7742 - reduce docking traffic at station

Code: Select all

if (sd2 < SCANNER_MAX_RANGE2 * 2.0f)

ShipEntity.h

line 80 - adjust turret shot speed against faster ships (only necessary for the recommended version but here it is...)

Code: Select all

#define TURRET_SHOT_SPEED	3000.0f

PlayerEntity.h

lines 306, 307 & 309 - increase torus speeds to compensate greater distances

Code: Select all

#define MIN_HYPERSPEED_FACTOR	128.0

Code: Select all

#define MAX_HYPERSPEED_FACTOR	4096.0

Code: Select all

#define HYPERSPEED_FACTOR	128.0

PlayerEntity.m

line 3019 - increase deceration from torus drive speeds

Code: Select all

float deceleration = (speed_delta * delta_t * HYPERSPEED_FACTOR * 64);

line 3300 - adjust masslock radius for planets & stars

Code: Select all

double factor = ([stellar isSun]) ? 1.44 : 1.35;

HeadUpDisplay.m

line 3686 - reduce reported distances from STE

Code: Select all

NSString*	infoline = [NSString stringWithFormat:@"%0.3f km", range / 5];

planetinfo.plist

find and replace all instances of "sun radius =" (to enable bigger suns) with:

Code: Select all

// sun radius =

And I think that's it.
Much copy and pasting there so hopefully it all made it here unscathed.

Necessary OXPs to follow...

EDIT:
Two shader adjustments to include.

oolite-default-atmosphere.fragment

line 59 - restore appearance of atmosphere

Code: Select all

float cosThreshold = -1.333333e-6 * atmRadius / 10 + 0.17333333;

oolite-default-shader.fragment

line 422b (additional line) - exposure adjustment courtesy another_commander

Code: Select all

totalColor.rgb *= 2.0;

[another_commander]

Nice, well done! I think there should also be a shader change for the atmosphere effect somewhere there?