Why not have the global economy configuration screen have both a global total for the amount of each ware, and a minimum for each warehouse? The "Temporary global limit" column could be removed. The algorithm for storing a ware would be that if the nearest warehouse has less than twice (it can't be just the minimum number, or you run into the idiocy of sending the same ware both ways and causing traffic jams) the minimum amount of that ware, it is stored in the nearest warehouse. If not, it is stored in the nearest warehouse with less than the minimum amount of that ware. If there are no such warehouses, it is stored in the nearest warehouse. This, algorithm would, I think, provide necessary amounts to build quickly far from the production center, while still avoiding the traffic jams of trying to equalize wares completely.
Also, altering production priorities is fine, but the desired amounts should be selectable for <B>ALL</b> wares, and probably even for producers. The economy should <b>NOT</b> continue producing things after the global maximum is reached, just because a programmer has decided to override the wishes of the player. Stopping production of logs when you have 5k or of iron ore after you have 1k is very useful. If nothing else, it gets rid of a lot of congestion.
SHORTAGE QUEUING PROBLEMS
The original Settlers was deliberately restricted to relatively small maps, so that the queue-based destination system for when the economy is in shortage wasn't as amazingly bad. This game, however, is <B>Wide</b>lands. We have huge maps, and this system for shortages is idiotic on large maps.
Consider the case where we have two identical production centers, 20 minutes travel time apart, and the economy is in shortage. Fish is produced at one center, and then chooses a destination randomly. It then spends traveling to the other center where it becomes a ration, then spends 20 minutes traveling back to the other center, where it becomes iron ore, then travels back to the other center and becomes iron, then travels back to the other center and becomes an axe. Production shuts down, because the road is jammed with identical goods traveling back ways back and forth on the same road. Currently, this situation can only be avoided by having only one production center, or by scrupulously avoiding having any goods go into shortage.
There are quite a number of reasonable ways this could be fixed. The one which could reuse the most code from the current system is probably queuing with destination trading of wares in transit. The way this would work is for all wares to be assigned under the current system, but as soon as a destination is selected, this ware is flagged to be checked for destination trading.
I'll call the original ware A, and it's destination A'. What we do if check to check all other in-transit wares B of the same type as A. If A is closer to B's destination B' than B is and B is also closer to A' than A is, we send A to B' and B' to A. Then we flag both A and B to be checked again for destination trading. (Probably the distance comparison would use uncongested travel time.)
This would eliminate the roads jammed with the same ware heading in both directions, which are currently a common sight in the game.
Currently, as soon as a military building loses a unit, a replacement unit is sent if available. This unit may be coming from the other side of the board. You're actually much better off if you have almost enough units to fill your buildings, but not quite enough, because then by lowering staffing levels on nearby buildings, you can get replacement units to the building that is about to be destroyed quickly. On the other hand, if you are severely understaffed, the replacement units will rush off to fill buildings on the other side of the board that have no need for new units at this time.
In any case, the user interface is very clumsy. What we <b>WANT</b> to do is to get a replacement to the building under attack as soon as possible. We <B>DON'T</b> want to be fiddling with occupancy levels all over the economy, until the idiotic AI finally agrees to do what we want to do.
The way I would implement this much more straightforwardly is to have a unique priority number for each building. When a new building is built or a building is attacked, it is bumped to the top of the priority list, and this number can also be changed manually. Warehouses get a the lowest priority. Training buildings get the highest (though only for trainable troops) by default, though this could be configurable. When a military building loses a unit, one is the sent from the <b>nearest<b> military building/warehouse with a lower priority. The highest level unit available is sent. This building then attempts to replace its unit. This system would leave the oldest, lowest priority buildings with only one troop in them when there is a shortage of available troops.
When a building is full, it would upgrade its lowest level troops one at a time by finding the nearest lower priority building which has a troop of a higher level, and having that troop travel it, and releasing its lowest level troop. The lower level building would then replace the troop it lost, as normal.
I would actually prefer to not have troops be able to be in warehouses at all, and to have their production from wares by warehouses take significant time, but that's change isn't required in order to implement a military building priority system. Also, under the current system in which injured troops recover their full health almost immediately, injured troops should do nothing other than to stay in their current building whenever possible.