Split: Re-scaling experiment

[jackiebean]

ok what kind of editor would i need to do that correctly? I have Vim, which is supposed to handle java scripts. I am not sure if the built in text editor can handle it correctly. (or maybe it can? i seem to remember opening something and having the lines actually numbered before)

I made the edit so hopefully it handled it right.

[phkb]

ok what kind of editor would i need to do that correctly? I have Vim

Vim should be fine. It's just a text file, so as long as the format doesn't change, you're all good.

[stranger]

Re-scaling Experiment considerations

There are 40 pages of topic, so I’ll base on Redspear’s post from Oct 9, 2014 (page 13). Some issues can be already solved or being obsolete.

Part I: System Rescaling

• Make planets, suns and moons bigger

I was initially intrigued with proposed scaling factor 3.3. Why not just integer value such as 2, 3, 4 or 5? Scaling factor 3.3 looks as converting factor between foot and meter. But the main controversy between old Elite foot scale and modern Oolite meter scale manifested in ship sizes, not planet or moons (I’ll discuss it a bit later).

Have we pressing need to enlarge vanilla planets, suns and moons?
Proportion of Earth twin (approx 6400 km) to vanilla sun radius is approx. 2...3, so in some configurations planet looks oversized. Increasing proportion to honest 1:100 or so will be overkill in game terms. I hope 1:15 in combination with increased distance between sun and planet(s), realized in Sun Gear, will be balanced solution. In Sun Gear only sun radii were readjusted, planet population remains in the same vanilla range 28,160...69,110 meters in game units.

What for increasing main planet radius?
It will give more room for improving game visual appearance. Vanilla Coriolis station looks not too oversized (1000 m size comparing with 56,320...138,220 m planet disc diameter), but large station like Kiota class station from WildShips (author Thargoid) will look oversized placed near moon. Maybe it was the reason for Thargoid to locate his stations in free space, not near planets or moons. Increasing planet radius will help to increase proportionally moons and improve visual appearance of moon orbiters.

Technically the only way to increase planet, moon or sun radius without hardcoding is to redefine these values in planetinfo.plist. It is simple procedure per se, but increased planet radius will lead to new issues, most of them already addressed in Redspear’s post.

Appearance issues:

• Adjusting planet size on F7 screen.

We have animated image of planet and planet radius displayed on set of system data lines on F7 screen.
AFAIK since Oolite 1.86 layout of system data lines on F7 screen can be completely customized, so we can display line with redefined radius without hardcoding, using OXP such as System Data Config (author phkb). But readjusting of animated planet image size is possible only on level of source code edition, right?

Sizes of circlets on F6 screen map proportional to system main planet radii, so source code edition again is needed to readjust vanilla scaling factor.

Game mechanics issues:

Increased planet radius means increased mass-lock zone radius too.
Solution proposed by Redspear is to decrease hardcoded mass-lock parameter.
There is another solution – just increase player.ship.maxSpeed proportionally to redefined planet scale to compensate time of flight if you have no any other mass-locking objects in scanner range, such as ships, missiles, stations or wormholes. In case of any such object entering scanner range player.ship.maxSpeed parameter resets to initial value. To avoid issues with scooping containers and splinters and with aerodynamic friction this speed increase mode can be primed by player like Torus drive.
And there is new issue in this simple solution – it violates rule of parity between player and NPC ships. But we have already example of more strong violation of rule of parity – NPC ships never uses Torus drive.

• Increase Torus drive multiplier

Again we can just reset maxSpeed with the same result. No need for hardcoding.

• Increasing heat insulation for sun-skimming activity

heatInsulation, controlled by script. Can be applied to player ship and to NPC ships too. No need for hardcoding.

Part II: System Rearrangement

• Double planet distance from witchpoint

Agreed, in case of increased main planet radius it seems logical decision.
Can be redefined using planet_distance parameter in planetinfo.plist.
The main difficulty is automatic converter, capturing all 2048 vanilla planet_distance values and generating new planetinfo.plist with new planet_distance values.

• Halve orbit of station

