Split: Re-scaling experiment

[Redspear]

Ok Zireal, I'll see what I can do in a month

Thanks to you and Dizzy for the enthusiasm. Thanks also Dizzy for the numeric hud tip earlier in this thread; I'm finally putting it to good use

Yeah, Dizzy's right on both counts: it is a source code rather than an oxp/z thing and it exists only on my computer atm... Sorry about that.

I'm not really familiar with git-hubbery and so on but it would be a simple matter to release the modified files as downloads to drag and drop into the standard source build (...wouldn't it?)

If you're waiting for a ship scale 'solution' or (more accurately) alternative then I'm afraid that's still waiting somewhere on a long to do list...

What I have done is to make planets and suns bigger (simple enough) and then, to modify the resultant longer travel times by adjusting the torus drive multiplier and mass lock radii (a bit more tricky to get right).

When you jump into a system you likely won't immediately notice any difference but... Hit that torus drive and you'll find it now has one hell of a kick to it and you'll realise how much further away the planet and sun are.

When you reach the planet, the station should no longer be obvious, you'll likely need the compass to find it, and as you approach, get a sense of how much bigger the planet now is. Suns should seem less tiny too (although they are so small in the core game that the benefit here is minimal - esp since the glare effect made it into the source).

If, like me, you use planetfall, then the surface should flatten out much more as you approach: more realistically IMO.

Otherwise, the game should play much as before.

Only real sticking point at the moment seems to be sun-skimming. It works but is currently a little too easy; responding nicely to tweakery though I just need a little more time to do some fine tuning and then I can show and tell.

Regarding ship scale and other 'universes', I'd be interested to know if there are any other well known ones (or perhaps less so) that display so little size difference between their fighters and freighters as does elite/oolite?
I don't mean that as any kind of provocation, I'm genuinely quite ignorant (I've set myself up for a quote there haven't I ) of these other ships and their sizes but the elite/Oolite ship scale always seemed rather squashed together to me.

I am aware however, that the above question has little to do with changing feet to metres and more to do with the values given in the original elite manual.

Thanks all.

[Diziet Sma]

I'm not really familiar with git-hubbery and so on but it would be a simple matter to release the modified files as downloads to drag and drop into the standard source build (...wouldn't it?)

It would.. but that's only a partial solution.. as the compiled binary will only run on the same platform as you used to build it on.. be that Mac, Windows or Linux. (of course, this assumes that you're not in the habit of cross-compiling for different platforms) And, if you built it on 64bit Windows or Linux, it won't run on 32bit versions of those operating systems.

Source code, or at the bare minimum, diff files, would be necessary if you wanted to cater to the full spectrum of systems Oolite runs on.

[Redspear]

Hmmm... Need to think about that then.

Thanks Dizzy.

[Diziet Sma]

Using diff may be the simplest solution, although it initially restricts testing to people who can compile Oolite themselves. On the other hand, those with different platforms to yourself could then release binaries as well..

[Redspear]

OK, so all was going well and then 1.8 came out so I thought it best to update my source if anyone else was going to play test this thing. So I removed all altered files and rebuilt before reapplying my alterations again, only now one of the numbers I was tinkering with (the most important one) doesn't seem to want to play.

Is there any reason why altering this line in Planet Entity m wouldn't behave as before?

Code: Select all

collision_radius = radius_km * 10.0; // scale down by a factor of 100 !

I realise that there are situations where rescaling the planets wouldn't be obvious but in other cases it should.

E.g. Sure, when I jump to a new system the planet should look just as big due to bigger planets being further away, but it should register as taking longer on numeric hud's ETA (not using torus), right?

When I approach the planet and the compass switches to the station, the station should be further away; both appearing smaller and taking longer to get to (again, illustrated by ETA). Even if distance between planet and station is proportional, it should still be further away from my arrival point (assuming that I headed straight to the planet)?

Other figures appear to be changing as before (and their effects appearing on numeric hud).

Any ideas? Have I likely botched the source update?

...On a lighter note, I just rediscovered this further up the thread:

...And the Star Wars universe (which is also subject to revision every time George Lucas gets a bit of time to himself)...

[cim]

Is there any reason why altering this line in Planet Entity m wouldn't behave as before?

New Planets have been enabled in 1.80, so the planets are now defined in OOPlanetEntity.m

[Redspear]

Once again cim, thank you.

[Redspear]

Predictably, I haven't had as much time as I'd like to work on this but I thought I should at least show where I'm up to (in part, spurred on by Zireael's request).

Way back in this thread...

My motivation is to address the inter-scale relationships within the game, not as a 'fix' but rather as an exploration of 'optimisation' and what that might mean to different people (me in particular, I admit ).

Nothing here is likely to make you think, "Wow! look at the size of that!", rather it's to reduce those little moments where the unrealistic scale becomes more glaring.

So, where am I up to?


Changes to Source

I've emboldened (if that's right) the core files that I've altered (within the myoolite/oolite/src/core folder, and most in the entities folder within that). The parts that I've changed or added have been underlined so that you can see what I've done.

Larger systems

We all know that planets, suns and distances are too small to be realistic and these alterations won't fix that. However they will make it a little less obvious. Encountering anything large like a station or a bulk hauler (or even another ship when close to the surface) tends to show up just how small the planet/sun is, the changes here should reduce that effect.

OOPlanetEntity.m - to increase body size and distances by a factor of 3.3

int radius_km = [dict oo_intForKey:KEY_RADIUS defaultValue:[planetInfo oo_intForKey:KEY_RADIUS]];
collision_radius = radius_km * 33.0; // Scale down by a factor of 100
OOTechLevelID techLevel = [dict oo_intForKey:KEY_TECHLEVEL defaultValue:[planetInfo oo_intForKey:KEY_TECHLEVEL]];

OOStellarBody.h - reduce planet size on F7 screen (cosmetic change to prevent all planets looking enormous)

#define ATMOSPHERE_DEPTH 500.0
#define PLANET_MINIATURE_FACTOR 0.0005
#define MAX_SUBDIVIDE 6

Immediate problems:

• It takes ages to get anywhere (see Faster System Travel below)
  Mass lock with suns and planets is extreme (see Reduced Mass-locking below)

Considerations:

• May affect encounter rates (seems ok so far...)
  May want to adjust position of main station and station buoy (cosmetic)

Faster System Travel

Predictably, larger systems require greater travel times. For comparable gameplay we need to traverse these distances at a faster rate whilst maintaining current combat speeds.
Luckily there are two key environments within this picture:

• 1. Scanner range - determines mass-lock of ships and is the environment for combat
  2. Space compass range - the system itself and the travel within it

Fortunately, each environment already uses a different method of travel, so we need to addreess the 2nd method: the torus drive.

PlayerEntity.h - increase torus drive speed

#define HYPERSPEED_FACTOR 100.0

PlayerEntity.m - to sharpen torus drive decelleration (to prevent gliding past, or even into, things too easily)

UPDATE_STAGE(@"slowing from hyperspeed");

// slow back down...
if (travelling_at_hyperspeed)
{
// decrease speed to maximum normal speed
flightSpeed -= (float)(speed_delta * delta_t * HYPERSPEED_FACTOR * 50);
if (flightSpeed < maxFlightSpeed)
flightSpeed = maxFlightSpeed;

Results:

• Intra-system travel times are now comparable with the game as we know it and combat remains unaffected

Considerations:

• I've given a pretty fierce decelleration here (you might want to halve or even quarter it) with one eye on adressing sun-skimming

Problem Solved?:

• Yes

Reduced Mass-locking

Whilst planetfall is an oxp environment, sunskimming is a core environment inherited from elite, so we need the latter to work from a gameplay perspective (and the former would be nice too). Therefore masslock radii need to be reduced. This is however, particularly fiddley to get just right. The values below will give a functional version but I'm still not entirely happy with it.

HeadUpDisplay.m - to decrease mass lock influence from larger bodies

double dist = stellar->zero_distance;
double rad = stellar->collision_radius;
double factor = ([stellar isSun]) ? 0.2 : 0.4;
// plus ensure mass lock when 25 km or less from the surface of small stellar bodies
// dist is a square distance so it needs to be compared to (rad+25000) * (rad+25000)!
if (dist < rad*rad*factor || dist < rad*rad + 50000*rad + 625000000 )

Results:

• sunkimming and planetfall are now viable again

Considerations:

• sunskimmiing is a bit quick in many cases and so needs some adjusting to compare to the original

Problem Solved?:

• ..kind of. I thought I'd cracked it with some different values but it's a matter of finding values that will work in most sytems. Testing made sunskimming practical wherever I tried it but a bit too easy.
  Feel free to try your own values and let me know but bear in mind that, as cim explains...

  The square root of factor is the number of radii from the centre you have to be before a masslock from a planet or sun - note that it's already closer in for stars. (Or as you'll see, within 25k of the surface)

Current Status:

• Playable?: Yes
  
  Issue free?: Not quite - sunskimming is a bit too quick and easy
  
  Preferable?: For me, yes

Questions:

Universe.h has

Code: Select all

#define SUN_SKIM_RADIUS_FACTOR				1.15470053838

is there anything useful I could do with that?

In StationEntity.m there's

Code: Select all

