Feedback and Suggestions

[Kailric]

I'm proposing a new variant to the family of domestic sales. The sales each turn should be considered raw material consuming, like blacksmiths consume ore. This influence the change at the bottom row and avoids the col2071 problem where it says +2, but you only get one because the other one is sold. Even more importantly the AI is capable to moving yields around to supply the need. It's not a matter of telling the AI how to do it, it's a matter of implementing this in the code the AI is already able to handle well.

I had proposed an option for a single national-level economy, where if a city ran short of a demanded good; instead of freaking out that you didn't send a Wagon Train to fetch 3 Rum it could simply consume some surplus from other cities that were set to sell that good, and everyone would be satisfied. Let me know what you think about it:

Yes, it would work best if a domestic system was part of the current system. As much as I have worked with the code it doesn't seem like to difficult of a task to merge it in. Goods consumed locally would just be a another modifier that takes away maximum output or goods stored.

I very much like your proposition, orlanth. I feel this could be used with the PlotGroups feature I added to my Forts mod. If two cities are connected by roads then they can auto trade between each other. We already have Import, Export, and Minimum Goods Stored (MGS). MGS could be set up to be used for the Local or Domestic Market. Say, CityA Exports Ale and sells Ale Locally and CityB Imports Ale and also sells Ale Locally. You would set CityA to Export Ale and set a MGS to satisfy the Domestic Market. Then any extra left at CityA would be auto shipped to CityB through the PlotGroup trade route system. If CityB is deficient in Ale it will cycle through all the Cities in it's Plotgroup and if it finds any excess it will remove it and add it automatically. In my Forts Mod I made it so that Forts require food from Cities so a system similar to that can could be used here to supply local markets.

 

[orlanth]

Yes, it would work best if a domestic system was part of the current system. As much as I have worked with the code it doesn't seem like to difficult of a task to merge it in. Goods consumed locally would just be a another modifier that takes away maximum output or goods stored.

I very much like your proposition, orlanth. I feel this could be used with the PlotGroups feature I added to my Forts mod. If two cities are connected by roads then they can auto trade between each other. We already have Import, Export, and Minimum Goods Stored (MGS). MGS could be set up to be used for the Local or Domestic Market. Say, CityA Exports Ale and sells Ale Locally and CityB Imports Ale and also sells Ale Locally. You would set CityA to Export Ale and set a MGS to satisfy the Domestic Market. Then any extra left at CityA would be auto shipped to CityB through the PlotGroup trade route system. If CityB is deficient in Ale it will cycle through all the Cities in it's Plotgroup and if it finds any excess it will remove it and add it automatically. In my Forts Mod I made it so that Forts require food from Cities so a system similar to that can could be used here to supply local markets.

Wow, that sounds like it could be great That would also solve the issue Nightingale mentioned about transport systems sometimes ignoring nearby sources and taking unnecessarily distant routes. Also, with the small amounts of different yields demanded by domestic markets, using lots of individual units to move them around locally gets difficult to justify. With this you could use your transport/Pedler units and routes for stuff a ruler would actually focus on like trading and long-distance transport, and not need to tie up lots of units in shuttling small amounts of yields back & forth between local settlements.

It seems like your system might take some processing time, but considering the savings compared to doing the same thing through loading, moving/pathfinding, and unloading of lots of units locally, I'm betting it could actually end up being a lot faster.

How exactly do the PlotGroups work? If it gets too computationally expensive to iterate through all cities in the PlotGroup, it could also be possible to do a single calculation per PlotGroup similar to below. I'd guess most games would end up with only 1 to 3 PlotGroups per player, and cities that aren't connected wouldn't need to use the system at all.

* For each PlotGroup and Yield, calculate a total Excess Supply, being the sum of (local supply - local demand - MGS) for all cities which are set to sell that Yield.
* For each city in a PlotGroup, if it doesn't have enough Yield to satisfy local demand, it can consume some to be subtracted from the PlotGroup's Excess Supply, charging a slight percentage for transport.
* At the end of the phase, the total amount consumed from Excess Supply is subtracted proportionally from the cities that had excess supply and are set to sell.

 

