George wrote:

and a version with front part report (report fail text for front part)

Attachments

• testw.grf (75.81 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5352

frosch wrote:

v->cur_image is updated after each part has been moved.
To fix this, all images need updating after all parts have been moved.

Same applies to trains.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5355

Rubidium wrote:

Wouldn't this NewGRF be horribly broken when the vehicle crashes and gets random orientations? It could be in basically any state, even 180 degrees between the parts.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5391

George wrote:

Rubidium: Yes, the degree can be 180, but it can happen and when RV turns around, for example. So, support for every degree between parts is planned.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5396

Rubidium wrote:

We need to update cur_image while it's being moved as only one vehicle can be moved at a time. Unless we completely turn this behaviour around it won't be possible to update cur_image outside of the loop without glitches.

So fixing this would basically mean adding _old_vehicle_coords to the vehicle struct just to support this. I'm not sure whether that's worth the effort. Or is it cheaper to just mark the viewports before and after moving instead of keeping track of what needs to be marked and mark them at the same time?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5743

Rubidium wrote:

Marking the viewports twice costs about 1.5 to 2% more CPU with ~500 trains.

Moveing the _old_vehicle_coords into the vehicle struct costs about 2 to 3% less CPU with ~500 trains (need to confirm this on other systems). The location where EndVehicleMove (and thus the viewport update) was called has not been changed.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5752

frosch wrote:

just to add: if the position hash depends on the sprite size, that is also a desyncer, as sprites can be changed with static grfs resp. 32bpp

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5759

Rubidium wrote:

The position hash depends on the sprite size. However... the position hash is only used for adding vehicles to the viewport. The "new vehicle position hash" uses v->tile and is used by the game's internals.

So there's no chance of desyncs here.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546#comment5760

Rubidium closed the ticket.

Reason for closing: Fixed

In r15677.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2546