R28 tile improvements by instafluff0 · Pull Request #34 · maxpetul/C3X

instafluff0 · 2026-05-08T15:23:57Z

This is my PR one of three for R28. Those are:

r28-tile-improvements (this)
r28-seasonal-cycle
r28-animations

I'd suggest merging them in that order, as (3) was branched from (2) and depends on the seasonal-cycle code.

This PR

Allows for districts as genuine custom tile improvements used by only one city at a time, using the config:

type                   = tile-improvement
ai_build_strategy      = tile-improvement

Allows workers to be consumed and despawned after completing a district, like colonies.
```
consumes_worker = 1
```
Allows the default resource on a tile to be suppressed if a district is built over it
```
subsumes_tile_resource = 1
```

…trict built

… if a tile-improvement

… missing purple outline for shields

# Conflicts: # C3X.h # default.districts_config.txt # injected_code.c

maxpetul · 2026-06-02T16:25:11Z

+			}
+			if (worker_to_consume != NULL) {
+				if ((p_main_screen_form != NULL) && 
+					patch_Leader_is_tile_visible (&leaders[p_main_screen_form->Player_CivID], __, worker_to_consume->Body.X, worker_to_consume->Body.Y)) {


Surely the worker should get despawned even when no one's looking?

Ah, sorry this was a dumb half-baked leftover from my experiments to show worker animations when they despawn, rather than simply disappearing. Because the camera was always on the tile when I finalized the code I hadn't realized I'd even left it.

Thanks for catching that - removed now.

maxpetul · 2026-06-02T16:33:50Z

-	} else if (slice_matches_str (key, "impassable") || slice_matches_str (key, "impassible")) {
-		struct string_slice val_slice = *value;
-		int ival;
+		} else


Notice how the lines around this insertion are considered to have been changed even though their contents is the same? That indicates the line endings have been changed. Please make sure that all lines in injected_code.c have dos-style endings. This seems to be a recurring issue with Codex and maybe other AI code editors that the edits they make have unix-style endings regardless of what's standard in the file they're editing. I had this problem before so I had Codex write fix_line_endings.py, which ensures that all lines in all files of the project have the expected ending style. That may be useful for you.

~~I know what you mean, but I'm not sure this is a case of that. I just ran it and I don't see anything with line endings off in injected_code.c. Am I misunderstanding the script?~~

Edit: scratch that, I think I had my local branch in a funny state due to a misbegotten git reset, trying again...

Edit 2: Ok, should be good now. I'll run this for the other branches as well.

maxpetul · 2026-06-02T16:49:22Z

 		}
 	}

