# suliman

Member

1425

1659 Excellent

• Rank
Contributor

• Interests
Art
Design
Programming
1. ## A* pathfinding: nodes instead of grid?

But while searching on a strict grid, it DID (always) find the shortest path. What do you mean by understating values? Could I do some trick with the move-cost for a connection (now I use simple distance) to lessen the errors? Or could I manually lessen the optimization to increase precision (without rebuilding it fully into djukstra). It seems to already optimize the NUMBER of nodes in a path (to have the least steps).
2. ## A* pathfinding: nodes instead of grid?

Yay it works! @Frob Maybe i ran into the problem you mensioned though: It always finds a path, but in certain circumstances it chooses a valid path that are slightly longer (around 10 %) compared to the most optimal path. I use distance (float) between nodes as movement cost for that connection. If I move that node so that path is now 20-30 % longer it will choose the shortest path instead. Any idea where this slight error may come from?
3. ## A* pathfinding: nodes instead of grid?

I propose to use the grid as normal (a 2d array of tiles), but I also give the pather access to my collection of "nodes". These have (max )10 neighbours which make up the "restriction". So when a tile checks for "neibours", they used to find all 8 adjacent tiles, but now it looks in the node-collection which tiles it could add as possible neibours. See the pic below. Node 3 would have only node 2 and 4 as neibours for example. It cannot find the tiles "right next to it" as it would in my normal grid-based mode. The nodes acts as my old tiles in other part of the code, they still have a x/y position which actually describes their position on the grid.
4. ## A* pathfinding: nodes instead of grid?

@Frob: not sure if I understand the problem, or if this would be a problem for me. After code inspection: So much of my code (both finding and storing the path and following it) depends on a grid (and I need one anyway for drawing the world / placing objects) I now consider this setup: 1. Use my tried and tested grid-based A* system. 2. Add a "node-based mode". This is work the same way but also keep track of the "nodes" in the way described above. Basically they inform the pather which are the adjacent "tiles" to each node-tile. So when running the grid-mode each tile has 8 adjacent tiles, but when running the node-mode it will check the structure outlined above for which (up to) 10 adjacent tiles are reachable from that tile. So basically I would pathfind over a restricted grid where only certain tile-to-tile connections are allowed. Seems doable?

6. ## A* pathfinding: nodes instead of grid?

Im using micropather, a c++ implementation of a* pathfinding in my games. I got it to work fine with a strict grid-based system, but now need it to also work with "nodes". My setup is like this: 1. I have a collection of nodes. Each node has a X/Y-position, an ID, and an array of max 10 node-ids it can move to ("adjacent nodes"). 2. Which nodes are reachable from each node are checked (based on a max distance and not having any obstacles between them). 3. Cost to move from a node to another is simply the distance between the 2 nodes' positions. I guess some things will be silimar to how a grid works, but im not sure how to reconstruct the code.

8. ## Progression in racing game: keep money and upgrades between races?

Thanks for your feedback! Useful input.

11. ## Pirate game: treasure hunting mechanic

Thanks guys! Some good thoughts. Any more input is always appreciated.
12. ## Unresolved external symbol?

yes it does. I continued to clean up and now it works (even with the body in the h-file). I think I had a reference to an old version of it that was local and not the standardized version i now use (#include "file.h" instead of #include <file.h>). This is one of my big problems with C/C++. It's so easy to get stuck on code administration (linking, include order, circle reference etc) It takes time (especially when reviving an old project that had a slightly different code architecture). Thanks for your help!
13. ## Unresolved external symbol?

Cool! Commenting out that call allows for it to compile. But what can be wrong here? That file (with the constructor for gameInventoryMaster) is included in all my project and those work without commenting out the call togameInventory::setSingleSlot(). Why is it now not allowed? I moved the body of the contructor (of gameInventoryMaster) to the cpp file (from the h file) and now all projects compile. So im confused, what could have have done here?
14. ## Unresolved external symbol?

Hi Having coded alot, i still get stuck on these things sometimes. I've restarted an old project so I needed to clean it up, fixed paths etc before it could compile. I still have one compile error: Error 1 error LNK2019: unresolved external symbol "public: void __thiscall gameInventory::setSingleSlot(class int2)" (?setSingleSlot@gameInventory@@QAEXVint2@@@Z) referenced in function "public: __thiscall gameInventoryMaster::gameInventoryMaster(void)" (??0gameInventoryMaster@@QAE@XZ) C:\Dropbox\PROJECT\code\games\racing\source\gameMaster.obj May it be a circular include or something? The function "setsingleSlot" is defined in a file called "inventory.h" which i dont have any references to in my project, so im a little stuck here. Any ideas? Happy holidays ya'all!