Seems station_vector in planetinfo.plist determines only main station position, you have always main station on H = R. So changing main station altitude by editing of source code is the only way. Maybe I’m wrong.

• Enable large objects to appear at much grater distances

Only hardcoding again?
Can create performance issues on machines with obsolete videocards.

Part III: Ship Rescaling

Oversized ships in Oolite are the most immersion breakers personally for me. I can’t imagine Cobra Mk III with 130 meters wingspan as personal ship of Lave Pilot Academy graduate. And I can’t understand only 20 ton cargo capacity of such huge ship (OK, 35 tons with cargo bay extension).
And I can’t imagine standard I ton container as barrel with 10 m height and diameter approx. 4 meters (125 m^3 volume!).
Well, I know historic reasons for such strange game setting. Having standard field of view 1 radian and monitor with 1920 pixel width, you’ll observe ship with 15 m wingspan (similar to modern jet fighters) on the edge of scanner range (25,600 m) as only one pixel (1.16 pixels exactly). It is problem of fighter sims: it is almost impossible to detect enemy fighter visually beyond 2...3 NM distance without radar and HUD visual helpers. Oolite as Elite reincarnation based on gunfight with visual targeting, so to ease precise aiming on distance up to 25,600 m you need really large ships like Cobra Mk III.
But wait, in old Elite manuals ships were measured in feet, not meters! So huge Cobra Mk III transforms to ship with wingspan only 40 m – less than B-2 Spirit (wingspan 52 m) with comparable 18 ton payload. Such Cobra seems more realistic as private spaceship. And huge 10 m tank transforms to 3 m height and 1.2 m diameter cargo container with internal volume 3.4 m^3 – quite realistic volume for fragile electronics or life support system for slave.
How to combine ship dimensions in feet and STE readings in meters in one brain? Personally I’m using advanced skill of doublethink. More direct approach is to rescale ships actually.

• Rescale ship models

Rescaling ships seems to be most labour-intensive part of project. There are more than hundred ships already beyond default set and new ships will arrive.
Fortunately, there is no pressing need to rescale dimensions of all original models. There is simple way to rescale ships – it can be done using parameter model_scale_factor in shipdata-overrides.plist.
Unfortunately, AFAIK there is no way to redefine model_scale_factor as global parameter. So issue with new ships can be solved providing regular (monthly or so) updates of such shipdata-override.plist.

• Adjust shipdata and halve ship speeds

Seems logical – halved ships must have halved speeds to maintain current gunfight dynamics with visual targeting.
Fortunately, ship maxSpeed parameter can be redefined in script without need to support regular updates of shipdata-overrides.plist. It can be set individually based on ship class or just model_scale_factor.

• Reduce the scanner radius
  Prevent “lollypops” to appear outside scanner range

The second task can be done using brilliant Norby’s idea in his Variable Masslock OXP. Just redefine his function of mass-lock radius vs ship mass and use transparent color for lollipops beyond defined range.
It will give more realistic game setting with large objects such as stations and Behemoth carriers detection on maximal range. So me think reducing scanner range is not crucial…
But wait. Variable Masslock AFAIK is gamer-centered point of view. It did not prevent your ship being detected by NPC ships on maximum range, so game balance issues with scanner range can be occurred.
Me think it need testing in game.

• Reduce laser ranges

Seems logical too. It will give game setting more similar to modern air combat simulations – envelope of gunfire solutions is only small fraction of detection range. In modern air combat you have detection range 30...40 NM or so and only 1.5...2.0 NM as upper range of effective gunfire.
Again, we have dosens of OXP laser guns beyond three vanilla ones. All these guns must be readjusted in equipment.plist.
Alas, there is issue with missiles. NPC ships usually uses missiles as “last hope” weapon, so having reduced gun range and unaltered missile range player will have advantage of first strike, launching missile from safe distance without risk of exposing to NPC counter-fire.

[Redspear]

OK, a little more explanation on my part...

There is a wiki page on the experiment but that too could do with updating.
It may also be useful to understand that when this was first attempted there were a few key differences to the game as it is today.