[Kailric]

It seems like your system might take some processing time, but considering the savings compared to doing the same thing through loading, moving/pathfinding, and unloading of lots of units locally, I'm betting it could actually end up being a lot faster.

I also forgot to add that this could be set up to add a new Diplomacy Trade Item, where just like in Civ4 you can trade Resources per turn. I mentioned a system like this in posts before. So, just working out the code on paper... When making Diplomacy deals the code would cycle through a Civs cities and find ones that have excess goods of value to the other player. It would produce a list of Cities and Goods then say set up a items so you could trade 4 Ale from York for 4 Wine from Constantinople (or the amount could be effected by their value in gold perhaps). Then to save CPU cycles there could be a new attribute added to Cities that would count Trade Cities that are connected. Then when CityB needs Ale it will Cycle all its Trade Cities. Trade Cities would be recalculated each time a PlotGroup change happened or a new Diplomatic trade takes place.

 

[Kailric]

How exactly do the PlotGroups work? If it gets too computationally expensive to iterate through all cities in the PlotGroup, it could also be possible to do a single calculation per PlotGroup similar to below. I'd guess most games would end up with only 1 to 3 PlotGroups per player, and cities that aren't connected wouldn't need to use the system at all.

* For each PlotGroup and Yield, calculate a total Excess Supply, being the sum of (local supply - local demand - MGS) for all local cities which are set to sell that Yield.
* For each city in a PlotGroup, if it doesn't have enough Yield to satisfy local demand, it can consume some to be subtracted from the PlotGroup's Excess Supply, charging a slight percentage for transport.
* At the end of the phase, the total amount consumed from Excess Supply is subtracted proportionally from the cities that had excess supply and are set to sell.

Just now seen this addition. Plotgroups adds a new attribute to plots with a Plotgroup ID and works much like Area does. All Connected water plots and their coastal plots are all automatically in the same Plotgroup. When you build a road not connected to an above Ocean plotgroup it creates a new Plotgroup with Cities being automatically considered having a road. Then each road built adds to this new Plotgroup. If this new Plotgroup connects with another Plotgroup the biggest one takes over. If a road is destroyed a Plotgroup check is made to see if that plot is still connected to its Plotgroup. (Note: all of this I am "trying" to recall form memory from working on the Forts mod)

I think the faster way to code it would be like I mentioned in previous post to add a new TradeCities attribute to Cities. That way you would not have to cycle through all plots in a Plotgroup (which could be extensive) or all Cities in the game. All coastal Cities would be connected automatically and then new ones added when a road is built connecting them. We could ask Nightinggale on his thoughts for coding this. Oh, Nightinggale...

 

[orlanth]

I also forgot to add that this could be set up to add a new Diplomacy Trade Item

ah, genius! It's like bringing back the best of Civ4.

Plotgroups adds a new attribute to plots with a Plotgroup ID and works much like Area does. All Connected water plots and their coastal plots are all automatically in the same Plotgroup. When you build a road not connected to an above Ocean plotgroup it creates a new Plotgroup with Cities being automatically considered having a road. Then each road built adds to this new Plotgroup. If this new Plotgroup connects with another Plotgroup the biggest one takes over. If a road is destroyed a Plotgroup check is made to see if that plot is still connected to its Plotgroup. (Note: all of this I am "trying" to recall form memory from working on the Forts mod)

Sounds impressive. Did you reuse any of the standard code from base Civ4BtS for cities having trade links with the capital? That was made for roughly the same purposes & it may be possible to adapt parts of it if there's anything else you needed. For instance you can allow Rivers to act as roads for traderoute purposes via a tech; and through other techs you can unlock the ability to have any Terrain type act as such. (For instance could have an early tech enabling trade on Coast, and later Caravans enabling trade across Desert.) It may even have some TradeCities function like the one you mentioned, since it does check if trade from the capital can reach other cities during diplomacy.

