Author
Topic: Optimizing cargo chaings (Read 5981 times)

I say that a cargo chain is optimal, if at all times, there is always at least one industry that is producing. I know it's not that simple for more complex networks, but let's stay with simple ones for now. For example, the simplest is a coal mine and a power station. If I can transport at least as many coal as the power plant can consume (given that usually a coal mine can produce much more than that), then it will always be working, making the chain optimal.

Here is how it happens. Until the buffer in the power plant gets full, the coal mine pumps out as many coal as it can. If I have enough transport capacity, the power plant's buffer eventually becomes full, at which time the coal mine stops putting its products on my station. When the power plant's buffer gets below maximum, the coal mine dumps all its buffer to my station and I can start transporting again. This way the transport is done in bursts, but it is perfectly acceptable, as the power plant is constantly running at full capacity. It would be really hard to transport just the necessary amount of cargo anyway.

I get to problems when the distance between a producer and a consumer industry is too large. The problem comes up when transporting the cargo from the producer to the consumer takes more time than it takes the consumer to empty its buffer. This is what happens in the previous example. Once the power plant's buffer goes below maximum, I start transporting. But by the time the first bulk of cargo arrives, the power plant's buffer is empty and it's not producing anything. So even though I can transport as many cargo as required by the chain, the industries are not at full capacity.

This happens especially on large maps, and when I use sea transport (ships are very slow). Is there any way to mitigate this problem?

It basically tells suppliers to produce supplies at the same rate the consumer consumes them, thereby avoiding the start-stop production with huge bursts of goods that you find bothersome in JIT1. Use the forum search.

I wonder, how many are using JIT2 in their games on a regular basis? Probably not many casual players that don't frequent this forum, as the setting is rather obscure, but what about more active players who indulge in add-ons and whatnot?

I haven't yet, because I'm still a bit sceptical about switching in mid-game, and I don't play much Simutrans in long periods, only have one game going at a time, play for over 100 in-game years and do not use fast forward. So I'm still in a game from just before JIT2 was introduced (started about 1830, currently around 1945, expect to play until 2000 or even 2030).

JIT2 really was meant to completely replace JIT1, just some devoted players want JIT1 mechanics still so it had to be hacked in so that both are supported. Since no paksets are actively maintained none of their authors updated the settings to use JIT2 by default instead of JIT1. One must explicitly opt-in to JIT2 unfortunately.

I don't think no pak sets are actively maintained. (Maintenance doesn't mean having lots of changes done, that is development.) But there might be a chicken-and-egg scenario going on. No pak set wants to enable JIT2 until it is thoroughly tested, and no one tests JIT2 because it isn't default.

I did not like the idea of JIT2 of a more regulated flow. Imho it is the task of the player to ensure that. Overcrowding and its avoidance are for me part of the play challenges (not least since I am playing simutrans since 2001). So that was a deliberate decision to has JIT1 for pak64.

Other paks (especially pak128) have much more unbalanced industries (with storage sometimes in the 32000 ranges) which would profit more from JIT2.

If only industries respected the maximum distance setting in all cases, not just when spawning new industries. Maintaining an even flow when there is over 1000 tiles from supplier to consumer is almost impossible. Maybe if that line was the only thing I had in the whole game. Passengers and mail give me enough overflows to handle.

Although there is something that I've been wondering: has overflowing goods at the source stop stopped giving warnings?

I tried JIT2, and generatlly I like it. Things work much more smoothly than with JIT1. However, I have a problem when the capacity of one train is higher than the input capacity of the consumer industry. It will swallow all the excess cargo (meaning that its buffer will be topped off at its maximum storage value) and its counter will be decreased by this same excess amount. This means that it gives me double penalty for overloading, decreasing the total transported amounts and also running out of buffer (the latter only being a problem when it is also a producer of some other goods).

For example, in pak64 gas stations have an input buffer of about 100. To carry less than that by train, that would mean each train pulling one wagon, which is very inefficient. I could use trucks, but they are also inefficient. I tried switching to trucks at the end of the way, hoping that they will stop hauling from the station if the input buffer is full. They don't.

