Cargo Distribution
Moderator: OpenTTD Developers
Re: Cargo Distribution
Sorry if this is a known issue which I've missed.
"Autorefit to any available cargo" seems to work imperfectly with cargodist. I think what is going on is that the vehicle autorefits based on the total available cargo, not the cargo which might actually be loaded onto the vehicle. This is very apparent with a station from which pax and mail go in many directions.
"Autorefit to any available cargo" seems to work imperfectly with cargodist. I think what is going on is that the vehicle autorefits based on the total available cargo, not the cargo which might actually be loaded onto the vehicle. This is very apparent with a station from which pax and mail go in many directions.
Re: Cargo Distribution
In fact autorefit should work fine, with some restrictions concerning reservation and initial route finding. For the case you're describing I've written a bit of code which should refit the loading vehicle to the cargo of which the highest amount is waiting for a ride to the vehicle's next stop. I won't be able to debug this until next week but it would be very helpful if you could provide a savegame.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
Ah, cargo distribution, something that I was very much looking forward to back when I was active.
After giving it a go, I must admit it is making passengers a more interesting game. I have noted cargo that is waiting at a station en-route forgets it's true "Source" in the tree view of cargo waiting at the station. I assume this is by design, as it would be a nightmare to store where cargo has been as well as planning where it needs to go next.
I have a server that I can put this on for the purposes of testing and such, if that would help testing.
After giving it a go, I must admit it is making passengers a more interesting game. I have noted cargo that is waiting at a station en-route forgets it's true "Source" in the tree view of cargo waiting at the station. I assume this is by design, as it would be a nightmare to store where cargo has been as well as planning where it needs to go next.
I have a server that I can put this on for the purposes of testing and such, if that would help testing.
The occasional look back at your past can teach you a great many things...
Re: Cargo Distribution
cargo remembers where it was produced (for subsidy purposes) and where it was first and last loaded at a station (for payment purposes), but there can and will not be a list of previously visited stations
Re: Cargo Distribution
This example for autorefit seems to work fine. There are some pitfalls with autorefit, some of which are already present in trunk:
- For each of the desired cargoes you have to initially send at least one vehicle refitted to that cargo to the source station with a pick up order. Otherwise the source industries won't deliver to your station.
- For each of the desired cargoes you have to initially complete one full route to any destination stations using vehicles refitted to that cargo. Otherwise cargodist won't know the cargo can travel along that route and won't route it.
- https://github.com/ulfhermann/openttd/issues/10 - or, improved loading and autorefit don't like each other.
- Attachments
-
- autorefit.sav
- (8.61 KiB) Downloaded 44 times
Last edited by fonso on 08 Apr 2013 15:50, edited 1 time in total.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
That is not as straightforward as it might be. I'll try to generate one afresh when I have some time.fonso wrote:damerell: I'm still curious to see a savegame showing your problem.
Re: Cargo Distribution
Question: if OpenTTD locks up, and does not produce a crash report, what would the recommended steps be? There is no NewGRF running at this time, just OpenTTD with CargoDist. Happens twice, and I have to kill the process. Otherwise, just lays there doing nothing behind a white veil of doom. I honestly have no clue what I did that could cause this.
EDIT: Oops.
Windows 7
ga2c8b50e-cd version of openttd, downloaded from nightly binary server, unzipped into folder.
Edit 2: It is possible that I may have a malfunctioning AI, would that be the cause?
Edit 3: Third runaround of an autosave finally produced a crash report. It is attached to this.
Edit 4: Tried a new game with no AI or newgrf. Same behavior. This time, the saved game freezes on July 14th without fail every time. No crash report (yet), trying to force the game to produce it. The saved game is now uploaded.
EDIT: Oops.
Windows 7
ga2c8b50e-cd version of openttd, downloaded from nightly binary server, unzipped into folder.
Edit 2: It is possible that I may have a malfunctioning AI, would that be the cause?
Edit 3: Third runaround of an autosave finally produced a crash report. It is attached to this.
Edit 4: Tried a new game with no AI or newgrf. Same behavior. This time, the saved game freezes on July 14th without fail every time. No crash report (yet), trying to force the game to produce it. The saved game is now uploaded.
- Attachments
-
- OpenTTD.rar
- (221.22 KiB) Downloaded 47 times
-
- Bedtown Transport, 5th Jul 1944.sav
- Save of the game. Freezes on 14th July 1944. No crash report.
- (5.8 MiB) Downloaded 46 times
Re: Cargo Distribution
Thanks for the report. I'll look into it.
If you encounter a "freeze" behavior you should post a description, as detailed as possible, of the events leading up to it with one or two savegames from before the event. A savegame from shortly before the event is always good. Another savegame of a some while back may be interesting if the game in the other one is already "doomed" with no way to reproduce how it got into that state. A freeze does not necessarily lead to a crash. It can be an infinite loop in the code that just goes in circles forever if you don't kill it.
I don't know if malfunctioning AIs can cause a hang. As far as I know the Squirrel interpreter is modified to the effect that it only permits a limited amount of operations per time unit for each AI. In that case an AI locking up the game would show a bug in the AI framework of openttd.
If you encounter a "freeze" behavior you should post a description, as detailed as possible, of the events leading up to it with one or two savegames from before the event. A savegame from shortly before the event is always good. Another savegame of a some while back may be interesting if the game in the other one is already "doomed" with no way to reproduce how it got into that state. A freeze does not necessarily lead to a crash. It can be an infinite loop in the code that just goes in circles forever if you don't kill it.
I don't know if malfunctioning AIs can cause a hang. As far as I know the Squirrel interpreter is modified to the effect that it only permits a limited amount of operations per time unit for each AI. In that case an AI locking up the game would show a bug in the AI framework of openttd.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
Actually in this case it would be very nice to have an earlier version of "Bedtown Transport, 5th Jul 1944.sav" and some savegame from before the crash. I can see from the savegame and the dump that the games are in an invalid state but it's hard to find out how they got there.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
I've found and fixed a possible cause for the hangs and crashes. The new fixed version gbc14f0a9-cd will be savegame-compatible with ga2c8b50e-cd. I'm not sure if I've found the actual root problem. It would be very nice to have an earlier savegame so that I could check that.
Besides, the link graph overlay was pretty broken in the last versions. It always showed links in both directions even if they were unidirectional and the capacities were messed up. I've also fixed that.
Besides, the link graph overlay was pretty broken in the last versions. It always showed links in both directions even if they were unidirectional and the capacities were messed up. I've also fixed that.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
January 1942 autosave. Hopefully this is far back enough.fonso wrote:Actually in this case it would be very nice to have an earlier version of "Bedtown Transport, 5th Jul 1944.sav" and some savegame from before the crash. I can see from the savegame and the dump that the games are in an invalid state but it's hard to find out how they got there.
EDIT: Ran the new build using old save game. Froze on the same day as before (July 14). Is that savegame doomed? I will create a new game and report back with results.
- Attachments
-
- autosave2.sav
- (5.46 MiB) Downloaded 48 times
Re: Cargo Distribution
Brand New Game. Same result. Crash Results posted. Cant upload saved games to this because its over 6mb, but here is the link to the saved games:_frozen wrote:January 1942 autosave. Hopefully this is far back enough.fonso wrote:Actually in this case it would be very nice to have an earlier version of "Bedtown Transport, 5th Jul 1944.sav" and some savegame from before the crash. I can see from the savegame and the dump that the games are in an invalid state but it's hard to find out how they got there.
EDIT: Ran the new build using old save game. Froze on the same day as before (July 14). Is that savegame doomed? I will create a new game and report back with results.
Early Save: http://www.puu.sh/2uO61
Autosave about 2 years prior: http://www.puu.sh/2uO7l
Crash Save: http://www.puu.sh/2uO8c
I hope this is helpful!
- Attachments
-
- crash2.rar
- Crash files
- (417.06 KiB) Downloaded 38 times
Re: Cargo Distribution
I'm still not 100% sure if that is the real problem but I have found a way how an invalid state triggering that assert could be reached by deleting stations during the calculation of their link graph. It seems the PAXLink AI in the saves by _frozen does that but I can't reproduce the exact sequence of events. Anyway, the bug I've found is fixed in gbfdccd1b-cd. That version is savegame-compatible with the previous ones and I've added a few asserts to detect the problem earlier if it persists. Thanks for the report.
The guy on the picture is not me, it's Alonso.
-
- Engineer
- Posts: 8
- Joined: 07 Apr 2013 16:01
Re: Cargo Distribution
Got a freeze whith "AppHangB1" in two savegames. It looks like beeing somehow connected with recalculation of distribution graph - the exact time of freeze chages when I change the recalculation interval.
Operational systems Win7 & Win8
Versions of CargoDist: geef1f48f (Win64, Win32) gbc14f0a9 (Win64)
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing - Freezes at 13th of August
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing - Frezes at 4th of July
Operational systems Win7 & Win8
Versions of CargoDist: geef1f48f (Win64, Win32) gbc14f0a9 (Win64)
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing - Freezes at 13th of August
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing - Frezes at 4th of July
Re: Cargo Distribution
I think I've also found this one. The new version is called g0b8fde5c-cd now. Here it would also be very interesting to have an earlier savegame.
The problem was that in certain cases the updating of link stats during full loading could add links to the invalid station "0". A combination of that with _frozen's first bug created an infinite loop. Probably the bug was triggered by changing orders (especially go to depot and refit) while a vehicle was loading. That must have happened to the wood products trains going from Sonnway-on-Sea West to Sonnway-on-Sea Halt. German_RLI: Can you remember doing something like that?
The problem was that in certain cases the updating of link stats during full loading could add links to the invalid station "0". A combination of that with _frozen's first bug created an infinite loop. Probably the bug was triggered by changing orders (especially go to depot and refit) while a vehicle was loading. That must have happened to the wood products trains going from Sonnway-on-Sea West to Sonnway-on-Sea Halt. German_RLI: Can you remember doing something like that?
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
PAXLink will add/remove feeder stations for the airport quite often. It will try to not have more feeder stations than needed to provide an airport with enough passengers to supply the current aircraft. In my experience the number of feeder buses and stations will go up and down quite a lot. (which is probably one of the reasons why the AI is not very good to survive economically)fonso wrote:I'm still not 100% sure if that is the real problem but I have found a way how an invalid state triggering that assert could be reached by deleting stations during the calculation of their link graph. It seems the PAXLink AI in the saves by _frozen does that but I can't reproduce the exact sequence of events. Anyway, the bug I've found is fixed in gbfdccd1b-cd. That version is savegame-compatible with the previous ones and I've added a few asserts to detect the problem earlier if it persists. Thanks for the report.
_frozen: Note that PAXLink has no code to adopt to cargodist. Thus it may or may not give problem when passengers now do not all get off at the airport but will also want to go further using buses. Among other things, the AI can not tell if passengers at the airport are waiting for a local bus to get to their destination or if they wait for an aircraft to the other town.
That said, if it works for you and you like to have it in your game, I'm more than happy that someone enjoys this AI that I've spent quite a lot of time to develop.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: Cargo Distribution
As long as the busses do "transfer and leave empty", no passengers should try to board the busses. however, you might want to switch passengers to "aysmmetric" for better effects
-
- Engineer
- Posts: 8
- Joined: 07 Apr 2013 16:01
Re: Cargo Distribution
Yes, I have changed the order list of trains going there when paper mill on Sonnway Halt was closed. It's looks like when I have two trains with fullload orders and redirect only one of them, it causes no problem.fonso wrote:That must have happened to the wood products trains going from Sonnway-on-Sea West to Sonnway-on-Sea Halt. German_RLI: Can you remember doing something like that?
Earlier saves:
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing
https://docs.google.com/file/d/0B3Iz0W0 ... sp=sharing
Re: Cargo Distribution
The problem only occurs in very special cases when the timing between loading vehicle, remaining cargo to be loaded and order change is just right. It manifests itself only later when the bogus link graph is recalculated. I wasn't able to reproduce it. Thanks for the savegames.
The guy on the picture is not me, it's Alonso.
Re: Cargo Distribution
As you may have noticed I have changed my git repositories around a bit. I've decided that it's silly to have multiple github accounts and because of that I'll eventually remove the "fonsinchen" account. The official repository is now at http://github.com/ulfhermann/openttd , not at http://github.com/fonsinchen/openttd-cargodist anymore. I'll keep the old repository around for a while, until everyone has fixed their settings.
The guy on the picture is not me, it's Alonso.
Who is online
Users browsing this forum: Semrush [Bot] and 5 guests