We could ask Nightinggale on his thoughts for coding this.

lol I'm sure nightingale is dazed from overwork at this point but hopefully it may be possible to bring most of the functionality from your Forts modcomp if you think it'll work.

 

[Kailric]

ah, genius! It's like bringing back the best of Civ4.Sounds impressive. Did you reuse any of the standard code from base Civ4BtS for cities having trade links with the capital? That was made for roughly the same purposes & it may be possible to adapt parts of it if there's anything else you needed. For instance you can allow Rivers to act as roads for traderoute purposes via a tech; and through other techs you can unlock the ability to have any Terrain type act as such. (For instance could have an early tech enabling trade on Coast, and later Caravans enabling trade across Desert.) It may even have some TradeCities function like the one you mentioned, since it does check if trade from the capital can reach other cities during diplomacy.
lol I'm sure nightingale is dazed from overwork at this point but hopefully it may be possible to bring most of the functionality from your Forts modcomp if you think it'll work.

Just a quick reply, yes, I used most of the code from Civ4 and I do believe rivers are included in plotgroups already, not sure about activated by tech though as that would require a seperate plotgroup for each Civ. Good suggestions though.

 

[orlanth]

As a thankyou for the help of M:C DLL to modmodding in 2071, I've put together that custom Monk SoundScape you'd been wanting for the Monastery cityscreen!



To use it, just add the following to the <CitySoundscapes> in gameinfo/civ4erainfos.xml :

<CitySoundscape>
<CitySizeType>CITYSIZE_SMALL</CitySizeType>
<SoundscapeScript>ASSS_CITY_MONASTERY_SMALL_SELECT_AMB</SoundscapeScript>
</CitySoundscape>

yeesh it can get kind of tedious making these AudioSoundscapes, since Firaxis dangled everything across five XML files! well its taught me the saintly virtue of patience Patientia virtus est

 

[mastrude]

I've set up couple of lists to track things for the MC Development Version. They're on the web at:

https://drive.google.com/folderview?id=0B8-M7ICqmnkddFdTblA1b3ZuWlU&usp=sharing

They are M/S Office 2007 documents. They are public and can be downloaded. I would appreciate comments.

 

[Kailric]

@orlanth

Thanks so much brother! I bet this is going to be awesome
@mastrude
I checked out your document. They are all good points. I'll make a reply to them soon.

 

[orlanth]

Sure, no problem Teddy Mac!
BTW for any monk-music fans out there I wanted to give a quick shout out to this kickstarter by a friendofafriendofafriend.
Their sample tracks actually sound really good
(though not quite good enough to make me want to take Holy Orders..)

 

[Nightinggale]

Yeah I agree. Having some actual supply/demand generated within your colonies makes things way more interesting. The Domestic Economy feature that allows generating demand from citizens/buildings was first developed by Androrc in his modcomp here which was included in the ancient 2071 version

I looked though the source code for that one and it appears surprisingly simple to implement. However I started thinking if it's good enough.

First of all I want to link it to the marked on/off sales. I would also argue that at least a simple marked should be available from the start as income is really tricky in the beginning.

I also came up with the idea that citizens can use yields. Not just the units, but the city counts the number of units working in buildings and the number working in plots. It will then create an extra demand based on those. This shouldn't be linear with the number of units. Instead it should encourage building huge cities, which intentionally clashes with max population restrictions.

Some amount of randomness. The modcomp adds all demands for yield X, then it divides it with 100 and the actual demand is there. I would like it to subtract 0-50% randomly in order to make the domestic marked more unpredictable.

Store leftover points. If a demand is 20, then it would demand one of those yields every 5th turn (or every 5-10 turns with random demand). If you don't sell on the turn where the demand is, then tough luck. It's gone.

