Feedback and Suggestions

Its obvious we have similar playing tastes. I is a pity I haven't been able to try your FTTW. I must have enjoyed it a lot.

 

DOOO IIIIIT!!!

 

I have come up with a new idea for yield transport management.

Vanilla focuses on one yield from A to B and while there are a few addons to make this work better, the core of automated transport is still based on this. I want to ditch that. Or rather, I want to write a new system based on an entirely new structure, which can then be used by the player. The existing system will still work and the two systems can work together.

The idea is more of a col 1 approach, though I didn't think of it like that until after I figured out how to do it

We make a new class of traderoutes and each player get a list/vector of those. A traderoute consists of multiple lines.
Each lines has the following:

• A city
• yields to unload
• yields to load
• min/max yields in city

The thresholds of a yield should be 3 numbers:

• minimum yields to leave behind when picking up
• max yields in city when unloading
• don't unload in city unless there is less than X yields

Transports can then be assigned to a traderoute. It will then visit all the cities in the order it is written in the list and load/unload according to the rules.

The city settings for import/export and threshold will be kept as it is for automated transports. The traderoutes will have their own settings, which will allow stuff like transporting lots of lumber in a unit from a forest rich area to a city in an area without trees. This city can then be used to distribute the lumber to nearby cities without transporting back to the forest area by accident.

We could add checkboxes to traderoutes, telling them to do stuff like

• use city settings for load/unload
• ignore order of cities

With city settings and ignoring orders, it would work as fully automated transports do now, except they will only travel to cities in the list. This will allow setting up trading hubs serviced with expensive units (think RaR trains) and then each hub can supply the local area without too much micromanagement.

Another way to reduce micromanagement is if it has the ability to add yields like "all raw materials", without having to set each individually.


If this is made, it will be post next release. Currently CivEffects is done (mostly anyway), but it needs testing and bugfixing.

 

that sounds grand to me!

 

The game concept for the coding task? I think it applies to both, which is why it will not be done before a release. However based on experience, the only part of this, which could be a technical issue is transmitting a string on the network. This mean naming traderoutes could be a bit of an issue. The rest is copy paste of existing concepts and it should work with savegames and stuff just fine.

Maybe we should consider what to call traderoutes. We have vanilla routes, this concept, Europe screens and the units, which automatically sells to natives. All of them would be some sort of traderoutes and we need proper naming to make it clear precisely what we are talking about.

 

Sorry I was using the term grand to mean good.

What about just using a prefix letter

traderoute or trade
+
Vtraderoute (Vanilla)
E(Europe) or F(Foreign) or S(Screen) or A(Auto) or O(Off Screen/Map)

Yours might be L(List) or P(Plan/Planned) or something like that..

The units would be traders or tradeunits or transports or peddlers (depending on what unit you mean and in what context)

 

Just one remark:
RaR_2.3 (never installed 2.4) has a little bug regarding transports: say, your target city (T) will collect a certain yield up to an amount of 200. You have 2 or 3 supply cities (A, B, C). Now it can happen that the cap is met with the second transport (from city B) and then the trensport from city C arrives.
It will not unload the transported good, which is a correct behaviour at first glance.
(In RaR, the transport will finally try to deliver the not unloaded yield to your main harbor, which opens another can of worms).
Now, what shall happen with the transport and its load? Waiting at T, going back to C or what?

From Nightingale's description I was not able to identify the expected behaviour in such a case.

Actually, I was planning to change the behaviour in such way that (can't motivate myself to mod at the moment):
a) the yield will always be unloaded in the target city
b) in case of surplus goods in the city the cheapest ones ("cheap" in terms of the least needed one) will be scratched first, and so on

I have been thinking about this and have never been able to come up with any other idea which would cause less trouble for the player.

 

