Forum Replies Created
-
Posts
-
Train Fever uses a static path-finding algorithm (whereas OpenTTD uses a dynamic pathfinder). This means that once a route is decided on, the pathfinder finds a path and only changes it if the track-layout changes. Introducing a dynamic pathfinder to TF would be quite a big task – especially considering TF has got path-based signalling as well (even OpenTTD did not have path-based signalling for several years – this meant that only one train could be in a signal block at any one time until PBS was introduced, whereas both TF and OpenTTD-post-PBS allow multiple trains in a signal-block as long as the paths do not cross).
However, I’ve had an idea for a compromise – a mostly static-pathfinder with only a bit of dynamicness. Imagine a station with two tracks and an island-platform with one of the tracks on the left side and one of the tracks on the right side. If the first switch for both tracks on either end of the platform was the switch joining the two tracks, then what could happen is that the trains could then choose only at the last minute which platform to go to, so they would always pick a free platform instead of an occupied platform (unless both were occupied). In this case, the pathfinder only needs to make a decision at the switch just before the platform, while keeping the rest of the path static (other stations with a similar layout would also be dynamic). I’m not sure how much more complicated the algorithm would be if other switches occur between the switch joining the two tracks and the platforms, but I do know that if both tracks were one-way (heading the same way), it would make the platform and two tracks more efficient. Also, making sure that all routes that use either of the two tracks have the option of taking both tracks (this will always be the case if the last switch before the platform and the first switch after the platform are the switches joining the two tracks). When this is implemented, the route-colour overlay would show the route splitting at the pre-platform switch and merging again at the post-platform switch. This also has the advantage that this sort of thing is done in the real-world too, and the passengers don’t have to walk to a different platform – they just change the side of the same platform they are already on.
Is your route working? You can check this by opening the “Manage Lines” dialog and seeing if the route of the tram is shown as a coloured overlay of the same colour as your line colour. If you don’t see it, it is because at least one stop is unreachable. In the case of trams, this means there is either one stop on the line not connected to the tram network, or the tram-networks of each bus-stop are not connected. There may be a small gap somewhere along your line without a tram-line in the road.
I just tried experimenting by dragging the roads according to the arrows in Person012345’s diagram, and while most of the time it works, I still sometimes get a curved road even if I immediately drag diagonally (like with the first diagram). Maybe I’m actually dragging in a pattern similar to the second diagram but with a really small first arrow? Perhaps the true answer is a hybrid of our theories. But even so, each time I get the road to go in curved mode in one direction, the amount of curvature is always the same whenever I move the end-node to it’s final destination.
I can confirm that disconnecting from the Internet also disables the TF menu (the text becomes grey). The good news is that if you put Steam in Offline-mode and then restart TF, you can play just fine without an Internet connection.
I was wondering if anyone had a more precise explanation that was based on how the game was supposed to work, rather than just experimentation. Also, are there just 3 modes (straight, left-curve and right-curve) or can the degree of curvature be controlled.
IMO a better way of controlling the curvature would have been to directly manipulate the node-orientation. To do this, a smaller circle that resembles the end-node circle should be at a fixed distance from the end-node marker, and this smaller circle can be rotated round the big circle using the mouse to drag it round.
They should have at least allowed us to keep the original version so we could play our old saves – even if it does not bring us the benefit of the new features. Personally, I’ve been playing the vanilla game (no mods) and have noticed my saves still work post-USA-DLC.
>there isn’t much more they can do without re writing the whole thing.
Personally, I disagree with this. TF contains a lot of small problems that could be fixed with very little effort (such as changing the mouse-cursor depending on which mode the UI is in (select, construct, bulldoze etc.), displaying the information for a particular line that’s currently in the “Mange lines” window in the “Line” window (eg. which vehicles are using the line), and so on…
While the pace of updates is slow, they do happen. It’s just that everyone has a different wishlist for what they want to see. Personally, I think that for now they should just focus on the really small fixes and shoot down a large number of bullet-points on the TODO-list. Also, I hope they fix all the small to medium issues before they go onto TF2. TF2 should be for big changes such as multiplayer, AI, boats, underground stations and proper U-Bahn networks, etc.
Also, bear in mind that the programmers and artists on UG are different people, so if UG were focused on exclusively fixing the game-issues, the artists would be twiddling their thumbs (and occasionally making a new UI-icon). Unless even more things in the game are to be made moddable, the artists could go ahead and make new vehicles, buildings, textures etc. and create an entire new DLC while the programmers sort the game out.
I’m pretty sure a modern image-editing package can handle 16384*16384 – even at 16-bit per colour-channel (apparently, the forthcoming version of GIMP can handle images with 64-bit per colour-channel).
I’m not sure if there are any restrictions in-game for maximum slopes (would it be OK for example to have adjacent pixels with heights of 0 and 65535)? Even if there were such restrictions, the terrain-generator could smooth out those steep slopes. Also, if using an 8-bit image (256 layers) or an image with reduced area (e.g.. 1024*1024 for the small map), the terrain-generator could always apply some smoothing or even a bit of noise to spice things up. Maybe we could have a really small heightmap-image and instead of using that as the actual heightmap, it would be used to ‘seed’ the map generator (i.e. it give it hints as to where the mountains, plains and plateaus are to be placed).
Also for the town-map, it could be a 256-colour paletted bitmap (8-bit), where each colour would represent a different town (only one pixel of each non-background colour would be allowed), and there would be a text file with a list of up to 255 town-names so that you can assign a name to the town of each colour. As an alternative to using a single pixel, the towns could be a blob that represents which parts of the map they occupy so you can have things like circular towns and skinny towns (the latter are usually placed in valleys). Alternatively, if the “town’s growth potential” feature is implemented, the blob’s area could represent the growth-potential of the town (is this town capable of growing into a vast metropolis, can it only grow to a medium sized city, or will it stay a small town forever?). However, you’d have to be careful to make sure all of the area of a single colour is contiguous (i.e. no exclaves). Alternatively, the growth potential could be mentioned in the text-file with the names and we can instead use the blobs to define the initial town-area.
The resources-map and the tree and farm placement maps could be combined to that each bit of an 8-bit bitmap represents the presence of a resource. So if bit 0 represents coal, bit 1 represents iron, bit 2, forests and bit 3 farms (although farms and forests would be mutually exclsive), an area of colour #5 would be a forest with a coal-seam underneath (both the woodcutter and coal-mine industries can be placed at this spot by the map-generator). Unless we use > 8 bpp images, we’d be limited to 8 primary resource-types or landscape features – not a problem for the vanilla game, but once you start using plug-in industries, it becomes a problem.
This sort of thing happens when the land under the second track is not deep enough for the tunnel, even though the land under the first track is. One solution is before you draw your first tunnel, attempt to draw another tunnel one track-width to the left or right to see if it can be done. If the tunnel-portals are in different places, you may have to massage your terrain so the two tunnels would start and end at roughly the same place (but this is impossible if the tunnel consists of more than one segment that does not have the same curvature/gradient as the rest). It would be nice if building a tunnel could terraform land upwards (and we could manually move the portal along the track when building) – nicer still if we had a double-track building mode (this would also allow us to build double-track bridges with the pillars in the right places, and also solve a whole lot of other problems).
When I first started playing TF, I was plagued by main connections, but then at the end of January, a patch came out that fixed a main connection bug and all of a sudden, I find building bypasses solves the problem 99% of the time (the other 1% can be solved with a more elaborate bypass).
@Shades: Have you updated your TF build to the latest version? Are any of the country roads going in to your city main connections? If you can find two such roads, make sure there’s an alternative connection between these roads that bypasses the city altogether.We all have our pet ideas which we hope that someday the developers will implement.
Anyway, I’m thinking about fleshing out my ideas for construction into the ultimate construction-tool with an explanation of how it could implement much of the functionality in a single tool, and even making some mockup screenshots showing the proposed tool-UI.
While a fully fledged map-editor would take a long time to develop, being able to import a heightmap is something that the developers could implement with little effort. Of course, then you would be limited to 256 height-levels unless you used a bitmap-format with more than 8 bits per greyscale-level (or used something like R*65536+G*256+B). Unfortunately, even with a heightmap, you’d still have no control over town and industry placement, so you’d have a real-world country with all the towns in the wrong places. You could have a secondary bitmap with a spot telling the map-generator where to place a town, and spots in different colours telling it where to place industries. Then you’d have the wrong towns in the right places, but if you are then allowed to rename the towns, then you can have a proper real-world map. Also, we could have a third bitmap telling the map-generator where to place trees, farms, etc. Or a fourth bitmap telling where coal, iron etc. are buried so that the industries can be placed randomly only in those areas.
I made an extremely long list of ideas for improving Train Fever at http://www.train-fever.com/forums/topic/a-very-long-list-of-ideas-for-improving-train-fever/ . Many of these are small UI improvements or small information-presentation improvements that could make the game a whole lot less awkward.
Re tilt function: Actually, it is possible to tilt the contents of the viewport-windows but the game won’t let me tilt far enough to bring the horizon into view. But I suspect there’s a reason for that – the closer we get to the horizon, the more geometry appears in the viewport.I can of course tilt the main view enough to see the horizon.
I too would like to collapse my windows and just see the info. This would be even better if there was a progress-bar so we’d also be able to see just how close the train is to it’s destination.
Anyway, I had a look at the latest build and saw that you could now have a choice in the format of the units and even whether or not they were in Metric or Imperial. This would be a good place to put the frequency format setting (“seconds if < 3 minutes, otherwise minutes” (current), “minutes” (with up to 2 decimal places), “seconds”, “mmm:ss”) as long as it can also be changed in-game.
