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.
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.
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.
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.
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).
