Conversation
TODO: Fix all of the visualization logic.
| /// <param name="b">The second <see cref="GasMixture"/> to compare.</param> | ||
| /// <returns>A float between 0 and 1 based on how similar the gas mixtures are, | ||
| /// based on percent compositions.</returns> | ||
| public float GetGasMixtureSimilarity(GasMixture? a, GasMixture? b) |
There was a problem hiding this comment.
nit/suggestion: mathematical similarity feels really arbitrary for thrusters, maybe just handle the gasses uniquely instead (esp as this can enable fun interactions like the thrusters oxidizing themselves to death if you put O2 in there and allowing the use of N2O for boosting which makes no sense they're ION thrusters and do not combust the plasma but it'd be funny)
| } | ||
|
|
||
| // Fall back to 1 if no valid denominator is present | ||
| return denominator == 0f ? 1f : numerator / 1f; // numerator is already normalized here. |
There was a problem hiding this comment.
don't use equals here because platform dependant fpu behavior :)
(use a small epsilon, arbitrary, like 0.001f, so Math.Abs(denominator) < 0.001f to see if the number is sufficiently near zero.)
| /// than effectively duplicating the code.</remarks> | ||
| [Serializable] | ||
| [DataDefinition] | ||
| public sealed partial class ThrusterGasMixturePair |
There was a problem hiding this comment.
calling it a "Pair" is a misnomer, it is not two numbered fields (i.e. public struct Foo(lower, upper)). Just call it a ThrusterGasMixture.
Also make sure to assert the mixture is immutable or you can and will have weird effects at runtime if anyone has the funny idea of balancing toward this mixture!
| /// <summary> | ||
| /// Cached query for shuttle components, | ||
| /// since they rarely change, and we need to access them frequently. | ||
| /// </summary> | ||
| private EntityQuery<ShuttleComponent> _shuttleQuery; | ||
|
|
||
| /// <summary> | ||
| /// Cached query for thruster transforms, since | ||
| /// we need to access them frequently when we preform thruster buff/nerf updates. | ||
| /// </summary> | ||
| private EntityQuery<TransformComponent> _thrusterTransformQuery; |
There was a problem hiding this comment.
nit: imo overly verbose docs for a common optimization.
|
|
||
| break; | ||
|
|
||
| // If the field is not present(???), fallback to Pure. |
There was a problem hiding this comment.
non-presence would be None (your first enum value, 0). You should throw new NotImplementedException() over the fallback, as that means the enum is some unknown invalid value.
| // gyroscope by feeding it tritium. | ||
| if (ent.Comp.Type == ThrusterType.Angular) | ||
| { | ||
| shuttlecomp.AngularThrust += deltaThrust; |
There was a problem hiding this comment.
These two thrust values scale very differently, I would slap a sqrt or smth on deltaThrust exclusively for angular thrust just so it doesn't result in extreme spinny with high efficiency. Mess with it a bit ig?
Because right now it seems like this would add over 40,000 angular thrust, way outside the 'intended' range of values, which would be really funny but not desired.
| { | ||
| var benefit = 0f; | ||
|
|
||
| // You'll never catch be writing this shit in upstream in a million years. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
# Conflicts: # Content.Server/Shuttles/Systems/ThrusterSystem.cs
|
ended up on #43 because of jank |
3 participants
About the PR
Introduces Fueled Thrusters, a thruster variant that requires some sort of gas to operate.
Thrusters receive benefits like reduced fuel efficiency and increased thrust depending on the gas mixture currently present in the thruster. Gas mixes and their benefits can be determined as an array and have their benefits applied in under different circumstances.
Why / Balance
Needed.
Technical details
A new object is defined that "pairs" up a GasMixture object with data about that GasMixture.
A new atmospheric update loop in ThrusterSystem processes this information and determines the final thrust multiplier/efficiency available to the thruster. It also determines if the thruster is allowed to fire or not.
Overall the code is very scrungly and to be honest I'm thinking of rewriting ThrusterSystem to more modern standards, as it wasn't super extensible to add onto. Ideally we'd like to define certain thruster effects that can happen. Right now it was complicated enough to get certain state/prevention logic working and even then the implementation still suffers from visual bugs.
Media
Requirements
Breaking changes
not yet
Changelog