- (HPVector) beaconPosition
{
	double buoy_distance = 1000.0;				// distance from station entrance

but changing the value (even dramatically) doesn't seem to do anything.

How can I change the position of the main station?
...and indeed, can the witchpoint beacon be placed further from the planet?

Thanks to those who've shown interest and/or helped with this

[another_commander]

Thanks for sharing Redspear. It is a very interesting project you've got there. I can't answer your questions right now (need to have a good look into the source myself before being able to) but I'll have a look at those changes when I get a chance and try to get a feeling of how gameplay changes with them applied.

[cim]

Universe.h has

Code: Select all

#define SUN_SKIM_RADIUS_FACTOR				1.15470053838

is there anything useful I could do with that?

Possibly. It's the height above the sun's centre in terms of the sun's radius at which sunskimming becomes possible. (Something to bear in mind with sunskimming: NPCs don't have torus drive, so you'll need to significantly increase their heat resistance - there's a bit in Resources/Scripts/oolite-populator.js (lines 1412, 1418) which sets increased heat resistance for ships which are likely to sunskim, and another bit in Resources/Scripts/oolite-priorityai.js (line 2016) which checks if a ship has sufficient insulation to safely sunskim. Both will probably need adjusting.

In StationEntity.m there's

Code: Select all

- (HPVector) beaconPosition
{
	double buoy_distance = 1000.0;				// distance from station entrance

but changing the value (even dramatically) doesn't seem to do anything.

That method I don't think is used for anything any more. oolite-populator.js line 77 sets the buoy position.

How can I change the position of the main station?

This is in Universe.m :: setUpSpace

Code: Select all

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

vf is set a few lines above.

...and indeed, can the witchpoint beacon be placed further from the planet?

Yes, though it's the other way round (the witchpoint is always at the origin, so the planet needs to be moved further from the witchpoint). In Universe.m :: setUpPlanet

Code: Select all

	double planet_zpos = (12.0 + (Ranrot() & 3) - (Ranrot() & 3) ) * planet_radius; // 9..15 pr (planet radii) ahead

[Zireael]

Redspear, judging from your last report this will soon be playable? I can't wait!

[Redspear]

Thanks for sharing Redspear. It is a very interesting project you've got there. I can't answer your questions right now (need to have a good look into the source myself before being able to) but I'll have a look at those changes when I get a chance and try to get a feeling of how gameplay changes with them applied.

You're welcome and thank you

...and indeed, can the witchpoint beacon be placed further from the planet?

Yes, though it's the other way round...

That explains a lot

I wouldn't have gotten half as far without your help, cim (and at a time when the devs appear especially busy too...), so yet again, thank you

Redspear, judging from your last report this will soon be playable? I can't wait!

Well, it kind of is playable (better do something about npc sunskimmers though...) but it could benefit from some cosmetic adjustment (much like myself ). Rescaling is, in large part, about cosmetics anyway but I supoose I have some room to move things like stations and witchpoint beacons now and to (hopefully) derive some benefit from that.

If you were to implement the changes I listed above then you'd still have an essentially playable game. Perhaps with some adjustment I can make the 'benefits' more apparent as at first they may seem a little 'hidden' (e.g. bigger planets masked by greater distances until you get really close).

I hope to make it better and I hope you'll like it.
Thanks for your encouragement

[Redspear]

I supoose I have some room to move things like stations and witchpoint beacons now and to (hopefully) derive some benefit from that.

Speaking of which ...

Can you find the station?

The orbit to planet radius ratio has been halved.
So the station is proportionally closer to the planet but the distance between it and the planet surface is still further than in the standard game (3.3/2 = 1.65 times further)
The low altitude reading might be because I'd just visited a moon, I can't remember...

Standard arrival at Leesti (one of the smaller planets)


Leesti with distance from witchpoint doubled (entity count up from 182 to 260)

It's probably a bad idea to be using the breakable torus drive oxp in this situation.

Leesti with moon sizes halved (Additional Planets oxp tweak)

Although halved in this environment they're still bigger than in the standard game (3.3/2 = 1.65 times bigger)

In the next ten seconds, that planet's going to appear a lot bigger...


See what I mean?...

Check out that torus speed

[Zireael]

That's some godly pictures (can we haz the halve-moons size tweak?), and I can see the station! roughly 45 degrees up, to the right of the crosshair, roughly mid-way between the crosshair and the readings.

[spara]

That's some godly pictures (can we haz the halve-moons size tweak?), and I can see the station! roughly 45 degrees up, to the right of the crosshair, roughly mid-way between the crosshair and the readings.

If you want to tweak the moon sizes in the Additional Planets, open planetinfo.plist and halve all radii from ap-moonX entries.