Rebased Rescaling Experiment IV

[mcarans]

Rebased version of PR: #287

Relates to: #584

[mcarans]

@Redspear-of-Oolite @oocube @LW-archlinux How do you find this rescaling?
(Packages here: https://github.com/mcarans/oolite/releases/tag/1.93.1-PullRequest287.7994)

[oocube]

I ran ./Oolite-1.93.1-PullRequest738.3157-dev-x86_64.AppImage. When exiting the station the planet is indeed much bigger and the sun is further away. In this respect I like the change. When flying towards the sun, eventually I looked back to see the station and the plant. And I got to see all three moons - and they are absolutely unrealistic. Or is that just my impression?

[phkb]

That would be an issue with the OXP, rather than the rescaling code itself. Several OXPs will need to be tweaked to match the size changes, particularly ships.

[phkb]

But one of the primary things we would need to test in this PR is the number of encounters ie. how many ships do you meet between the witchpoint and the station, with the goal of having a similar gameplay experience to 1.92.1. That would mean testing with no OXPs installed, or in strict mode.

[mcarans]

That would be an issue with the OXP, rather than the rescaling code itself. Several OXPs will need to be tweaked to match the size changes, particularly ships.

Hmm, that sounds like a major piece of work involving coordinating changes with OXP authors. On the other hand, it's an opportunity to get OXP authors interested in this feature and get some Commanders to try it - which hasn't happened so far even though I've asked on Discord, Reddit and the BB.

I looked more closely at how this has been implemented. It could be beneficial to have many of the hard coded values exposed and changeable by OXP instead. I see some multipliers like sun_distance_multiplier and planet_distance_multiplier already exist in the Obj-C as values in a dictionary but it looks like they aren't changed anywhere and always use their default values. I'm unfamiliar with the mechanics of how they might be changed by OXP and how then other OXPs could be coded so that they respect and adjust to the values that have been changed to avoid the issue in oocube's screenshot.

How would you suggest taking this forward so it doesn't block other work like the long overdue reformatting of the code to modern standards?

[LW-archlinux]

You would have to expose them through javascript, probably by extending the systeminfo object, https://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_SystemInfo .

@phkb might be able to estimate the amount of work this will require.

[oocube]

Suggestion: We accumulated a lot and really good changes since the last release, mainly on technical debt and how the game is built. How about making a new one before changing the gameplay?

[mcarans]

@oocube If this is done as an irreversible change then what you suggest would be wise and advisable. If it is something that can be switched on or off by OXP, then it can be introduced at any time although I suspect this approach would be much more work.

[phkb]

Suggestion: We accumulated a lot and really good changes since the last release, mainly on technical debt and how the game is built. How about making a new one before changing the gameplay?

I think the idea in this PR is that it wouldn't change gameplay. The game would work very similarly to what it does currently. If this PR was ready to be merged, it would just be a visual change.

That said, because of the nature of this change it will undoubtedly need tweaking before we get it to the "it plays the same" state.

@oocube If this is done as an irreversible change then what you suggest would be wise and advisable. If it is something that can be switched on or off by OXP, then it can be introduced at any time although I suspect this approach would be much more work.

To make this OXP-able, I will need to take out the shipdata.plist, equipment.plist and planetinfo.plist changes, keeping them separate. Then I would need to go through the code changes and change all the tweaked numbers to instead be pulled from one of the plist files, and put in the pre-existing numbers into the core plist files. At that point the PR could be merged with (fingers-crossed) no material change to anything. But once merged, an OXP would be trivial - include the updated shipdata, equipment and planetinfo, and update the values in the other core plist files to match what this PR currently has. Hopefully that makes sense.

I'm aiming to spend some time tomorrow to look at this in more detail.

[oocube]

Suggestion: We accumulated a lot and really good changes since the last release, mainly on technical debt and how the game is built. How about making a new one before changing the gameplay?

I think the idea in this PR is that it wouldn't change gameplay. The game would work very similarly to what it does currently. If this PR was ready to be merged, it would just be a visual change.

That said, because of the nature of this change it will undoubtedly need tweaking before we get it to the "it plays the same" state.

The change is just optical only? I assumed it would be rescaling planet/moon/star sizes and their distances. If the distance from the whichpoint beakon to the station aegis is larger, the player has more time to cover under pirate attack. My combat skills require me to corkscrew to the aegis and the game is not very entertaining when doing so.

If the above is wrong, what is then the PR's nature?

[phkb]

If the distance from the whichpoint beakon to the station aegis is larger, the player has more time to cover under pirate attack. My combat skills require me to corkscrew to the aegis and the game is not very entertaining when doing so.

True, and there are a number of other changes that would count as gameplay changes (weapon ranges, ship speeds, etc).

[mcarans]

Good news! I have successfully done some git hackery to rebase this PR after the big clang-format.