+	if (is->current_config.enable_districts) {


What is the purpose of this block of code? For food and shields it's redundant because the base City::calc_tile_yield_at returns the values from Map::calc_food_yield_at and Map::calc_shield_yield_at, and those Map functions are already patched to handle improvement districts and generated resources. This block is necessary to calculate commerce yield correctly, but why place that here instead of in a patch for Map::calc_commerce_yield_at?

Right. Short answer: I got a crash every time I tried to patch Map::calc_commerce_yield_at.

If I remove this block and add:

inlead, 0x5d7AD0, 0x0, 0x0, "Map_calc_commerce_yield_at", "int (__fastcall *) (Map * this, int edx, int tile_x, int tile_y)"

int __fastcall patch_Map_calc_commerce_yield_at (Map * this, int edx, int tile_x, int tile_y) { if (! is->current_config.enable_districts) return Map_calc_commerce_yield_at (this, __, tile_x, tile_y); Tile * tile = tile_at (tile_x, tile_y); if ((tile != NULL) && (tile != p_null_tile)) { struct district_instance * inst = get_district_instance (tile); if (inst != NULL && district_is_complete (tile, inst->district_id)) { if (! district_uses_tile_improvement_rules (inst->district_id)) return 0; City * yield_city = get_city_ptr (tile->Body.CityAreaID); if (! district_tile_bonus_applies_to_city (tile, inst->district_id, yield_city)) return 0; struct district_config * cfg = &is->district_configs[inst->district_id]; int commerce_bonus = 0; get_effective_district_yields (inst, cfg, NULL, NULL, &commerce_bonus, NULL, NULL, NULL); if ((cfg->generated_resource_id >= 0) && (cfg->generated_resource_flags & MF_YIELDS) && district_generates_resource_for_civ (tile, inst, cfg, yield_city->Body.CivID)) { Resource_Type * res = &p_bic_data->ResourceTypes[cfg->generated_resource_id]; commerce_bonus += res->Commerce; } return commerce_bonus; } } return Map_calc_commerce_yield_at (this, __, tile_x, tile_y); }

I get a crash upon founding a city or trying to open the city screen. I could not figure out why and probably should have tried to determine if the arguments we had for that function in Ghidra were correct, but did not, so this seemed a reasonable workaround. But I hear you and agree it is duplicative. I think my development of this branch also pre-dated our earlier discussion of how to figure this stuff out using Ghidra.

Let me take another stab at it.

Update: I believe I've got things running now and corrected. Ghidra had RET 0x18 for Map::calc_commerce_yield_at, so 6 args, which I'm fairly certain were exactly the same as Map::calc_food_yield_at.

I updated civ_prog_objects accordingly, removed the block in patch_City_calc_tile_yield_while_gathering, and added patch_Map_calc_commerce_yield_at.

…nsumption animations, erroneously left over

instafluff0

Please see comments below.

instafluff0 · 2026-06-02T22:54:47Z

-	} else if (slice_matches_str (key, "impassable") || slice_matches_str (key, "impassible")) {
-		struct string_slice val_slice = *value;
-		int ival;
+		} else


~~I know what you mean, but I'm not sure this is a case of that. I just ran it and I don't see anything with line endings off in injected_code.c. Am I misunderstanding the script?~~

Edit: scratch that, I think I had my local branch in a funny state due to a misbegotten git reset, trying again...

Edit 2: Ok, should be good now. I'll run this for the other branches as well.

instafluff0 · 2026-06-02T23:05:56Z

+			}
+			if (worker_to_consume != NULL) {
+				if ((p_main_screen_form != NULL) && 
+					patch_Leader_is_tile_visible (&leaders[p_main_screen_form->Player_CivID], __, worker_to_consume->Body.X, worker_to_consume->Body.Y)) {


Ah, sorry this was a dumb half-baked leftover from my experiments to show worker animations when they despawn, rather than simply disappearing. Because the camera was always on the tile when I finalized the code I hadn't realized I'd even left it.

Thanks for catching that - removed now.

…ock from patch_City_calc_tile_yield_while_gathering

instafluff0

Please see comments inline regarding Map::calc_commerce_yield_at.

instafluff0 · 2026-06-02T23:21:00Z

 		}
 	}

+	if (is->current_config.enable_districts) {


Right. Short answer: I got a crash every time I tried to patch Map::calc_commerce_yield_at.

If I remove this block and add:

inlead, 0x5d7AD0, 0x0, 0x0, "Map_calc_commerce_yield_at", "int (__fastcall *) (Map * this, int edx, int tile_x, int tile_y)"

int __fastcall patch_Map_calc_commerce_yield_at (Map * this, int edx, int tile_x, int tile_y) { if (! is->current_config.enable_districts) return Map_calc_commerce_yield_at (this, __, tile_x, tile_y); Tile * tile = tile_at (tile_x, tile_y); if ((tile != NULL) && (tile != p_null_tile)) { struct district_instance * inst = get_district_instance (tile); if (inst != NULL && district_is_complete (tile, inst->district_id)) { if (! district_uses_tile_improvement_rules (inst->district_id)) return 0; City * yield_city = get_city_ptr (tile->Body.CityAreaID); if (! district_tile_bonus_applies_to_city (tile, inst->district_id, yield_city)) return 0; struct district_config * cfg = &is->district_configs[inst->district_id]; int commerce_bonus = 0; get_effective_district_yields (inst, cfg, NULL, NULL, &commerce_bonus, NULL, NULL, NULL); if ((cfg->generated_resource_id >= 0) && (cfg->generated_resource_flags & MF_YIELDS) && district_generates_resource_for_civ (tile, inst, cfg, yield_city->Body.CivID)) { Resource_Type * res = &p_bic_data->ResourceTypes[cfg->generated_resource_id]; commerce_bonus += res->Commerce; } return commerce_bonus; } } return Map_calc_commerce_yield_at (this, __, tile_x, tile_y); }

I get a crash upon founding a city or trying to open the city screen. I could not figure out why and probably should have tried to determine if the arguments we had for that function in Ghidra were correct, but did not, so this seemed a reasonable workaround. But I hear you and agree it is duplicative. I think my development of this branch also pre-dated our earlier discussion of how to figure this stuff out using Ghidra.

Let me take another stab at it.

instafluff0 · 2026-06-03T18:40:59Z

 		}
 	}

