A pattern governing supply and demand changes

[samson]

An update.

Caravan deliveries act as a trigger event in both the source and destination cities. Of course, this doesn't mean it always cause an S/D list change. Both when conditions are right, changes in both cities will be made visible.

[Elephant]

My question about TradeAdvisor versus CityScreen was because they were giving different lists on the same turn, and the CityScreen changed back to agree with the TradeAdvisor AFTER I cross-checked with the TradeAdvisor.

In checking my notes I missed the fact that the city had promoted from 1 citizen to two that turn. Could that have been the "trigger" for a S/D change?

Here is some of the log:

pre-first-move:
Hides-Card,Zimb,Crewe
Beads-Card,Zimb,Madrid
Cloth-Card
Wine-Zimb,Crewe
Spice-Madrid
Gems-Crewe,Madrid
C01-Cardiff (Hide,Bead,Cloth)
C02-Zimbabwe (Hide,Bead,Wine)
C03-Crewe (Hide,Wine,Gems)
C04-Madrid (Bead,Spice,Gems)
(NOT sequenced correctly)

4000 - founded LONdon (c9/103,17) on Plains
__supplies Silk,Dye,Gold
__demands Hides,Beads,Wine
start Monarchy
3950-
TradeAdvisor Demand:
_Hides- Card,Zimb,Crewe,LON,Beijing
_Beads- Card,Zimb,Madrid,LON
_Cloth- Card
_Wine- Zimb,Crewe,LON,Beijing
_Spice- Madrid,Beijing
_Gems- Crewe,Madrid
so C06-Beijing is Hide,Wine,Spice
3900- Demand: same
3850- worked square has new road; Demand: same
3800- new city C07-Delhi: Hides,Wool,Wine
3750- Demand: same
3700- Demand: same
3650- HUT (104,22): WarCode
Demand: same
3600- Demand: same
3550- Demand: same
3500- Demand:
Hides- Card,Zimb,Crewe,LON
Wool- Delhi
Beads- Card,Zimb,Madrid,LON,Beij
Cloth- Card
*Dye- Beij,Delhi
Wine- Zimb,Crewe,LON,Beij,Delhi
Spice- Madrid
Gems- Crewe,Madrid
so Beij now Bead,Dye,Wine
and Delhi now Wool,Dye,Wine
(could Delhi have changed last turn AFTER me, then Beijing this turn?)
3450- LON size 2, disorder (fixed with Elvis)
__LON change:
__Supplies Silk,Gold,Gems
__Demands Dye,Hides,Beads
TradeAdvisor Demand: same
!!!after Trade Advisor, LON returns to S:Silk,Dye,Gold; D: Hide,Bead,Wine
3400- Madrid now Cloth,Dye,Gems

Could the temporary Disorder on getting to size 2 have caused a S/D change, which then reverted when I corrected it? Have you tested for city size or disorder effects yet?

[solo]

Here's the dope on Washington:

coordinates (75,51)
supply wildcard - beads
demand wildcard - salt

2250 s: silk,salt,gems d: dye,hides,beads
1850 s: hides,silk,salt d: dye,beads,wine
1050 caravan builds dye, options were hides,silk,dye
1050 s: hides,silk,salt d: dye,copper,beads
875 dye(d) delivered s: silk,beads,cloth d: dye,salt,wine

Attached is a hot save file in case you would like to check out terrain around Washington. Save is for the turn just before 1050.

Elephant,

My Trade Advisor lists look okay. City growth (i.e. changes in size) can cause S/D changes. I am not sure about disorder, but it's something I could test for:

[samson]

Elephant,

Okay, I loaded up the Trade start you are working with and saw the problem you're talking about. And I think I can explain what is happening here.

First of all, London is the 5th city founded, not the 9th as your log indicates. This means that London's first solo-cycle year occurs in 3450BC. Now, before that turn London's S/D list looks like this:

Supply: Silk, Dye, Gold
Demand: Hides, Beads, Wine

The wildcards are: Supply = Beads; Demand = Beads.

Curiously both the wildcards are the same and also (as it turns out later) the same as the true 2nd place Demand item. Thus, we are looking at actual S/D rankings here without wildcard substitutions.

In 3450BC London goes into disorder and doing Zoom-to-City brings up a City Display with these S/D lists:

Supply: Silk, Gold, Gems
Demand: Dye, Hides, Beads

