Working on walls logic

Major refactoring of the wall building system completed over several days, culminating in restored wall rendering and connection logic. The changes involved moving scattered wall code into a unified class structure and fixing image ID resolution.

Architecture Refactoring

The first step (March 16) moved all wall building logic from the global src/grid/tiles.cpp into the building_mud_wall class. This migration consolidated over 300 lines of scattered wall-handling code into a single, maintainable location:

• update_all_walls() — iterates over the entire map and updates wall tiles
• update_area_walls() — updates walls in a specific region after construction or demolition
• get_gatehouse_position() — determines wall orientation relative to adjacent gatehouses
• set_wall_gatehouse_image_manually() — handles edge cases where automatic detection fails
• set_image() — core function that assigns the correct sprite to each wall tile based on neighbors

This refactoring touched 19 files and removed 363 lines of duplicated logic while adding 393 lines of clean, class-based code. The wall system now follows the same architectural pattern as other building types in the engine.

Image ID Resolution Fix

The critical fix (March 19) addressed how wall sprites are loaded. Previously, the code used a hardcoded GROUP_BUILDING_WALL constant that pointed to the wrong texture pack. The fix changed three key functions to use current_params().anim[animkeys().base].first_img() instead — pulling the correct base image ID from the building's configuration data:

// Before (broken):
map_image_set(grid_offset, image_id_from_group(GROUP_BUILDING_WALL) + image_offset);

// After (working):
const int id = current_params().anim[animkeys().base].first_img();
map_image_set(grid_offset, id + image_offset);

This change ensures walls load their sprites from the correct .sg3 texture archive defined in the building's JavaScript configuration, rather than a hardcoded fallback. The obsolete GROUP_BUILDING_WALL macro was commented out to prevent future confusion.

Gatehouse Integration

The final piece simplified map_image_context_get_wall_gatehouse() to properly handle wall segments adjacent to tower gatehouses. Walls now correctly detect when they connect to a gatehouse entrance and adjust their sprite orientation accordingly — visible in the animation as walls seamlessly connect to gate structures.

Technical Details

The wall rendering system uses a context-based approach where each tile examines its eight neighbors to determine the correct sprite variant. The terrain_image structure returned by map_image_context_get_wall() contains:

• group_offset — which wall orientation set to use (straight, corner, T-junction, etc.)
• item_offset — specific rotation within that set
• is_valid — whether the context produced a valid result

When a wall tile is adjacent to a gatehouse, the system falls back to set_wall_gatehouse_image_manually(), which uses directional logic to determine the correct sprite based on the gatehouse's orientation (top-right, top-left, bottom-left, or bottom-right).

Result

Walls now render correctly with proper connections between segments and gatehouses. The refactoring also makes future wall-related features (like stone walls or damaged wall states) much easier to implement, since all logic is centralized in the building_mud_wall class rather than scattered across the codebase.