pathfinding is triggered upon changing any start or end position , it should draw a path as soon as both start and end points lie within the walkable tiles (not the red ones) and obviously if a path is possible towards the points ..
new obstacles (non walkable tiles) will only be included within the path ,upon requesting a new path ,in that simple test script it is not handled by code to refresh paths when tiles are removed ,but can be done by moving one of the start/end points to request a new path .
normally each unit of different size would need its own navmesh , but there are other techniques as well but there is only one unit size and navmesh in that test ,for the sake of simplicity.
rts pathfinding is very dependant on the game and function itself , therefore difficult to code a library for multiple use in different games , but if it is tile only like rts games ,I think I could manage flexibility somewhat to an extent for possible unforseen things .
anyway , usually on some implementations of recast/detour , they use the tile cache/temporary obsticles for obsticles , or they use a tile rebuilding technique with polygonal regions of types , usually tiles themselves aren't used like I did.
I know unreal engine has a pretty flexible navmesh system , I haven't played with unreal engine yet but have read about its navmesh system being editable pologonable ,without using an external modeling application , to be honest I have never noticed a rts game build upon unreal engine yet .
I drop and pick up projects quite frequently , this is because I try out a prototype and quickly drop it if it sucks , so projects like this one survive only because I see something of value in it ,it could be learning /an interest/ challenge myself / usability / fun or something I would like to do , as this little idea came it might also fade away again .
