Cargo packet change suggestion

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
User avatar
Expresso
Tycoon
Tycoon
Posts: 1760
Joined: 09 Aug 2004 00:14
Location: Gouda, the Netherlands

Cargo packet change suggestion

Post by Expresso »

Something which has puzzled me for a while now, is that the game keeps track of how long a particular cargo packet is in transit in the number of days.

A better solution would be to keep track of the date a particular packet was created and the number of days spent at stations (this requires keeping track of the date the cargo packet is dropped off at a station). However, this does add 8 bytes to the cargopacket class.

If this gets implemented, only perishables need to be processed when in a vehicle, potentially increasing performance a bit. Days in transit then becomes a simple computation formulate:

(current date - generation date) - days at stations = days in transit.

As for the year cheat, a simple calculation could fix that (subtract/add x years and you are done).

EDIT: after posting this, it occurred that instead of storing the date, the game could instead store the tick information. That way you don't get all kinds of ugliness to deal with day length patches.

NOTE: I posted this here, because this isn't a suggestion for a new feature and purely deals with how stuff works internally, thus I felt the suggestions forum to be inappropriate for this post.
User avatar
FooBar
Tycoon
Tycoon
Posts: 6553
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Cargo packet change suggestion

Post by FooBar »

Expresso wrote:(this requires keeping track of the date the cargo packet is dropped off at a station)
You would need way more than 8 bytes for that.