Namely:

• planetinfo.plist did not include data for each system (that came from a seed value)
• torus drive speed did not increase relative to distance (it was a set valuse)
• there was no 'sun glare' without rescaling
• default planet textures weren't so great

Further, there are some consequences of careless rescaling:

• less system traffic (fixed by lane width adjustments)
• less visible fighters (fixed by laser range adjustments)
• greater travel times (fixed by torus drive adjustments)
• lack of station traffic (fixed by keeping default scanner range)

So, with all that in mind...


Part I: System Rescaling

When you increase the planet size, it's just one number in the entire code and then you have bigger planets, stars and distances (including the witch point beacon) - it just looks as though all the ships and stations have shrunk (along with the player ship).
It was suggested by one of the devs that making things bigger would likely be easier than making things smaller, thus the feet/metre ratio (approx). I decided to attempt both.

3.3 turned out to be a rather good value for making orbiting stations look more believable without making them so small that you can't find them.

Re: torus drive, it's not just the speed to be considered but also the deceleration - or else players can simply drift out of some masslocks at very high speeds

With the new planetinfo.plist changes, there's potential to do more with star sizes in particular.


Part II: System Rearrangement

Because I'd taken the station as the thing to scale around (it is the one entity that is to the correct dimensions of elite lore) I really wanted to change that they were visible so far from a planet - sometimes I could see an oxp station from both the planet and the witchpoint. Bigger planets solved that but then the orbit looked a bit high, so shrinking it looked much better. Lengthening the spacelane changed the scene greeting the player on entering the system - it's not just that you have more space, it looks like it too.


Part III: Ship Rescaling

This one is the most problematic but also the most rewarding IMHO.
There were some problems around scanner size and docking behavior, so my last change was to scale around the scanner instead of the station.

So, station ×2, planets ×6.6, freighters ×2, fighters × 2/3

Re: laser ranges and missiles, with rescaled ships there is no laser range that produces identical play to standard oolite (but there are tweaks to stop large or small ships benefitting too much if so desired).
Shrinking missile ranges is easy enough, I just thought it was more interesting if I didn't.

[stranger]

It may also be useful to understand that when this was first attempted there were a few key differences to the game as it is today.

Yes, I clearly understand it. My attempt to analyze project based on partly obsolete info, so I'm trying to suggest these new opportunities to solve most of declared tasks without hardcoding.
There is a similar issue with any project considerably altering game mechanics: new method realized in game update sometimes changes task from extremely hard to quite easy.

Re: torus drive, it's not just the speed to be considered but also the deceleration - or else players can simply drift out of some masslocks at very high speeds

Clearly understand it too. Deceleration path is proportional to initial velocity in power two, so having ship velocity increased x4 you'll have x16 deceleration path length. Acceleration/deceleration parameter for Cobra Mk III is set to provide approx 1/2 scanner range deceleration from Torus drive to cruise speed, so in case of mass-locking it will finish transit from Torus to cruise speed having 1/2 scanner range or more to mass-locking object. Increasing ship max speed without readjusting thrust parameter will lead to overfly targets and sometimes to collisions.
There is one trick with maxSpeed parameter however. Seems in Torus mode readjusting player.ship.maxSpeed will change Torus speed (32 * maxSpeed) too instantly, without acceleration/deceleration. So you just need to detect objects on course before closing distance to scanner range and to switch maxSpeed to default value.
The most simple way to do it is to scan ship proximity for any entities in radius, proportional to ship velocity. This approach was used by Norby in his Far Planets / Torus to Sun OXPs and I'm adopt Norby's solution for my warp drive. Cobra Mk III velocity on Torus is 32 * 350 = 11,200 m/s, so having maxSpeed increasing tenfold you'll have Torus velocity 112,000 m/s. Scanning ship proximity for any entities on 10 * scanner range radius every second will detect any entities, leaving enough time to reset ship maxSpeed to default value.
This is working solution, tested in game since Oolite 1.82.

[Redspear]

What's the size range for planets on planetinfo.plist?
Is it still 3,000 - 7,000?

