#openttdcoop

As some of you might have already noticed, the last psg was a bit different from the last ones. In this article/review I would like to look inside and examine, what has been done differently to make it special. Also, I am going to check how the refitting works and what it causes, how we solved it, and what flaws I noticed.

The Refitting

For those who didn’t play this game or want some explanations of this network mechanics caused by our cute multifunctional trains I will make a few points here to introduce this technique: Let’s just imagine a train … it picks up wheat, goes to the food plant and drops it. Now we let it refit to food and go to the food pickup. The important thing to note is that food does not produce in 1:1 ratio compared to number of delivered wheat. That way we can not set the full load order in the food pickup. So the train comes, and loads what is available. Now because this is quite random, it could also load almost, or completely nothing. For this we had a conditional order, where the train that wasn’t loaded at all, returned to a refit center, refitted back to it’s original primary cargo, and returned back home to the primary pickup. Because we think trains under 25% load are also quite inefficient (!!! not in terms of money but in terms of network throughput), we added a conditional where the trains would drop the goods/paper back to the pickup, if they have loaded only <25%, and then refit in the center and go back home. One note: UKRS trainset is the only set I know able to refit to all cargoes producing goods/food in arctic and temperate environment, so I recommend it :). And here goes our order list of wood trains:

“Similarity” to psg 179

In the very planning stages of the game, I’ve heard some comments like ZOMFFFG! Refit game again!… Let’s look at it a bit more closely. The words obviously pointed at game 179… if we put these two games next to each other and compare them, what do we get? First of all I would like to say that I consider refit orders just a way how to play, just as for example srnw, or some other stuff that modifies the whole game playstyle. Therefore, I think it is pretty fine to use it more often because it is fun :). The psg179 was a game where we basically tested refitting for a bigger network and more cargoes for the first time. The network structure was a ring, which seemed to be quite inefficient for a refit game. Why? The refitting makes some connections a bit different…

Here we have a map of game 179. Let’s focus on food line (red/yellow). This line represents the path of ALL farm trains. Simply because trains serving farms in the east go there too, not only the western ones. On the other hand, eastern and western trains return back to farms by their own routes (white and purple). That way, the food line tends to be overloaded with trains, which I consider a plan flaw, or we need to be aware of expanding only some directions, like LLLL_RR for example. Why not just use LLLL_RRRR? I consider that wrong because the space we use for building anything on the RRRR can be reduced if we keep just RR. And otherwise, I like when tracks are really busy, preferably all of them to reach maximum traffic spread and therefore maximum network capacity.
Just out of curiosity: look how paper trains go. (green-blue-yellow, returning on the purple one) These just move on one part of map, using both L and R, therefore not breaking anything :). And now one funny thing: because we didn’t have that many farms connected, the food trains issue didn’t cause anything bad.

This could be an issue and it would be good to solve it somehow. Here are a few solutions I came up with:
Firstly, LL_RRR antisymmetric network – as discussed above and also:

Creating more than one town drop

This idea seemed better to me when planning for a organic network fit in the mountains, so the trains return to about the same place they came from. At this point you can think I am BSing you greatly, because even the plan itself had LL_RRR and such in it. That was mainly caused by the wood-paper loop. Because this is a three-cargo refit, the paper trains just ignore the split of traffic into 4 town drops… that way they would create one stream of trains that just goes from the paper mill to printing works. Yeah, of course … they did! But still, the trains kept on their loop.

Wood-paper-goods Train Routes

First off, let’s take a look at the wood-paper-goods trains loop. (green-blue loop) The bold line shows shared track of ALL wood trains. All trains go there, and just add the route towards goods drop (green), returning back to the forest (white) and going to the loop from the forest (green). Also note that there are a bit different paths of trains when trains don’t get 25% or more load (they return to the primary right away). If you imagine that here, you can see that they just cut out the goods drop, but they keep their paths L_R symmetric! All of this works the same for all town drops and sidelines, so I will not show any other examples.

Exceptions are the green and blue marked areas. From these areas (connected to SLH 02) wood trains have to go all around the loop to drop wood, then they go to drop the paper, and after that they don’t have to go towards BBH03 again! So the only place where we could say we have “unexpected” trains is between SLH 02 and MSH 02. That way they act differently, but nothing really serious because it really wasn’t significant in this high other traffic. This “problem” applies only to the green area because there were no forests in the blue one – that one is just theoretical, if there were)

Farm-Food Train Routes

The farm-food trains worked a bit differently, thanks to the fact that they didn’t loop around anywhere, they kept L_R symmetric network at all times! Which was just a very nice result to see. The only area of exception was the red marked area, from where trains just looped around – primary-loaded via the bottom of that area and food-loaded via the left of that area. Since there weren’t many farms connected here, it wasn’t really significant. (Note: I will not examine the oil-goods trains routes because these work similarly as farm-food ones)

Another influence of refitting is in train travel times. Of course in every game primary productions fluctuate a bit… but this time, it was actually pretty random how long do the trains go (because we didn’t want to make goods/food trains go empty to the town drop, we made them come back if they had less than 25% load of goods) this makes trains go just randomly long, and therefore also their count needed to serve a primary station fluctuated. This caused quite some issues on sidelines, occasionally jamming the whole SL just because there were too many trains at the moment. The solution to this was quite quick and efficient: building overflows.

A huge aspect of this game I would like to really stress is choice of trains. This game perfectly showed that we don’t need to use the fastest trains (as long as it has a reason!). In this special case, we have all seen that the AL-10 engine acceleration made everything much more comfortable. Also a funny thing was that we had to aggressively signal the diagonals to prevent slowdowns. Note that train acceleration doesn’t only affect the number of trains that are able to pack onto a line, but also shortens times of unjamming, possibly even preventing jams! (if the jam-likeness isn’t too high) This is the reason why we were able to beat the current train count record – 2000 trains from psg 131! 55 games old record, and additionally – on a double-sized map than this one.

Town Drop 04

There were multiple discussions on the topic that we should have sent coal to multiple town drops, not only 04. Just look around the map and tell me, which direction you would like to expand 😉 I think it was quite fine that we kept just the 04 :).

Bridges

Besides some errors like making unshared orders trains and on the other hand shared trains with trainyard, rather just a note I would like to say a few words about our building techniques in terms of bridges. In this game I found many bridges built like this:

This is a possible source of issues! First of all, this just doesn’t work unless you use the 2way and penalty on the other line! See what trains do, they really like to annoy you by choosing the second bridge instead of the first one, and of course the next train coming just jams there instead of choosing the first. This can be fixed by adding a 2way signal for the eol effect, and penalize the second bridge, so trains use the first bridge, if they can. Now look a-t it. It doesn’t save any space in total, it just saves a little space in the beginning of the bridges (particularly useful for SLHs when the point you care about is the beginning and the end of bridges is just any merge, as SL traffic tends to cope with it) But still there remains the other disadvantage, and that is impossibility to use presignals or PBS to make trains wait in front of bridge section in case both bridges are occupied. (most likely in some jam-time or just merge-slowdown – especially common on sideline entrances) Therefore I would like to kindly ask you not to use this type of bridging ever again 🙂 (if you check for these bridges in the final save, you will find these only rarely because they just failed and got replaced)

Conclusion

The rest of this game was quite normal… we just had fun with a lot of expanding network, complaining and bitching about lag issues, and getting angry on dumb trains, of course. Also because we all love numbers and stats, ODM brings us his fancy log statistics. [link coming soon] Thanks to everyone who participated in this game, it was really nice and I am looking forward to another one :). Thanks for reading and see you in the next game!