+	if (is->current_config.enable_districts) {


Update: I believe I've got things running now and corrected. Ghidra had RET 0x18 for Map::calc_commerce_yield_at, so 6 args, which I'm fairly certain were exactly the same as Map::calc_food_yield_at.

I updated civ_prog_objects accordingly, removed the block in patch_City_calc_tile_yield_while_gathering, and added patch_Map_calc_commerce_yield_at.

maxpetul · 2026-06-04T17:12:06Z

Great, that all looks good now. There's one little cosmetic thing I just noticed: the commerce gathered from improvement-type districts is not outlined in purple in the "COMMERCE" area of the lower frame of the city screen. That's unlike shields from improv-type districts and commerce from normal-type ones, which are both outlined in purple.

And that reminds me of another cosmetic thing I didn't mention before: when you hover over an improv-type district that's being worked on the city screen, the game doesn't highlight the tile yields like it normally does. I figured you were aware of that and decided it wasn't worth bothering with, but I'm pointing it out just in case. I'm not insisting you change it, if you really think it's not worth the effort, I'm fine merging this PR as is.

instafluff0 added 11 commits May 7, 2026 08:58

Begin implementation of tile improvement alternative for districts

6f06ed8

Districts as tile improvements appears to be fully working

4bebf34

Add feature for consuming worker

53de0b1

Add subsumes_tile_resource feature to suppress native resource if dis…

d7ef045

…trict built

Fix tile improvement replay on R28

4e488e0

Merge branch 'maxpetul:master' into r28-tile-improvements

5855c67

Update default.districts_config.txt documentation

ce3090c

Fix resource subsumption/suppression, update docs

3d3bb1c

Fix issue with food and shield calculations not being added correctly…

7b37447

… if a tile-improvement

Fix issue with tile-improvement districts not removing correctly; Fix…

a1e9d97

… missing purple outline for shields

Merge branch 'master' into r28-tile-improvements

c91ad4a

# Conflicts: # C3X.h # default.districts_config.txt # injected_code.c

maxpetul requested changes Jun 2, 2026

View reviewed changes

instafluff0 added 2 commits June 2, 2026 16:01

Fix line endings

e60104c

Remove unneeded lines previously left from experiments with worker co…

0693ac8

…nsumption animations, erroneously left over

instafluff0 commented Jun 2, 2026

View reviewed changes

instafluff0 added 3 commits June 3, 2026 08:03

Attempt to switch to Map_calc_commerce_yield_at

6a586e7

More normalized line endings

bc59889

Fix Map_calc_commerce_yield at to add proper args, remove previous bl…

2faf807

…ock from patch_City_calc_tile_yield_while_gathering

instafluff0 commented Jun 3, 2026

View reviewed changes

Conversation

instafluff0 commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

instafluff0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

instafluff0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maxpetul commented Jun 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

instafluff0 commented May 8, 2026 •

edited

Loading