Spring.Buildpaths().

[Argh]

Simply put, rebuilds the pathfinder's valid paths to match the current heightmap geometry and game / movetype (I don't know what it uses), then alters the path files accordingly.

That's the easy version, at least for me. I know that dynamic re-pathing isn't in the cards, due to costs.

But I really need a way to do it somehow, or the whole dynamic-map stuff just isn't very practical. Units do not repath correctly when lua manipulates the heightmap, basically. I knew this was a problem, when I tested early CA experiments with this, but now I know for certain that it's basically ignoring changes in height entirely.

The hard version is that somebody could explain what the hex in the path files does, and how to find the game / movetypes (because it appears that it's appended per game) and then I could, theoretically, write it via Lua. I just need to know how to write "yes", "no" and "marginal", basically, although I don't think it works that way.

[aegis]

change the heightmap using only a series of explosions

[Argh]

1. Then I'd have to deal with the radius, etc., and it's not clean. It'd be one thing, if we had a heightmap operation that acted like an explosion on a per-pixel basis, but it doesn't seem to do that.

2. Explosions can't raise the height, IIRC.

I've found a (crappy) workaround for now, though. It appears that if you defined the max / min height of the map to be low enough under water that it's > than maxWaterDepth in the moveTypes, then raising it above the water creates a truly valid path (i.e., my poor Units don't just sit there A*'ing against walls, but actually find a path). I have no idea whether this also works for ships / subs, but I'm guessing yes.

That's just a crappy workaround, though. What I need is either a way to define, on a moveType basis, that some squares are valid / invalid, or to write a new path, and it needs to be done within a running game state.

[Google_Frog]

Did you try Adjusting the heightmap around the changed area by 0?
AdjustHeightMap(left-16, top-16, right+16, bottom+16 , 0)
The engine doesn't seem to re-path the edges of the changed area which lets units walk partway up the walls. Ajusting an area around the changed area forces the re-path. Once I added that the wall walking bug was fixed although the height of blocks needed tweaking to stop units from walking up the top right and bottom left corners.

[Peet]

then alters the path files accordingly.

Yay for desyncing immediately on the next game!

[Argh]

Yay for desyncing immediately on the next game!

I was kinda assuming that they'd keep the old CRC.

[Peet]

Even if that made any sense it'd still cause desyncs ingame.

[Argh]

Why? Everybody who runs the map would have the same result... we're talking about doing it at the beginning of everything, here. So, yeah, somebody who hasn't played the map with you will desync the very first time, but on the second try they'll all be in sync.

Anyhow, I'll try the AdjustHeightMap, as perhaps that and Level are the right combo to make this work.

[aegis]

crc is based on the file's current contents... change the contents, the hash normally changes.

[Argh]

But again... won't it change the same way, and result in the same CRC for everybody? I was thinking that this would be a one-time pain, basically, since I can include the final path results in an installer.

[Argh]

I take it that nobody knows how the path files work, either?

Seriously, guys. I need to either write a custom pathfinder file, or I need Lua control over the moveType map values... please...