Building trains again and again might be a daunting task. Especially when you start making a lot of mining outposts, artillery/supply trains with filtered cargo wagon slots etc.
So I decided that we should extend blueprints to work with trains as well. The first condition was, that trains are only selected when you explicitly allow it in the checkbox, so they don't get in your way when building rail setups.
Checking the button allows the train that was there to be put into the blueprint (similar to the way tiles work). For the sake of simplicity, we decided that once there is any rail in the blueprint, the train in it will be always buildable (as a ghost obviously), even if there are not rails to support the train at the moment. The train ghost will simply stay there and won't be buildable until rails are placed under it in a way so it can be placed.
If I remove the rails from the blueprint, I get a second type of rail blueprint. In this case, all the parts of need to have rails to support it, this is mainly needed as without rails, there is no rail grid forced, so we should make sure, the train ghost won't be created in some wrong position.
The small touch here is, that the blueprint also contains the schedule. With little-bit of improvisation, I can optimize the mine building a lot in the late game. I create a blueprint of mine train station. The stop will be called "
Mine X".
Both of the trains in the blueprint will have the " Mine X" -> " Smelting" schedule setup. Once I build the blueprint, I just rename the " Mine X" to whatever I want (" Mine 12" for example), and the train schedules are updated as well, so I'm almost ready to go.
The last tweak I'm considering is to allow blueprints to contain the fuel insertion info similar to how they contain the module insertion info for assembling machines now.
When we showed it, the upgrade planner was Prototype ready, but playtesting uncovered various kind of missing tweaks, and as always the real usability is in the details. Especially since the mod already solves most of these issues, we have to at least be as good as the mod.
The first problem was, with underground belts. With the naive approach of just upgrading entities that are selected, it happened quite a lot, that I upgraded some belt area, but I didn't notice, that some of the underground belts have only one side marked for upgrade, so the belts get disconnected when the upgrade is executed:
This was usually discovered half an hour later when I was investigating the reason of some part of factory not producing. When it happened few times in a row, it was quite annoying... So the fix was, to make sure that the upgrade planner always upgrades connected underground belts in pairs if possible:
Part of the tweak is, that the robot upgrades both part of the underground belt as one action, so the items that are "flowing" underground don't have to be touched.
The next thing we wanted was to not only upgrade entities, but their also contents, so you can now specify module upgrades in the upgrade planner as well. (Please note, that the upgrade planner/blueprint UI is a work in progress, and this particular screen was not yet addressed by our GUI polishing process).
Another feature is to be able to upgrade blueprints with the upgrade planner. The upgrade planner mod could do it as well, but we will be able to integrate it better with our GUI.
You can immediately see, that another tweak might be to also upgrade the blueprint icons as well.
My thanks goes to galibert, who created the original pull request of this feature (giving source access to stranger sometimes helps us) and Rseding91, who fixed the technical problems and added the tweaks mentioned earlier.
It has been quite a long time since we described our latency hiding system in FFF-83. Since then, we have had to make a tough choice whether to incorporate a new interaction feature into the latency hiding or not as we developed it. With undo, it was kind of implied, that it needs to be incorporated in the latency state system, since you need accurate instant feedback of what you undid, especially when you are undoing few things in a row, and you don't want to do more steps by accident because of the multiplayer delay. Since there are more and more things in the latency state, and they need to interact with each other in a reasonable way, the amount of possible cases starts to grow, so we have to make sure that the corner cases are covered by tests more than in other areas.
Let me present you a quite simple case of what you see compared to what is happening in latency state under the hood, this is a simple thing:
| Start |  |
| Furnace built |  |
| Marked for deconstruction |  |
| Undone | |
But when you play in multiplayer, it might easily happen, that after the last undo step, not even the first command to build the actual furnace is in the game yet as the multiplayer latency might be too big. But as the local simulated state must act as it all was done instantly, it needs to solve different kind of situations:
| What you see (latency state) | Actual game state | ||
| Start: | |
Start: | |
| Fake furnace created | |
Nothing yet | |
| Fake furnace created fake marked for deconstruction | |
Nothing yet | |
| Fake furnaces fake mark for deconstruction fake undone | |
Nothing yet | |
| Now real furnace fake marked for deconstruction | |
Furnace built in game state | |
| Real furnace fake mark for deconstruction undone | |
Furnace marked for deconstruction in game state | |
| What you see is what you get | |
Furnaces mark for deconstruction undone in game state | |
Doing all of these kind of cases right might make a big difference between Prototype ready and Release ready. With the undo feature itself, I added 42 different tests and I'm not completely finished.
As always, let us know what you think on our forum.
