int CC = BOARD.childCount;
for (int x = 0; x < CC; x++)
{
Debug.Log(CHESS + " " + CHESS.HEAT_MAP.Count + "" + x + " " + BOARD.childCount);
}
The info shown here might be a little confusing. But it shows that reference to CC (child count) is 64. but the forloops x iterator. displays 039;
So its obviously not formatted back end. or a rare type of bug. I don’t usually obtain a transforms child count this way so I don’t usually encounter this type of bug. I didn’t file the post as a bug yet wanted to see what others make of it. Or see if anyone else had experienced anything like it.
Have you ever seen anything like it?
I’l just explain once more;
The Boards child count is 64.
for looping that child count returns values in unformatted 0 + index and eventually a null reference lol
an expected value without a zero. I’ll dig around some more. I may have a legit null reference somewhere. Stops around 39 just debugging the x. So i’ll confirm nothing is up at 39 before continuing.
See because generating my heat map takes a few frames to establish the 8*8 grid, after each turn, or inbetween turns i should say. Sometimes the move is viable before the heatmap has established. The Heatmap is only for the AI see, and for Check Vetting of the royal piece. So the list was partial or zero while firing. So the fact 039 is returned is inconsequential and is something to do with the long multi-data debug habit I have. But ultimately it is still considered 39; value. just displayed as 039.
I am curious why you would think that a basic read-only property on such as fundamental Unity thing would be a bug as opposed to your script. I feel thinking like this can stop you from debugging your own code correctly.
I always assume it’s my code and verify the Unity side using another code check before making any decisions. Maybe not so on huge complex things but for fundamental stuff it’s different.
I mean, I’ve been guilty of shouting “What the heck Unity” only to go make a drink, come back and quickly realise my mistake which was mostly that I’ve been staring at the screen too long without a break!
As we are in the game of anticipating problems coding in ways to avoiding problems. When it seems a problem arises in the structure of the program we use it can cause temporary haywire to our plans.
I managed to achieve my plan anyways. See the heat map establishes at a quick interval. Sometimes I click on a unit, before it established, and generate movement options by action of selected unit. So I made sure my clicks cant function during heat map generation. In the above the queens cannot move to other tiles (not currently highlighed), they only have movement options available for capture or block of the white queens line of sight.
So I managed to achieve what I wanted in the end. Enforcement of the player to resolve the check issue.
