This may just end up being a question rather than a bug report but...
How does cargodist handle obselete routes/links?
I have a game (attached) with a glass works. There are 2 vehicle plants being supplied, one of which also has a factory next to it. Originally I was running direct services to each of them. I later changed my routing scheme so that all the glass is taken to the closest one (which also has the factory) and then a shuttle takes it to the second vehicle plant. Unfortunately, even though there are now no vehicles with orders direct from the glass works to the furthest vehicle plant, it won't break the link, even after several game months. I have deleted the orders for all the glass trains going there and then re-creating them with no success in fixing the problem. The only time it works properly is when the furthest vehicle factory is full of glass and stops accepting it. I figured I'd post this here as I am using your (amazing ) patch pack. I'm not sure if it would be better being posted in the cargodist thread?
the "broken link handling" is one of the most controversial parts of the cargodist patch, and has been refined multiple times. but the version included in this patchpack is very old, and thus has not benefited from these changes.
IIRC, the version included here starts decreasing the capacity of a link ever so slightly when you stop providing tranport service.
If you had lots of capacity this may take quite a while indeed.
The speed of decay is hard to get right (and not ?yet? configurable), in the patchpack I have daylenght to consider and time in minutes, which is combined to have trains stay overnight. You do not want these links to dissapear; the same goes for traffic jams.
I will have a look at your savegame in a bit because I do not quite get what you mean with "The only time it works properly is when the furthest vehicle factory is full of glass and stops accepting it.".
In regards of bugreports do please post here when using the patchpack.
Thank you for the feedback much apreciated.
Edit:
Daylengh may be influencing the time it takes ... I'd have to check to be sure.
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.
Thankyou for the speedy reply. I "solved" the problem by deleting the station, letting it lapse and then recreating it. But that is only a temporary fix! Thankyou for you time and effort, it is much appreciated.
What number of nightly version is base for h122e7a62?
Someone asked to me that his NewGRF(OpenGFX Airport 0.4.1) doesn't displayed on the newgrf list in h122e7a62.
I think the version dismatch is the reason why he can't see the newgrf.
So I want to know the nightly version number where h122e7a62 version was based.
- OpenTTD/OpenRCT2/Parkitect Korean Translator
- TELKLAND site manager, the korean website of OpenRCT2/OpenTTD (https://telk.kr)
I think that the NewGRF list shows all NewGRFs, even if they are made after the nightly was made (of course, they won't work), so I think you need to refresh your NewGRF settings.
UseYourIllusion wrote:I think that the NewGRF list shows all NewGRFs, even if they are made after the nightly was made (of course, they won't work), so I think you need to refresh your NewGRF settings.
Thanks your reply but I don't think so.
Because my own newgrf doesn't displayed in Chill's patch version similarly when I made it.
The reason was some kinds of version dismatch.
- OpenTTD/OpenRCT2/Parkitect Korean Translator
- TELKLAND site manager, the korean website of OpenRCT2/OpenTTD (https://telk.kr)
Most probably its the GRFv8 and GRFv7 incompatibility, which latest ChillPP only can read the later while the output from latest NML should be GRFv8. I'm not sure which version of NML that still gives GRFv7.
Else, it's due to unsupported features, like rotating airports (as in OpenGFX+ Airports 0.4.1) or something else that there's no compatibility if the feature isn't available.
YNM = yoursNotMine - Don't get it ? 「ヨーッスノットマイン」もと申します。
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.
ChillPP does not understand grf v8. NML produces in its default branch grf v8, as such OpenGFX+ Airports is a grf v8 and container format 2 for quite some, which are not understood by ChillPP (you would need NML 0.2.x to create grf v7, container format 1 NewGRFs - but that limits NewGRF options quite a bit in comparison).
i think your patch is awesome
i get these massage's every time i start or exit the game
ini; invalid value 'SHOW_TOWN_NAMES|SHOW_STATION_NAMES|SHOW_SIGNS|FULL_ANIMATION|FULL_DETAIL|WAYPOINTS|SHOW_COMPEITOR_SIGNS' for 'display_opt'
ini; trailing characyers at end setting 'difficulty.economy'
ini; trailing characyers at end setting 'difficulty.line_reverse_mode'
ini; trailing characyers at end setting 'difficulty.disasters'
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
It happens because you've previously ran a newer version of OpenTTD, which has changed some of the settings in the configuration file, and the older version of OpenTTD used in ChillCore's Patch Pack doesn't recognize it. The configuration file is hanging out in your shared settings folder. Delete this file, run CPP clean, and when the new configuration file is created, remove it from the shared folder and move it over to the root folder where CPP is installed.
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.
) patch pack. I'm not sure if it would be better being posted in the cargodist thread?
