How Supply and Demand Lists Are Determined

[solo]

Civ turn order may reflected in another way in my hot seat game, since the Babs, #2 in sequence discovered trade, which they shared with all others. After that all cities in existence long enough to have gone through a cycle were compared. All demanded dye, except for the Roman cities Rome and Veii. Rome is the only civ preceding the Babs in turn order. On the their next cycle turn, Rome and Veii converted to dye demand, as did all of the newest cities.

After loading a few MGE singleplayer saves and delivering caravans to AI cities, those not already having dye or copper in slot #1 of demand lists were "converted".

Another thing I tried was loading a 2.42 save into MGE. At first, all AI I could see had dye, but as the turns went by, you could see the cycle purging these cities of dye. Caravan deliveries re-instated dye demand. However, a food delivery did not.

[solo]

Since "Find City" lists in MGE are alphabetical, I use the the Trade Advisor demand lists to piece together this information, since these lists are in chronological order. I start with the dye or copper lists because they contain so many cities.

My MGE hotseat game consists of just human players, so AI city lists can not be observed in that one, unless I purposely lose a city to barbs. I haven't checked into what is happening in MGE with AI civs yet.

When you say the changes stick, how long does this last? Even past the next AI turn?

[samson]

Another confirmation of the Trigger Hypothesis.

(2.4.2)

The AI never "views" its own cites and so it accumulates Dye-demanders. However, if you send a diplo to investigate an AI city on a cycle-year, it shows you the 'corrected' S/D lists with Dye purged. The changed demand list will pay caravan bonuses on different commodities than it would before the city was investigated. These newly demanded commodities are predictable from the formulas.

Now, if your civ's turn (Romans) comes before the AI (French) then on the AI's turn the city will convert back to being a Dye-demander. But if your civ (Americans) comes after the AI, then the changes caused by the investigation of the city will stick. Cute, huh?

[solo]

Yup, that's the way ties are working in all my tests.

In 2.42 games, if automatic updates cause huge dye and copper demands, than I would infer that these would be retained unless "corrected" by a cycle turn look or caravan delivery, just the opposite of what I've confirmed to happen in MGE multiplayer. Right?

Also, I MGE singleplayer may work differently for the human player than it does for the human players (all are human) in my hot seat test game. This is something I have not checked into yet.

Again, intervening posts, I will check into your latest questions...

[samson]

Solo,

I think the trigger hypothesis also explains why AI cities on 2.4.2 always demand Dye and later Copper. They only get the cycle-year auto-update, they don't "view" their cities. However, when caravans are delivered to these dye hungry cities, this causes the Dye demand to disappear: until the next cycle-year reinstates it.

An opposite scenario should hold true for AI cities on MGE. Does it?

Another question, how do you determine the City# on MGE? On 2.4.2, after sharing maps the Find City command lists all cities in City# order (0 first). This is how I get City#s. But on MGE, the Find City list is sorted alphabetically.

[samson]

Tie breaker rules:

If a commodity's Supply and Demand Quotient are equal: it goes on the Supply Roster.

If a city's Supply and Demand wildcards are the same, the commodity is used for Demand.

If two or more commodities on a Roster have the same quotient, they are ordered by commodity number (15=Uranium, 14=Oil, 13=Gold ... 0=Hides).

[solo]

Again, your latest post appeared as I was posting my last one. I agree with your latest findings, and can check out what happens to copper, which appeared on Washington's demand list on that turn I built a caravn there. Instead of looking on the cycle turn, I will wait one more turn and see if copper still shows up. Be back in a few...

...I'm back, and copper is being treated like dye in that situation. A delayed look found neither on the demand list, but a cycle turn look found both. Copper appeared due to the cycle look trigger and due to the change to size 3.

I also concur about how cheat mode functions.

[Elephant]

re: Uranium DQ: Hmmm - another integer relationship - you have exceeded 32,000...

Samson, have you taken the month off to work on this stuff? I'm looking at punting the CFC GOTM just to catch up with all you've put out in the last two weeks!

[solo]

It was a semantics thing. I was referring to list results and you were referring to the trigger function with the word "works", although at first I was mistakenly thinking delayed looks were acting as a trigger. To summarize our knowledge so far:

Only three triggers in both games:

1) Automatic list update at beginning of each cycle turn.
In 2.42 this update implements the the dye bug, putting dye at the top of the demand roster, which results in a "bugged" list. In MGE games this update produces "correct" lists uncorrupted by the dye bug.

2) A look at a city during a cycle turn will trigger another update, which can include list changes caused by cycle turn events such as a change in city size, or the acquisition of techs. For 2.42 games, this look will also change a "bugged" list into a "correct" one. In MGE multiplayer games, the dye bug is also triggered by a cycle turn look, putting dye at the top of the demand roster, which results in a "bugged" list.

3) A caravan delivery to or from the city, or the use of a caravan produced by the city to help make a wonder, acts as an independent trigger, working on any turn to update a city's lists. As with 2.42 cycle turn looks, a "correct" list results. As with MGE multiplayer cycle turn city looks, the use of a caravan will trigger the dye bug in MGE games.