Pakset authors were meant to raise the input storage amounts to be appropriate for the type of haulage. No one did... It works reasonably with Pak128 due to the much larger input storage on most factories.

Eventually I plan to revise the system such that input storage does not really matter. After some online testing it was not working out as intended as it was frustrating people more than being a good game mechanic. The problem is, and will always be, how to burn off excess cargo that builds up due to bottlenecks once it arrives.

I rarely deliver gasoline by train directly to gas stations (or most city industries). Trains unload at a freight terminal, and one or two trucks take it from there. Early on there might be even a bit more trucks, as they have lower capacity. Sometimes, a greater distance, or multiple nearby gas stations, mandates more trucks as well.

(There are three reasons for this. 1: A typical train station looks huge compared to a gas station. 2: Gas stations don't usually have stations in real life. 3: I might have to demolish lots of stuff to get to the gas station, unless I "cheat" with underground or elevated railroads, the latter of which can look stupid by itself in interaction, or rather lack of, with buildings.)

I think that the intention was to motivate (force) players to use appropriately sized convoys for supplies. Even in real life, gas stations are supplied by trucks. If even the truck has bigger capacity than the gas station input, then you have to use one truck to supply more gas stations. JIT2 is good for that too.

I agree. There should be some kind of mechanic that benefits a steady flow and punishes use of oversized vehicles. Just having low input storage does that, and should achieve it. The problem really is that currently, the behaviour seems like it's bugged, and the player does not know how to fix it or does not like the solution of 'just using smaller vehicles'. Perhaps somehow, a 'steady flow' could become important in other applications (I proposed in-station-stores as the flavour coverup), so the player would be more aware of that concept.

As I said, I tried to use trucks, but if there is cargo on the station, they won't respect the overload of the gas station. So basically I'm back at JIT1 where I have to delicately balance the transported amount or there will be disruptions in utilization. It is practically impossible to transport just the right amount of goods without some kind of scripted scheduling. Which, by the way, would be a nice feature.

I rarely have more than one gas station near enough to each other that the vehicles will not operate at a loss due to going more or less half-loaded between the first and the second. I don't see how scripted schedules will solve this particular problem. The only solution to not waste goods and not overfill the consumer, is to have the vehicle wait until it is fully unloaded. That is something new. As it is now, there is little need to scale stops/platforms where only unloading takes place, as there the vehicles quickly leave again, but this will then no longer be true. On the other hand, having the vehicles wait will not encourage use of the right kind of vehicle, unless a loaded vehicle costs more than an empty one, even when not moving.

Scripting can help in many ways, since then scheduling can be controlled arbitrarily. For example, having trains haul the fuel to a station near the town, then trucks carry it to the gas station. With scripting, you could tell the trucks not to leave the station if the gas station's buffer is above a certain level. If station overloading ever becomes a problem, then some additional scripting can help make the trains not to get stuck on the station waiting to be unloaded.

Having full wagons cost more than empty ones seem to be counterintuitive to me. However, I can imagine adding a monthly costs to vehicles in addition to running cost per km. For example, passenger trains and planes only operate cost-effectively if they have high utilization (unlike buses and trams, which can afford lower utilization), so you can just build a lot of them and have them wait until they are full and not care about them as your passenger network is expanded. The only additional cost is the maintenance of the extra station space to accomodate the waiting vehicles. With a monthly cost, that behavior would be discouraged in favor of taking care of having the right amount and right size of vehicles.

A big problem is Simutrans has no real simulation of fuel economy. In real life a lighter convoy will use less energy/fuel to move between points than one fully loaded despite being the same length. This would mean a fully loaded coal train would use more fuel (cost more) getting to its destination to unload rather than returning from it. The difference is non trivial as well, especially with coal trains where the fully loaded weight can be several times more than the empty weight. In Simutrans it costs the same.

A big problem is Simutrans has no real simulation of fuel economy. (...)

How does that affect this particular issue? I can see how it would affect gameplay, as players might be less encouraged to have vehicles be loaded in both directions if the empty trip back was cheaper than it currently is. Though would that be a good thing? Seems to me it would make hubs and network planning less effective compared to point-to-point connections.

If you wanted fuel to affect convoi size, you'd need a non-linear scale. Instead of each wagon just having a fixed running cost, it would affect how much fuel you need, but with each wagon, it costs more. This means the optimal convoi size is not always the longest convoi that can still move on full speed, but a shorter one with much less fuel cost, and if you have an even shorter convoi, it would have less of a negative effect. Hence convoi size is more likely to be chosen by what you actually need. Though it seems to me that would be very hard to understand for players, and would fit better with extended.

Scripting can help in many ways, since then scheduling can be controlled arbitrarily. For example, having trains haul the fuel to a station near the town, then trucks carry it to the gas station. With scripting, you could tell the trucks not to leave the station if the gas station's buffer is above a certain level. If station overloading ever becomes a problem, then some additional scripting can help make the trains not to get stuck on the station waiting to be unloaded.

I just never imagined giving schedules access to the industries, just the stops.

Having full wagons cost more than empty ones seem to be counterintuitive to me.

My basic idea was that a loaded vehicles needed to be manned. With empty vehicles, one could send the driver/conductor home or to do other work. It is more realistic for valuable cargo and passengers, which has to be guarded and served respectively, than for very plain cargo like gravel.

players might be less encouraged to have vehicles be loaded in both directions if the empty trip back was cheaper than it currently is.

The empty return trip would not generate any income, so unless the cost of shipping the cargo is greater than the income, having the vehicles loaded in both directions would still be beneficial. If it is, sending the vehicle empty both ways would be the best (except not having the vehicle at all).

A big problem is Simutrans has no real simulation of fuel economy. In real life a lighter convoy will use less energy/fuel to move between points than one fully loaded despite being the same length. This would mean a fully loaded coal train would use more fuel (cost more) getting to its destination to unload rather than returning from it. The difference is non trivial as well, especially with coal trains where the fully loaded weight can be several times more than the empty weight. In Simutrans it costs the same.

If you wanted fuel to affect convoi size, you'd need a non-linear scale. Instead of each wagon just having a fixed running cost, it would affect how much fuel you need, but with each wagon, it costs more. This means the optimal convoi size is not always the longest convoi that can still move on full speed, but a shorter one with much less fuel cost, and if you have an even shorter convoi, it would have less of a negative effect. Hence convoi size is more likely to be chosen by what you actually need. Though it seems to me that would be very hard to understand for players, and would fit better with extended.

I think vehicles in Simutrans usually go back and forth on the same stretch, so the running cost could be seen as the average of the fully loaded and empty running cost, including fuel consumption. (Vehicles for passengers and mail may go in a more circular fashion, but then they also stay somewhat loaded at all times.) It doesn't quite hold up, as it might be mostly up-hill one way, and the per wagon fuel cost is the same whether the locomotive is steam, diesel or electric. Simulation of fuel cost probably would not affect train length. Nor do I think that is a major influence in real life, beyond the cost for the fuel used for moving the locomotive itself having to be covered by the profit from the following wagons, which is kind of already in Simutrans.

To the scripting suggestion. I think that scheduling already present in extended should be enough. Just divide the gas station consumption by truck capacity and set it to depart only x-times per month.

The empty return trip would not generate any income, so unless the cost of shipping the cargo is greater than the income, having the vehicles loaded in both directions would still be beneficial. If it is, sending the vehicle empty both ways would be the best (except not having the vehicle at all).

Sure. But currently, the empty return trip costs just as much as the full trip. Hence if you could fill the vehicle on the way back, you can double the income with no extra costs. If an empty vehicle had only half the running cost (to keep things simple), the empty way back would still cost money. If you fill the vehicle on the way back, you still double your income, but you also add 1/3 in costs, which is beneficial, just not as much.Usually, to double-fill a vehicle, you need to utilize hubs, which means taking a detour. In some settings, a detour does not get paid. So using hubs is a balance between the benefit of double-filling vehicles and the drawback of having a detour. If the benefits are reduced, the balance shifts, and hubs become a bit less profitable in comparison to direct connections, hence there will be less situations where they are the right choice.

Simulation of fuel cost probably would not affect train length. Nor do I think that is a major influence in real life, beyond the cost for the fuel used for moving the locomotive itself having to be covered by the profit from the following wagons, which is kind of already in Simutrans.

It does affect train length if you model it to affect train length. To make it simple, let's say a locomotive has a base fuel consumption value, and each wagon multiplies to that value. Let's use a rather high number for larger affect - we multiply by two.If the locomotive alone costs X for fuel, the same locomotive with 5 wagons would cost 32X for fuel, about 6X per wagon. With 6 wagons, it would cost 64X fuel, about 10X per wagon. If a full wagon would generate 8X income, you could have a train with five wagons and make a profit, while a train with six wagons could never do that.The difference is huge if you double the fuel cost. Naturally, the multiplier would be more like 1.4 - 5 wagons would cost 5,38X fuel, 1.08X per wagon; 6 wagons 7.53X, 1,26X per wagon; and 7 wagons 10.54X, 1.5X per wagon. So with each wagon you add, you have to pay more per wagon, earning less per wagon. But on the other end, you have the existing mechanic of paying the locomotive with income from the wagons which becomes less per wagon the more wagons you have.So you don't want to have too many wagons and you don't want to have too little wagons, there is an optimum of wagons somewhere in the middle. And the more you diverge in either direction, the less profitable your convoi will be. This is different from the current concept, where you want to have as many wagons as possible until you hit the rather harsh limit of getting slower. Sometimes it might even be beneficial to have a convoi that can't even reach max speed anymore.

If the goal was to shorten trains, you might as well change the power of locomotives. But that would be a hard limit. With such a fuel concept, it would be a soft limit - which are arguably better, as they provide model railway players more leeway in doing something besides the intended (for a cost) and 'power players' more options to optimize.

Whether it has anything to do with how fuel works in reality I can't say (I know it would work somewhat like that for speed - the faster, the more fuel you need. Is it the same for weight?)

I would expect wagons to add to fuel consumption, not multiply it. And empty wagons would use less fuel than the full ones. Although the formula probably isn't simple. When going down hill, they would not add to fuel consumption. With electric trails, fuel consumption could even be negative. After going down hill, heavier wagons may still reduce fuel consumption compared to lighter ones due to inertia.

And I rarely get both way utilization of freight vehicles, because the flow isn't balanced and very hard to predict. I don't want the vehicles to run empty, but I can't have them wait on either end either, because there might be goods waiting on the other end.

Trying to be overly realistic is not always beneficial. It adds much complexity to the code, in turn the game would be more difficult to balance out well, but would have minimal impact on actual gameplay. Just think of Dwarf Fortress. I think having different per km running costs for full trains might be a good idea, but I would approach it differently. Add monthly maintenence cost to all vehicles, remove per km running costs for wagons, and make the per km running cost of engines depend on total weight. I think that would be realistic enough without adding too much complexity. It would still require completely redesigning the paksets, though.

About scripting. In real life, transportation of goods is planned exactly considering the actual transport contracts. It is quite inconcievable, given the transport company has enough capacity, to be holes in the supply chain. Goods may be late if there are unforeseen traffic events, but it would be weird for the buyer to have distuptions in its production because the transport company transports too much goods at a time. Even with the simplified economy of this game, writing a general purpose for this is really hard, as there are so many things that needs to be taken into account. JIT2 tries to work on the problem, but sometimes even its approach falls short. With scripting, more tech savvy players could write scheduling algorithms that works specifically for the situation they just encountered. Less tech savvy players would have to live with what JIT2 can provide, but that's OK if there is an option to disable scripting for multiplayer games. And I didn't mention that there is no way for the player to prioritize traffic. The current signal system only allows the vehicles to look ahead, and never behind. This means that it's impractical to sent trains with different speeds on the same track. In real life, cargo trains stop at stations on a side platform when a passenger train approaches, which will use the straight path to pass the station (especially if it is not scheduled to stop there). Let's say a new game feature is introduced implementing just this. Add train priority, lookbehind signals, and whatever else you need. All is well and good, then cue the next forum post like this, someone complaining that "I can do this and this, but I can't do that so my transport route behaves weirdly". With scripting, all of this can be left to the player's imagination. At worst, everything will go on as it is now if someone chooses not to use scripting. At best, there would be some lovely stories of how efficiently someone solved some problem with scripting.

The problem with prioritizing trains is that the time a train has to wait to be overtaken, will typically be a rather large part of the total journey time. In addition, by the time it starts running again, it will be in the way of the next express train. Which is ultimately another consequence of the different scales in Simutrans. On really busy lines, the distance between trains may be shorter than the length of the trains. (The default signal spacing is just two tiles, which I assume is for a reason.)

The problem with prioritizing trains is that the time a train has to wait to be overtaken, will typically be a rather large part of the total journey time. In addition, by the time it starts running again, it will be in the way of the next express train. Which is ultimately another consequence of the different scales in Simutrans. On really busy lines, the distance between trains may be shorter than the length of the trains. (The default signal spacing is just two tiles, which I assume is for a reason.)

I tend to play on rather large maps, so my railways can span long distances. Without any method of overtaking, it would be unwise to transport both urgent and non-urgent cargo on the same line. Passengers are less of a problem, as I tend to use planes for such distances. Besides, it's just an example why scripting would be useful. Your reasoning actually supports this, because this overtaking method is only useful for a few cases, so a dedicated feature would not be practical. But with scripting, it becomes possible. Other players may find other good uses.

I would expect wagons to add to fuel consumption, not multiply it. And empty wagons would use less fuel than the full ones. Although the formula probably isn't simple. When going down hill, they would not add to fuel consumption. With electric trails, fuel consumption could even be negative. After going down hill, heavier wagons may still reduce fuel consumption compared to lighter ones due to inertia.

If you want to be realistic, additional fuel would not be required on flat ground once the vehicle reaches max speed. At least not because of weight, the deciding factor would be aerodynamics.For a simulation, accuracy with these kind of things might be important. For a game, you'd have to tweak it to become important.I don't think weight is additive, each engine has probably a setting where it is most efficient. Pretty sure a rig without trailer wastes fuel simply for having too big an engine, since it's made for much more weight. Same for using a heavy hanger with a small car, even if it's able to carry it, it's probably not efficient. My proposal is not aimed at realism, as it's too complicated to simulate realistically.

It's a gameplay thing. Ever played City Skylines? To provide electricity to the city, you build power plants. But you can also adjust the funds for the powerplants. 100% payment means 100% electricity; 200% payment means 150% electricity, 50% payment means 25% electricity (or something like that). Obviously, staying at 100% payment is ideal, but not always possible.I think the same concept should apply to trains, where there is an ideal amount of wagons, while both more and less wagons can still be profitable, just not as much.In older Simcity games, you also have to provide electricity. But you can only build power plants. So, whenever there is a shortage, even if it's just a tiny bit, you build a new plant. That's similar to how currently, you'll buy trains and attach as many wagons as you can without the max speed dropping. If that's not enough, you can't really add another wagon, you need a second train. But it's usually no good to make that train, or both trains, shorter, the ideal play is usually to make two trains of max length, make them wait for load, and just let them pause eventually, as having the big trains standing around doing nothing does not cost you (yet), while shorter trains make less money all the time.It seems to me that fuel would be a nice coverup for such a mechanic, even if not completely realistic.

Trying to be overly realistic is not always beneficial. It adds much complexity to the code, in turn the game would be more difficult to balance out well, but would have minimal impact on actual gameplay. Just think of Dwarf Fortress. I think having different per km running costs for full trains might be a good idea, but I would approach it differently. Add monthly maintenence cost to all vehicles, remove per km running costs for wagons, and make the per km running cost of engines depend on total weight. I think that would be realistic enough without adding too much complexity. It would still require completely redesigning the paksets, though.

Exactly, realism should not be the driving force, it's a tool to make a gameplay concept understandable via real-life expierience.I would not remove running costs for wagons completely, since a moving wagon will wear down quicker than a standing wagon, requiring more little repairs and maintenance. Though engine running cost depending on weight is an obvious choice - I'm shocked I did not actually write it and only went for a simplified per-wagon-example only. The real question is which formula to use - it does not need to be linear, and it does not need to be the same for each engine type either. But in general, that would be a gameplay option dressed in realism for immediate understanding.