Forum Replies Created
-
Posts
-
To clarify: The “Steam profile” is something members of the “community” have. As I said, the only thing I use Steam for is to play games. I have no intention to register for their community. And – if I had registered there, I would not have wanted to post my ID in a public forum. You will have to take security and privacy more seriously unless you want to run the risk of a scandal. At the very least, you must provide a private communications channel for users to send you potentially sensitive information. If you have some place I can send you the dumps, I can pack up the whole thing and send it.
There is a crash dump generated every time I try to start the game.
I do not think it is a good idea to publish account information in a public forum, though. And I am not sure what you mean by “Steam profile” – there is nothing called that to be found in my account information. I only use Steam to play games, and have never signed up for any of their other functions.
This is exactly what happens to me, even after I tried to uninstall, remove the TF directory and have Steam re-install on a different drive. Seeing that everything except the OS on my system is different, I am led to suspect a rather fundamental bug. Is there something the uninstall and removal of directory leaves behind that is referenced during startup? My other computers do not have graphics that support TF, so I cannot try on another computer.
Windows 8.1 Pro 64-bit, kept updated
Core i7 4770 @3.40GHz
32GB RAM
GeForce GTX770 @2560×1440, 59Hz
Driver 347.88
There seems to be a number of issues with the overactive pathfinding in the game, and this is the worst of the problem but not the only one. A slightly less serious problem is that trains sometimes spontaneously change the track they use at a station, potentially causing deadlocks.
The solution is obvious, and would even make the game less resource hungry: Run the pathfinder only on demand. It is appropriate that it runs when you make a new route. When you change either the route or the track/road, it should give you a hint that you need to take action, but it should not start on its own. Only the player knows when a change is finished and ready to be committed.
Since we have not seen their core code, we have no idea how flexible or well-written it is. From the exposed parts of the game, I would guess that it is rather well made.
The problem areas are in some of the design choices, and given the small staff and need for priorities I can understand that. I have, myself, lost more money on game startups than I like to think about. I think it was a bad decision to make one game release to cover the entire 1850-2000+ era. The effort is spread too thin. It would have been wiser to make a really polished 1850-1900 base game with a sufficient number of vehicles to enable realistic transport systems. Then, they would have been able to sell 1900-1950, 1950-2000 and 2000+ add-ons to create a sufficient cash flow to increase the development effort.
For me, the biggest disappointment is the unrealistic turn around of trains and the lack of proper freight train handling. Most freight trains do not stop at a platform to get loaded and unloaded like a passenger train. We should have a need for marshaling yards, shunting and sidings where cars are left for loading and unloading. This kind of activities are demanding on game logic, but does not use much computer resources so it would not cause a performance hit.
It looks to me like they are trying to make another children’s game rather than a serious simulation. I believe that to be an unwise move, since the bulk of the train enthusiasts are older people who want all details to be correct. Children do not complain if something is realistic, but enthusiasts get upset when things are wrong. It would have helped if they consulted with somebody who has a clue about railroads, they might have avoided such blunders as a locomotive without a tender.
A major weakness is that there are no passenger engines available for the 1850-1900 period. The Baldwin six-wheels was a freight engine. Without too much effort they could also have made a model of the fast passenger engine Baldwin built for the Virginia Central in 1849, since most of the parts are the same. Having both freight and passenger cars and engines available with reasonable update intervals is a must for a proper railroad operation.
I have found the track laying to be very inaccurate and buggy. My hope is that they eventually would make a more realistic method – first put down some survey posts with an altitude indication on them, let us adjust the positions of the markers, then let us start construction of a roadbed with a centerline through those markers with an even slope. There should not be any abrupt changes of slope (or curvature) either – we should be able to define a transfer length where the slope or curvature gradually changes to make a smooth transition between endpoints. This is the way RL railroads are built.
We need documentation to be able to make a usable freight system with marshalling yards, town-to-town cargo and industries contracting for bulk freight instead of waiting for somebody to provide it.
I do not see any good reason for any of the parameters to be other than normal metric units, so that a unit of bulk cargo should be one ton. Passengers are a bit different, it looks like a unit of passengers is four persons. I guess that is in order to keep a reasonable number of people walking around.
It seems the power curve used for steam engines is wrong, initial acceleration is quite fast. A steam locomotive has good pulling power from a standstill, but poor acceleration. Rated effect is only available at maximum speed. This is why they are not fond of grades – they cannot shift gears.
For road vehicles it looks like the rolling resistance of carriage wheels on dirt roads is seriously underestimated, and even on cobblestones carriages move rather too easy.
Keeping at least the internal workings working rationally with SI units will avoid lots of misunderstandings and bugs. If users want to see something different, it can always be converted for display.
Even worse than all the useless icons are the even more useless red and green numbers that comes popping up every time money is made or used. If I want to see the financial situation, a menu is better for thqt.
Many of the problems are due to too much “gamification” or lack of realism. Running costs are a typical example: in real life there is no single “running cost”, there are separate fuel, crew, periodic maintenance and load-dependent wear and tear. There is also a choice between replacing and refurbishing aging equipment.
RL equipment does not run non-stop, it has at least a daily turnaround pause to get cleaned, refuelled and inspected. Horses need frequent rests and fodder. Steam locomotives need frequent watering and a load of coal at the end station. The amount depends not just on distance, but very much on the load. A heavy freight train running uphill will need a lot more fuel than a light train on level track.
If all that, as well as replacements or upgrades, could be automatically handled with upgrades based on per line, per type or whatever user settings, everything would be both more realistic and more enjoyable. It would need a more sensible (much slower) timescale, though.
“cleary first step what you should do”
i love the confidence
Certainly – but he is right. I wrote threadsafe programs over 20 years ago, and it has not become more difficult since then. I suppose the main problem is limitations in game engines, which seem to have been hobbled by console hardware.
If you write today, you’d better be able to make use of 16 cores and 64GB RAM, because tomorrow some of your users will have that.
The number of passengers boarding at each count of the timer should be the same as the number of doors on the platform side of the train.
No real train enthusiast will be satisfied with something that plays out in a few hours or days. If the time scale is made moddable, I bet we will see mods to make a game year last many hours.
