My nodes outside the gridManager brake every time I make the changes in this video.
Hi,
What do you mean by “break”? What did you expect to happen? What happened instead? Please share more information on what you did and have in Unity.
Everything works the way it should right up until I make the changes in the MORE DEBUGGING TOOLS video. After making the changes in that video my Labels outside the GridManager no longer change to the correct color. The ones inside the grid manager act the way they should, they use the default color but all labels outside of the grid no longer use any other color than the vetex selected color on the original tiles. And garry says at the end of the video that all tiles outside the gridmanager should work normally and mine dont.
All I did here was make the changes in CoordinateLabeler and GridManager.
I checked my code against the project files code, but there was no errors so then I just copied the code straight from the project files but I still get the same issue.
I did create my own assets for this and I did follow along as closely as possible when creating my tiles and everything seemed to be going fine right up until this point. I didnt want to just start again as Ive already done that once in this project and I’d rather figure out why this doesnt work to be honest lol.
Normally I try to figure this stuff out on my own but I just dont understand where Im going worng in this one lol. I started the 2d course after getting stuck on this project and Ive since finished that course now and I still cant figure this out XD. Thanks for the reply.
Hi Marno, I am seeing this same behavior!
The Problem
The tiles outside my GridManager did not keep the colors set by the previous version of CoordinateLabeler. Instead, with the new version of CoordinateLabeler, all tiles managed by GridManager turned defaultColor (white in my case), as expected, but all tiles outside GridManager reverted to the label color of the Tile prefab. You can see this distinction if you change the label color on your Tile prefab to something different from defaultColor in your CoordinateLabeler script (to show that it is using the prefab color, and not the defaultColor).
The Reason
If your tiles are indeed using the prefab color, it’s because the tile instances have not overridden the prefab color – i.e. if you look in the Inspector at your tile instances, the Vertex Color will not be bolded or marked with a blue indicator. I did verify that when @garypettie 's code is run in the editor, the Vertex Color property of each tile’s Text (TMP) object does get saved as an override.
So why didn’t mine (or yours)? In my case, I’d made a seemingly-minor change that broke this behavior. I’d wanted to see the coordinate labels even during gameplay, so I removed the label.enabled = false; line from the Awake() method, seen here in Gary’s version.
The Explanation
I switched back to the waypoint-based color behavior and added some debugging to the CoordinateLabeler script to try and track down what was happening:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using TMPro;
[ExecuteAlways]
[RequireComponent(typeof(TextMeshPro))]
public class CoordinateLabeler : MonoBehaviour
{
[SerializeField] private bool debugThisTile = false;
[SerializeField] private bool enableLabelInAwake = false;
[SerializeField] private Color defaultColor = Color.red;
[SerializeField] private Color blockedColor = Color.grey;
[SerializeField] private Color exploredColor = Color.yellow;
[SerializeField] private Color pathColor = Color.blue;
private TextMeshPro label;
private Vector2Int coordinates = new Vector2Int();
private GridManager gridManager;
private Waypoint waypoint;
private void PrintPropertyModifications(string method)
{
if (debugThisTile)
{
PropertyModification[] mods = PrefabUtility.GetPropertyModifications(label);
string result = "No prefab overrides";
if (mods != null)
{
result = "No vertex color override";
foreach (PropertyModification mod in mods)
{
// Observed that this property, along with `m_fontColor.r` and
// `m.fontColor.g`, show up when the Vertex Color property appears
// as overridden in the Inspector.
if (mod.propertyPath == "m_fontColor.b")
{
result = "Vertex Color overridden";
break;
}
}
}
string mode = Application.isPlaying ? "Game" : "Editor";
Debug.Log($"[{mode}] {method} method - {result}");
}
}
private void Awake()
{
PrintPropertyModifications("Awake");
waypoint = GetComponentInParent<Waypoint>();
label = GetComponent<TextMeshPro>();
label.enabled = enableLabelInAwake;
gridManager = FindObjectOfType<GridManager>();
DisplayCoordinates();
}
private void Start()
{
PrintPropertyModifications("Start");
}
private void Update()
{
if (!Application.isPlaying)
{
DisplayCoordinates();
UpdateObjectName();
label.enabled = true;
}
SetLabelColor();
ToggleLabels();
}
private void ToggleLabels()
{
if (Input.GetKeyDown(KeyCode.C))
{
label.enabled = !label.enabled;
}
}
private void DisplayCoordinates()
{
coordinates.x = Mathf.RoundToInt(transform.parent.position.x / UnityEditor.EditorSnapSettings.move.x);
coordinates.y = Mathf.RoundToInt(transform.parent.position.z / UnityEditor.EditorSnapSettings.move.z);
label.text = $"{coordinates.x},{coordinates.y}";
}
private void UpdateObjectName()
{
transform.parent.name = coordinates.ToString();
}
private void SetLabelColor()
{
PrintPropertyModifications("Beginning of SetLabelColor");
label.color = waypoint.IsPlaceable ? defaultColor : blockedColor;
PrintPropertyModifications("End of SetLabelColor");
// if (gridManager == null) return;
// Node node = gridManager.GetNode(coordinates);
// if (node == null) return;
// label.color = !node.isWalkable ? blockedColor : node.isPath ? pathColor : node.isExplored ? exploredColor : defaultColor;
}
private void OnApplicationQuit()
{
PrintPropertyModifications("OnApplicationQuit");
}
}
The new debugThisTile field allowed me to see debug statements only for a single tile for simplicity, and the enableLabelInAwake field allowed me to see the effect of either enabling or disabling the TextMeshPro label in the Awake() method.
Below I’ll show two scenarios where I:
- Reverted the Vertex Color override on my test tile instance
- Entered Play mode
- Exited Play mode
- Took a screenshot
The first screenshot shows the behavior when label is disabled on Awake(), as in Gary’s code. Note at the top of the inspector that the Vertex Color is bold and marked blue to show it’s overridden. The logs indicate that this override is saved after an initial call to SetLabelColor() (i.e. an initial call to Update()) while in Editor mode after having exited Play mode.
The next screenshot reproduces the problem. Note that “Enable Label in Awake” is now checked. This time, after entering and exiting Play mode, there is no override on Vertex Color.
The Answer
Sorry, I still don’t have a satisfying answer as to why enabling the label in Awake() means the color change does not get saved as an override, particularly since we are enabling it anyway in the Update() method while in Editor mode.
Hoping @Nina or @garypettie can provide some insight there!
Afaik, the GridManager is only concerned with tiles that are inside the grid. The CoordinateLabeler ignores tiles that are outside the GridManager dimensions and therefore does not change the colors on those, keeping it at whatever they are set to in the prefab, or overridden in the inspector.
These lines here is what ignores tiles that are not inside the grid
Node node = gridManager.GetNode(coordinates);
if(node == null) { return; }
Yes it’s definitly a hard one to track down since everthing looks correct even my tiles. They all resize if I change the main tile and the path still works, it just doesnt display the colors correctly the old way for some reason but I dont think it matter anyway…
I watched the rest of the project last night and it seems like using the new way will make this issue a none issue lol. By the end of the project we wont be using our path tiles anyway, we end up using Breadth first search completely. Im going to just go ahead and finish the project and see if can still finish the project without this being an issue. We will see.
You are right. As long as your pathfinding algorithm works correctly, the colours do not matter. Their purpose is to give us a visual help for debugging but if they add more problems than they solved, they defeated their purpose. 
1 Like
My labels work both ways but not at the same time like garrys does lol. Ive almost finished this project now and other than this minor difference everything has gone smoothly 