News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Control the directions of a traffic light by buttons for Extended

Started by THLeaderH, March 26, 2018, 09:32:41 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

Hello James ;D
I made a version of this patch for simutrans extended. This patch is originally made for OTRP, so this post does not mean the request for the integration, but please consider integrating if you like this.
https://github.com/teamhimeh/simutrans/tree/ex-road_signal_direction

jamespetts

Thank you for this. Looking at the thread for the Standard version, I am slightly unclear on how this is intended to work. Can you imagine this being useful other than in conjunction with the OTRP? If so, some suggested use cases would help me to understand this better.

Thank you for your work on this - it is much appreciated.
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.

THLeaderH

This patch is useful when a vehicle turns in a intersection that consists of more than one tile, even without OTRP.


Let's think about an intersection like this image. Two traffic lights are placed in the each tile. These traffic lights switch two status (a) and (b) alternatively. In both status, the orange vehicle cannot turn left because of the traffic lights.


This patch enables us to control the open directions of a traffic light. With a proper setting, the orange vehicle can turn left in status (a). This is the benefit of this patch.

jamespetts

Thank you for that. I am just looking at this now. I note that there is at least one line where furhter save data are added:


if(  file->get_version()>=120005  ) {
file->rdwr_byte(open_direction);
} else if(  file->is_loading()  ) {
open_direction = 0xA5;
}


For a feature specific to Simutrans-Extended, you will need to make sure that the data are only loaded and saved in a new version of Simutrans-Extended, which you need to define. You should increment the EX_SAVE_MINOR in simversion.h and then use file->get_extended_revision() as follows:


if((file->get_extended_version() == 13 && file->get_extended_revision() >= 6) || file->get_extended_version() >= 14)


You will need to check that you have done this for all the additional data that need to be saved/loaded for this feature. Additionally, I note that you add some text for cardinal directions: can I check whether these are the same texts as appear elsewhere where the game uses a textual representation of cardinal directions so that the translations are consistent? Also, if you have added any new text, you will need to produce a .dat file with the translation definitions for this so that this can be added to Simutranslator.

I have integrated your branch into a branch of the same name on my repository for testing. Having tested this briefly, I note that it is not immediately obvious what the various check boxes do; I wonder whether the interface could be made a little clearer? Also, is it intentional that the traffic lights do not change at all when both "South" checkboxes are ticked?

In any event, thank you very much for your work on this: it is much appreciated.
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.

THLeaderH

Thank you for your reply and I apologize for being so late to reply.
I obeyed to the extended revision system and the fix is commited on the brunch.
The only texts that I added in this patch are north, east, south, and west. I think these directions are already translated but is this not true?

Quote from: jamespetts on March 28, 2018, 11:22:57 PM
Having tested this briefly, I note that it is not immediately obvious what the various check boxes do; I wonder whether the interface could be made a little clearer?
You can see what this patch does in the "directions". In the attached image, directions = 15 because the signal opens to all directions by the checkboxes. Yes, this interface is not so clear for many players, but I don't have an idea of the better interface.

Quote from: jamespetts on March 28, 2018, 11:22:57 PM
is it intentional that the traffic lights do not change at all when both "South" checkboxes are ticked?
It is not intentional. The standard version of this patch has the same problem. I'm researching about this issue but it's not clear that this can be fixed easily because drawing more than 2 layers is not so easy with display() and display_after() methods.

jamespetts

Thank you for your reply, and apologies for my own delay in replying: I have been very busy this past week.

The "Directions: 15" does not make clear what is happening with this interface. Indeed, I am still unclear myself what the significance of the checkbox to the left of each of the cardinal directions are as distinct from the checkbox to the right of those directions. The interface really does need to make it clear to players just from what the players can see on the screen when using the interface as to what the functions do.

I also notice that the number of directions does not update when the boxes are checked and unchecked, but only when the traffic lights change, which is most confusing, as users would then be very unlikely to think there any relationship between which boxes are checked and the number of specified directions.

There is great potential for players to create unintended traffic deadlocks by unchecking too many of the checkboxes, so there really does need to be some way of making very clear to the players when using the interface, and without having to read a help file, what each of these checkboxes signifies and what will happen if any one of them be checked or unchecked.

Can anyone think of a suitable UI for doing this? That would be most helpful.

Thank you very much for your work on this.
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.

THLeaderH

Quote from: jamespetts on March 28, 2018, 11:22:57 PM
is it intentional that the traffic lights do not change at all when both "South" checkboxes are ticked?
I studied about the dat definition of a traffic light and it revealed that displaying correct status for all direction settings is not so easy. To overcome this situation, I have to propose a method that is slightly destructive, and challenging to the current roadsign add-on architecture.

A traffic light requires 16 images except for the icon and cursor images. Image[0] ~ image[3] correspond to the single directions... north, south, west and east. Image[4] and [5] are images for combined directions. [4] is north and west, and [5] is south and east. And they are used only when drive_on_left is disabled. Image[6] and [7] are also images for combined directions and they are used only when drive_on_left is enabled. Image[8] ~ [15] are for the alternative state of a traffic light.
However, a traffic light can be drawn by just a combination of images for single directions. For example, a traffic light that indicates red to north-south traffic and green to east-west traffic can be drawn by image[0], [1], [2], and [3], although the current simutrans uses image[4] and [5], or image[6] and [7] for the left sided driving. The current simutrans requires image[4]~[7] and [12]~[15] to draw a traffic light with 2 layers because any visible object in simutrans commonly use display() and display_after() methods.

It is reasonable to draw a traffic light by a combination of 4 images, otherwise a pak author is requested to draw more patterns of signals to display the state correctly for all opening direction settings. This requires a modification in display() and display_after() methods to handle 4 image layers. Surprisingly, I did almost the same modification in the display methods when I wrote the front/back images for a roadsign patch.
However, introducing 4-layer drawing methods ignores image[4]~[7] and [12]~[15]. If these images are just a combination of the images of single directions, there is no problem. But when these images have special meanings more than the combination, the drawing result is affected. I am not sure if this modification for the display methods is allowed in the view of compatibility.