I'm thinking something like the amount of yields on all transports combined can't exceed the combined demand. In other words, say there are two cities, each set to gain at least 100 lumber and never more than 200. They have 80 each, which mean they should get more delivered. All the transports combined will not be able to carry more than 240 as this is what it takes to fill both cities to their limits. This should prevent loading 600 lumber into the transports and then have nowhere to unload.

I'm not sure it's the best solution though. Performance might be an issue and it might be a hassle to set up with the game GUI as well (micromanagement).

Also if the transports takes the same circle around your cities to gather all the raw materials, you will fill each with the first two resources and then the next can't get rid of whatever they are producing. This mean for this to really work efficient, it should be able to handle mixed cargo transports like DoaNE.

I'm not saying that I solved all the issues. I wrote what I had come up with for the forum to remember and other people to start brainstorming on how this can be done best.

 

I'm no expert on the transport system, but Night's idea seems to be an improvement.

In regards to the mentioned issue, we could store delivery info somewhere. If an transport is headed to a city, then that transport's manifest could be recorded somewhere so that the City knows how much and of what good is currently targeted for that city. That way each city knows how much of each good it has incoming. If there is enough incoming to satisfy its demands then it will turn off imports to prevent other transports from targeting that same city and good.

There would need to be code added that allowed the incoming transport to still unload their goods once they arrive because if imports are turned off when it arrives it probably wouldn't unload. A simple variable that told the transport to override the import setting would all that would be needed perhaps.

There isn't any code that does this already? Its like real life, if you ship a good to a port that fills the port, the port won't order anymore. When the ship arrives it still unloads. So, if a city needs 120 Ore to fill its quota, it puts out an "order" for 120 Ore. This is simply done by selecting to Import Ore. When a Transport loads 60 Ore intended for that city, the City records that it now has 60 Ore in transit. If 60 more Ore is then set in transit, it turns off Imports.

On another issue (if it is an issue) we could have a Minimum Load attribute added to Transports as well that players can set. This would be to prevent a Transport from delivering 4 Ore, when the next turn the City will produce 30 more. Thus instead of leaving to deliver the 4 Ore, the Transport waits until it has the Minimum amount before leaving.

 

That's besides the point. Vanilla works ok for small empires and feeder service expands on that to handle mid size empires too. Still the automation can't handle the concept of distance or inter-region transport very well (to some extend, not at all).

This mean a brand new system, in which case knowledge of the existing system is less important. In fact lack of knowledge could be beneficial in the sense that it will not pollute your mind to think "this is how it's done". Knowledge of logistics could be beneficial though.

That's good and bad at the same time. If the transport service 5 cities and wait 5 turns for it to reach the minimum, the other cities might overflow in the meantime. While we should design a system, which will not have to rely on a setting like this, it could be useful in some cases. Imagine having two clusters of cities and then a traderoute linking those two. You only have one ship and it takes several turns to make the journey. Adding a restriction to fill at least X% sounds reasonable. It sounds even more reasonable if the concept of non-free fuel is added. However a single ship like that wouldn't be too difficult to control manually... maybe not the best example.

 

Then perhaps in that case the transport "monitors" the yields in storehouses... if a city that Exports has enough to fill its minimum load it leaves for that city. Of course there cold be some advanced formula for things like turns it would take and such.

Another idea I had on this is to have advanced Transport features unlocked through technology. These days its not an issue to be able to, for example, tell two transports to leave from different cities at the same time and how much they should carry, but back then it would have been a much greater challenge. If a shop had an unexpected shortage of a resources it could be days before another storehouse received word there was a shortage.

Anyway, so certain technologies could allow for such advanced transport operations. Even messages by pigeons (or ravens if you are into Game of Thrones) would be an advance that would help businesses in their logistics.

PS Speaking of Game of Thrones, M:C needs an GoT mod mod

 

there was a civ mod that did GoT.

 

I don't think making automation options unlockable with CivEffects is a good idea. While it sounds great on paper, I fear it ends up being annoying.

