Things I Wish I Knew BEFORE Starting this *@*#~&ing .oxp

[MrFlibble]

Scenario.plist Savefiles for new game starts

I'm stuck.


I started my Galactic_start.oxp using a "neutral" save file titled "Jameson - Full game - unhacked".

(The strict game Jameson would only load up a strict game).

I created another 15 based on this with riveting names such as "G7 Qutegequ.oolite-save".

I then start up a game with "G7 Qutegequ.oolite-save" (to modify the checksum) and then save it, and quit. The name in the save dialogue box is "Jameson - Full game - unhacked". Presumably from the old checksum? I then re-open the OXP and change the old checksum in the relevant Jameson save.


It should now be ready for somebody to use as a new Jameson.


But when I start up a second game with shift held down and with the re-checksummed "G7 Qutegequ.oolite-save" - and then try to save it, the name in my dialogue box is still "Jameson - Full game - unhacked".



Why is this happening?

And what should I do about it?

I'm guessing you just made copies and renamed them with Finder. Doing that may cause some confusion with naming as the save name is also stored in the file.

An excerpt from my file Flibble-Z4-20250506-01.oolite-save

Code: Select all

    <key>player_save_name</key>
    <string>Flibble-Z4-20250506-01</string>

You can either edit that key as well as the filename, or simply save the file from Oolite with different names, which will embed the save name properly, and save a bit of editing.

[Cholmondely]

You, sir, are a genius!

"Digby - treble his salary - immediately!"


Edited to add: It works!

[Wildeblood]

I then start up a game with "G7 Qutegequ.oolite-save" (to modify the checksum) and then save it, and quit. The name in the save dialogue box is "Jameson - Full game - unhacked". Presumably from the old checksum? I then re-open the OXP and change the old checksum in the relevant Jameson save.

The first thing you do is STOP fretting about the checksum. It's not what you think it is. Just stop thinking about it, and you can't edit a file to modify it, that's not how a checksum works.

[Cholmondely]

The first thing you do is STOP fretting about the checksum. It's not what you think it is. Just stop thinking about it, and you can't edit a file to modify it, that's not how a checksum works.

When I started modifying the Jamesons and flying them, the big problem was that the money was reset to 100₢ each time I reloaded the Save File after playing for a bit. Hence my fretting about checksums.

[hiran]

Since when is this check in the game?

I was wondering myself that there is no such check when I raised my money to buy big ships or increased the auto repair kits to benefit from in-combat repairs.

[Cholmondely]

Since when is this check in the game?

I was wondering myself that there is no such check when I raised my money to buy big ships or increased the auto repair kits to benefit from in-combat repairs.

So, I've seen two things.

1) My money getting reset to 100₢ on re-loading a new-ish "scenario.plist-ed starting Jameson" with a different account balance.
2) Sarcastic comments in my Latest.log.

And I've also seen mentions of edited-out Trumbles re-appearing.

The checksum was originally introduced by Aegidian to the vanilla game code. I'm dubious about the extent to which it has been updated/tweaked over the years. The small amount of check-summation that there is seems humorous to me. More would seem a bit pointless - why would you care if I cheat - and vice versa?

[Wildeblood]

And I've also seen mentions of edited-out Trumbles re-appearing.

This is what it does, nothing else.

I'd suggest your credit balance reverting was a simple case of thought you'd saved after making changes, but actually forgot to save.

[Cholmondely]

I'd suggest your credit balance reverting was a simple case of thought you'd saved after making changes, but actually forgot to save.

Alas, no. It happened several times (G1, G2 & G7) - and each time I'd changed the name of the Jameson save file.

[hiran]

I'd suggest your credit balance reverting was a simple case of thought you'd saved after making changes, but actually forgot to save.

Alas, no. It happened several times (G1, G2 & G7) - and each time I'd changed the name of the Jameson save file.

Disclose the message you see in the logs. We might check where they stem from.
Would that be the vanilla Oolite code or some OXP?

[Cholmondely]

Disclose the message you see in the logs. We might check where they stem from.
Would that be the vanilla Oolite code or some OXP?

Alas, those are long gone - a month ago. From my current OXP-to-be Galactic_start (for want of a better name).

[Wildeblood]

From my current OXP-to-be Galactic_start (for want of a better name).

Galactron: New Beginnings

(Omnibus edition of the Galactron Saga, parts 1-8) Use patented Galactron Chart-o-matic technology to begin your journey of interstellar exploration where you want to start, not where you ought to start.

[Cholmondely]

I'm trying to create a believable Larais (...the planet is permanently shrouded in a thick, orange haze. No-one knows exactly what secrets are to be found at ground level as the industrial fog is simply too dense.)

1) Orange without a planet texture seems to become purple with a texture!

2) I can't get seem to get a thick murky orange haze. It seems to be too transparent and too thin.

Current planet description.plist reads (I'm experimenting on Diso as that is where my Jameson is)

Code: Select all

   "0 147" ={description = "This planet is mildly noted for its ancient Ouza tulip plantations but is ravaged by frequent earthquakes. The Diso Digital Corp has built a planet wide sensor-network, with the latest OO32000 super-risk processors. This is capable of predicting the earthquakes a full day before they happen. Houses on Diso are built on giant shock absorbers and are often mobile. Diso is also famous for its 10,000 km long Veers fault.";
            "air_color" = "0.995 0.2 0.0 0.69";       //Experimenting with Diso for Larais!
            "air_density" = "1.0";			    // much higher than normal
            "cloud_alpha" = "8.5";                        // much higher than normal
            "atmosphere_rotational_velocity" = "0.3";  //
            "percent_cloud" = "97";};                    // much higher than normal 

I want a thick pea-souper. And the atmosphere seems rather thin for the size of the planet (or is it just me?)

How am I going wrong? What should I be doing?

References:  Planetinfo.plist & https://rgbcolorpicker.com/0-1

[Redspear]

I want a thick pea-souper. And the atmosphere seems rather thin for the size of the planet (or is it just me?)

Clouds in oolite are... on the subtle side.

I too would like much thicker clouds (in some cases at least).
I 'baked in' clouds layers for additional planets based on Earth's clouds. Much more realistic but a bit samey and very much static.

[phkb]

You're also coming up against the limitations of the engine and the built in assumptions it makes. By default, planets are only there as eye candy, and as an anchor point for the main station. They were never designed to be interacted with. And so clouds were designed to be something that is always viewed from a distance.

I have a feeling the only way we'll get any sort of "pea-soup" fog effect is to add an overlay to the player ship views which gets more opaque the deeper into the atmosphere you go.
Edit: Thinking a bit more, this is probably a job for shaders, similar to the effect when the ECM is fired.

[another_commander]

Code: Select all

 
            "cloud_alpha" = "8.5";                        // much higher than normal

cloud_alpha is expected to be between 0.0 and 1.0. It is the opacity of the cloud layer. 0.0 is fully transparent, 1.0 is fully opaque. 8.5 is clamped to 1.0 in the best case scenario or undefined behavior in the worst.