Hex Grid Pathfinding distance solution for ShootAction and GrenadeAction?

[Dwightski]

Great course, and the hex system is a great bonus… I found the bug on the shoot, grenade, interact and other action distances that CodeMonkey didn’t address, and also saw the solution that was published that included a math function, but I was able to solve both the GrenadeAction and ShootAction scripts by adding the pathfinding instance inside the GetValidActionGridPostionList function for each action.

Looking into the other distances, but I thought I’d bring it up.

[CodeMonkey]

What bug did you encounter? What is the issue with those screenshots?

[Dwightski]

Hi CodeMonkey,
Those two routines did great. I didn’t see where I needed the extra math function for them that people said was necessary.

When I did the same with the interact and sword is where I get an extra hex set (two left or right) selectable depending on odd or even row.

When playing, it allows me to do one interaction with the out of bound interaction. (opening the door)

Then testing I click the move interaction and then back to the interact and the one that shouldn’t have been selectable is now unselected and everything works correctly, so the initialization is what I’m not getting correct…

[CodeMonkey]

Hmm I remember I encountered a bug just like that during my testing but I thought it was fixed.
Does it only ever happen that first time? It no longer happens after selecting another action just once? Really not sure what could be happening there, maybe add some Debug.Log inside the GetValidGridPositionList(); to see what is happening differently between the first and second time

[Dwightski]

Hi CodeMonkey,
Sorry for the delay, I may still be banging my head over here, but after going through a few manual pages, I stumbled upon this prefab drop and thought this is exactly what is needed to get the closest grid locations to the unit, no matter which row it’s at, odd or even…

Unity - Manual: Instantiating Prefabs at run time

Let me know if I’m on track here or if I’m making things too complicated again…

[CodeMonkey]

You can’t just get the position based on angles, that only works for a position with a distance of 1, once you go past that if you use that logic it will miss a bunch of hex positions.
Have you tried downloading the final project files? I did encounter that issue during testing but I believe I fixed it in the final code.

[Dwightski]

Hi CodeMonkey,

I did not download the final version of your program code yet.
I like these types of puzzles, so I’m enjoying the thought process.

I will download the code to see what you did for the one unit distance solution for the sword and interact components.

Thanks again for the awesome course, I always learn so much from your teaching.

[Dwightski]

I did as you asked and setup a debug for the InteractAction.GetValidActionGridPositionList() to see what was happening, and the validGridPositionList has 9 values. Leans to the right if it’s even, left if it’s oddrow. It doesn’t use pathfinding as far as I can tell, that’s why my earlier post about the six positions around the unit.

I downloaded your solution, and I think our code is the same.

[Dwightski]

Hi CodeMonkey,
I got the InteractAction script to operate properly. Transitioned it to six positions for what it’s worth. Works on both odd and even rows.

Now to copy and paste to the SwordAction and properly implement the if statements. I’ll keep working on it…

[Dwightski]

Here’s the top of the file.

position = unit.transform.position + new Vector3(x, 0, z);
Debug.Log("positionList " + positionList);

position should replace positionList in the Debug.Log and positionList can be removed from the script.

[CodeMonkey]

So you hardcoded the position amount? Sure that works for that specific distance
Did you test the Interact action from the downloaded project files?

[Dwightski]

Hi CodeMonkey,

Yes, the debug I did on the GetValidActionGridPositionList() please see above, had the logic from your interactAction file.

All the Actions have the same logic:
for (int x = -maxMoveDistance; x <= maxMoveDistance; x++) {
for (int z = -maxMoveDistance; z <= maxMoveDistance; z++) { }

When the grid was square, there were 9 positions when you include the unit. This logic can be found everywhere. Even in the UI for the soft_red color.

All I did was take the lookup and changed it to look for 6 positions, which are the interact positions around the unit.

The bug comes from looking up too many positions for the unit on the hex grid.

You get invalid results and it allows the unit to select a location that is out of reach to do the interaction. I made the same change to the swordAction and now I’m getting the correct results for that action as well.

I’m of the opinion that all of the locations where the logic is trying to find 9 positions should be turned into logic looking for 6 positions.

The pathfinding shouldn’t be effected because it goes one hex at a time and saves the location.

Hope this helps as to why my thinking is going down this path.