C3X: EXE Mod including Bug Fixes, Stack Bombard, and Much More Release 23

[tjs282]

Basic organization of workers into classes: "peasants" (of widely different sorts), serfs, and slaves (the first recorded mention of which is in Hammurabi's famous "Code.")This would also have extended troughout the entire society into into various sorts of efficiencies/hierarchies: Hammurabi mentions Slaves, "Regular People," and "Superior People," and his Code was written ca. 1,750 BCE. "Agriculture" itself began about 9,000 BCE.

But as I noted above, what happens in Civ3 is already a fairly abstract representation of human history. And as players/ modders, we are limited in how we can represent these abstractions, such as the development of new techs, or the adoption of new governments, by the hardcoded tech-, government-, and building-flags available in the Editor(s).

So the development and application of "early agriculture" is arguably already modelled by Irrigation — but the potential outputs are limited by the intial government being Despotic (hence the "mine green, irrigate brown [+ Food-bonuses on flatland]" rule of thumb for the early game).

One of the highest priorities in the early game is then to learn and adopt a new government which does not penalise tile-yields. Arguably this represents the more complex forms of society you describe above.

(noting that Code of Laws is already required for Republic — and should arguably also be required for Monarchy!)

Watermills were introduced by the Romans, and were used to grind grains into flour.

And this at least may already be moddable to a lesser or greater extent.

If @Flintlock (or @Quintillus?) could decouple the "Increases food from [salt]water tiles" building-flag from the saltwater tiles, and allow it to be applied to all (irrigated?) land-tiles as well — using the same code that currently only applies to Rails? — then a generic "Watermill" building could be added which could increase a town's food-yield, and hence growth rate and/or productivity (weren't watermills also used to power some medieval/early industrial processes?).

Any mod with such a building would probably also need additional constraints to prevent the surfeit of food from becoming completely unbalancing, though:
— To prevent Watermills from being built everywhere, they might also be given the flag(s) "Must be near a river" (would anyway be logical!) and/or "Requires [Wheat] in the town radius"; the latter has the drawback(?) of also requiring [Wheat] to be set as a Strategic/ Luxury resource, which will change its distribution-pattern on a random map
— Citizens might reuire 3 food per turn to prevent starvation, instead of only 2 FPT
— Some/all post-Ancient military units might also need to consume a population-point(s), in addition to their shield-costs

Or the Watermill could work similar to the "Granary", "Maize farm" and "Dairy Farm" SWs in @haluu's Tides of Crimson, autoproducing a unit whose only purpose is to be joined to a town, to increase its population.

In the Middle Ages, three field crop rotation. Crop yields then peaked in the 13th century, and stayed more or less steady until the 18th century.

Improving food-yields in the early medieval might be accomplished by allowing a new building with say, Engineering or Feudalism.

But we do already have the generic Granary, which 'improves' food-yields by halving the amount of food required for growth — so it might just be simpler (even if historically less 'accurate'! ) to move the Granary to a later point in the tech-tree.

Alternatively, add locational-constraints to the "Ancient" Granary, as described above for the hypothetical Watermill — but also allow a "Medieval" Granary to be built which has no such limitations.

I thought that the RR movement limit is set in the .ini file ... ?

In the patch's .ini file, yes. But at the moment the patch only allows to set a single, hardcoded limit.

Are you asking whether the patch could be used to impose multiple potential movement-limits, which were e.g. tech-dependent? That would be really cool, especially if it could also be applied to Roads.

Then you wouldn't need any extra Worker-jobs, because "Build Road" could then cover both a rutted track (increased commerce but no movement-bonus?) to a paved road (movement-factor per the .biq; unlocked with... Construction?) — and "Build Rails" could cover both steam-powered (rail-movement limited per the patch, as at present), and modern diesel/electric locomotives / superhighways (unlimited movement*; unlocked with... Motor Transport? Computers? Ecology?)

*

Spoiler Digression :

I have never had a conceptual problem with unlimited rail-movement in the epic-game. On a global map, with turn-lengths of a year (or more) of in-game time, it makes gameplay 'sense' to me, for my units to be deployable anywhere around my continent within a single turn. Conversely, the horribly 'slow' naval movement-rates, even into the Modern Age, have always been far more immersion-breaking from my PoV.