If so, it remains the case that I need to make source code changes in order to achieve the desired result.

If I could shrink everything else instead (i.e. ships and stations) then that would require scanner changes, again via source code according to my understanding.

Of course if you don't want planet rescaling then this is much less of a problem, which is why I listed my rescaling in 3 parts so that people could choose what they wanted for their own game.

Give me a planet radius option up to 50,000 however (and a similar increase for sun radius, witchpoint distances etc.) and I'd happily turn this into an oxp project (assuming some of the ship behaviours around laser ranges were also accessible).

Re: Far Planets, Norby had enormous planets in that but not including the main system planet, is that correct?

[stranger]

AFAIK there is possible to increase main planet radius far beyond 7000 km. Trying 10,000 km fo Zaonce - it has texture of gas giant in Famous Planets. No any issues except radius of mass-lock zone. Unfortunately, I don't know if there is any upper limit for main planet and sun radius. Me think floating point format of distance presentation since Oolite 1.80 allows increase of main planet radius up to real 6,378,000 m. The only issues with main planets is diameter of circlet on F6 map, proportional to main planet radius, and radius of animated main planet image on F7 screen, proportional to main planet radius too (latter issue was already addressed in your post).

[Redspear]

AFAIK there is possible to increase main planet radius far beyond 7000 km.

If that is true (along with similar for star radius and distances) then things just got a lot easier

My experience is mostly with the source code in this regard. I already have an oxp solution to planetary/solar masslocks (if you tweak Masslock Compensators) but looking at the wiki I think planetinfo.plist gives limited potential to increase things.

Planet size increase with source code changes

• f6 display looks fine
• f7 display can be fixed easily
• f7 radius info remains as intended
• distances and stars become bigger
• can be combined with .plist changes for extra versatility

Planet size increase with .plist changes

• f6 display (probably) looks not so good
• f7 display can (probably) be fixed easily
• f7 radius info increases along with planet (too big)
• distances and stars remain the same
• is restricted to .plist changes (according to wiki: last edited: 29 January 2018, at 02:17) unless altering source code

If I'm wrong (I hope so ) then please let me know!

[stranger]

Planet size increase with .plist changes

• f6 display (probably) looks not so good
• f7 display can (probably) be fixed easily
• f7 radius info increases along with planet (too big)
• distances and stars remain the same
• is restricted to .plist changes (according to wiki: last edited: 29 January 2018, at 02:17) unless altering source code

Distances and suns can be readjsted in the same planetinfo.plist or separately.
Need some tools to generate vast planetinfo.plist with 2048 entries of course.
There is Galaxy Guide project on Elite Wiki (unfortunately, seems to be abandoned). Author Christian Treczoks. Has links to spreadsheet in .xls format, emulating procedural generation of Elite systems.
I was using the next steps:
1. Importing raw data from .xls spreadsheet to FileMaker database.
2. Readjusting data
3. Exporting readjusted data in TAB format
4. Converting TAB to planetinfo.plist by plist editor.
There is also reincarnation of Galaxy Guide on new level - Oolite Galaxy Maps. Excellent work of phkb. I think he can help with converting raw data to planetinfo.plist too.

[Redspear]

Distances and suns can be readjsted in the same planetinfo.plist or separately.

"or seperately"
Please explain what you mean by this.

If we assume for the moment that all distances are to be adjusted by planetinfo.plist, then to achieve results comparable to the rescaling experiment we would need the following.

• All planets 6.6 times bigger
• All stars at least 6.6 times bigger
• All witchpoint distances 13.2 times longer
• All sun distances at least 6.6 times further

Sun distances are easy because of sun distance multiplier but as for the witchpoint distance, I don't think there is such a property. Presumably then it is directly proportional to planet size so it would be necessary to abandon extended spacelane length.

Can the system populator script be overridden? I think that sets some of the default distances (like station orbit) and is in the resources folder rather than hidden in the source code.

[stranger]

