Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo capacity should be recalculated on TRIGGER_VEHICLE_NEW_LOAD #6907

Closed
George-VB opened this issue Sep 16, 2018 · 12 comments
Closed

Cargo capacity should be recalculated on TRIGGER_VEHICLE_NEW_LOAD #6907

George-VB opened this issue Sep 16, 2018 · 12 comments
Labels
component: NewGRF This issue is related to NewGRFs needs triage This issue needs further investigation before it becomes actionable stale Stale issues

Comments

@George-VB
Copy link

Tested on 1.8.0 stable

I've got serious problem with varying capacity wagons (container platform).
A platform can carry one or two containers, which is defined with TRIGGER_VEHICLE_NEW_LOAD.
The loading speed CB, the capacity CB, graphics are different depending on random_bits.
Loading speed CB and graphics work well, but capacity CB works only once. After the first change it stays unchanged, providing capacity, that is incorrect for the current graphics.
Please force the recalculating of capacity CB after TRIGGER_VEHICLE_NEW_LOAD.

You can test the issue with 11-H004 flatbed http://bundles.openttdcoop.org/xussrset/push/LATEST/

image

@George-VB
Copy link
Author

A workaround for the correct values. Force the train to refit to some other cargo, that is not available on both stations, and back to the required cargo on loading. You will get capacity to be recalculated on refit and always get the right values and graphics.

@andythenorth andythenorth added component: NewGRF This issue is related to NewGRFs needs triage This issue needs further investigation before it becomes actionable labels Sep 16, 2018
@George-VB
Copy link
Author

Capacity CB code
https://dev.openttdcoop.org/projects/xussrset/repository/entry/src/freight/cargoes-capacity-refit.pnml
Loading speed CB code
https://dev.openttdcoop.org/projects/xussrset/repository/entry/src/freight/cargoes-loadspeed.pnml
Graphics code
https://dev.openttdcoop.org/projects/xussrset/repository/entry/src/freight/cargoes8/container/containers.pnml

Typical code to choose - (random_bits >> 1) & 0x01

switch (FEAT_TRAINS, SELF, cargo8_container_2_20or40_sprites, (random_bits >> 1) & 0x01)
{
0: cargo8_container_40_sprites;
cargo8_container_2_20_sprites;
}

@George-VB
Copy link
Author

A workaround does not work for long train. last wagons of 9 square train become damaged the same way - capacity does not fit the random bits

@George-VB
Copy link
Author

To prevent error I've commented the difference in capacity CB.
If you would like to test you have to uncomment these strings:
switch (FEAT_TRAINS, SELF, container_20and40_cargo_capacity,
[ STORE_TEMP(2, 7),
((random_bits >> 1) & 0x01) ] )
{
// 0: container_2040_cargo_capacity;
container_2_20_cargo_capacity;
}

switch (FEAT_TRAINS, SELF, container_2_20or40_cargo_capacity,
[ STORE_TEMP(2, 7),
((random_bits >> 1) & 0x01) ] )
{
// 1: container_2_20_cargo_capacity;
container_40_cargo_capacity;
}

@TheGwyd
Copy link

TheGwyd commented Nov 7, 2018

I think the problem here is that the game doesn't like to change the cargo capacity of vehicles when they are not in the depot. This is because is can cause desyncs and is unreliable in certain situations (giving the vehicle more cargo that it can actually take). This is seen if a NewGRF which has been adjusted to give a vehicle in the game a different capacity. This gives an error saying "vehicle xx has had capacity changed. This can harm the game state" or something along those lines.
I would not consider this a bug, rather the approach of your NewGRF may need a different approach to the issue.

@George-VB
Copy link
Author

The game already allows changing capacity at station with autorefit (outside depot!).
The problem is that it does not force recalculating capacity before loading (after autorefit and new cargo trigger) .

@stale
Copy link

stale bot commented Jan 24, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Jan 24, 2019
@George-VB
Copy link
Author

The problem is not fixed in master 27012019

@stale stale bot removed the stale Stale issues label Jan 28, 2019
@PeterN
Copy link
Member

PeterN commented Jan 28, 2019

Hmm, the trigger is called after the cargo quantity is reserved, as well.

@andythenorth
Copy link
Contributor

andythenorth commented Jan 28, 2019

I might be 100% wrong, but this issue reminds me of autorefit bugs I saw when testing cdist stuff for fonsinchen, which resulted in this fix f790d70#diff-ebbc445f07842947d83d0f98b7fa5140L1568

The comment is interesting, curious if cargo loading reservation causes the autorefit to not happen.

@George-VB
Copy link
Author

@stale
Copy link

stale bot commented Apr 4, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Apr 4, 2019
@stale stale bot closed this as completed Apr 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs needs triage This issue needs further investigation before it becomes actionable stale Stale issues
Projects
None yet
Development

No branches or pull requests

4 participants