That said, I can certainly see a good case for Rail-movement to be limited in mods/scenarios with prebuilt small-scale regional/urban maps, and/or turn-lengths on a much shorter scale of e.g. hours to days (e.g. EFZI, SuperCiv).

 

[Flintlock]

Here's what I've been working on this week (and why I was messing around with the renderer). It's a visualization of the AI's city location preferences. Red tiles are the most desirable, white the least, yellow in the middle, and unshaded tiles are unacceptable city locations.



All these maps are generated from player one's perspective, i.e., they show the AI's opinion of city locations assuming it was in the human player's shoes. The reason desirability declines farther from Thebes is that the AI is programmed to find locations less desirable the farther they are from its already existing cities, presumably so that it doesn't beeline its settlers across the map. Also you can see that tiles in the third & fourth rings around Thebes have penalties to desirability presumably to cause the AI to spread its cities out.
The next step is to try to improve the AI's evaluation. Based on what I've seen so far on these maps, I'd say one big problem is that the the AI's city placement is dominated by terrain (it loves grassland) and distance to existing cities, where it should instead be looking for bonus food resources and be more willing to found cities close together. These maps also confirm some things we already knew, like the AI almost completely ignores coastal resources and has no qualms about founding directly on a resource.

 

[Ozymandias]

Is there a single algorithm, or set of algorithms, which you've found, guiding these AI "decisions?"

 

[Flintlock]

Yes, there's one function responsible for evaluating potential city locations for the AI. I've named it ai_eval_city_location and it's at 0x442480 in the GOG executable. I think it's labeled in the decompilation currently on GitHub but I'm not sure.

 

[Ozymandias]

Yes, there's one function responsible for evaluating potential city locations for the AI. I've named it ai_eval_city_location and it's at 0x442480 in the GOG executable. I think it's labeled in the decompilation currently on GitHub but I'm not sure.

I had worked out some simple, mathematical algorithms for this for, "The Project." (E.g., "Plains" = Value "0"; "Grasslands" = Value "1" - but IF "Adjacent to River" = Value "2;" etc.) Let me know if such could be helpful.

 

[Flintlock]

Sure, I'd like to have a look at that. Rewriting ai_eval_city_location would be totally doable, for reference the original function is about 500 lines and half of it is not even relevant to the AI (it's for the tutorial as far as I can tell). If you had those rules written out in C they could be dropped into the game easily, though of course they'd have to be written in a way that they could interface with the rest of the code. Antal and I have already decoded all the important stuff like how to determine a tile's terrain type, whether it has fresh water, what resources are on it, etc.

 

[Ruin]

I'd love a way to make paratroopers able to move/attack after jumping. Apologies if this is already accomplishable through the editor.

 

[Ozymandias]

Sure, I'd like to have a look at that. Rewriting ai_eval_city_location would be totally doable, for reference the original function is about 500 lines and half of it is not even relevant to the AI (it's for the tutorial as far as I can tell). If you had those rules written out in C they could be dropped into the game easily, though of course they'd have to be written in a way that they could interface with the rest of the code. Antal and I have already decoded all the important stuff like how to determine a tile's terrain type, whether it has fresh water, what resources are on it, etc.

I'm decades gone from hands-on programming I'll email you some (very) pseudocode later this week.

 

[Flintlock]

I'd love a way to make paratroopers able to move/attack after jumping. Apologies if this is already accomplishable through the editor.

Added to the list, I can't imagine this would be very difficult. Have you already tried giving paratroopers multiple moves in the editor?

I'm decades gone from hands-on programming I'll email you some (very) pseudocode later this week.

I'll keep an eye out for it. Do you have my email address? The one I used for CFC I haven't checked in 15 years and have lost the password for, but you can reach me on the email I've been using for Git. I don't think it appears on GitHub but does on my commits, I'm not sure how that works, in any case I'll PM it to you.

 

[Puppeteer]

