Forum Replies Created
-
Posts
-
Mod has been updated to version 5080/5112 of the game.
Download: http://www.train-fever.net/filebase/index.php/Entry/535-Balance-Mod-UPDATED-for-5080/
- Add option to change Particles (off/low/med/high)
Only On/Off make sense.
- Add option to change LOD (off/low/med/high)
Geometry Low/Medium/High does this,
- Add option to disable floating text over vehicles [income/expenses] (*EASY*)
Most of these texts are lost as you can only observe one text at a time!
No. Just add a sensible LOD to this text. say, 200 metres.
- Add option to turn off shadows (off/low/med/high)
It might look bad, but you could give us this option for weaker computers.
No. This is almost entirely graphics card issue. Even semi weak cards ( like my radeon 6850 ) can run at high shadows.
- Better multicore support
Currently the game supports 2 cores, but mildly. It does not support 4 cores or more (when in reality, there must be 4 different areas of calculation, right?)
This is a vacous request. Without knowing where the performance bottleneck is, we cannot assume it is in the lack of threading.
- Better performance with large population
Obviously.
Anyhow. I attach my semi complete list of bugs:
http://www.train-fever.com/forums/topic/semi-complete-list-of-bugs-and-usability-issues-4831-repost/
There are some suggestions there as well.
Pasi:
How long did you play?
When do you think trains become to cheap to run?
Capital expenses are covered in HSR track, which is uber expensive to build ( about 30 times more expensive then regular ). Also, historically speaking, running cost of a mainline locomotive was kind of flat when adjusted for inflation, so BR103 being just 2-3 times more expensive then, say, prussian G3 is quite realistic.
I am now playing a hard large map and it took me 85 years ( 1850-1935 ) to finally set up my main line to double track and run some freight on it. For the first 30 or so years it was a struggle to survive, in spite of running 15 car trains almost chock full of people. Heck, I still cannot afford electrics, since they are 2,5 million a piece in the current build of BM 🙂
Anyhow – the passenger car weight is actually a bug in the game acceleration code. BM just tries to work around it.
I am now waiting for the next patch, so I can adopt BM to it and release next version and I will gladly make adjustments for advanced players.
That is an entirely different issue.
If a train loses a path, it will try to find a new one. If, by any chance, finds one which requires a reversal, the train will reverse and if there is a train behind it, it will deadlock with eternal “waiting for new path” since its path is blocked by a train which did not lose its path.
This is annoying because reorganization of a major hub at one place may end up with a pile of deadlocked trains somewhere else.
I _think_, but haven’t checked yet, that this can be remedied by using a one-way signal at the entry of a long stretch of one-way trackage.
In that case, the bi-directional loop would work, it does not!
Because it is not doing what you think it should do. If, for whatever reason, a train loses its path, it will attempt to return to it, and in most severa cases, will go into “no path” mode.
Easily chacked if you make a working line, then insert a waypoint which reassigns the path to different trackage. Trains following a particular path will then search for a way to return to it.
Just accept the simple fact. TF is a game in which trains have their own designated route and will do whatever needed to reach it. It is a feature of this game, and a conscious design decision of the devs.
Deadlocks only result on bad designs and dynamic path selection would cause even more of them.
A system in which several ( minimum two ) trains can request sections of trackage occupied by another train. The passing loop you have shown in the first post will ewentually deadlock with 4 or more trains on that particular route.
Pathifinding is a way of finding best path between 2 points, it can work same for TF as it does for OTTD. Lines are system that says where train goes, not how it gets here!
Yes. And in TF all points between which a train needs to find a route are on a Line.
Better than having it standing on the main track blocking all other traffic!
Your inability to design efficient junctions is irrelevant to our discussions. Intrestingly, TF is much more demanding when it comes to junction design then OTTD. This makes it superior to OTTD IMO.
BTW, did OTTD had a waypoints? I can’t remember that I ever needed them.
Kind of. In 2001, or so, new “non-stop” handling was introduced to TTDPatch. Newer handling made trains run “through” a station without stopping ( earlier trains would run to “non-stop” station without stopping anywhere on route ). This made it possible to use 1×1 stations as waypoints. Which TTD needed because pathfinding was terrible in original game.
Later OTTD also used that feature, then added a nice graphic to it and thus added “waypoint” feature. Later NPF and YAPF were introduced which made waypoints kind of moot.
Ok guys. Herr is the thing. Â Threading from programmers perspective is just a method of organizing the execution of code. Â What yoy are discussing her is concurrency – which is doing things in parallel. Â The popular term of “threading” is used interchangeably with “concurrent”. For a programmer tym these are different things.
Btw – i would also like to read the sources.
Btw2 – hi eis_os 🙂
As far as I understand it though, there is not much the Devs can do now though except totally rewrite the game to make use of hyperthreading, ie, ‘Train Fever II’. Despite all the problems this has had, I WOULD buy that!!
No. No, no, no, no, no. Just no.
Software is built incrementally. You don’t scrap a huge deal of your software to rewrite it unless you want your company to fail. The approach to this is to incrementally identify performance hot-spots and fix them untill you get the desired performance.
For example, at this point I work on a software that was first written 17 years ago and still gets sold. But it received a continuus stream of updates, patches and fixes over the years and while there are some issues in it, most problems from it that existed 15 or so years ago were fixed.
But that requires an actual software engineer behind this. Afair all people in Urban Games are academics.
gGeorg: My crow consumption is only about platform selection for buses/trucks/trams. I keep my position on the railroads 🙂
Anyhow – from my ~8.5 year experience as a software developer I would be inclined to consider what you suggest “fuzzy logic”. The word “optimal” in the case of multi faceted problems is not well defined, thus any mechanism you will introduce will fail one way or another, causes alot of problems and breeds tons of ill defined bugs.
Hint: there is “automatic vehicle spacing” in this game. You know well how well it works 🙂
Besides – most lines in TF operate on a similar frequency ( or would, if we could properely space trains ), so even if you could get that platform selector work the way you want, it would devolve to what we have now, because there is just one optimal solution, and it is static, except for rare aberrations of the natural rythym.
The deal is, that the game already does so. Follow a vehicle with its properties open. Everytime a vehicle cannot reserve a path on its line, it will display “waiting for free path” and will start braking. This is the time when a new path is searched for.
Deadlocks are not caused by poor pathing, but by incorrect junction placement and construction. This remains true from the earliest versions of TTD, through TTDpatch and OTTD. Sure, OTTD has more elaborate signalling system, but its most advanced signalling – path based signals, are what TF implements.
The only difference is the static pathing of TF. Sure, OTTD can do dynamic platform allocation, but does it so in the dumbest way possiblem, and then it is useful just for drop-off stations near big industries and for passenger traffic. If you want to have passing loops in OTTD with more then three trains then you need to set up the whole shebang just like you would in TF – using path signals. Otherwise the system will deadlock.
My point is – TF offers you 95% of functionality of OTTD’s signals, but also offers what OTTD cannot offer. Sure, having some features of OTTD’s signalling would be nice, even if because that would be less confusing for begginers. But I, personally, don’t see them as being all that useful.
Interesting factoid: in my last OTTD game ( about 3 years ago ) I have used only path signals in a manner identical to what TF does now.
