Pak64 - North/South Choose point sign reversed?

[arl85]

Hi,
I'm not sure it's a bug or I'm misunderstanding how road choose point sign works in pak64.
It seems that choose point sign facing north/south are working backward. I try to explain: instead of waiting on blue side of the sign, veichles wait at the white side.

They simply wait there "waiting for a clearance". I understand they are waiting a free bay at their destination ("Center" station) but that's now what I expect. I expect they wait for a free bay when coming back to "North" station.

On East/West directions it works this way, indeed: vehicles queue facing blue side of the sign when directed to go to East station. Not waiting at all when going to Center.


I'm attaching savegame used for testing it; just default pak64 and simutrans 123.0.1

I'm quite sure it's a graphical bug, like having the image of the sign "reversed", so feel free to move it in an appropriate bug section in case it's indeed a bug.

[Andarix]

https://sourceforge.net/p/simutrans/code/2104/

[arl85]

https://sourceforge.net/p/simutrans/code/2104/

Nice, So it should be fixed in next release (or maybe I'll try to "compile" it in a .pak file to use it earlier). Thanks!

[arl85]

I dowloaded the fix, packed it but it was not working:


with rev 2103 dat, the same as OP file


with rev 2104 dat, the suggested fix: notice how N/S's graphics (according to compass) did not change, but E/W did, instead!


fixed reverting to 2103 and swapping E/W (attached dat and pak). Now graphics are matching the real behavior.

Then I found another strange behavior: according to this post first number in traffic light settings is N/S green period, but according to this video it's indeed the E/W timing (I set 1 and 10 to clearly differentiate timings). So, does the compass indicate the "real" north?

Last thing: probably after adding yellow timings something broken because rotating the map the third value (extra offset) should remain 0, instead it changes (gif here


and if values rotates, so should be done with labels: the direction you're facing should not change the timing or at least labels should be changed accordingly

[arl85]

A quick check:
loading a simple heigtmap like this


produces that

so compass is correct

[prissi]

The traffic light should change indeed.

For the signs, N and S seems consequently swapped, also for minimum speed. THat is a bug, which needs addressing!

[arl85]

The traffic light should change indeed.

Sorry, my English is not so good. I don't understand if you're saying that traffic lights are working correctly right now or if they should be changed (label, third value setting, etc)

For the signs, N and S seems consequently swapped, also for minimum speed. THat is a bug, which needs addressing!

for no-entry too, but even in this case Image[E] vs Image[W]

I investigated furhter and found that rails.dat works correctly and it uses numbered syntax (Image[0]) while roadsign.dat uses character syntax (Image[N]).

Code Select Expand

image[0]=railsign.0.0
Image[1]=railsign.0.1
Image[2]=railsign.0.2
Image[3]=railsign.0.3


(revision 2103)

Code Select Expand

image[N][0]=roadsign.0.0
Image[S][0]=roadsign.0.1
Image[W][0]=roadsign.0.2
Image[E][0]=roadsign.0.3


if I read the code correctly, in roadsign_writer.cc directions are defined as

Code Select Expand

static const char* general_sign_directions[] = {"n", "s", "e", "w"};
so

Code Select Expand


N -> 0
S -> 1
E -> 2
W -> 3

attached pak seems to work fine, now

ps. sorry, maybe I'm just making wrong assumptions on a lot of things, first time trying to understand how code works.

[prissi]

Ｔhe definitions in makeobj itself were wrong. Ｆixed in r10538, I hope
.

[prissi]

The traffic lights ue the apparent screen direction. It even changes EW and NS on rotation intentionally.

The compass is a later addition and not for all paksets. So maybe the text of the traffic lights uses the screen NS/EW directions. I tried a new one using / and \ instead of NS and EW

[arl85]

The definitions in makeobj itself were wrong. Ｆixed in r10538, I hope

Nice; I'm quite sure revision 2104 of pak 64 should be reverted, then, because it reverses wrong couple (N/S were in the right order in rev. 2103)

[prissi]

Thanks, I also forget the offset_left