Open CardamomCake opened 6 months ago
{ "name": "", "author": "", "gameType": "Free Roam", "environment": "Yellow / Green Nebula", "location": "Space Station", "musicTrack": "Digital Battleground", "authorTimeTarget": 60.0, "startPosition": { "x": 831.8865, "y": 829.9015, "z": 1022.73615 }, "startRotation": { "x": 24.9638634, "y": 101.7147, "z": 9.371663 }, "shipConfig": { "angularDrag": 0.0, "boostCapacitorPercentCost": 70.0, "boostCapacityPercentChargeRate": 10.0, "boostMaxSpeedDropOffTime": 12.0, "boostRechargeTime": 4.0, "boostSpoolUpTime": 1.0, "drag": 0.0, "inertiaTensorMultiplier": 175.0, "latHMultiplier": 0.5, "latVMultiplier": 0.7, "mass": 1100.0, "maxAngularVelocity": 7.0, "maxBoostSpeed": 932.0, "maxSpeed": 800.0, "maxThrust": 220000.0, "minUserLimitedVelocity": 250.0, "pitchMultiplier": 1.0, "rollMultiplier": 0.3, "throttleMultiplier": 1.0, "thrustBoostMultiplier": 3.25, "torqueBoostMultiplier": 2.0, "torqueThrustMultiplier": 0.08, "totalBoostRotationalTime": 6.0, "totalBoostTime": 5.0, "yawMultiplier": 0.8 } }
I do like this idea quite a lot, but I also want this to be somehow presented in a human-readable manner when people load up a map. I'm also not entirely sure the full gamut of configurable options needs to be tweakable (still like inetriaTensorMultiplier for collisions has probably outlasted its' debug intent!). Open to thoughts on this though.
The readability of the custom config when loading the level is a good idea, but maybe it is enough to have a custom config warning or indicator. These parameters are not that readable in the first place, so warning people that they should expect something different might be equivalent to giving them all the stats for the vast majority of the player base.
The way I think it should work is that Time Trials always enforce the base config, or the specified custom config. This clashes with the current behavior where you are allowed to load the map, but it just invalidates the time without any warning, which I don't think is ideal behavior.
A simple warning that the ship config of the Time Trial is different from the config in the settings could solve both problems.
How do you feel about having the custom config automatically be included within the "Copy ship location" option?
InetriaTensorMultiplier was like the mass equivalent for rotations, right? I think that removing could break compatibility with older ship configs, since it also affects the speed at which ships will turn. Hiding it will probably be the better choice. I do agree that the inertiaTensorMultiplier and mass are technically redundant outside collisions, which are punished so hard that it might as well not be part of the game. Further discussions on this should probably be done in a separate issue tho.
I have started a little bit on this now. The previous issue I did was meant as a warm-up for implementing this. I assume that's fine, unless you are also already working on this.
My plan Is to add shipConfig{} to the Track data/json and make sure that it only lists the non default parameters, so that it stays as readable and space efficient as possible.
I plan to make it not overwrite the settings in the Dev Panel so that we don't accidentally overwrite anyone's config, but instead hide the panel or gray out the apply button while in a time trial mode, because I think ship configs should be enforced in trial modes.
I don't have a specific plan for the GUI warning for a custom ship config yet. This might be something I leave to you to implement.
Does this sound reasonable?
Yeah that sounds quite reasonable. We'll also need to update some stuff for leaderboard compatibility:
Include ship parameters (IF not default! It must maintain the current UUIDs for maps with no params) in the generation of the UUID for the level data - this ID this maps to leaderboards and would mean changing these values would be considered a different leaderboard as the rules for the map have effectively changed.
Change the validation for the score saving to check to see that the flight parameters for the map are intact (vs just the defaults as they do now)
Another question is how we handle the ship param display in the dev console - do we change those to match the current map? does clicking 'default' revert to the maps' params or the actual default?
Those problems were already on my list, but I had not yet come around to it until now.
I have added a hash string generator function to the shipParameters class, which creates a string of all the changed parameters and their value in a defined order. In the case that the shipParameters are unchanged, the string will be empty.
However, the isVallid check was giving me more trouble when I changed that. Apparently it is called as soon as the game launches, causing it to try to read levelData which has not been created yet and crashes the game. A simple try, catch{ return false} did the trick.
Things seem to be working now. Now I think I have to turn on Steamworks in order to test ghosts n stuff. I'l do that in a special custom race or something.
Everything seems to be working with the PR I just reopened. There was still an issue of communicating that a custom config has been loaded. I don't have much of an opinion on how that should be handled. Do you have an idea of the best way of tackling that?
How cool would it be if a costom ship config could be specified for a race like this: