Conversation
… their size, refactor some code, add comments
|
The lead programmer for Thrive is currently on vacation until 2026-01-07. Until then other programmers will try to make pull request reviews, but please be patient if your PR is not getting reviewed. PRs may be merged after multiple programmers have approved the changes (especially making sure to ensure style guide conformance and gameplay testing are good). If there are no active experienced programmers who can perform merges, PRs may need to wait until the lead programmer is back to be merged. |
|
I have tested it with previous saves and it works as intended |
|
Does the terrain area now at least extend as far as the spawn system spawns stuff? Because otherwise a microbe might spawn and then as the player moves a bit it might get dumped under a mountain of spawned terrain. |
|
|
||
| public string CollisionResourcePath; | ||
|
|
||
| public bool SkipCollisionLoading; |
There was a problem hiding this comment.
I think it would be clearer to just not set this component for stuff that doesn't want to collide...
Edit: and of course it would be more efficient as well to not create the physics component either for purely visual stuff.
There was a problem hiding this comment.
I'm pretty sure I tried it and I was getting an error because of it but I'll try
There was a problem hiding this comment.
With the new ECS framework, you need to tell it the list of components beforehand, so you'll need a variant of the spawn method that uses a different component list, otherwise it'll blow up. For example for the normal chunks I needed to write quite a complex component list selection algorithm but this should be a simpler case that can be done with a single if branch.
There was a problem hiding this comment.
Okay thanks, I have created new spawn variant
When I was messing with the sphere collision radius set to big numbers, if a chunk spawned inside it it would be pushed out of the collision shape, so I guess the same would happen with the microbe. I will test it though. |
That's usually the case but when there are multiple physics bodies overlapping, it can get permanently stuck. For example cell colonies have a much higher chance of being permanently stuck than single cells. So I imagine cell colonies or multicellular species to be more susceptible to this bug. Which is why I would like the terrain area to be big enough so that terrain already exists before the spawn system triggers for it. This is because I made the spawn system explicitly ask the terrain system that it doesn't try to spawn stuff overlapping terrain (though it uses a fixed radius so it needs a bit improving for multicellular). |
|
hhyyrylainen
left a comment
There was a problem hiding this comment.
I didn't yet read the microbe terrain system changes as the diff shows the entire file as new. But here's some overall comments about the other parts of the architecture and how I kind of don't really like how many parts of the system have been dismantled.
simulation_parameters/Constants.cs
Outdated
| public const float TERRAIN_GRID_SIZE_X = 330; | ||
| public const float TERRAIN_GRID_SIZE_Z = 315; |
There was a problem hiding this comment.
These grid sizes seem a bit specific... Any reason why not a round number like 300?
There was a problem hiding this comment.
well, when I was messing with it it used to be more rectangular since the screens are wider, so that chunks would spawn further horizontally and less vertically (for example 200x300 but with such low difference now it doesn't make sense to keep it)
There was a problem hiding this comment.
That doesn't fully make sense to me because the spawn system spawn radius is a circle, so having more horizontal space doesn't really help with stuck-in-terrain spawns...
| public const int TERRAIN_VENT_SEGMENTS = 6; | ||
| public const int TERRAIN_VENT_RINGS_MAX = 5; | ||
| public const int TERRAIN_VENT_RINGS_MIN = 2; | ||
| public const int TERRAIN_SECOND_VENT_RINGS_MIN_THRESHOLD = 3; | ||
| public const float TERRAIN_SECOND_VENT_CHANCE = 0.4f; | ||
| public const int TERRAIN_VENT_OVERLAP_MARGIN = 2; | ||
| public const int TERRAIN_VENT_RING_HEIGHT_REDUCTION = 10; | ||
| public const int TERRAIN_VENT_OUTER_RING_HEIGHT = -27; |
There was a problem hiding this comment.
I haven't read all the code yet, but my impression is that these would be nice to configure from the JSON.
| "PotentialClusters": [ | ||
| { | ||
| "RelativeChance": 1, | ||
| "SpawnStrategy": 1, |
There was a problem hiding this comment.
Please use enum value names here in the JSON so that it is easy to read.
| current = true | ||
|
|
||
| [node name="BackgroundPlane" parent="." instance=ExtResource("2_yrakl")] | ||
| transform = Transform3D(1.1, 0, 0, 0, 1.1, 0, 0, 0, 1.1, 0, 0, -10) |
There was a problem hiding this comment.
Like I said in the description, I lowered the background image a bit
There was a problem hiding this comment.
Ah, okay.
Did you test with the max multicellular zoom out distance to see if the edges of the plane are visible?
There was a problem hiding this comment.
Well, I also increased the size of the background to negate it but I will have to check
There was a problem hiding this comment.
Somehow I missed that. Otherwise I would have made sure the size to UV ratio is the same so that the visuals aren't stretched differently than before.
| public readonly float Radius; | ||
|
|
||
| [JsonProperty] | ||
| public readonly Vector3 RelativePosition; |
There was a problem hiding this comment.
Why are you removing the advanced chunk configuration from the JSON?
There was a problem hiding this comment.
What was the need to include the relativePosition and Rotation there? It can be configured programatically anyway (and it is done so)
unless we want to also define complex structures using only json. If so, I can revert it
There was a problem hiding this comment.
unless we want to also define complex structures using only json. If so, I can revert it
That's exactly it. I wanted the JSON to be used to define complex structures.
There was a problem hiding this comment.
Okay that makes sense. But I guess it is okay to have 2 ways to define the terrain shapes? One by having it done programmatically like the vents and the other statically in the json?
There was a problem hiding this comment.
I'd say that it would make sense to modify the chunk configuration so that it is either a single chunk or a procedurally generated shape.
Or just flat out not permit the sub-group definitions if the spawn shape is one that is automatically calculated.
| /// <summary> | ||
| /// Handles terrain spawning shapes logic | ||
| /// </summary> | ||
| public partial class MicrobeTerrainSystem |
There was a problem hiding this comment.
Why did you rename the file this system is in but not the class? You should probably revert the file name back. That should also give a more useful diff.
There was a problem hiding this comment.
I didn't rename the file, I created second one creating a partial class because in my opinion there was too many lines of code for one file
There was a problem hiding this comment.
Partial class files should be named ClassName.PurposeOfPartial.cs so that they are grouped next to each other.
There was a problem hiding this comment.
And if renaming back, this file sohuld probably be deleted.
| var entity = worldSimulation.CreateEntityDeferred(entityRecorder, TerrainWithCustomCollisionSignature); | ||
|
|
||
| Quaternion rotation; | ||
| if (chunkConfiguration.RandomizeRotation) |
There was a problem hiding this comment.
Why did you remove the base rotation feature? Devon said that some of the chunks were clearly meant to also rotate horizontally etc. so I don't think that feature makes sense to remove from this base code...
There was a problem hiding this comment.
Honestly, I must have forgot about that...
src/microbe_stage/Spawners.cs
Outdated
| typeof(MicrobeTerrainChunk), typeof(PredefinedVisuals), typeof(Physics), typeof(PhysicsShapeHolder), | ||
| typeof(CollisionShapeLoader), typeof(StaticBodyMarker)); | ||
|
|
||
| private static readonly Signature TerrainWithCustomCollisionSignature = new(typeof(WorldPosition), |
There was a problem hiding this comment.
I'm reading this and this looks to be the exact same as the TerrainSignature, so why does this exist?
There was a problem hiding this comment.
It doesn't have CollisionShapeLoader
There was a problem hiding this comment.
Ah, apparently I'm blind then. Still, I recommend changing the name to TerrainWithoutCollisionSignature for clarity as to what the purpose of this is.
src/microbe_stage/Spawners.cs
Outdated
| entityRecorder.Set(entity, new PredefinedVisuals | ||
| { | ||
| VisualIdentifier = VisualResourceIdentifier.None, | ||
| }); |
There was a problem hiding this comment.
This is just a waste if this is meant to be just a collision to even have the visual component in it.
There was a problem hiding this comment.
True, I guess I will need to create another signature for that
|
Still haven't fixed all things so please don't review it yet |
# Conflicts: # src/microbe_stage/MicrobeCamera.tscn
This PR does sevelar things:
Example terrain:

Area of terrain generation before:

And after:

Left to do:
Progress Checklist
Note: before starting this checklist the PR should be marked as non-draft.
break existing features:
https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
(this is important as to not waste the time of Thrive team
members reviewing this PR)
styleguide.
Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.