Doing that still spams you with warnings (disaster occurring), just not cautions (disaster watch, 10 marks prior) or alerts (disaster imminent, 5 marks prior).
Good point Arklon. Perhaps some more thinking is required.
Side note, the TethysGame::SetLavaSpeed is sorta useless ain't it? (Yes it is, that 300 in TethysGame::SetEruption is the lava speed, 50 is slow, 500 is, well, lava probably shouldn't move that fast...)
I think so, yes. That's why I omitted it.
NEXT=> A lot of this could be used for a controlled meteor shower right? All of the meteor impact points would go in:
That "MeteorShowerA/B/C" looks an awful lot like an array.
As for the meteor shower offsets, it's similar to how it's done with the volcano. From what I remember, SouthFlowAni sets two tiles to animate. You specify one coordinate, and the other coordinate is offset from there. The meteor shower cloud could have relative coordinates from a center point. You specify a center point to the function, and the function will spawn meteors about that center point. The offsets could be controlled by using set layouts, passed in an array, or they can be randomly generated. The layout idea is neat, but beware the player will quickly recognize those layouts if you don't have a lot of them. That might not be desirable. It does allow for control over the damage pattern though, and can prevent two or three meteors from overlapping, and possibly causing too much localized damage.
void CreateMeteorShower(POINT ¢er, int numMeteors, POINT offsetList[])
{
for (int i = 0; i < numMeteors; ++i) {
POINT pt = center + offsetList[i];
int meteorSize = 2; // Better not to hardcode this
TethysGame::SetMeteor(pt.x + 31, pt.y - 1, meteorSize);
}
}
A modification to the above, is rather than pass "POINT offsetList", is to define a new data structure that contains both the offset, and the size of the meteor. That way it's not always hardcoded to 2. Such a struct might look like this:
struct MeteorInfo {
POINT pt;
int size;
};
You can then use array[index].pt, and array[index].size to control the offset and size of the meteor.
A further extension might include varying time delays, so the meteors don't all crash down at exactly the same time. I think that would actually be rather important to give the meteor shower some flavour. I'll leave you to think about it first. It will likely involve using scriptGlobal to control placement over multiple game ticks.
You can do away with the layout array by just using random numbers to generate the offsets. A parameter might be the size of the area around the center where meteors can hit. You can also play around with random number distributions to get meteors more likely near the center, and only rarely near the edges, and shape the area so it's more circular, or oval, or linear, rather than a box. There are also ways of controlling layout to prevent crowding, but you'd likely need to generate and store coordinates in an array and then spawn the meteors after all of them have been assigned a place. If you're also doing time delays, then the array will need to be stored between ticks, again using scriptGlobal.
