Static blobs

The simplest way I can think of doing it is to iteratively delete old blobs and create new blobs based on distance from your piston with the properties of the old blob. This way blobs that interact with a data structure like mechanisms can be instantiated correctly.

 

Skinney's gone over the sad truth of moving static blobs around - just be sure to write in the correct health values and any relevant tags (probably the "on fire" stuff is most relevant).

setTileValue_Legacy() - this is a dirty hack by MM ;)

It's basically a helper function to call CMap::SetTileFlags_Legacy at the blob's overlapped position, which basically sets the "expected" engine-side flags for the tile, and then grabs overlapping static blobs and takes note of their ID.

The reason for the flags getting set is simple: they determine the tile's behaviour, if you didn't set them the tile wouldn't do anything. This is the same as how you have to manage tile flags for custom tiles. (There is a bit more going on, but I'm trying to avoid this being more confusing than it needs to be.)

The reasons for the blob ID being needed are.. more complicated. Basically a lot of other code checks this to handle "blob tiles" for things like lighting, water passing etc - and that's why those behaviours are a little buggy.

The idea when this system was designed was to allow "blob tiles" to slot neatly into the old tile-based systems, but there are problems that were never totally addressed, like how larger-than-one-tile blobs are handled, how multiple blobs in one tile is handled (think ladder overlapping door), how strangely-shaped tile blobs are handled (ramps, half-tiles, circles) and so on.

The main thing to understand is that "without it, some stuff doesn't work properly, but it doesn't work properly anyway in some cases".

(...this could probably be formalised as "the governing law of everything in kag" or similar)