Forum Replies Created
-
Posts
-
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.
- When choosing a locomotive, as well as the maximum speed, also take into account how fast it can accelerate, and how it can handle steep uphill slopes.
I also think it’s a good idea for towns to accept more types of commodities than just ‘goods’. The most obvious would be to introduce an agricultural cargo-vector. Towns above the snow-line would require food to grow, whereas towns below the snowline would just accept food. Because of the way the cargo ‘walks’ if it’s close enough to it’s destination, this would work really well in Train Fever, because towns above the snow-line would be fed if they are close to a food-processing-plant which is close to a farm.
Another good reason for making towns accept multiple types of commodities is that in the current system, it is too easy to oversaturate a town with goods, and beginner-players may be confused as to why their goods-lines are not working (because the destination town already has it’s full supply of goods).
I also like the idea of dividing the map into rural and urban places. As it is, the map just contains ‘cities’ in a uniform distribution. As well as adding ‘towns’ and ‘villages’ to the map, it would e a good idea to make the distribution non-uniform, so for example, we could have one part of the map that resembles the German Ruhr-area, and another part that has a very rural characteristic to it.
Another idea I had for the different cultural regions would be to make slight changes to the pedestrian/driving behaviour. Depending on the region, drivers would be less or more likely to do things such as give way to pedestrians waiting to cross the road and other vehicles. Things like how reckless the driver is or how likely a passenger is to make an unsafe crossing of the road could also change from region to region. This would be more interesting if disasters were added (such as a bus colliding with a pedestrian), but even if there were no disasters, it would still have an influence on traffic-flow.
Also, the different types of roads could have different speed-limits depending on the region.
While I like the idea, I’d imagine it would be a bit of an overhead. Not only would each segment have to remember how long it had been since a train last rode over it, but every so often, the game would have to check each segment (which would add more overhead) and then change the track texture (or model even) with something more grassy. Segments with more than two exits (switches, crossovers, etc) would either have to be treated as a single segment (the rust/grass would only start at the next segment), or implement segments that can handle multiple levels of disuse depending on a particular track within the segment. Currently, a segment is either rendered as entirely low-speed or entirely high-speed even if the tracks are a mixture of low-speed and high-speed, so this would imply that the segments won’t be able to handle multiple levels of disuse unless the code is rewritten (this would also enable low-speed and high-speed sections to be properly shown).
As for rust being shown, as well as changing the texture or track-colour, you can also make it less shiny just by decreasing the specular component of the rails on that particular segment. While on the subject of specular lighting, when vehicles get older, their specular component decreases – that is, they become less shiny. If you replace an old vehicle with one of the same type, it would be nice to see it look shinier. That way you can get a feel of their age by just seeing how shiny they are.
I think turning loops are something as train fuelling with water towers and maintenance depots – really not needed, but adds some immersion. It is my personal wiew, I am not trying to force it to anybody.
And likewise, I’m not forcing my view on anyone. In OpenTTD, there is an option to choose whether to allow the train to self-reverse at platforms. I personally choose to have this enabled, but I still think those who want to have it disabled should have the option to do so. Of course, if TF enabled de-coupling, shunting etc, I’d be more inclined to play with self-reversible trains disabled. As well as turning loops (balloon loops) and depots (which would be more realistic if the depot was as long as the longest train it could handle), the trains could make use of triangular junctions (wyes) and escape tracks (Headshunts), turntables and even marshalling yards (classification yards).
#7: If this is added, it should be optional. Sometimes, we may later want to add a switch, and if the switch straddles a segment-boundary, this would make it impossible to add. Perhaps we could just have the ability to divide a large segment into X smaller segments (but there should still be a mimimum segment length in this case).
Actually, if segment-joining/merging was implemented, this would no longer be such a problem.
AFAIK, it should be possible to make Lua scripting-language for C# / Java etc programs. Is Lua used just for the mods, or also the low-level game-logic. If too much of the game is written in Lua, that might be one of the causes of the slowdown (although, it would be worth trying to optimize the approaches and algorithms used before considering rewruiting that part of the code in C++).
-Very powerful trains accelerate fast and then start to decelerate, I assume to keep their distance from the train in front of them, dropping to very low speeds, only to accelerate fully again, instead of keeping a nominal speed. Adding more signals doesn’t really solve this.
There’s currently a bug(?) where occasionally, small (and sometimes very small) segments of track are built that have a much lower speed-limit than the surrounding track. The easiest way to find them is to let a train drive over the segment, and when the last wagon has left, the train will accelerate once again. This is where the slow segment is. The trick is to demolish that segment and possibly a few surrounding segments as well, and then rebuild the track (taking care to make sure those really-small segments are demolished as well). Hopefully, once you rebuild the track, the trains will pass it at a much greater speed.
-When skipping several stations before arriving at the next destination, at the second-to-last station trains slow down for no apparent reason, accelerate again after passing it and then make a normal arrival at the destination station.
Maybe this has something to do with the bug(?) with the small segments – in this case, there could be small slow segments just in front of or behind the tracks of the station.
-Stations should really have exits on both sides, for being usable as a circular line.
Actually, you should be able to use a one-exit station for a circular line, but yes, it would be nice to have stations with two exits, or even better, stations that exit directly into an adjoining bus-station without the people first having to go to the main road and then go to the bus-station.
-When stopping vehicles to clear a road for reconstruction, after removing a road, sometimes the stopped vehicle moves and becomes impossible to select, or even find. The only way to find it again is by sending the entire line to the depot and waiting for the one that remains outside.
In the “All lines” window, for each line, there is a list of all vehicles on a line. If we knew which line the disappeared vehicle was from, we could select all vehicles from within the lines window and open their windows to see which ones are stopped. Of course, it would be nice (hint! hint!) if we could see this list of vehicles from within the window for an individual line, rather than only the window for all lines (I think the list of vehicles should be in both windows).
#4: Could this at least be optional? While reversing trains may not be realistic, it saves us from having to build a turning-loop in the game.
#5: If the game-settings are divided into Easy/Medium/Hard/Custom where all but custom use pre-defined settings for the individual difficulty settings, ‘main-connection’ should not be active in ‘easy’, but active in ‘hard’ (not sure about ‘medium’).
#7: If this is added, it should be optional. Sometimes, we may later want to add a switch, and if the switch straddles a segment-boundary, this would make it impossible to add. Perhaps we could just have the ability to divide a large segment into X smaller segments (but there should still be a mimimum segment length in this case).
C# is compiled to a virtual machine, whereas C++ is compiled directly to native machine-code. This means that running C# code has the extra overhead of running on a virtual machine.
Does anyone know what language Train Fever is written in and which engine it uses?
Would we be confined to flat tracks, or would it be possible to build a station on a sloped track? AFAIK, in the real world, stations-platforms are not built on sloped tracks.
The pencil mark is NOT clutter, it indicates that you can edit (re-name) the item.
Or just use F2 to rename if a window has the input-focus. Anyone familiar with the Windows UI might be able to discover this, and even so, this could be mentioned in the docs or on forum-posts from time to time. Of course, double-click-to-rename should work too.
there’s also way too much info being shown.
While I agree that there should be some decluttering going on, all the info should still be accessible. If you really want to get rid of tabs, at least being able to hover over things like the financials should show the full financial details. One thing tabs are good at is aiding discoverability, but if you want to go for the ‘hover to bring up more details’ approach, at least make the hoverable area show some sort of change when a mouseover event happens. Less clutter does mean it looks tidier, but it should always be possible to access the information.
I do like the new vehicle detail screen – especially the age-progression and value-deprecation graphs. Perhaps, there should also be a distance-graph for how far the train has travelled from the previous stop to the next stop (Railroad Tycoon 2 has something like this).
Text labels of other stats replaced by icons
If that does happen, it should be possible to hover over an icon to see what it is. The icon for loading-speed does not look very intuitive.
Another problem could be new interfaces (touch screens). They are known to be defective regarding hovering compared to older interfaces…
ARGH! The T-word!!!
I honestly don’t think that Train Fever is suitable for the user-input-abomination known as the ‘touchscreen’. And if Urban Games did try and make it touchscreen friendly, I hope they don’t have to compromise on the usability of a keyboard-and-mouse interface.[re: main connections] There’s no point worrying about the minutiae of (2) while (1) is happening, because the game is getting slaughtered in the ratings, harming reputation of UG in the process. (1) has to be fixed before (2) can even be thought about.
Perhaps there could be four difficulty-levels: Three (or maybe more) pre-defined levels – ‘Easy’, ‘Medium’, ‘Hard’, and a fourth one – ‘Custom’. Easy, Medium and Hard have things like main-connection fixed (off for easy, on for hard – not sure about medium) and in ‘Custom’ mode, ‘main connection’ can be turned off or on independently of other difficulty-parameters. This way, the Easy mode can have several things turned off (eg. Main Connection) that new players have a hard time with.
From my point of view as a user (different from the point of view of the company), I’d rather see a more challenging game than to make it simpler in order to gain more audience or higher ratings in whatever popular ranking. Most of games are very simple just in order to get more market and that’s specially frustrating in simulations.
This! Very much this! Please don’t insult the intelligence of your players, insult their stupidity instead! Fortunately, TF doesn’t fall into this trap, although the UI can still be frustrating at times (but not as frustrating as it used to be).
Just similar with the “not able to align terrain” when building. It makes no sense since construction is really possible. You have to elevate terrain here and there. Construction should be either impossible or automatic. If the programmers wants to forbid certain abuse when building, just put a higher price in unrealistic constructions.
I agree – more flexible construction at a price. I find that when building a track at a different altitude than the ground, unless a bridge or tunnel is built, the land that is added or subtracted slopes ca. 45 degrees, which can be the cause of many a terrain-alignment-collision error, but if I use the raise/lower tools, I can create steeper slopes – and hence tighter junctions. It would be nice if we could automatically build steeper slopes – even if it came at an extra cost (in the real world, you’d have to build something to re-inforce a steep slope to prevent it from collapsing, so the extra cost would be justified).
Oh, and my suggestion for the TF UI: could you please change the mouse-cursor-image according to the mode/state the mouse-action is in (a different mouse-cursor for ‘select’, ‘build’, ‘delete’, ‘add-station-to-route’, ‘group-station’, ‘road-upgrade’, etc). Currently, we have this implemented for electrification and high-speed-rail, so why not for all possible action-states? This would come especially in handy if bulldozer-mode is selected – it will reduce the chance of someone accidentally demolishing something when they were intending to select something. Being able to tell at a glance which mode the cursor is in would all of a sudden make the interface feel a whole lot less awkward.
Trains in the real world arrive at a predefined platform. Last minute changes, for example due to reasons like delays, can be very confusing and annoying for passengers.
Passengers in the game behave in the same way. They like to line up at a definite platform and wait for their train to arrive. This is the sole reason why trains do not choose an arbitrary (or any free) platform to stop.
WRONG!
It’s because Train Fever only implements a static path-finder – hence unless the track is modified or the route changed, it will always take the same path. And yes, it would be annoying as a passenger to make a last-minute platform-change, but in the real world, this does happen, and in some stations (especially in the UK), the platform is only announced at the last minute. However, if the track was changed to the other track of an island-platform, that would be a lot less annoying for the passengers.
One idea for improvement that I have is for when editing the route, it should be possible to create a branch in the route so that after a certain point, the route will split in two … even if it is just for the length of one waypoint – and then recombine. Which way the train takes when it encounters this split would be whichever way is cleared of blockages first. So if we had a station with an island-platform and two waypoints – one on each of the two tracks surrounding the island platform, you could split the route (using a ‘decision-point’ which is a bit like a waypoint (in fact, you could probably use an existing waypoint or even a signal, as signals can be added to the route)) and place each waypoints on each branch, and then recombine the route when it gets to the station. That way, the train will take whichever platform is liberated the first. It’s not a completely dynamic pathfinder, but even so, adding a few decision-points could improve station-throughput. You could also of course place the two waypoints after the station, and each branch of the route would have the station in it (after the decision-point) before the waypoints, and would then recombine. Another use of decision-points could be for building overtaking-track which can be used in the event that you’re gradually upgrading the locomotives on your line to faster ones, but can’t afford to do all at once and don’t want the faster ones stuck behind the slower ones.
I do agree with the fact that a train should be bound to a platform. But why cant other trains (lines) make use of the same platform? Why do all lines have their own platform.
In Train Fever, you can get multiple lines to use the same platform. In fact, you can even force your lines to use a specific platform by making use of waypoints. Unfortunately, when using the large bus-station, I still find that most of the time when I have a lot of lines using the bus-station, not all of the bus-platforms are made use of by the lines 🙁
Say i have a 320 mtr long platform. In Amsterdam Central Station trains can use the same platform from both sides simultaneous.
I agree, this would be a nice feature to have in TF. Even nicer if you had advanced station layout options and could divide the terminating track into two using buffers and a concourse where people can walk to other platforms. Without advanced station layout, you’d just need a virtual signal in the middle, and the ability for the pathfinder to be able to only occupy a half-platform (if the train is short enough) when stopping at the station. Another advanced station layout would be to have a third track in the middle of the two tracks with platforms at their edges, and two crossovers in the middle so that two platforms can handle four trains (that don’t even have to terminate or reverse). In fact, if the station is long enough, there could be two sets of crossovers and the two platforms would then be able to handle six trains at once.
Well, combining stations is a whole other story. As it is not possible to adapt a station directly to the landscape (it always keep horizontal) i am having a very hard time in placing two station either against each other or place them in length of each other.
A station is always placed at the altitude of the end of the path leading out of it (the hot-spot – where the mousepointer is, and the pivot the station gets rotated around using the M and N keys). To keep the station-parts aligned at the same altitude, you can make sure that all places that are likely to have a station-path have the same altitude. To do this, decide on which part of the area will have your station-altitude, and then build a road staring from that point. The road must be perfectly flat (to do this, click on the gradient arrow, and change the arrow so that it is horizontal (note that it must have a blue background – if it has a white background, that means it is just following the land-contours and it would be ‘almost horizontal’ instead of ‘perfectly horizontal’)). Demolish the road when you’ve finished with it. By building and demolishing several roads, you can turn an area of land perfectly flat.
Here is an interesting article on whether to use a home-grown engine or licence an existing engine – http://www.gamasutra.com/blogs/DietmarHauser/20151007/255394/License_an_engine_or_create_your_own.php
Is it not possible that Urban games will go for a complete new genre?
According to this article, a reference is made to tram tracks in their next game – “We will also treat you with a widely requested improvement initially developed for our next game: Tram tracks can finally be electrified and therefore get the long awaited catenary.”. This would imply that their next game is also going to involve transportation of some sort. With luck, it might even be “Transport Fever” – Train fever with boats and planes and many of the often-requested improvements.
