Maptile.expand --- Used By Lava?

[Flashy]

The HFL says

Code: [Select]

unsigned int expand  	:1;  // true if lava / microbe is expanding to this tile

But i wasn't able to find a tile that was set to true during an eruption+lava flow, though I was able to find at least one during a blight infection. Is it really used by lava?

[Hooman]

It's been so long I'm not sure anymore. I know there is some sharing of code between blight expansion and lava expansion. I remember finding that a bit odd before I realized there was shared code. It's possible they both use the same bit, due to the shared code, or memory efficiency reasons. It's also possible that I may have gotten confused by trying to debug while using a map with both blight and lava expanding at the same time. Perhaps a breakpoint fired for the wrong reason, an I traced into code thinking it had to do with lava, but it was actually blight that caused the breakpoint.

Of course it could also be a timing issue. Maybe you're just not reading the value at the right time? Are you using breakpoints or continually scanning memory? If you used breakpoints, then maybe the address was wrong? (Map indexing is pretty screwed up). If you're scanning, maybe you just missed it? It could be that lava expands faster, in that the bit is both set and cleared between two ticks.

I suppose if you're curious I can take another look at the code, but I'm not going to do it right at this moment.
 

[Flashy]

It's been so long I'm not sure anymore. I know there is some sharing of code between blight expansion and lava expansion

From what I remember, you said that both things use the same code to calculate the next tile to grow

It could be that lava expands faster, in that the bit is both set and cleared between two ticks.

That would be even better, since dealing with blight expansion and lava expansion at the same time can lead to serious mistakes.

I'm just using some code to manipulate lava, it was supposed to message me when it encounters an expand-tile, but nothing happened until the blight spawned. If its really used between two ticks, so much the better, so I don't have to worry about it.

I experimented with expand, and setting an area of blight to expand = 0 resulted in passable tiles that couldn't be reclaimed by the blight.

[Arklon]

I honestly don't think lava uses the expand bit at all, based on my observations from messing around with the Blight for CCF2. I didn't actually look at the lava function disassembly all that much, though, so I could be wrong, but it really didn't look like it was the case, for a multitude of reasons. As for why they really thought it necessary to use two different flags for the Blight, I have no idea... just as it is with all sorts of other things in OP2.

[Hooman]

I just took a quick look at the code, and I think I know what happened.

There appears to be some sort of class hierarchy, where both Blight and Lava derive from the same parent class. The parent class makes a virtual function call to a SpreadTo method, which is different for each of the derived classes. Years ago, I was tracing the parent function, and probably followed it into some blight related code at the virtual function call and didn't notice it may only apply to one of the derived classes. I likely documented the behavior as applying to both derived classes, and the info has been wrong ever since then. This means the comment is probably in error.

From what I'm seeing of the Lava.SpreadTo function, it seems to only check if Lava is present around surrounding tiles. The more complicated Blight.SpreadTo function uses both the expand and the blight present bits. It seems blight can only spread to a tile that's been previously marked with the expand bit. The expand bit seems to be set around tiles that are newly infected, although this isn't done until it's another two function call in. There is also a check to see if lava has already expanded to the tile, and will prevent blight expansion. From what I can tell, the expand bit appears like it was intended as a speed optimization, in that most of the spreading checks can be avoided for tiles that aren't around the frontier of the blight. I'm not certain of that though.
 

[Arklon]

I just took a quick look at the code, and I think I know what happened.

There appears to be some sort of class hierarchy, where both Blight and Lava derive from the same parent class. The parent class makes a virtual function call to a SpreadTo method, which is different for each of the derived classes. Years ago, I was tracing the parent function, and probably followed it into some blight related code at the virtual function call and didn't notice it may only apply to one of the derived classes. I likely documented the behavior as applying to both derived classes, and the info has been wrong ever since then. This means the comment is probably in error.

From what I'm seeing of the Lava.SpreadTo function, it seems to only check if Lava is present around surrounding tiles. The more complicated Blight.SpreadTo function uses both the expand and the blight present bits. It seems blight can only spread to a tile that's been previously marked with the expand bit. The expand bit seems to be set around tiles that are newly infected, although this isn't done until it's another two function call in. There is also a check to see if lava has already expanded to the tile, and will prevent blight expansion. From what I can tell, the expand bit appears like it was intended as a speed optimization, in that most of the spreading checks can be avoided for tiles that aren't around the frontier of the blight. I'm not certain of that though.

I know the expand bit also seems to be used as a speed optimization in a part of the drawing code. It'll only do the calculations for drawing the Blight overlay on a tile if the expand bit is set, but the actual calculations use the microbe bit.

[Hooman]

Ahh, that optimization makes a bit more sense now. Particularly since the blight seems to behave in a 2x2 offset grid manner. To determine the overlay for a given tile, the entire 2x2 grid must be examined. Having a single bit tell you if just the one tile's data, or the data of all 4 tiles is needed would be helpful there.