What automation should be:
Do boing repetitive tasks the human player could do if he has way too much patience. If a player can see that a city lacks 10 ore, then the automation can see it too. If buildings are only supplied with input resources using manually controlled transports, then people will just turn off automation, in which case we can save a lot of time by not coding it in the first place.

Making stuff regarding yield transportation unlockable sounds good, but it needs to affect automated and human controlled transports alike.

Sure it's historical correct that communication sucked until fairly recently. However I don't see a way we can implement this in the civ4 engine in a way, which aids to the game.

 

The other part to remember about this level of 'realism' is that one turn is 1 or more years anyway, so the 'slow' pace of life is already reflected in the 'time' it takes to do one turns worth of 'stuff'.

It would make more sense that certain yields cannot be moved until certain techs are unlocked, or something like that, if we wanted to go that way. So if you wanted to do something with stone in the beginning you would need to have a source of stone in the city. Something of that nature. Until you unlock 'stone moving tech' or whatever scenario you would want to invent.

Other than that I think those kinds of 'automation' limitations because of time, space and technology are better represented by new buildings, vehicles, prices, storage capacity, etc. or in regards to the future of random events, having technologies, etc. that unlock new options that were not available before, like 'send word by raven that winter is coming and have a large shipment of grain sent to avoid a famine'. That kind of thing.

So that a larger, or better regulated 'years worth' of stuff gets done more effectively and more easily/efficiently due to the introduction of better communication/logistics/transportation/economic technology.

Automations will be handy for the future if we bring back population consumption/demands and the like, so that a set of transports can predict what they need to 'buy' and 'sell' in the various locations on their route.
With the ability to designate certain towns as 'hubs' and such so that if a transport does end up with 'left overs' or something it can go and drop it at it's designated 'Route Hub' or whatever so that you can then sell that to foriegn or off screen markets.

Or something of that like... I am trying to figure out ideas/ways that would be beneficial as simple automated options that do relatively simple 'math' tasks so that the player doesn't have to. Like making sure that every town has enough supply to last for the full length of the trade route.

By that I mean if it takes 8 turns to complete a full circuit of the particular route, then it will take all of the consumption for a turn(for/of each city), times it by 8(number of turns of route length) and then try to deliver(across all transports in the route) that number of every consumed yield.

All with a few button clicks.

Does that make sense?

 

We don't have to "bring back" population consumption as this code is still in the DLL. It's just not very active due to XML setup. Also I added that feature to set import threshold to X*(number of yields consumed by buildings each turn). You can then set the X in the top of import/export. I can't remember offhand if it handles population demands or just building demands, but it could be extended.

I too have been thinking of not allowing all transports to transport all yields and possibly add CivEffect tags to unlock transporting specific yield types. We talked a few times about mixed cargo and it would also be possible to make CivEffects, which adds +X capacity to each slot. There are plenty of interesting options for this, but I will not mix it up with transport automation. Instead it should be separate implementations for humans and then it should work for automation simply because it's forced to follow the same rules.

As for leftover cargo in the transport: I was thinking something like declaring a specific city as "sink". It will work like a hole all transports can dump everything into to make sure they are empty. Perhaps it would make sense to make a sink setting for each yield, making the export city the sink for everything except ore, which goes to the tool factory city instead. I think it would be best to make the trade system (once I get that far) and then consider fine tuning features like this afterwards. The design should be somewhat modular to leave room for easy expansion as it will never be done. This goes for everything, but particularly here since it's a new class design and not expansion of an existing one.

 

yes what I meant by bring back was from a game play perspective, along with some motivating factor as to why you need to meet their piddling demands!

SHUT UP AND GET BACK TO WORK SCUM!!!!

Yeah I remember we have the XxConsumption setting already, I ws just trying to think of helpful bits of 'automation' type maths.

I was just thinking in terms of if there was a screen system or something, a plan route system. If it could calculate the number of turns it takes to complete it's route. (I have been playing Grand Ages:Medieval which shows how many 'weeks' a route takes, same with Partrician and Port Royale) Anyway..

