Wish: Diagonal graphics for signals

[makie]

Wish: The possibility to define diagonal graphics for signals.

This look strange:

If it were possible to define custom graphics for diagonals, one could create suitable graphics for this case.

[Isaac Eiland-Hall]

Seems useful for road signs as well

[victor_18993]

Hi Prissi,

I have prepared and visually tested a proof of concept for optional diagonal
graphics on railway signals and static road signs.

I would like to keep the scope of this proposal deliberately small. I am not
proposing an immediate migration of paksets or a replacement of the existing
roadsign format.

Current proof of concept

The current patch adds an optional image block:

    diagonalimage[dir][state]



When present, the signal uses this list on a way for which
weg_t::is_diagonal() is true. Otherwise it continues using its normal
image[dir][state] list.

The runtime implementation has been tested for:

- normal and diagonal track;
- RED and GREEN states;
- per-slot fallback when a diagonal entry is "-";
- automatic image refresh when a later way_builder operation changes an
  existing signal tile from normal to diagonal;
- loading existing roadsign descriptors versions 1–6;
- no savegame, signalling, routing or network-state changes.

Compatibility issue found during review

The proof-of-concept writer currently emits roadsign descriptor version 7 for
every roadsign, including objects that do not define diagonalimage[].

The version-7 layout is:

    [name, copyright, normal images, diagonal images, cursor]

This works with the patched engine, and existing binary paksets continue to load
unchanged. However, recompiling an otherwise unchanged pakset with this makeobj
would unnecessarily convert all its roadsigns to version 7, making them require
the new engine.

I consider that broader than the feature needs, so I do not propose the current
writer behaviour as the final migration strategy.

Proposed intermediate transition

My preferred next step would allow the old and new systems to coexist:

1. Existing binary roadsign versions 1–6 remain fully supported.
2. If a .dat object does not contain usable diagonalimage[] entries, makeobj
  writes the existing version-6 layout exactly as before.
3. Only an object that explicitly opts in to usable diagonal graphics is written
  as version 7.
4. A partial diagonal list remains a fatal makeobj error.
5. An all-"-" diagonal block is treated as no diagonal graphics and remains
  version 6.
6. The new engine reads both version 6 and version 7 objects in the same pakset.
7. Pakset maintainers may therefore introduce diagonal signals gradually,
  object by object, without recompiling every other roadsign into the new
  format.

Under this intermediate model:

- current paksets continue to work unchanged;
- recompiling unchanged pakset sources preserves compatibility with existing
  engines;
- only the individual signals using the new feature require the updated engine;
- experimental diagonal signals can initially be distributed as optional
  addons;
- no pakset-wide migration is required.

This deliberately does not attempt to make a version-7 diagonal object load in
an old engine. The compatibility goal is instead to ensure that objects which do
not use the new feature remain in the historical format.

Possible further compatibility option

If preserving compatibility even for objects carrying diagonal graphics is
important, another possibility might be to keep the existing cursor child
position and append an optional diagonal-image child:

    [name, copyright, normal images, cursor, optional diagonal images]

That would only be viable if older readers safely ignore additional children.
I have not assumed this in the patch because I would prefer your guidance before
testing or relying on that behaviour.

Questions

1. Would conditional version-6/version-7 output be an acceptable intermediate
  migration strategy?
2. Would you prefer an append-only child layout, assuming old readers can safely
  ignore the additional child?
3. Should the first implementation remain an experimental addon/nightly feature
  until pakset maintainers have had time to adopt it?

The attached patch should therefore be considered a tested proof of concept for
the runtime behaviour, not a request to commit the current unconditional
version-7 writer unchanged.

I can revise the writer and regenerate the patch once the preferred compatibility
direction is clear.

Thanks.