Imagine a cargo packet transferred a million times (unrealistic, but it's possible to do so). Then you'd need to store a million "arrived at station" timestamps.
Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Cargo packet change suggestion

Post by Terkhen »

Cargopackets are one of the intensive entities in both memory and CPU processing time. Things get worse with a destination/distribution implementation. Even 8 extra bytes per cargopacket is quite a lot already.
Arie-
Director
Director
Posts: 593
Joined: 20 Jan 2009 16:07

Re: Cargo packet change suggestion

Post by Arie- »

If I understand this suggestion correctly it will reduce CPU requirements and increase the memory footprint of a game?
User avatar
Expresso
Tycoon
Tycoon
Posts: 1760
Joined: 09 Aug 2004 00:14
Location: Gouda, the Netherlands

Re: Cargo packet change suggestion

Post by Expresso »

FooBar wrote:
Expresso wrote:(this requires keeping track of the date the cargo packet is dropped off at a station)
You would need way more than 8 bytes for that.

Imagine a cargo packet transferred a million times (unrealistic, but it's possible to do so). Then you'd need to store a million "arrived at station" timestamps.
No, the "stored at station" time stamp is needed only once per station. If a vehicle comes to pick up the cargo packet, you can compute the number of days the cargo packet has been waiting at the station and simply add to the "waited at station" counter. That counter would need to be large enough in order to accommodate the result of a million transfers, though. :) This way you can recycle the "stored at station" counter.
Terkhen wrote:Cargopackets are one of the intensive entities in both memory and CPU processing time. Things get worse with a destination/distribution implementation. Even 8 extra bytes per cargopacket is quite a lot already.
Yes, well. In that case the space currently being used by the two tileindexes already stored in a cargopacket (they can be figured out) could be used for this instead. Loaded_at_xy could then become Loaded_at_station (making it 2 or 3 bytes (to accomodate FooBar's million transfers)). The increase at this point comes down to two or three bytes.

EDIT: The whole point of this suggestion is in order to reduce CPU consumption of cargo packets. What's the point of visiting a cargo packet just to increase a counter when that counter can be avoided in the first place?
Yexo
Tycoon
Tycoon
Posts: 3663
Joined: 20 Dec 2007 12:49

Re: Cargo packet change suggestion

Post by Yexo »

Arie- wrote:If I understand this suggestion correctly it will reduce CPU requirements and increase the memory footprint of a game?
It'll definitely increase memory usage. Whether it actually reduces CPU usage has to be measured.
Expresso wrote:
Terkhen wrote:Cargopackets are one of the intensive entities in both memory and CPU processing time. Things get worse with a destination/distribution implementation. Even 8 extra bytes per cargopacket is quite a lot already.
Yes, well. In that case the space currently being used by the two tileindexes already stored in a cargopacket (they can be figured out) could be used for this instead. Loaded_at_xy could then become Loaded_at_station (making it 2 or 3 bytes (to accomodate FooBar's million transfers)). The increase at this point comes down to two or three bytes.
The tile can't be figured out in case the original station gets removed, that's the reason we have that variable.
EDIT: The whole point of this suggestion is in order to reduce CPU consumption of cargo packets. What's the point of visiting a cargo packet just to increase a counter when that counter can be avoided in the first place?
And it might work, or it might not work. But it requires proper testing to show that is actually has a positive effect. More memory usage might result in more cache misses which might result in more slowdowns than you win by reducing the amount of work. Again, all speculation, it needs to be coded and tested.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Cargo packet change suggestion

Post by Rubidium »

Another caveat of storing the actual creation and arrival dates is that more packets are generated. At the moment packets are coalesced when their origin and days in transit is the same, so if you transport wood from an industry to a "feeder" station, then all wood cargo would be stored in a single packet at the feeder station since the days in transit is the same. This means that cargo can be moved around with less cargo packets.

Adding more data to cargo packets means that there is more difference, thus more cargo packets and less use for coalescing; possibly even to the point that coalescing makes no sense and you would have a single cargo packet for a single unit of cargo instead of one cargo packet for all cargo in the vehicle. That ofcourse means that you need to iterate over much more cargo packets when (un)loading.

So it isn't "simply" adding some extra bytes to the cargo packets to remove some other loop, you are also increasing the size of the loops that you aren't going to remove. Then ofcourse you should not break the NewGRF feature regarding cargo aging.
Creat
Traffic Manager
Traffic Manager
Posts: 141
Joined: 26 Oct 2009 16:33

Re: Cargo packet change suggestion

Post by Creat »

Also possibly problematic might be date cheats, most notably setting the time back a significant amount. Not a primary concern of course :)
User avatar
fonso
President
President
Posts: 945
Joined: 13 Oct 2007 08:28

Re: Cargo packet change suggestion

Post by fonso »

Rubidium wrote:Another caveat of storing the actual creation and arrival dates is that more packets are generated. At the moment packets are coalesced when their origin and days in transit is the same, so if you transport wood from an industry to a "feeder" station, then all wood cargo would be stored in a single packet at the feeder station since the days in transit is the same. This means that cargo can be moved around with less cargo packets.

Adding more data to cargo packets means that there is more difference, thus more cargo packets and less use for coalescing; possibly even to the point that coalescing makes no sense and you would have a single cargo packet for a single unit of cargo instead of one cargo packet for all cargo in the vehicle. That ofcourse means that you need to iterate over much more cargo packets when (un)loading.

So it isn't "simply" adding some extra bytes to the cargo packets to remove some other loop, you are also increasing the size of the loops that you aren't going to remove. Then ofcourse you should not break the NewGRF feature regarding cargo aging.
If you store "date_created", "days_in_stations" and "date_current_station" instead of "days_in_transit" you can trivially determine the value for "days_in_transit" from the stored data and merge packets if they are equal in that. date_current_station would be set to current_date once a vehicle enters a station, days_in_stations would be incremented with "current_date - date_current_station" when the vehicle leaves a station. At that point date_current_station would have to be set to some INVALID_DATE value (or maybe we can figure out the "in station" state somehow else). The formula for days_in_transit would be (in pseudo code):

Code: Select all

days_in_transit = ((date_current_station == INVALID_DATE ? current_date : date_current_station) - date_created) - days_in_stations
Like this you can keep the coalescing behavior without incrementing a counter for each packet every day.
The guy on the picture is not me, it's Alonso.
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: Cargo packet change suggestion

Post by Eddi »

you'll need to fiddle the cargo aging modificator in there, for each transfer leg
User avatar
Tafidis
Traffic Manager
Traffic Manager
Posts: 157
Joined: 19 Oct 2010 19:49

Re: Cargo packet change suggestion

Post by Tafidis »

Having advocated a "timestamp" system before myself, I would like to add on this a bit.

I think it only makes sense if cargo actually does age at stations (this has also been suggested), in which case the formula is simplified significantly. You only need load and unload dates to calculate payments.

W.r.t to feeder systems:
fonso wrote: Code:
days_in_transit = ((date_current_station == INVALID_DATE ? current_date : date_current_station) - date_created) - days_in_stations
Eddi wrote: you'll need to fiddle the cargo aging modificator in there, for each transfer leg
This is the most difficult to do, days_in_transit counter is the easiest way to penalize/reward both the individual leg as well as the entire route without going into heavy calculations. Otherwise, you need to keep some info on each leg until the end or modify some of the variables (such as date_created and/or feeder_share) to reflect on different aging behaviour "so far".

w.r.t daylength patches:
Expresso wrote:after posting this, it occurred that instead of storing the date, the game could instead store the tick information. That way you don't get all kinds of ugliness to deal with day length patches.
I believe the contrary, a timestamp system would be paving the way for a consistent daylength patch, i.e. not having to consider "how many ticks in a day" and all that. [In fact i believe Pavel's daylength patch does not work like that at all. It just skips increasing the tick counter a set amount of times.]

So, a timestamp system has its pros and cons, which cannot be found out until such a system has been developed and tested. I would like to help in doing this, but do not have the time, unfortunately.
Citizens Celebrate! First train arrives in <insert your favourite town/station name here>!
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Cargo packet change suggestion

Post by planetmaker »

Tafidis wrote:I think it only makes sense if cargo actually does age at stations(...)
I have to disagree quite thoroughly. For once the cargo aging is a nice means to differenciate between slow and fast vehicles. And for second it's nice means to differenciate between comfort (slower aging) and economy class (normal or faster aging) vehicles. Removing these two elements from cargo income calculations would basically make sure that all cargo pays the same per tile, irrespective of the mode and duration of transport.
User avatar
fonso
President
President
Posts: 945
Joined: 13 Oct 2007 08:28

Re: Cargo packet change suggestion

Post by fonso »

Well, alternately one could also save days_in_transit and a date_last_loaded (if that isn't even there already). Then you only have to update days_in_transit when unloading some cargo. At that point you know the vehicle you're unloading from, the date you loaded the cargo and the date when you're unloading the cargo so it's easy to calculate the increment for days_in_transit. Merging packets would be slightly more complicated. You'd have to "update" the date_last_loaded of the packet to be merged with to the current date and then compare days_in_transit. It's no rocket science, though.
The guy on the picture is not me, it's Alonso.
User avatar
Tafidis
Traffic Manager
Traffic Manager
Posts: 157
Joined: 19 Oct 2010 19:49

Re: Cargo packet change suggestion

Post by Tafidis »

@planetmaker:

Er, aging the cargo while waiting at stations does not remove the behaviour you describe. You still make more if you transfer the cargo faster and/or with containers in which cargo is aging slower. But it also adds complexity in that perhaps you can add facilities to the station (non-track tiles) that modify the aging factor at the station itself. Right now you can transfer from primary industries to intermediate stations in which cargo can wait very long before starting to decay in quantity and still get almost the same payment as you would for a direct transport. But all this is off-topic in this thread.

I think that, for the current game behaviour, the days_in_transit counter is the simplest implementation, or so my limited coding knowledge suggests.
Citizens Celebrate! First train arrives in <insert your favourite town/station name here>!
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Argus and 19 guests