The place to talk about Transport Tycoon
https://www.tt-forums.net/
Yes, always attach the save, it makes it much easier to reproduce the problem. It#S not THAT much work after all to attach a filePinuccio wrote:Hi again
Someone can explain me what happens in this station?
This 30 passengers do not want to go away... it seems that they haven't a destination...
The station is linked with all other stations (only 4).
I have to attach the save file? Or there is a simple explanation?
Ok! Happy to give some helpfonso wrote:Seems I introduced some bugs with the new random number routing scheme ... unfortunately I can't fix them right now. If you want to play a nice bug-free game over Christmas you should probably use this one: http://bundles.openttdcoop.org/cargodis ... 43d6d1-cd/
Smallmap EZ has been removed from CargoDist a long time ago. It was disliked by the Devs for some (unknown to me) reason and fonso complied.Wasila wrote: I can't seem to be able to zoom in to the small map any more than normal.
You are correct, that is how it works ... you can filter by cargo to get to know more about a specific cargo-link.Furthermore, I'm not sure how the new overlay works. All it does is show you how overfull the route is on the small map, correct?
Code: Select all
//assert(capacity >= usage);
usage = ClampU(usage, 0, capacity); //hackYou can still zoom out right? If not something is broken that should not be broken.Wasila wrote: I assume the small map zoom doesn't work with trunk anymore then?
I feel the same way,A great shame - I grew very accustomed to zooming in to analyse my links, and I think it will be very difficult to manage inner-city bus routes without being able to zoom in. Thanks for the help anyway.
, but this has been dicussed in length before.Thank you for explaining ... I remember the discussion but did not remember the details.Leroot wrote: The developers of OpenTTD were not keen to include any smallmap zoom functionality that made it as zoomed/detailed as the main game screen, because that's not it's intended purpose.They felt that anything that needs to be that big should be shown in the main viewport
Clamping values is a very ugly hack indeed ... it prevents problems that may happen afterwards and why the assert was/is there but does not solve the cause of the issue.fonso: The crash I reported previously (Assertion failed at line 3367 of ..\src\station_cmd.cpp: capacity >= usage) still occurs on the December 11th build you linked. I temporarily fixed it with the following (terrible) hack:
Hopefully that is all that will happen ... You may want to keep an eye on your CPU usage anyway. CargoDist (and OpenTTD) can be quite CPU hungry and will not stop because of the CPU being maxed out.Anyway hopefully the worst that can happen is my hack will throw out the moving averages a little bit. =)
Yeah, that works. I thought that was already in trunk?You can still zoom out right? If not something is broken that should not be broken.
You should post a savegame so that we can see. There is a setting called "Saturation of short paths before using capacious paths". If you lower this the "longer" link via B and C will be chosen earlier, even if A-D is not saturated yet. However, that only happens if there actually is capacity left over on A-B-C-D. If A-B-C-D is already saturated the algorithm will still saturate A-D first.Lordmwa wrote: My only query is what are the best settings to make people go different routes!
For example:
A-B-C-D but there is also a service that runs A-D direct
I cannot seem to get it so passengers for D will just get on the first train with space. They all seem to wait for the fast service
Do any settings make this less likely to happen?
Ah, thankyou =)fonso wrote:Leroot's problem is this one: http://bugs.openttd.org/task/4912. Don't autoreplace trains to ones with smaller capacity for now.
Wasila wrote:Been testing further. Thanks for that, Leroot, but both the minimap and the new main map display lack certain functionality - one cannot see the demand generated at a station, for example, or hover over a link to see its two termini, which is useful in busier networks.
I think the current display does lack some functionality. I like the colour and shape interface for getting a quick impression of how things are working, but when I see bright red, my first thought is "okay, but what are the numbers." I'm looking to write a patch myself that addresses some of the things mentioned, and if it's useful and polished, I'll post it for your perusal =) I will probably make a link info window (capacity, usage, etc.), and then put a list of attached links in each station window somehow.fonso wrote:The link hovering doesn't fit into the spirit of the OpenTTD UI. It would be the only UI element to use mouse hovering as input method. That's why i dropped it. You should be able to figure out the termini of a link by zooming in. The monthly supply is still shown as size of the station dots, but the scale has been tailored a bit. It's one pixel of radius per 200 units of cargo now.
If it fits nicely I'll certainly integrate it. I guess everyone knows by now that I'm having a hard time writing UI code and that's why I'm always grateful if someone else does that for me. You can also make it available before it's ready and I'll give you some feedback if you like.Leroot wrote:I think the current display does lack some functionality. I like the colour and shape interface for getting a quick impression of how things are working, but when I see bright red, my first thought is "okay, but what are the numbers." I'm looking to write a patch myself that addresses some of the things mentioned, and if it's useful and polished, I'll post it for your perusal =) I will probably make a link info window (capacity, usage, etc.), and then put a list of attached links in each station window somehow.
If i get it obviously in my current game i will post a save. In previous games i have had this problem with hundreds of passengers waiting for the fast service and the stoppers going totally empty.fonso wrote:You should post a savegame so that we can see. There is a setting called "Saturation of short paths before using capacious paths". If you lower this the "longer" link via B and C will be chosen earlier, even if A-D is not saturated yet. However, that only happens if there actually is capacity left over on A-B-C-D. If A-B-C-D is already saturated the algorithm will still saturate A-D first.
In fact the point of cargodist is not to make cargo choose different routes but the most intelligent ones. As long as A-D is not saturated it is in fact the most intelligent choice for those passengers.
You are using what and are reporting where?Lordmwa wrote: I'm using the latest release of Chills patch pack
Just to make things clear ... I like the current implemention too but as I played CargoDist from the very start of development I got used to the old implementation and grew more than a bit fond of it as it was easy to evaluate links without the need to filter by cargo.Creat wrote: Just to provide a bit of balance to the issue: I'm extremely happy with the current linkgraph mechanic! Meaning I very much prefer the main view implementation over the smallmap. At least for me this solution is the better one by a huge margin.