Implemented/Fixed Mine Door rotation - #58
Conversation
Issue Warlander/DeedPlanner3 Warlander#7
Warlander
left a comment
There was a problem hiding this comment.
I think door direction rotation should be happening on graphics level only, without Ground model needing to be aware of it as we only really need it for rendering - and it shouldn't be a performance issue given we only need this info if something is changing with the ground.
| ground.data = newData; | ||
| ground.Tile.Map.Ground.SetGroundData(ground.Tile.X, ground.Tile.Y, ground.data, ground.RoadDirection); | ||
| ground.DoorDirection = ground.Tile.UpdateDoorDirection(); | ||
| ground.Tile.Map.Ground.SetGroundData(ground.Tile.X, ground.Tile.Y, ground.data, ground.RoadDirection, ground.DoorDirection); |
There was a problem hiding this comment.
Why do we need to serialize it?
There was a problem hiding this comment.
It's not serialized anymore
| Tex2d = tex2d; | ||
| Tex3d = tex3d; | ||
| Diagonal = diagonal; | ||
| IsCaveDoor = ShortName is "wcaDoor" or "gcaDoor" or "scaDoor" or "mcaDoor"; |
There was a problem hiding this comment.
I would lean more towards optional XML tag here, similar to how openings and diagonal-enabled ground types are defined.
There was a problem hiding this comment.
As cave doors are the only ground types that can rotate, I used the "Cave door" category name to set it to true
There was a problem hiding this comment.
I think using the category name is a better way to check this as it is already documented in objects.xml whether it is a cave door or not, and this way we require no extra tag.
| // Cave.Initialize(this, Database.DefaultCaveData); | ||
| } | ||
|
|
||
| public DoorDirection UpdateDoorDirection() |
There was a problem hiding this comment.
Update would indicate something within the tile changes but it's not the case, the door direction seems to be calculated here.
There was a problem hiding this comment.
Renamed it to CalculateDoorOrientation
| // Rotating vectors based on DoorDirection | ||
| if (dir == DoorDirection.E) | ||
| { | ||
| (v00, v10, v11, v01) = (v10, v11, v01, v00); |
There was a problem hiding this comment.
That's interesting syntax, honestly it makes lots of sense here! 👀
| DoorDirection doorDir = doorDirectionsArray[x, y]; | ||
| Vector2Int selfCoords = new Vector2Int(x, y); | ||
|
|
||
| int westSlot = vertexIndex; |
There was a problem hiding this comment.
I think syntax where these values are only initialized once would be easier to read here.
There was a problem hiding this comment.
In the newest commit I changed it a bit:
var (wOffset, nOffset, eOffset, sOffset) = (data.IsCaveDoor ? doorOrientation : DoorOrientation.N) switch
{
DoorOrientation.E => (9, 0, 3, 6),
DoorOrientation.S => (6, 9, 0, 3),
DoorOrientation.W => (3, 6, 9, 0),
_ => (0, 3, 6, 9),
};
int westSlot = vertexIndex + wOffset;
int northSlot = vertexIndex + nOffset;
int eastSlot = vertexIndex + eOffset;
int southSlot = vertexIndex + sOffset;
| private int[,] slopesArray; | ||
| private GroundData[,] dataArray; | ||
| private RoadDirection[,] directionsArray; | ||
| private DoorDirection[,] doorDirectionsArray; |
There was a problem hiding this comment.
Just as a sanity check, is it guaranteed to be correct initially? All door directions will be set to N by default.
There was a problem hiding this comment.
For cave doors it is guaranteed to be incorrect almost always initially. But then it should almost immediately correct itself as of the current version.
| private bool needsUvUpdate = false; | ||
|
|
||
| public void Initialize(int width, int height, OverlayMesh newOverlayMesh) | ||
| public void Initialize(Map map, int width, int height, OverlayMesh newOverlayMesh) |
There was a problem hiding this comment.
I'm not a fan of map knowing about GroundMesh and GroundMesh about the map, but this entire part of code needs later refactor anyway so I'm ok with it for now.
There was a problem hiding this comment.
This should not be a problem now, groundMesh just gets the orientation, doesn't initiate calculating it.
Ground.cs: New CalculateOrientationFor method using Tile.CalculateDoorOrientation, method is being used in setting orientation into ground data. Also added old/new state switches to execute, undo GroundMesh.cs Pretty much same as was before, I just had to re-add it after merge conflict overwrite. Except GroundMesh now doesn't know about map.cs TIle.cs Calculate orientation inside refreshorientation method now, rather than calculating it at groundMesh, so now when it is called in ground this both calculates it and sets it into groundData.
| break; | ||
| case "category": | ||
| categories.Add(child.InnerText.Split('/')); | ||
| caveDoor = (child.InnerText == "Cave doors") ? true : false; |
There was a problem hiding this comment.
Project convention is to use XML tags for this kind of data - check "diagonal" for example. :)
| meshUvs[vertexIndex + 10] = v00; | ||
| meshUvs[vertexIndex + 11] = vCenter; | ||
|
|
||
| RenderMesh.uv = meshUvs; |
There was a problem hiding this comment.
This is an expensive call, but we already have needsUvUpdate flag to make sure it gets triggered once per frame at most
| tile.Map.GetRelativeTile(tile, -1, 0)?.RefreshSurfaceEntities(); | ||
| tile.Map.GetRelativeTile(tile, 0, -1)?.RefreshSurfaceEntities(); | ||
| tile.Map.GetRelativeTile(tile, -1, -1)?.RefreshSurfaceEntities(); | ||
| t10?.RefreshSurfaceEntities(); |
There was a problem hiding this comment.
Is there something about this change that requires refreshing surface entities on nearby tiles?
There was a problem hiding this comment.
I believe this is actually not changed just added the Tile variables. Before the PR it looked like this:
tile.RefreshSurfaceEntities(); tile.Map.GetRelativeTile(tile, -1, 0)?.RefreshSurfaceEntities(); tile.Map.GetRelativeTile(tile, 0, -1)?.RefreshSurfaceEntities(); tile.Map.GetRelativeTile(tile, -1, -1)?.RefreshSurfaceEntities();
I would assume this is to set walls and fences properly on neighboring tiles when the slope changes.
| { | ||
| ground.data = oldData; | ||
| ground.Tile.Map.Ground.SetGroundData(ground.Tile.X, ground.Tile.Y, ground.data, ground.RoadDirection); | ||
| DoorOrientation orientation = CalculateOrientationFor(ground, newData); |
There was a problem hiding this comment.
Should we pass new data in undo? May be worth testing if that's the correct behavior
There was a problem hiding this comment.
Thanks for catching this, this should definitely be oldData 😅
This PR is related to issue #7 .