If an MGE city's lists have become "bugged" by a cycle turn look or the use of a caravan, the next cycle turn automatic update will "erase" this effect, producing "corrected" lists. In MGE games, as long as this automatic update is not followed by triggers 2 or 3 above, new caravans produced by the city will use this "corrected" supply list. A "bugged" list that has been transformed into a "correct" one, can be inspected on non-cycle turns, since these looks can not trigger any further changes.

(Edited and corrected to reflect Samson's latest findings)

Samson,

Onto another item, which I do not think has been mentioned. Sometimes a city will have the same commodity as its supply and demand wildcard. I have noticed that in situations where a wildcard has to be used for these cities, the game selects the demand wildcard.

[samson]

Solo,

Okay, I think I'm getting a handle on the interaction of the various triggers with the Dye/Copper Demand calculations. For Copper Demand, I actually have a working formula that looks like this:

Demand = BASE*
Techs: Electricity: x 3/2 Computers: x 1/4
CitySize: 1-2: Demand = 0 3-4: 1/2 5-7: 1x 8-12: 2x 13-17: 3x 18-22: 4x ... etc.
City Improvements: Marketplace: x 3/2 Bank: x 3/2

* BASE depends on the type of trigger. On 2.4.2 the triggers' effects on BASE are:

Cycle-year auto-update: LARGE NUMBER
City Display during cycle-year: City# + Rivers + Roads
Caravan Delivery/Receipt: Rivers + Roads

On 2.4.2, the cycle-year automatic update introduces the super-high demand for Dye and Copper. But if you view the City Display during that year, these demand values are "corrected" and the S/D lists shift to reflect this. Caravan activity also "corrects" the problem, although in a different way with possibly different results.

On MGE, the triggers have just the opposite effect on Dye/Copper calculations:

Cycle-year auto-update: "correct" demand values
City Display during cycle-year: VERY LARGE NUNBER
Caravan Delivery/Receipt: VERY LARGE NUMBER

I haven't checked this Copper formula on MGE with Cycle-year auto-update to see which of the two "correct" formulas it corresponds to.

This may not be the entire picture, but it can be used as a testable hypothesis for now. In fact, it explains the "Washington" glitch you saw where you were able to build a Dye caravan on Washington's cycle-year turn, even though Dye was demanded when viewed from the City Display.

What happened, assuming you were on MGE, was that the cycle-year auto-update "fixed" the S/D lists and Dye moved from demand to supply. At that point you were offer the choice to build Dye when the city was processed during its pre-turn. However, when you went back to view the city on the same turn, this was another trigger which caused the HUGE Dye Demand to be reinstated. Had you waited a turn before viewing Washington, the "correct" dye value would have locked in and the city would have continued to supply dye.

I think this also explains how the Cheat Menu Reveal Map command effects S/D calculations. Reveal Map, apparently, sets every city to trigger on the current year. This doesn't update anything by itself, but when you view a City Display the S/D lists are updated. On 2.4.2, this causes Dye/Copper demands to normalize. On MGE, this causes Dye/Copper demand to become HUGE.


Another tidbit: with 100 techs the DQ for Uranium should be 10,000 for a city with size 12+. If you build a Nuclear Plant, this goes up to 20,000. If you add a SDI you should get an DQ of 40,000. On 2.4.2 at this level Uranium drops off the demand list. Apparently, an overflow occurs at 2^15. On MGE this overflow does not happen.

[samson]

Right. That's how I understand it.

I still don't know how or why the Dye/Copper bug works the way it does. High demand for both Dye and Copper happens on 2.4.2 as well, but I'm not sure what causes it, or how it differs from MGE.

[solo]

Okay, I understand and agree with what you are saying. Without a look on cycle turns, the Trade Advisor shows "correct" values and if looks are delayed longer, even past a size change occurring after a cycle change, those looks still display the same "correct" values triggered during the last cycle turn.

However, cycle turn looks in MGE end up producing a different list than they do in 2.42, because in MGE they activate the dye-copper bug, right? Both game version cycle turn looks work as a trigger, but have different results. This is what I meant by saying they "work" differently. I now agree that delayed looks are not triggers.

[samson]

The difference between 2.4.2 and MGE (I have both versions) isn't in the way cycle-turn looks work ... it's in the Dye/Copper bug.

[solo]

Okay, I did not see your reply to my first post on this. What you say makes sense to me, but if dye-copper bug is not implemented by cycle turn looks, then their "correct" demand values should be lower, right?

In any event, I can alter or "correct" lists by choosing to delay looks until after cycle turns in MGE games, or use cycle turn looks if I want "bugged" lists.

From what you say, in 2.42, a cycle turn look always gives a "correct" and updated list. If so, this is a radical difference between game versions.

[samson]

A brief update on this. For cities that have list changes on cycle turns, but do not have size changes or tech changes on these turns, delaying a look until after the cycle turn produces different lists, again with dye moving from demand to supply. Ditto for a delay of another turn. Looking on cycle turns makes something different happen.

Solo, you are observing the same phenomenon I described but attributing a different cause to it. What's happening is just what I said: Viewing the City Display on a cycle-year is a trigger-event. So is the automatic update at the beginning of a cycle-year turn. The automatic update corrects the Dye/Copper distortion, but Viewing the City Display in that year reinstates it. It works the same way on 2.4.2 except without the Dye/Copper bug. [Actually 2.4.2 has its own Dye/Copper problem but it manifests differently.]

There's a bit of Heisenberg at work here, but it's not entirely unpredictable.