The International Simutrans Forum

Simutrans Extended => Simutrans-Extended development => Simutrans-Extended bug reports => Topic started by: Ranran on September 10, 2018, 10:05:07 AM

Title: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: Ranran on September 10, 2018, 10:05:07 AM
Hi. I noticed that there was a bug in the drawing of the bridge. (´・ω・`)
Even though has_own_way_graphics = 1, most parts are drawn like has_own_way_graphics = 0.

pak.nippon's case:
These are bridges of pak nippon, I added has_own_way_graphics = 1 and paked for extended.

The source images are these: bridge-3 ( bridge-4 ( bridge-5 (

An unintended ballast is drawn under the bridge. It's hard to see, but ramps are the same.
After construction, only the last one squares are displayed correctly(unintended ballast not drawn), but if you turn the camera or load the saved game, only one square on the front side will be displayed correctly.

pak.256's case:
Perhaps the bridge of "pak.256" is the same. This is very recognizable than the example above. I believe that the image of the cursor is the correct appearance.

This is a test to check the behavior of has_own_way_graphics = 1:
I modified pak by changing BrickViaduct and BrickViaductRoad of 128britain-EX to has_own_way_graphics = 1.
They are displayed like this.

Drawing of BrickViaductRoad is the same as other pakset.
However, only BrickViaduct is drawn as intended unlike other pakset. Moreover, rotating the map will not break it.

the modified pak can download from here: BrickViaduct (, BrickViaductRoad (

next: pak.sweden's case
I put modified BrickViaduct and BrickViaductRoad in pak.sweden.
They are displayed like this.
The drawing of modified BrickViaduct which was normal in Britain-EX is broken somehow. ???

I suppose that this bug is related to my previous bug report (,18136.0.html) about "High Voltage transmission line bridge".
In case of transmission bridge, it may be drawing the trash image as a result of trying to draw an image which does not exist(things like ballast).

EDIT: Drawing bug of has_own_way_graphics and drawing bug of power line bridge seems to be another issue.
EDIT2: changed the thread title more clearly.
Title: Re: Bridge drawing bug
Post by: jamespetts on September 10, 2018, 06:45:42 PM
Thank you for the report. The bug with the power lines has been notoriously difficult to find - given the other challenging bugs at present, I will have to regard this as a low priority issue for now, although if anyone can find the cause of this issue, that would be very helpful.
Title: Re: Bridge drawing bug
Post by: Ranran on September 10, 2018, 10:15:11 PM
I tested by replacing void bruecke_t::calc_image() in with standard's code.
(Note that I rewrote "set_foreground_image" to "set_after_image".)
Code: [Select]
void bruecke_t::calc_image()
grund_t *gr = welt->lookup(get_pos());
if (gr) {
// if we are on the bridge, put the image into the ground, so we can have two ways ...
if (weg_t *weg0 = gr->get_weg_nr(0)) {
// if on a slope then start of bridge - take the upper value
const slope_t::type slope = gr->get_grund_hang();
bool is_snow = welt->get_climate(get_pos().get_2d()) == arctic_climate || get_pos().z + slope_t::max_diff(slope) >= welt->get_snowline();

// handle cases where old bridges don't have correct images
image_id display_image = desc->get_background(img, is_snow);
if (display_image == IMG_EMPTY && desc->get_foreground(img, is_snow) == IMG_EMPTY) {
display_image = desc->get_background(single_img[img], is_snow);



if (weg_t *weg1 = gr->get_weg_nr(1)) {

Then no power line bridge drawing errors are seen.

Latest nightly build

Own testing build(Standard's code)

Latest nightly build

Own testing build(Standard's code)
Note: since it is standard code, has_own_way_graphics is not supported and the drawing of the road bridge is broken.

From the above, I guess that there is an error in Extended's bruecke_t::calc_image() or related part(Extended specific).
bruecke_t::calc_image() has been modified from standard for separating bridge and way image.
I am not familiar with C++ so I hope someone will help with this.

Title: Re: Bridge drawing bug
Post by: DrSuperGood on September 11, 2018, 03:09:19 AM
Might be useful if you could assemble a test map that clearly shows off all these issues in one place and labels all the cases with signs. Can use its own pakset if need be.

This way when someone eventually comes around to fix it the map can be used as a check list to make sure it really is fixed.
Title: Re: Bridge drawing bug
Post by: ACarlotti on September 11, 2018, 05:31:37 AM
So it's a bug currently in Extended that isn't currently in Standard. At a glance there seem to be no functional changes to calc_image in Standard that aren't already in Standard, so the differences are entirely due to changes made in Extended. I'm not familiar enough with that code to be able to debug it now, but if noone else solves this in the next couple of weeks I could take a look.
Title: Re: Bridge drawing bug
Post by: Ranran on September 11, 2018, 01:13:02 PM
Thank you both.

I changed the current code by just one line like this. Then the drawing bug of power line bridge disappeared. And the drawing of has_own_way_graphics(railway bridges and road bridges) seems to be the same as before.
Drawing bug of has_own_way_graphics and drawing bug of power line bridge seems to be another issue.
So I think that it is better for this thread to focus on the topic of "has_own_way_graphics = 1 issue".

As for "has_own_way_graphics = 1 issue", pak128.britain-EX and sweden-EX can not reproduce bugs without using modified pak as shown above.
Because there are no bridges such that the lower image (like a ballasted railroad) protrudes due to the narrow bridge in these pakset.
However, in the case of pak.256, you can check it in demo.sve. For example, around the coordinates (413, 288).

I'd appreciate your help as I have poor programming knowledge. :)

Summary of this issue:
In most cases the parameter (,15174.0.html) of "has_own_way_graphics = 1" is ignored except one tile.

has_own_way_graphics:{E} (only bridges) Wether this bridge does not have the way graphics painted directly in the bridge graphichs. Default 1.
It becomes 1 if the parameter is not set.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: Phystam on September 12, 2018, 04:45:46 PM
Thank you, Ranran.
I cannot understand another issue related to "has_own_way_graphics=1 issue".
After checking "has_own_way_graphics=1 issue", please wait for a while. The misplaced way will disappear completely.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: DrSuperGood on September 14, 2018, 08:15:35 AM
Can confirm this is a separate issue from the power line problem. Where as the power line seems to be compiler related (appears on optimized GCC nightly, not on debug MSVC) this bug is visible on all clients.

Bridge construction is excessively complicated so I have not been able to track the cause. It appears the way images are being set correctly but it would seem that somewhere it is either being unset or ignored during drawing.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: jamespetts on September 14, 2018, 12:07:22 PM
Thank you for looking into this: that is helpful. My apologies that I have not had time to look into this recently.

Dr. Supergood - I note that your investigations reveal that the way images are set correctly but unset or ignored on drawing. This is curious, since the drawing code itself is unmodified in Extended - only the setting of the images has been changed. Could there be either a latent bug in Standard or some unclear implicit assumption about what images that the Standard drawing code will get and when that are being violated by the Extended code leading to this behaviour?
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: DrSuperGood on September 14, 2018, 12:24:06 PM
It can easily be a drawing bug from standard. Recently I fixed one regarding underground back will image height when in sliced view and another got fixed regarding incorrect clipping with tunnel entrances.

That said I did not check the order construction is done. I assume the ways are constructed after the bridge ground is and then the bridge ground image is calculated which also updates the way image. However if the way image is then updated after the bridge ground image then it may be incorrect, I will need to check that.

If that is the case outside of reordering a possible solution would be to decouple way images from bridge image calculation. Instead when calculating way images it tests if the way is on bridge ground and if so checks if the bridge has its own bridge way graphics and if so sets its image to blank. This would make it order independent as the way would always choose its own graphics rather than the bridge trying to hide the ways graphics from the way.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: jamespetts on September 15, 2018, 05:29:04 PM
Thank you for your thoughts on this: this is helpful. I have to say that I know very little about graphics programming generally, so would find it very difficult to fix this bug myself.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: Ranran on January 14, 2019, 06:36:50 AM
This bug seems to behave differently in network mode and offline mode somehow.
In network mode, It try to repair the bridge drawing immediately after loading. After that, it will automatically repair at some timing. It does not do it in offline mode.
Title: Re: Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored
Post by: jamespetts on January 14, 2019, 09:30:45 AM
That is very odd. I have no idea why the graphics should behave differently when connected to a server or client than otherwise. How very curious.