Gameware navigation

[Anonymous]

Hello, I'm doing an RTS-esque game project. The map is covered with fog in the beginning and there are special units that can walk around and remove said fog, the other units can only move within explored areas. I have been using GwNavTagVolume to mark foggy areas and I forbid the regular units to traverse areas with the stingray.GwNavBot.set_navtag_layer_cost_table function. When a special unit walks close to a foggy area the GwNavTagVolume there gets removed from the world.

The issue is that the GwNavTagVolume doesn't get removed immidiately after calling stingray.GwNavTagVolume.remove_from_world so computing a path to a resource inside this previously fogged area doesn't work. If I calculate a path some frames after it works.

Question is:

Is there a way to have stingray.GwNavTagVolume.remove_from_world work synchronously so it's finished when the function return or,

is there a way to have gameware retry the path computation x frames after it has failed once or,

is there a way around this except doing my own retry the path computation x frames after it has failed once.

[Shanii2]

My i know why your trying to remove the fog layer that is gw.navigation layer. Fog obviously is some sort of particle effects, but then again you can dynamically change the layer cost at run time like initially you can set specially units to transverse through while other can not, then after special event you can then simply make it to see the fog to be removed and dynamically allows the other units to transverse through that layer only, by updating its layer cost on other units bots. this is more optimized for runtime as technically you dynamically tag the layers and update their cost at runtime to provide dynamic control over the units, like a fire are where only fighter can go while others can not and then changing the layer cost dynamically to allow the units to transverse after fire's extinguish. .Again its better you if you explain why you exactly need to remove, cause in actual simulation or game dynamics you simply update the layer cost

[brice.gros · Accepted solution]

You can know the integration status of a TagVolume into the NavMesh by calling

     stingray.GwNavTagVolume.get_integration_status()

The TagVolume is in the NavMesh if its value is:

   - stingray.GwNavTagVolume.IntegrationStatus.INTEGRATED                    

        TagVolume is fully integrated into the NavMesh

   - stingray.GwNavTagVolume.IntegrationStatus.TO_BE_DEINTEGRATED    

        TagVolume is still integrated into the NavMesh but user queried its removal from the NavMesh

The TagVolume is not in the NavMesh if its value is:

   - stingray.GwNavTagVolume.IntegrationStatus.NOT_INTEGRATED      

        The TagVolume is not integrated into the NavMesh

   - stingray.GwNavTagVolume.IntegrationStatus.TO_BE_INTEGRATED   

        The TagVolume is not integrated into the NavMesh but user queried its de-integration

So in your situation, after you called stingray.GwNavTagVolume.add_to_world(), you can wait for the TagVolume to reach the INTEGRATED status before displaying the fog area.

And after calling stingray.GwNavTagVolume.remove_from_world(), wait for the NOT_INTEGRATED status before actually removing the fog effect, and thus you also know the exact moment when you can start pathing through this foggy area.

Also, as mentioned in the previous answer, you can change the cost of the layer without removing the TagVolumes, since you already have several TagVolumes covering the whole map, you could assign them different layer ids, and change their cost when they are discovered.

Brice

[Anonymous]

---

@brice.gros wrote:

you could assign them different layer ids

---

How do you this? I looked around the documentation but could not find anything on it, I believe that just changing the id of my TagVolumes would do wonders for me.

[Anonymous]

Nevermind, I reread your post and realised that you meant that I could assign a different layer Id to each piece of fog. I thought you said I could change the I'd of a tag during runtime first. That might work I'm just worried that on a 100x100 tile map having 10'000 differently tagged navtags will slow down gwnavs astar. I'll try it anyways, thanks for the idea.

[Shanii2]

You can dynamically change. The tag volume layer I'd and cost that what makes it more dynamic during runtime. That information lies in the unit script data of the tag volume. And you can surely change them either in flow or in lua

[Anonymous]

Can you give me a link to where you found this or some example code? I can't find what you're talking about.I know how to change the cost of gwnavtagvolumes with a layer_id but I can't find anything about changing the layer_id for a gwnavtagvolume

[brice.gros]

---

@Shanii-2 wrote:

... unit script data of the tag volume ...

---

Changing the script data at runtime won't change the NavTag written into the NavMesh by the TagVolume.

---

@brice.gros wrote:

you could assign them different layer ids

---

when I said this, I meant as you understood it that you could assign a different layer Id to each piece of fog, not changing it at runtime

So, you can do one of these:

1 - change the layer cost dynamically, beware that:

    a - already computed path won't be changed automatically

    b - paths being computed could not reflect these changes

2 - destroy and create TagVolume (calling stingray.GwNavTagVolume.create()) to change layer ids, in that case:

     a - already computed path going through these TagVolumes will be revalidated, so path could end prior to the destination (e.g. in your case if you could reenable some pieces of fog it could cut paths going through it) but they won't be automatically recomputed

     b - paths being computed could be aborted

With case 2, check stingray.GwNavBot.is_path_recomputation_needed() to know the path must be recomputed either because the NavMesh has changed along this path or while computing the path.

With case 1, stingray.GwNavBot.is_path_recomputation_needed()  could tell you to recompute when the bot following the path will reach the point where the path is invalid (assuming the layer is now forbidden, if only the cost changed, the bot will continue to follow its path)

So in the case you presented, #1 should be good enough since you are only removing piece of fog, so only increasing the navigable area, no path is invalidated. The worst thing that can occur is if a bot has already a path, but if a shortcut through the fog has been created by other pawns who discovered a new area, the bot will continue to follow its current path without taking the shortcut.

Note that at some point in your game, I assume that you will probably want to create obstacles dynamically, at this point you will face case #2, paths becoming invalid due to changes in the navmesh. But it does not mean it is either #1 or #2 for the whole game, you can have fog following case #1, and obstacles following case #2, it is up to you.

Let me know if it is unclear.