News:

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

[wayobj] Separating pole images and catenary images

Started by THLeaderH, August 21, 2018, 08:48:36 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

Typical electrified rail tracks are like this.


However, the catenary poles are too dense, aren't they? If we reduce the number of the poles, they look so nice like the image below 8)



This can be realized by using different catenary wayobj. One contains the pole and the other doesn't. In the current simutrans, players have to put these two different wayobj by hand and this is very irritating. If the interval of the pole were configurable, players could build a beautiful catenary with much smaller effort. So, why don't we separate the pole image and the catenary image in one wayobj? The interval of the pole should be configured in the window like the roadsign interval setting window.

To separate these two, PoleImage and CatenaryImage should be defined in the dat file. An example of a dat file is below.

PoleBackImage[NS] = ...
PoleFrontImage[NS] = ...
CatenaryBackImage[NS] = ...
CatenaryFrontImage[NS] = ...
PoleBackImage[EW] = ...
PoleFrontImage[EW] = ...
CatenaryBackImage[EW] = ...
CatenaryFrontImage[EW] = ...


For compatibility, images of conventional wayobj should be treated as CatenaryImage and its pole is shown for all tiles.

This proposal contains a change in the add-on dat file definition and needs a discussion. How do you think?

Leartin

Even though I like the idea, I don't like the proposed execution.

Why not simply add "AlternateBackImage" and "AlternateFrontImage" as graphics parameter? If your "CatanaryFrontImage" is the same as a blank "FrontImage" anyway, there is no need to rename it. Since the object type is called "wayobj" rather than "electrification", this would also make sense with purely aesthetic wayobjects.

Why would the base graphic be the catanary? I beg to differ, it should be the graphic containing the pole. You only show straight track as an example, and thats where more distance makes the most sense, but if you think of curves, you always need a pole there, since otherwise your catanary would be hanging on thin air. The Alternate/Catanary image would only be shown in case there are at least 3 straight pieces next to each other. Compare to power lines, but allowing for diagonals.
But that's only for electrification with something hanging on poles. If each part is connected to the ground, eg. a third rail or a noise protection wall, any tile could use the Alternate image, and it wouldn't even need to be regular.

Use a parameter like "AlternationType" to decide whether it needs to follow powerline logic or not.
Use a parameter like "AlternationQuantity" to decide how many tiles you can have without pole, OR the percentage of alternated vs. unalternated tiles. I'd go with a number between 0 and 5, going in 10% steps (if the altered graphic for an object is pretty much equal, you could use 50%, but if it's special, eg. skidmarks, you'd rather have it only on 1 out of 10 tiles. No need for a higher number, as 60% would be the same as 40% with alternate and base graphic switched, and for catanary it would look very strange to not have a pole for that long.)

So, to show your code again:
AlternationType=1 #0 is random, 1 is powerline-mode
AlternationQuantity=2 #0 would mean no alteration.
BackImage[NS] = ...
FrontImage[NS] = ...
AlternateBackImage[NS] = ...
AlternateFrontImage[NS] = ...
BackImage[EW] = ...
FrontImage[EW] = ...
AlternateBackImage[EW] = ...
AlternateFrontImage[EW] = ...


Does pretty much what your idea does, while being not restricted to electrifications.

THLeaderH

#2
I agree with Leartin's statement. Thank you for your comment :D
Let me summarize Leartin's idea.

  • In addition to BackImage and FrontImage, AlternateBackImage and AlternateFrontImage are defined.
  • In case of catenary for electrification, Back/Front Image corresponds to a pole image. And Alternate Back/Front Image corresponds to a catenary image.
  • AlternationType defines how to set AlternateImages. If 0, use AlternateImage randomly. If 1, follow power-line logic.
  • AlternationQuantity is defined. If AlternationType==0, AlternationQuantity is the percentage of use of AlternateImage, which varies from 0 to 5. If AlternationType==1, AlternationQuantity is how many tiles you can have without pole.

Ters

Although the distance between poles hasn't bothered me (each tile is after all supposed to be 1 km), reusing the implementation for alternate images from power lines is preferable. That makes for more coherent behavior, which should make it easier for both players and pak authors, as well as hopefully reduce the amount of logic that needs to be maintained. Improvements, such as longer spans, could also benefit both.

(Reusing logic for both ways and wayobjs can be tricky, but I think it is possible without making a complete mess of things.)

Leartin

Different Approach to the same idea:

Instead of altering the objects, it could be a "Container", with icon, cursor and references to other objects, as well as instructions on how to mix them.
Basically, as the original suggestion said, players can already have two wayobjects and mix them manually - the container-object would create a new tool that places both wayobjects at once automatically.
Any technique required to figure out whether the normal or alternative graphic needs to be rendered would instead be used when the objects are placed.

For placement in the menu, a container acts as if it had the properties of the first referenced object. (The assumption would be that all objects in a container would usually have the same or very similar stats, as the idea is that it should not matter for gameplay which one is actually placed.

I think that would have some advantages:
1) One could use the container-object for a first placement and then "polish" whatever was placed manually. If it was just different graphics of the same object, one would require completely new tools to alter them (eg. to delete/add a pole manually)
2) While the container-object would be completely new, everything on the map would be old, hence maps created with container-objects would be backwards compatible, or put in another way, the save format for Simutrans games would not have to change. (I assume that would also be true if the alternate graphics were automaically defined and don't need to be stored, but then there would be no way whatsoever to alter it manually...)
3) Reuse of resources. If two overhead wires were to use the same wires, but different poles, you could use the same catenary way-object referenced in several containers. Similarly, a dedicated "only catenary" object and a "only poles" object would always be included without requiring image duplicates. (If you don't want them in the menu, just don't give them an icon)
4) Usable in different object types, even those which are traditionally placed one tile at a time, like stations and extension buildings. (a bit like how residential buildings in the Anno series work)

Lieven

Just a litte question...
Where did you find your double way cetanary ? Or can you bring me the pak file by attachment ?

Thanks ;)
Lieven
Europeans addons in project:

Too much ! ;-)