Helping maintain and update the pakset

[jamespetts]

As to electrification types, this is not as straightforward as it may seem in some respects. Electrification is provided by what are known as "way objects". These are stored in a static string hashtable called "table" in wayobj_t (file wayobj.h). However, not all way objects are necessarily types of electrification (although I think that they are in many paksets, including Pak128.Britain), and not all types of electrification are bound to just one type of way object. What happens in Experimental is that Standard's all or nothing electrification model is overlaid by Experimental's way constraints model: way objects that carry electrification both have the Standard electrification flag and Experimental's way constraints. Each type of electrification in a pakset designed for Experimental will have a separate way permissive constraint, but lots of things that are not electrification will also have way constraints, either permissive or prohibitive, such as narrow underground railway tunnels for Tube trains or barge canals. Meanwhile, it is possible for multiple way objects to have the same way constraint but differ in other ways (for example, two types of electrification catenary with different speed limits but the same basic type of electrification). Pak128.Britain-Ex has this for the tram electrification as against the DC overhead electrification for railways. Furthermore, not all types of electrification have way constraints: the trolleybus electrification may well not have way constraints (although I cannot remember now), as there were not, so far as I am aware, multiple incompatible types of electrification for trolleybuses that ever operated in even peripherally connected networks, as with trains. Even more complex is the fact that electrification way objects can have more than one way constraint bound to them: the fourth rail DC electrification in Pak128.Britain-Ex is a good example: it works with both third and fourth rail vehicles, allowing third rail vehicles to use fourth rail electrification but not the converse. There are also combined electrification types (overhead AC with third rail DC, for example) that allow electric trains of two different types to use the same tracks. These do exist in reality (Farringdon station in London springs to mind), but, for obvious reasons of economy, not for long stretches.

You will thus need to decide whether to have each specific colour bound to: (1) each type of way object; (2) each type of way object that is also a form of electrification; (3) each different type of way constraint; (4) each different type of permissive way constraint only; or (5) each different type of way object that is associated with a type of way constraint.

You are probably better off doing (3), because it would be useful in and of itself to have a way constraints display in the minimap separate from the electrification display. This would also be a lot simpler to code. You would, however, have to find 16 unique colours (8 for permissive and 8 for prohibitive constraints), and make the description of what is happening clear in the very limited space in the minimap window. If you are adding any new GUI text to the game, you will also need to add it to the base_texts_passenger_generation.dat file (or something similar if I have not accurately remembered the filename) so that it can be uploaded to Simutranslator and translated into multiple languages before launch; you will further need to use the translation function (translator::translate("text")) instead of just ("text") for all such text.

I hope that this is helpful.

[Spenk009]

I'm extremely glad to see that the setup of things are fairly close to what I had inferred from reading up on the code. And I now understand why you say it's best to separate the two.

(for example, two types of electrification catenary with different speed limits but the same basic type of electrification)

The idea of electrification waytpes being entirely separate from electrification was sparked in my head by the bridge bug, where bridges would lose their permissive waytypes and retain only the electrification flag.

So I am checking for the individual way constraint in this case and displaying the tile on screen in that colour. I am fairly lost in terms of how I find the correct constraint in the code, so a bit more reading up on the code and C++ is in order.

By adding another selector in the map for this, could the different types of signals find their way in different colours on to the map? We have the has_signal flag, but is it "easy" to dig deeper and find the type? The benefit of this may be limited, with pre- and choose signals being fairly rarely necessary in comparison to standard signals.

[jamespetts]

Separating signal types is easy - you just have to find the base type using the get_besch() function, and then check for the various flags such as is_pre_signal() and the like. Note, however, that I am working on the signalling code at present, so this is something of a moving target; it may be better to stick with way constraints for the present.

Incidentally, have you thought how you will deal with ways that have multiple types of constraint?

[Spenk009]

Choosing from the three main colours and their derivatives, I have devised the following:

• No constraint:        white
  
• Third rail:                blue
  
• Fourth rail:             light blue
  
• DC OHC:                yellow
  
• DC OHC + 3rd rail: green
  
• AC OHC:                 red
  
• AC OHC + 3rd rail: purple
  

AC, DC, and 3rd rail have the central colours and in the case of both are mixed.  The issue is, that this is all fine if we limit ourselves to pakbritain. But other paks that include rack railways or other alternatives aren't respected well in this. I assume you want all 16 possibilities respected for the whole operation? The alternative would be one button for permissive and one for restrictive constraints (8 colours each).

[jamespetts]

You must be very careful not to put in the code things that depend on a particular pakset configuration. The idea is that any pakset can have any way constraints and any combination of way constraints that it likes, and the code should behave consistently whatever way constraints are set, so choosing specific colours for specific combinations from one particular pakset is not a workable solution, I am afraid. There is an inherent conceptual problem that is difficult to overcome about what to do about mixed way constraints on one way; the only thing of which I can think is alternating pixels of the different colours of the various constraints.

[Vladki]

Hi, I would suggest making the colors pak dependent. Here in czecho-slovakia, we had a tradition of distinguishing railway engines by colour, and it would make sense for pak.cs to use those. (If we happen to make an experimental version of it). The colours are these: green - 3 kV DC, red - 25 kV AC, blue - AC/DC, dark red - diesel. Even the offical map of electrification uses them: http://www.szdc.cz/obrazky/mapy/pocty-tratovych-koleji.gif. It includes these colours:
green - 3 kV DC (north of CS, poland)
red - 25 kV AC 50 Hz (south of CS, hungary)
yellow (orange) - 15 kV AC 16,66 Hz (austria, germany)
blue (light) - 1,5 kV DC (historical line Tabor - Bechyne, narrow gauge lines in Tatra mountains)

I don't know if there was some similar custom in britain to paint engines of one system in similar colours, but if it was it would make sense to use it.

[jamespetts]

That is an interesting thought - the colour/constraint pairs would have to be able to be set in simuconf.tab. There would need to be a way of describing each colour in a way that the code can understand, which might take a bit of work. One would also have to think about what colours would be displayed in default of any specification in simuconf.tab.

[Spenk009]

When setting the permissive and restrictive waytypes, one can select between eight possibilities. If we add a note in the pakset creation post as to what each number corresponds to, then pakset creators can choose their own colouring scheme. That map is gorgeous Vladki, it even shows where in cities the stops are and how they're connected. Following that model, we keep a ranged colour palette. As to mixtures between colours, I suggest actually mixing them. E.g. Type 0 (blue) + Type 3 (yellow) = green.

Also, something that I noticed while playing "0.9.2", how come roads are not allowed on steep slopes? I thought the intention was for very steep roads to be possible, but very taxing on vehicle speeds. Not for them to equal rails in terms of possible elevations.

[jamespetts]

Blending the colours is an interesting idea, although I wonder how clear that the results would be to a user? Also, the way in which colour is represented in Simutrans might make blending harder, although you might find a way of doing that satisfactorily. If you think that blending can be made to work, it is probably better to have a go and see what you get when you try it and see whether it works well.

[Vladki]

Blending colors might be quite confusing. I would suggest making double line or alternating the colors