Reply To: Ideas for an 'encore-patch' for Train Fever.

Home Forums General Discussion Ideas for an 'encore-patch' for Train Fever. Reply To: Ideas for an 'encore-patch' for Train Fever.

#21647
electricmonk2k
Participant

And here are a few more I thought of. These would probably require more effort, and therefore not be worth implementing in Train Fever, but could perhaps be incorporated into Transport Fever.

  • In the “List of vehicles” dialog, there should be an extra column to show whether or not the vehicle has been put in ‘stop’ mode by the user. Optionally, when not stopped, it should show the current speed (but this might require the window to be refreshed more often, but it already gets refreshed when the amount of goods changes).
  • Segment-query tool (gradient, curve-radius, length). With this tool, you can select a particular segment, and you will be given details such as the length, curve-radius, gradient, etc. . Minimalistically, the text-colour could just be red if the vehicle is stopped (this means we don’t add an extra column, but we can now no longer display the speed)
  • Show segment boundaries – outline all track as in select-mode. This shows the boundaries between all the track-segments. This can make things like building level-crossings easier as you can see where the road-segments join (which means a level crossing cannot be built at that point). To do this, either all track-segments could be highlighted (the code to hilight individual segments is already implemented, so jut do it for all segments), or draw something wherever there is a segment boundary.
  • Show speed-limits option for all track – not just track currently being built. Lower limits should be displayed in front of higher ones – this is good for finding those tiny segments that slow down trains. When rendering these, use some kind of z-buffer where lower speed == closer to screen. To prevent toomany speed-signs being shown, only show them within a certain radius of the camera’s location projected vertically onto the ground.
  • Rename towns. If the towns use an index into an array of pre-defined names, it shouldn’t be too hard to change it to use a dynamically-allocated string of arbitrary length. Even if someone renamed all their towns “Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch”, the sting size would still be insignificant compared to the size of the heightmap required for even a small map. If the developers are concerned about the memory-fragmentation involving dynamically allocated-strings, they can always be garbage-collected each time a town is renamed.
  • Some of the recently-ish added features (such as settable town-density and heightmap-loading) that are currently only accessible by adding or hand-editing some .lua file could become part of the user-interface.
  • X-ray mode: This has already be implemented (it shows when building track underground): It should however be an option in view-mode to enable it for all tunnels even when not building, so we can see all our tunnels at a glance.
  • A very minimalistic mini-map that only shows where the town-centres are, where industries are, and where the water is. This can be handy for planning the overall strategy on a large map. With some more effort, this could also show the altitude by colouring the land appropriately, but then it will have to be updated each time some terraforming occurs.
  • If attempting to build a railway across a road (in order to build a level-crossing) at the point of segment-boundary, the error-message shown should be “segment boundary collision”. Maybe this error-message could be used elsewhere.
  • If attempting to build a second track across a segment (that isn’t part of a double-tracked railway), it currently just says “not enough space” – it should either tell the user to properly double-track the railway or to build the railway across the road further away from the other track.