IF the route system could in someway reference the 'length' of it's route, then a useful auto button would be something that sets the 'stock/consumption' turns to that number of turns.

Was just thinking out loud.

Yeah some kind of Dump/Hub/Sink setting would be useful, to allow a transport to 'clean out' rather than get gummed up with an over produced resource.

 

That would be great.... in theory. The problem is how to get those numbers for real. The time it takes are affected by which unit is used for transport, road construction (how often to recheck without slowing down the game) as well as completely unpredictable issues, such as wild animals. On top of that, how to handle if more than one unit serves the same route? Even worse: one is faster than the other.

Perhaps we could go another way. If it knows it has to deliver 12 units of lumber each turn, it picks up 12 units of lumber each turn. The number of turns in transit will then not matter. Transit time would matter of how responsive the system is to change though.

However I would rather have some sort of system where cities can tell how much they demand of each yield. Looping units on the traderoute can tell how much cargo is already in transit and this combined can be tell how much to pick up. Presumably caches would be needed to make this work fast enough, but the general idea would be the same.

The number of turns to store for.... why not solve this on a city scale? The city can record a history of imported yield shortage and if it is frequently experienced, it will try to increase the number of turns to store yields for, possibly with a number for each yield rather than a global for all yields. The trade route will then not have to consider transit time. The city will demand just tell the trade route that it accepts more.

We could also try to keep this simple and see how well it works before it gets so complex that it is never coded.

 

pheow this all sounds complicated

I too agree constantly fiddling with local Wagon Train / Peddler scheduling can get tedious fast, so anything that can ease that burden is welcome (especially if it helps AI players be able to transport/produce and be more effective opponents).

I think the biggest improvement for local domestic trade would be to take advantage of the Plotgroup mechanic to enable Yields to be shared within a Plotgroup for completing units/buildings and fulfilling domestic demands. This could be a selectable Game Option for those that want it (could be good to enable AI player Plotgroup use at higher difficulty settings to make it a much better opponent), or it could be unlockable by some transport or economic techs.

It always puzzled me how a grand strategy game where you play a national leader or feudal monarch can devolve into near full time duties as Wagon Train Scheduler Anyway since M:C has special Trade Screens, it strikes a good balance to let day-to-day local commerce be automated/laissez-fair while still allowing you to launch special Peddler excursions to exotic Trade Screens from time to timewhen the situation calls for it

 

I wonder if one possible idea for how often it checks for new data/roads/vehicles/blah would be a button, like an update button. So if you know you made some significant changes you just go in, click the button and it just runs 'the math' and updates what is needed.

For the demand situation, maybe it would just check at onbuild or onjoin (or whatever they are) in a city, so if the pop increases it checks, and if something is built that would increase demand, it checks.

Then when you upgrade your vehicles or road types you just have to click a button for your route schedule (Maybe a check all routes button somewhere) and it runs the update check.

For AI it could perhaps just run it every X turns. Potentially with X being something of a difficulty/performance setting so if things are too slow you increase the number.

Some thinking out loud.

 

I think Nightingale is on the right track.

The whole game is about cities. Without cities no collecting of raw yields, no production, no food, no money, no nothing.
Transportation obviously is about cities, too.

The logical place where the needed calculations have to take place is in city management which is called each turn anyway (and a lot of times intra-turn, too). All a transport has to know is which cities it has to visit, the sequence of the visits and in which of them it has to load/unload.

Each city A should know which other cities B, C , D ... are in the same area (land transport) and if and how many goods any other city in that same area needs from A and when. Additionally (and I think, plotgroups make this calculation even easier) it should know how long it takes from A to B or C or D.
These information belong into an array or vector and then are retrieved in the moment in which the transport loads/unloads.

In addition each city should hold a vector about goods planned to be delivered to it with yield, quantity, transport ID and ETA (in turns).
Having all this the calculation of planned transports shouldn't be too time consuming anymore. It is just quite some effort to set it up properly.