Some amount of randomness in units. Say a UnitType is set to demand 50 of 4 different yields, but have a max demand of 100. Whenever a new unit is created of that type, 100 points is distributed randomly between those 4. It should take the amount for each into account as it should be more likely to demand more of a yield, if it's set to 100 than the 3 set to 50. This mean two units of the same type might demand noteworthy differently from each other. You can then have good and bad units based on what you produce on your land.... now which one do you want to make a scout and which one do you want to stay in the city?

I think this would be the most ideal solution as it would provide the ability to have a fair amount of domestic trade while at the same time it's unpredictable enough and it will not be the same in two games even if you do the very same thing twice.

 

[orlanth]

Yeah, I agree the consumption should be able to be turned on/off by the Market mechanism, and it works well to have it act like a regular use of yields as you said earlier rather than a totally separate system like in the original modcomp. The <AutoSellsYield> used by buildings like Market could be repurposed to mean that the building enables local consumption of that yield (which can be set on/off after having that building). The basic town buildings in M:C could allow trading in some basic goods, while fancier ones like Wine need a Tavern, etc. I'm not sure what the MODER_CODE_TRADING_POST currently does in addition to that though.

I guess it would be good to add some element of randomness to demand, but it could eventually get a bit fiddly for players to cope with tracking idiosyncratic demand values that remain fixed and different for many dozens of individual units. (Also, in the timeframe of Civ4Col mods the units don't represent a specific individual person with unique preferences that stay fixed forever, rather a group or class of local people many of whom continuously die and are born etc during the course of a game). But like you suggested, in addition to the base demand from units/buildings there could be some random fluctuations in local demand across time, like there are in any market. That plus the existing randomness in what emigrants you get and what yields are obtainable in local terrains should make things play interestingly different in each game.
(edit: it might eventually be interesting to add some random Events using the xml Event system that could add extra demand temporarily to a city due to a temporary shortage or disaster. i.e. "Shortage of Barley in Paris! Demand +5 for 10 turns.")

What do you guys think re this earlier proposal to let local prices vary somewhat based on supply/demand balance? It would probably take quite some doing to have local prices, but letting prices respond gradually to supply/demand imbalances could make the interplay of supply/demand and trade opportunities a lot more interesting.

I've been thinking about a mechanism for allowing supply and demand to realistically shape local prices, while allowing plenty of flexibility to balance these features however is desired using just XML. Here are the ideas I've come up with, let me know what you think!

Where iBuyPrice is the current buying price in that city, and the already existing variables below come from CIV4YieldInfos.xml:
iBuyPriceLow : minimum buying price of that yield
iBuyPriceHigh : maximum buying price of that yield
iPriceChangeThreshold : price sensitivity of that yield (how many units you'd need to sell to drive the price down to iBuyPriceLow, or how many units you'd need to buy to drive the price up to iBuyPriceHigh)
iSellPriceDifference : difference between buying and selling prices (may work best to convert this to a percentage rather than a fixed integer?)

Whenever a yield is bought from a city during trade, call the following function, thus raising the local price by a degree proportional to the amount bought, never exceeding iBuyPriceHigh.
iBuyPrice = min(iBuyPriceHigh, (iBuyPrice+(iBuyPriceHigh - iBuyPrice)*(iUnitsBought/iPriceChangeThreshold)))
At the end of the turn, add up the Demand from local units/buildings (based on Androrc's mod), and call the above function using this demand as iUnitsBought; thus generating upward support for prices based on local demand.

Whenever a yield is sold to a city during trade (or sold via its Market/Tradingpost building at the end of the turn), call the following function, thus lowering the local price by a degree proportional to the amount sold, never less than iBuyPriceLow.
iBuyPrice = max(iBuyPriceLow, (iBuyPrice-(iBuyPrice - iBuyPriceLow)*(iUnitsSold/iPriceChangeThreshold)))

iSellPrice can be updated after each transaction as follows:
if using iSellPriceDifference as a percentage margin: iSellPrice = iBuyPrice*(1+iSellPriceDifference)
if using iSellPriceDifference as an absolute margin: iSellPrice = iBuyPrice+iSellPriceDifference

The basic effects should be that local prices drift down slightly if you're earning lots of gold from selling a certain yield to a city via trade or Trading Post/Market; and drift up slightly as the city generates demand for that yield (especially if that demand goes unfulfilled by selling). The price sensitivity and min/max price for each good can be set as desired. Special markets like Spice Route could get their own set of modifiers to adjust min/max price of certain goods for their unique situation, and cities with high Prosperity can get a bonus to the Demand they generate, building higher prices and profits there. Overall it would be a cool way to generate realistic and subtle shifts in local markets in response to supply/demand, so you can benefit by satisfying your citizens' demand through good strategy, without having to micromanage to an artificially precise limit like "demands exactly 3 Cigars per turn".
The main issue I'd see with this (or any other system for price change) is that in vanilla, the smallest possible price change of 1 gold ends up being extremely large in percentage terms for many goods with low price per unit (less than 5 or so, where the smallest possible movement is 20%). And if a given transaction isn't big enough to move the price by at least 1 unit, its effects won't be stored unless we make some special remainder variable to store it. The easiest fix for both of these would probably be to "inflate" overall price levels by a set amount so small/gradual price adjustments become possible. The vanilla system seems pretty crude with a large random component, so almost anything would be an improvement..

 

[Nightinggale]

Maybe it would be best to start simple. First step would be to add demands for buildings, get it working and then commit. After that add demands from units, commit and then we will figure out what to do from there. A great plan for a goal is useless unless you know how to get there. Just adding demands for buildings without any randomness or anything to it appears to be strait forward. Units shouldn't be too hard either.

I will postpone the whole pricing scheme until later as well. No use for price on something you can't sell anyway.

 

[orlanth]

Ok, sounds good BTW once Buildings can generate demand, I think it should already become possible to implement moddable XML Events boosting local demand temporarily without need for DLL changes. (XML Events could create an invisible "Building" with that demand effect, which could be destroyed after x turns.)

 

[Kailric]

I moved the conversation on the economy to its own thread. Ill make a reply there(from my iphone)

 

[Nightinggale]

I think the faster way to code it would be like I mentioned in previous post to add a new TradeCities attribute to Cities. That way you would not have to cycle through all plots in a Plotgroup (which could be extensive) or all Cities in the game. All coastal Cities would be connected automatically and then new ones added when a road is built connecting them. We could ask Nightinggale on his thoughts for coding this. Oh, Nightinggale...

I did a bit of research on plotgroups.

|M:C|BTS
Lines with PlotGroup mentioned| 1 | 396
Files with PlotGroup mentioned | 1 | 26

The one place it's mentioned in M:C is even commented out.

We should keep this simple. I wondered about the ultra simple solution, which is to copy CvPlotGroup.[cpp|h] from BTS, but looking though it makes me wonder if that is that wise. At least a lot of civ concepts will have to be deleted. On the other hand having a PlotGroup class, which is included in savegames provides interesting possibilities. It can also be used to cache combined demands from all cities in the plotgroup and similar data.

The basic plotgroup should contain

1. PlotGroup ID in plot class
2. PlotGroup::add()
3. PlotGroup::remove()

#1 is easy, #2 is also fairly easy unless you merge two groups. #3 is tricky as it can split a group into two or more groups. I looked at how BTS does this. Looks like the plotgroup is defined by the first plot in its list of plots. Whenever a plot is removed from the list, it will loop though all other plots in the group and remove those without access to the first plot. Sounds like a pathfinding intensive solution to me, but then again how often is road removed?

Another question is if a plotgroup should be cut in two if enemy unit(s) blocks every single route between two cities? This would really encourage having multiple routes between your cities, specially if wild animals are able to appear out of nowhere and block your road.

I'm thinking of letting PlotGroups spread on player owned plots, which has something from Misc\CIV4RouteInfos.xml built on them.

When this is working, the player and city classes can cache PlotGroups. We could also make PlotGroups cache pointers to cities.

This is all the work, which is needed to set up at least minimal PlotGroup Functionality. After that we will have to code the stuff, which does something with cities, which shares PlotGroup. Seems like a lot of work just to get a shared domestic market. Can we think of anything else where it could be useful? The AI could be made a bit more clever when moving yields around, but apart from that, what else can it do?

 

[orlanth]

I'm thinking of letting PlotGroups spread on player owned plots, which has something from Misc\CIV4RouteInfos.xml built on them.

The Civ4BtS trade system includes this, and also allows options to let trade access spread via Rivers and via Terrain types which can each be unlocked by Tech (eg discovering Sailing enables trade to spread along Coast).

I think Kailric said he had implemented many of PlotGroups features in the Forts modcomp; so that might be able to be merged over but not sure if it would help much versus adapting the code from Civ4Bts itself. If implementing Plotgroups turns out to be more arduous than expected, I think it could be almost as good to have one domestic trade group per civ, at least to start with. Several local plotgroups per civ would be more realistic (esp for 2071 Planets ), but OTOH in most games of M:C players would end up with a max of 2 or even one plotgroup, which would work quite similarly to a single civ-based group for domestic trade.

 

[Kailric]

I think Kailric said he had implemented many of PlotGroups features in the Forts modcomp;

Yes, It is in the Forts modcomp and as far as I know it works great but I have never had that code reviewed by a real programmer. I would probably be easier to merge Forts with M:C and that has actually been one of my goals.

 

[Nightinggale]

Yes, It is in the Forts modcomp and as far as I know it works great but I have never had that code reviewed by a real programmer. I would probably be easier to merge Forts with M:C and that has actually been one of my goals.

I guess I better just copy paste all the changes into M:C then. There are quite a lot of them and I can't make heads or tails of it with a brief look. Making a commit and then review the changed line appears to be way easier. It will also force me to read all lines while copying.

In semi related news I fixed a bug in RaR where automated transports could unload in cities belonging to other players, though I think they have to be on the same team. I haven't checked yet, but I think M:C inherited the same vanilla issue, which mean I will end up copying the fix. Figuring out how to fix the issue uncovered something, which for sure is useful for M:C. It turns out that all transports, be it human or AI, are controlled by CvSelectionGroupAI::AI_tradeRoutes(). The only exception is human owned transports, which aren't assigned to any traderoutes at all. This mean this is the function to look into if we need to restrict a transport to only transport between a select group of cities. In other words this appears to be a key in making a solution to make feeder service scale better to large empires.

 

[Kailric]

I guess I better just copy paste all the changes into M:C then. There are quite a lot of them and I can't make heads or tails of it with a brief look. Making a commit and then review the changed line appears to be way easier. It will also force me to read all lines while copying.

I am excited about this. This is one of the main additions I wanted to add to this mod. It will enable all types of possiblities. In my economic studies we have been learning about "Determinants of Growth". Its funny that while I am studing I notice the similarities to Col's economy. For instance the Determinants of Economic Growth are:


Supply Factors

• Increases in the quantity and quality of natural resources
• Increases in the quantity and quality of human resources
  • Increases in hours worked
  • Increases in labor productivity
  • Education and Training
• Increases in the supply or stock or capital goods (equipment and transports)
• Improvements in technology

Demand Factor

• supply must be purchased or sold

Efficiency Factor

• full employment and production efficiency

All these things are almost common sense and they are all found in M:C Edit: Well most of them are found in M:C

I've also learned that improving ones public infrastructure with roads and bridges has the added effect of increasing production in the private sector. So, by adding plot groups we can finally set it up so that cities can be connected by trade routes. I am thinking one benefit to being connected to a trade route is +Hammer so that a city receives two free production.