Transfer bug (again)

[Quark]

I was reporting this a while ago, but it seems that nobody want to fix it, so there is ill report again.

Every station has fixed-size GoodsEntry

Code: Select all

GoodsEntry goods[NUM_CARGO];

Code: Select all

typedef struct GoodsEntry {
	uint16 waiting_acceptance;
	byte days_since_pickup;
	byte rating;
	StationID enroute_from;
	byte enroute_time;
	byte last_speed;
	byte last_age;
	int32 feeder_profit;
} GoodsEntry;

It can store only one cargo entry of same type, it can't store two entry of same type, but with different ‹enroute_from›

Then here is one fucntion that reset ‹enroute_from› and ‹enroute_time›, so our valuable cargo get transferred unpayed.

Code: Select all

static void UpdateStationWaiting(Station *st, int type, uint amount)
{
	SB(st->goods[type].waiting_acceptance, 0, 12,
		min(0xFFF, GB(st->goods[type].waiting_acceptance, 0, 12) + amount)
	);

	st->goods[type].enroute_time = 0;
	st->goods[type].enroute_from = st->index;
	InvalidateWindow(WC_STATION_VIEW, st->index);
	MarkStationTilesDirty(st);
}

that was called from TransportIndustryGoods and TileLoop_Town, TileLoop_Unmovable

Also ‹enroute_from› is reseting when new cargo is unloaded with new ‹enroute_from› value in LoadUnloadVehicle

So we can done with it? At least we can pay for tranfer when reseting ‹enroute_from› and ‹enroute_time› values, so industry will «buy» that cargo, but it isn't most correct solution anyway.

[prissi]

This requires cargo packets. As soon as the bugs from the passenger destination stuff are fixed, I will look into this. The current code should be easily extend to CargoPackets then.

[Quark]

do you remember my PM?

Can you make patch that will save cargo source when vehichle unload cargo for trasfer? currently if 2 vehichles unload cargo on one station or station produces more cargo then all cargo on station get source that match source from latest unloaded cargo

and your reply:

It would be possible (actually, that was the cargo packets idea). However, this would make the size to 10 bytes, which is badly aligned and would require more effort for route storage and so on. Therefore, I did not follow the initial idea. Also OTTD cannot handle passengers traveling for more than 255 days, which also could happen often with transfers.

Sorry to deny this,
Markus

What about just use ‹enroute_to› as ‹enroute_from› for cargo in CargoEntry?

Is here a way to just make GoodsEntry dynamic (extensible) array and check for ‹enroute_from› when looking for cargo?

[Darkvater]

Celestar is also working on cargopackets, or will be. There was a cargopackets branch from a while ago by Celestar as well but it has been abandoned.