Belugas wrote:

although it has been verified that it actually works on our side, George, it is reopened.
Now: it would be nice if you could provide grf as well as screenshots of good and bad behaviour

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment2992

George wrote:

the same grf, 2 s different screen shots

Attachments

• 4LVw.grf (2291.00 KiB)
• 11588.png (154.94 KiB)
• 11629.png (215.28 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment2993

Rubidium wrote:

For me 11629 works as intended with the provided NewGRF.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment2999

George wrote:

config

Attachments

• openttd.cfg (6.13 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3003

Rubidium wrote:

Can you post a savegame that shows this behaviour?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3009

George wrote:

Do not watch at coal mine like iron ore mines industry - it is a test grf for iron ore mine used, just ignore it. If necessary, I can make a blank game.

Attachments

• Sharkey & Co., 26th Feb 1984.sav (135.96 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3010

Rubidium wrote:

Seems rather like a local configuration problem to me. Anyhow, looks like TTDP disables the NewGRF in that case, so we should too.

Attachments

• fs1461.png (117.93 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3011

George wrote:

Yes, you should. But why does it loading after error? The GRF should be totally disabled (and marked red), doesn't it?

P.S. Yes, reordering files fixes the display problem, but it is rather confusing that GRF with error is still loading.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3014

Rubidium wrote:

Because the persons who have messed with implementing Action 7 did not understand the NewGRF specs completely it did not disable the NewGRF, it just skipped all 'next' sprites. Anyhow... if a NewGRF should be disabled with an error, why don't you use the Action B 'fatal error' that immediately disables the NewGRF instead of relying on yet another piece of NewGRF?

Anyhow, that not-completely-correctly-implemented-Action-7 issue should be solved in the current trunk.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3015

George wrote:

With fatal error you can't load the grf unless you restart TTDp. In current situation you can fix error by disabling ECS files after LV4, so the error is not fatal.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3017

Rubidium wrote:

Anyhow... is it better in today's nightly?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3029

George wrote:

I loaded the save, got the error as intended, reordered the files (moved LV4 to the end), pressed applay... Error disappeared, but file stayed disabled without reporting a reason for disabling. I supposed it to become enabled :(

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3032

Fragster wrote:

I guess this bug appears not only with LV4... same thing happens with UKRS from Pikkabird

Attachments

• mineral wagon.png (191.63 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3033

Rubidium wrote:

Those wagons are different because they are different mineral wagons (they are not equal in length).

This comment was imported from FlySpray: https://bugs.openttd.org/task/1461#comment3109

Rubidium closed the ticket.

Reason for closing: Fixed

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