Again, no wildcard substitutions occur because Beads is already on the Demand list. However, the "Dye bug" has produced an artificially high demand for Dye. So much so, that Dye's DQ is now greater than its SQ and it jumps from the Supply list to the top of the Demand list. This pushes Hides and Beads down to 2nd and third place. On the Supply list, the vacancy created is filled by Gold moving up to 2nd place and Gems joining the list.

Now, after you exit the Zoom-to-City display and return to the map screen, you looked at the Trade Advisor. It shows what it thinks are the correct S/D values in its display (exactly what you saw in the Zoom-to-City display. The Trade Advisor doesn't update anything, it just displays the last stored values for each city's S/D lists. The Trade Advisor is working fine.

However, if you then return to London and enter the City Display, the S/D lists are back to what they originally were. These are the "correct" values. After viewing the City Display, you return to the Trade Advisor which now shows the original values again.

This is all a manifestation of the "Dye bug". The problem is that for each different way that the S/D list updater is invoked, the results for Dye's Demand Quotient can be different. The ways we know about are:

1) 16-turn cycle. S/D lists are updated automatically at start of turn.
2) City Display. If they on a solo-cycle year, a city's S/D list is updated every time the City Display is entered.
3) Zoom-to-City during the pre-turn on a solo-cycle year.
4) Reveal Map used with City Display.
5) Caravan deliveries.

Apparently, the interface between each of these events and the S/D list updater is slightly different and can effect the calculation of Dye's Demand Quotient. Because of the interrelated nature of commodity calculations, this single bug can affect other commodities on both the Demand and Supply lists, as your example illustrates.

The Trade Advisor appears blameless in all this.

[solo]

Sorry for uploading the wrong hot file. Here is Washington just before dye is built:

[samson]

Solo,

It looks like the "Dye bug" operates differently on the Gold edition and 2.4.2. Using your "Dye.sav" on 2.42, I can send caravans into Dye-demanding cities and it triggers a change in S/D lists, removing Dye from the demand lists. But on Gold Edition it doesn't. It seems that on Gold, Dye-demanding is the persistent state and non-Dye-demanding is transitory. On 2.4.2 it's just the opposite.

Your Washington glitch and Elephant's London glitch seem to be the same thing. In your case, on Gold, the non-Dye-demand state occurs briefly during the pre-turn phase when you build a caravan on a cycle year. Then the Dye-demand state returns. In Elephant's example just the opposite happens in 2.4.2.

A couple explanations:

1) The dye bug manifests differently on Gold and 2.4.2
2) The dye bug has been "fixed" on Gold, and Dye-demanding is the intended result. (A slight glitch still occurs on cycle years.)
3) The Trade system was revamped for Gold Edition and there are other surprises in store.

I think #1 is the most likely although #2 is possible. My testing with S/D formulas is being done on 2.4.2 and I sure hope things are not too different on Gold.

[solo]

Samson,

Hmm, I was thinking the differences were between MP and SP, regarding dye, but if dye deliveries are always triggering changes on Destination demand lists in 2.42, then there must be some difference between versions, too.

I have calculated all the wildcards for the cities in my MGE hot seat game, and there is only one city I have to check out a little more for errors on my part while doing this. All other cities are showing behavior consistent with what you describe for wildcards, so I would bet that the treatment of individual commodities will remain consistent between versions of the game, too.

Armed now with the knowledge of the masking effect of the middle positions by wildcards, I want to do a little more analysis on commodity trends, while taking wildcard action into account. I'll be back later with those results.

[samson]

Solo,

Thanks for checking the Wildcard stuff on MGE. It's a big help. I was beginning to think I'd have to do all my testing over again, if the versions were too different.

[solo]

My latest thought about dye, is that this extra demand could be on purpose to make the shifting of commodities on the demand lists even less noticeable.

Some news about dye, which I will add here with an edit. After a beads(d) delivery to Leipzig in 725 BC, copper replaced dye on Leipzig's demand list. Leipzig is now size 5, and this was the second time it has received a delivery. Unless copper has become supercharged, the way dye seemed to be before, it appears that dye's lead over other commodities was not as commanding as it first seemed. Either that, or something happened recently to make cravers of dye come to their senses.

So dye is behaving the way you described in your 2.42 game, where deliveries also were taking it off the demand list. A few more details:

before: hides,(silver),(wool) dye,salt,beads
after: hides,(silver),(wool) copper,salt,(beads)

Leipzig wildcards are silver and salt.

Since dye is amenable to change, it makes me back off more from the glitch theory, since with a glitch, I would expect a much greater difference between dye's quotient than those of its nearest competitors on the demand list.