I've found the area of the code that randomly chooses a civ for the AI when culturally linked starts is set but I don't know yet exactly how it works. So far I don't see any loops over culture groups, only over players and civs. Also I don't see anywhere that it accounts for the distance between starting locations, only what continent they're on. Does that sound right? Does anyone know exactly how the culturally linked starts option is supposed to work?

Short answer "no, I don't know", but each civ definitely has a culture ID, so it should just have to match the starting player civ's culture ID for the other civs on the same continent. And that makes me realize I have no idea if other continents are also culturally linked.

So I could easily imagine looping over players, randomly picking a civ, and then ensuring only civs with matching culture IDs are on the same continent. I guess everyone knows the problem is that you always get the American culture group when the option is picked. (For single player games; I have no idea what it does on multiplayer games.)

And yeah, for some reason the save file has continent IDs for each tile, and a continent list with some stats for each. I always assumed it was tracked for trade route purposes, but it probably makes more sense if it is used for culturally linking. (I'm pretty sure there are trade route IDs for each tile, but I don't understand much of that yet.)

 

[Civinator]

I've found the area of the code that randomly chooses a civ for the AI when culturally linked starts is set but I don't know yet exactly how it works. So far I don't see any loops over culture groups, only over players and civs. Also I don't see anywhere that it accounts for the distance between starting locations, only what continent they're on. Does that sound right? Does anyone know exactly how the culturally linked starts option is supposed to work?

This is the description in the Civ3ConquestsEdit:

Culture Group (Civilization Properties)
Selects the culture group of the civilization (American, European, Mediterranean, Middle Eastern, or Asian). This value determines how cities will look on the map, how citizens in a city look, as well as how certain buildings will look in the city aerial view. It is also important to note that civilizations of like culture groups start near each other.

Addition from me: It determines the look of buildings in the city screen, too.

So I think, there must be a "common loop" influencing the graphics of cities, graphics of citizens, graphics of buildings in the city view (Civ 3 Vanilla) and of buildings in the city screen (culture setting of buildings in the pediaicons text file). The common loop is connected to the culture groups. The Civ3ConquestsEdit is speaking of a "value", so may be it is a number from 1-5 for each one of the five culture groups.

------------------------------------------------------------------

For the distance between starting locations of civs on random maps there must be a value, too, as in the registry for world sizes in the editor, such a value can be set:

If the value for the distance between civs on random maps is set too high for the choosen world size, an "overcrowded" start can happen, setting the starting settlers next to each other without the distance values.

 

[Sutsuj]

With regards to AI city placement, I think that ideally the code would not factor in the type of the terrain in any hardcoded sort of way (e.g. "if grassland then ...") but rather would consider terrain stats like base food, food with irrigation, base shields, shields with mine, resource stats, etc.. That way, when playing a custom scenario that modifies terrain or worker improvement values, the AI will adapt accordingly.

However, a human analysis of the values of things like grassland vs. plains in the regular game may be helpful in determining the values of the underlying stats like the value of 1 vs. 2 food.

 

[timerover51]

I do not know if this has been brought up, but increasing or eliminating the 32 combined strategic and luzury resource limit would be the fix that i would like to see.

 

[Flintlock]

@Puppeteer @Civinator
Since you guys mentioned it I had another look at the culturally linked starts bug. First I did a quick test to confirm that starts are linked by continent not distance. The test was to start a bunch of games on tiny pangaea & archipelago maps with random civs and linked starts, on pangaea the bug appeared almost every time but on archipelago it was unnoticeable. This squares with that I'm seeing in the code, which is good since it means I'm looking at the right thing. Also it means that description from the editor is misleading, it should mention that cultures are grouped by landmass not that they are "near" each other which implies distance.

I still don't see where the bug is coming from. Unfortunately the code to roll random civs for the AI is a mess since it's part of a big function with a lot of variables and the decompiler was not able to completely de-sphagettify it. As far as I can see, the algorithm is pretty straight forward. It just loops over every AI player that needs a random civ then loops over the list of civs starting from a random element, checking if any of them match the culture group of any other player starting on the same continent. If a match is found the player in need gets the matching civ and otherwise it gets a civ chosen at random. I don't see where the critical problem comes from, that is, why it should favor the American culture group.

