Animations

[instafluff0]

PR three of three for R28. This PR is less dramatic in terms of changes than it seems, as most of the 7.8k line additions are INI, config, and Python files for processing animations outside of the game. About 2.5k lines are in injected_code.c (and much of that is config parsing).

The general approach is to piggyback on Civ3’s existing tile-effect machinery instead of creating a new animation workflow from scratch. When a tile matches a configured ambient animation rule, we use Tile_spawn_animated_effect to spawn a normal built-in tile effect (AE_Disorder) as a carrier. So we use a vanilla animated effect path that already knows how to allocate, position, update, and draw an effect. While AE_Disorder is being loaded, I set a temporary override so Units_Image_Data_load_animated_effect ignores the AE_Disorder’s normal art and instead loads the configured custom Art\Animations...*.INI. After vanilla finishes constructing the effect, we rewrite the effect id back to the custom id and apply per-animation direction and pixel offsets. So just as with smolder & disorder, the native animation system still owns lifetime, frame advancement, AMB/FLC handling, and rendering; we just swap in an INI and decide which tiles should spawn or clear those effects.

Here are the main features:

1. Allows custom FLC tile animations to be configured for terrain, resources, PCX sprite indices, and coastal waves, using:

enable_custom_animations = true

---

2. Adds a new tile animation config file with #Animation entries, for example:

#Animation
name = Fish
ini_path = Resources\Fish\Fish.INI
type = resource
resource_type = Fish

---

3. Allows animations to be filtered by day/night hour and season:

show_in_day_night_hours = 7-17
show_in_seasons = winter

---

4. Supports animation placement controls, including direction, x/y offsets, and playback speed:

direction = southeast
x_offset = -15
y_offset = -20
frame_time_seconds = 0.13

---

5. Adds animation support for natural wonders through their config entries:

animation = ini=NaturalWonders\AngelFalls.INI; hours=7-17; seasons=spring,summer,fall,winter; offsets=0,-10

Note that natural wonders can have multiple animation entries.

---

6. Adds tie-breaking logic (pick_tile_animation_winner_for_tile and get_tile_animation_type_priority) for tiles with multiple matching candidate animations, using this priority order:

Resource > Natural Wonder > PCX > Terrain > Coastal Wave

If still tied, animations with day/night or season filters take precedence, then the later config entry wins.

[maxpetul]

There are some addresses for you. Would you say this PR is ready for review? I started looking into it a few weeks ago but got distracted with other things (many such cases) and since then more commits have trickled in.

[instafluff0]

No problem at all. I was going to wait to resolve the merge conflicts until after the day-night/seasonal cycle no-cache branch was merged in. Are you ok with merging that first? Else I can go ahead and fix the merge conflicts first, either way is fine.

[maxpetul]

I'd assumed the no-cache branch was supposed to come after this one, but there's no reason I couldn't merge it first. I'll do that and maybe merge some other things too in the near future.

[instafluff0]

Ok, just to follow up on our earlier conversation, this branch should be good to review now. I've merged in changes from master and cleaned up line endings, etc. I've also tested extensively on multiple games as well.

One thing I'm not sure about is the type = pcx animations, which is really just pairing an animation to a given indexed sprite chunk from a terrain PCX, like "index 5 from snow mountains". The code for all of that is really fairly unique and works a bit differently from other animations. The main use case I was thinking about that was animating rivers - which works - but in practice I'm not sure anyone will ever really use it, and it's a good amount of code. So we can consider dropping that if you want.

Also, I put "r28" and "r29" in these branch names to help me track them, and don't mean to presume they should necessarily be in any version. I know there have been a ton of other great changes lately so if you want to put these on a different schedule and release the current code sooner, etc. that's totally fine.