[samson]

Solo,

Interesting that you mention Copper. I have been testing Copper today. I agree its DQ does exhibit some of the same behavior as Dye's, but only after the city's size grows above 3. The fact that two commodities are showing this "supercharged" demand makes it more likely to be by design. Also, Dye is more well-behaved on MGE than it is on 2.4.2. So it's possible that some kind of glitch was fixed in that version.

What really bothers me about Dye, is not the huge DQ is seems to have but the flakiness it seems to introduce into the whole Trade system, as in Elephant's example and some of your own.

[solo]

One more note about dye, is that ALL cities were demanding it at the time this delivery happened. No new cities had been founded for enough turns to allow all of the newest ones to be "dyed" on their first cycle turns.

[samson]

My latest thoughts on Dye.

There are actually 3 commodities with "supercharged" demand. Dye, at the start of the game; Copper, after cities reach size 5 (you were right about that, it's size 5 not size 3 that triggers the "copper rush"); and Uranium, after Nuclear Fission is discovered. The existence of three such strong demanders is evidence against the "bug" theory of Dye. [Although I still think 2.4.2 has a bug that was fixed in MGE.]

Since we have 3 commodities at different stages of the game that produce remarkably strong demands, I'm starting to think that this is a designed feature. Perhaps the fact that I have found little correlation of demand strength to terrain or other factors just means that I just don't know what the demand of these items is based on. Here's what I do know about the demands of these commodities:

Dye: demand is reduced by Chemistry and Mass Production.

Copper: demand starts at size 5, is increased by Electricity, reduced by Computers.

Uranium: demand starts with Nuclear Fission, increased by # of techs and city size.

Today, I'm going to look at Uranium a bit closer, see if I get some clues there.

[solo]

Yes, copper is starting to show a lot of strength. I will monitor it as more cities grow to size 5. Copper is even climbing lists on smaller cities at this time.

One thing your tests might not be simulating are phases of the game when the addition of new cities slows down and even stops for periods of time. Dye may be used for keeping track of this, since it is immediately added to fresh cities on their first cycle turns. This always happens, except to the human player in SP games, so it seems quite deliberate to me, since most new cities do not start off with dye as #1 in demand.

It could be that copper gradually starts to take the place of dye when this stage of a game is detected.

This last turn, all 3 caravan deliveries have triggered S/D changes, in both the Source and Destination cities, although one Source had its cycle turn at the same time.
Each cargo happened to be hides and was demanded.

[samson]

Solo,

You're right. The turn number (or game year) could be a factor that alters supply and demand in any commodity. I haven't tested for that at all. Another thing you mention is the "human player". All my testing as been done with "human" cities. Some formulas may work differently with AI civs.

If you look at the latest formulas I've added to the list, most of the supply sides are done, but I have lots of demand missing. It is much easier to crack Supply formulas because the basis I use for comparison in order to adjust all formulas to the same scale is COPPER SUPPLY. It is the simplest fomula I've found, based solely on Hills and Mountains with the same coefficient. Originally I used a "copper=1" scale, but got a lot of fractional coefficients in other formuals. Currently, I'm using "copper=5" and have mostly integer coefficients to deal with now.

To scale Demand Side formulas, I've got to get a commodity to appear on the Supply side first (at approximate equality to Copper) and then flip it to the Demand side by pumping up what I think affects its demand. The point at which it jumps to the Demand side is its point of approximate equality to Copper's SQ. Then it's a matter of finding and measuring all factors and doing the algebra.

[solo]

Yes, I can see how supply would be more likely to be tied to terrain, which is more of a constant, and much easier for conducting systematic tests.

Demand is probably quite more dynamic, changing more often, and tied more to the progress of a civ through the different stages of the game, something harder to simulate easily while conducting tests. Because of this, I am making saves of my game after every player turn, in case the game becomes of use for demand tests, later.

One thing I have noticed in all my games is that the Germans are always wanting wine, much more so, on average, than other nationalities. Demands may be linked more to individual civs (not just colors). I know you are testing for this, but are all civs being included in a systematic way?

I have looked over the additons to your commodity lists, and see a lot of progress. When you have your best estimates in place for all supplies and demands, I will want to be checking these against what actually occurred in my test game. This may be a good way of fine tuning the formulae, or detecting new influencing factors.

For now, it's on with my game, in which it is taking a lot of time to make progress in, since I don't want to omit what might turn out to be critical information.