News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Bug: Bridge parameter - "has_own_way_graphics = 1" is ignored

Started by Ranran(retired), September 10, 2018, 10:05:07 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

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 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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

I tested by replacing void bruecke_t::calc_image() in brueke.cc with standard's code.
(Note that I rewrote "set_foreground_image" to "set_after_image".)

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)) {
#ifdef MULTI_THREAD
weg0->lock_mutex();
#endif
// 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);
}
weg0->set_image(display_image);

weg0->set_yoff(-gr->get_weg_yoff());

weg0->set_after_image(IMG_EMPTY);
weg0->set_flag(obj_t::dirty);
#ifdef MULTI_THREAD
weg0->unlock_mutex();
#endif

if (weg_t *weg1 = gr->get_weg_nr(1)) {
#ifdef MULTI_THREAD
weg1->lock_mutex();
#endif
weg1->set_yoff(-gr->get_weg_yoff());
#ifdef MULTI_THREAD
weg1->unlock_mutex();
#endif
}
}
set_yoff(-gr->get_weg_yoff());
}
}


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.

(´・ω・`)サムワンおりゅ?
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

DrSuperGood

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.

ACarlotti

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.

Ranran(retired)

#5
Thank you both.

Quote from: Ranran on September 11, 2018, 10:36:15 AMI 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. :)

EDIT:
Summary of this issue:
In most cases the parameter of "has_own_way_graphics = 1" is ignored except one tile.

Quote
has_own_way_graphics:{E} (only bridges) Wether this bridge does not have the way graphics painted directly in the bridge graphichs. Default 1.
has_own_way_graphics=0
It becomes 1 if the parameter is not set.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Phystam

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.

DrSuperGood

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.

jamespetts

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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.