Separately - means one pnanetinfo.plist for sun radii & distances (like in Sun Gear) and another one planetinfo.plist for main planet radii & witchpoint distances.
Look for planetinfo.plist in game Config folder - since Oolite 1.81 it has parameter planet_distance - distance from center of main planet to witchpoint.

Oops... me think i begin to understand your position. For sun_distance we have global parameter sun_distance_multiplier to re-scale all sun distances. There is no such global multiplier for planet_distance or planet radius, so all 2048 planet distances and radii need be readjusted individually.
Seems it is more simple task for you to edit source code, for me - to generate edited planetinfo.plist.

[Redspear]

Separately - means one pnanetinfo.plist for sun radii & distances (like in Sun Gear) and another one planetinfo.plist for main planet radii & witchpoint distances.

So both via planetinfo.plist.

Look for planetinfo.plist in game Config folder - since Oolite 1.81 it has parameter planet_distance - distance from center of main planet to witchpoint.

Ah, I missed it. Thanks.

Seems it is more simple task for you to edit source code, for me - to generate edited planetinfo.plist.

I would hope there is the potential to combine the two. Certainly when I get back to the rescaling for 1.88 I will try tweaking the sun size via planetinfo.plist. and see how much scope there is.
Thanks for pointing it out

[stranger]

Can the system populator script be overridden? I think that sets some of the default distances (like station orbit) and is in the resources folder rather than hidden in the source code.

Populator is just another issue omitted in my starting post. And this is my blind spot - I have only general idea how it works
Scanner radius in vanilla game is a significant part of planet radius. For planet with 5000 km radius (close enough to mean value for Oolite planet population) scanner range is approx 1/2 planet radius.
AFAIK there is upper limit for number of ships seeding by populator on system - I don't know exact value. I don't know also is diameter of spacelane cylinder is function of planet radius. If answer is yes, increasing planet radius AND decreasing mass-lock ranges will lead to significant reduction of rate of encounters - most ships along spacelane will be undetected during trip. It can be game breaking issue.
Let's image Random Hits standard mission - you must find and eliminate special target with no exact knowledge of its location - you just patrol along spacelane between planet and witchpoint with hope to meet this bad guy sooner or later. Increasing spacelane diameter AND decreasing scan radius will turn this task from moderately challenging to almost impossible.
For main station - I think it is special case. You have no option to set main station location arbitrary. Onli orientation of position vector, not magnitude.

[Redspear]

Now that I've got more time on my hands I thought it might be a good idea to blow the dust off this thing and update it for 1.89, even if only for my own amusement.

Every time I come back to it after considerable time off I need to spend a little while to get my head around the whole thing again. Skim reading through the posts, a few things struck me.

• 3 Forms of rescaling: System (planets, stars etc.), Cosmetic (longer space lane, station proportionally closer to planet) and Ships (scanner, laser ranges etc)
• System and cosmetic rescaling all worked great AFAIK, with no outstanding problems reported
• There was a glitch with ship rescaling but that was fixed (absence of docking ships at station)
• When omitting ship rescaling, core gameplay was essentially identical to the 'oolite experience'
• A proportionally smaller scanner (rather than just a smaller one) did produce some clear gameplay perks according to myself and some testers

So, to focus...
Rather than simply show that each stage can be done (I think I've achieved that), I could instead concentrate on putting together a recognisable, oxp friendly build that didn't touch gameplay beyond making planets, stars and indeed space, seem much bigger. Maybe throw in the bigger asteroids but essentially just the bigger systems and some cosmetics. So, it's the Oolite you know, only bigger.

Also...
Assuming 1.89 doesn't present any new issues, explore the gameplay improvements with a scanner at 66% (i.e. masslock, escape, dogfighting, station approach) and see if scaling around the mk 3 (rather than the station) gave me sufficient room to shrink the scanner without triggering the docking glitch. The previous ones were either at 50% or 33% (100% or 66% proportional to the shrunk mk 3 but not to hardcoded scanner values - no need to shrink the mk 3 this time).

So the first version should be to most people's liking.
As for the second, it's not the same but it's clearly recognisable. I think it's a clear improvement but can it be done bug-free?...

There's only one way to find out

[Day]