I do not know if this has been brought up, but increasing or eliminating the 32 combined strategic and luzury resource limit would be the fix that i would like to see.

It has been mentioned and I've looked into it a bit. The bug is a consequence of the fact that cities that aren't connected to the main trade network have their available resources recorded in their own 32-bit field. Resources correspond to bits based on their index and indices over 32 wrap around so that resources #1 and #33 share bit #1, #2 and #34 share bit #2, etc. I don't know yet if it would be practical to fix the bug. Doing so would require would require modifying the code to store the resource availability bits somewhere else with more space and whether or not that's practical depends on how many places in the code access the 32-bit field and how they do it.

 

[timerover51]

@Puppeteer @Civinator

It has been mentioned and I've looked into it a bit. The bug is a consequence of the fact that cities that aren't connected to the main trade network have their available resources recorded in their own 32-bit field. Resources correspond to bits based on their index and indices over 32 wrap around so that resources #1 and #33 share bit #1, #2 and #34 share bit #2, etc. I don't know yet if it would be practical to fix the bug. Doing so would require would require modifying the code to store the resource availability bits somewhere else with more space and whether or not that's practical depends on how many places in the code access the 32-bit field and how they do it.

I was afraid that it would be sometning like that, otherwise it would have been fixed already. Thanks for the quick reply.

 

[Civinator]

@Puppeteer @Civinator
Since you guys mentioned it I had another look at the culturally linked starts bug. First I did a quick test to confirm that starts are linked by continent not distance. The test was to start a bunch of games on tiny pangaea & archipelago maps with random civs and linked starts, on pangaea the bug appeared almost every time but on archipelago it was unnoticeable. This squares with that I'm seeing in the code, which is good since it means I'm looking at the right thing. Also it means that description from the editor is misleading, it should mention that cultures are grouped by landmass not that they are "near" each other which implies distance.

In Civ2 and Civ 2 ToT every landmass, even small islands had their own numbers, influencing a lot of functions, even if a city at the coast of such a landmass can build a harbour, when some tiles of that landmass were transformed by events from land to water terrain.

 

[Civinator]

Flintlock, what is meant by the term AI routine for "pop units" in the readme file and the default.c3x_config file of your mod ? Units that need population points, units that pop up like MGLs or what else ?? Edit: Or flag units like the supply shipments ?

 

[Flintlock]

In that case "pop" refers to city population. Pop units are units whose only purpose is to be joined into a city. To be considered a pop unit, a unit must have the terraform AI but no abilities other than join city, so it only applies to certain modded units. I added that feature at haluu's request because those kind of units appear in Tides of Crimson (wheat stalks, chickens, etc. spawned by buildings).

 

[Civinator]

In that case "pop" refers to city population. Pop units are units whose only purpose is to be joined into a city. To be considered a pop unit, a unit must have the terraform AI but no abilities other than join city, so it only applies to certain modded units. I added that feature at haluu's request because those kind of units appear in Tides of Crimson (wheat stalks, chickens, etc. spawned by buildings).

Flintlock, thank you very much for the explanation. This is needed for the German translation of your mod. As you mentioned somewhere in this thread, that there are no new mods for C3C: The new German version of Civ 3 Complete, that will come with the German translation of your mod this week, will have 245 additional units and tons of new leaderhead graphics for the translated conquests (most of the units also integrated in the epic game) and several different sets of terrain. So here your mod triggered a new modding initiative for C3C. Of course your mod has also a massive influence for the next versions of the existing mods and scenarios CCM, RARR and SOE. Especially the land-/sea intersections have a lot of potential for the future.

 

[Flintlock]

The new German version of Civ 3 Complete, that will come with the German translation of your mod this week, will have 245 additional units and tons of new leaderhead graphics for the translated conquests (most of the units also integrated in the epic game) and several different sets of terrain. So here your mod triggered a new modding initiative for C3C.

Nice. Make sure to send me a link once the German translation is done so I can put it in the C3X readme. By the way I'm planning to post C3X R9 this week some time, the big changes are AI stuff (the city location view like I showed earlier and a full implementation of perfuming) plus a few small things.