Usage of X(Y) offset string codes in NewGRFs

[DaleStan]

Well then, OzTransLtd can get around the freetype-overrides-newgrf rule anyway (and relatively easily, with a bit of perl).

So, it comes down to one of two things:

1. Why make difficult what is possible anyway?
   • (To discourage said control-freak-y behaviour.)
2. Why bother changing things to provide an ability that is already present?
   • (To avoid the mess of de facto standards for the private use area.)

Pick your poison.

And now, back to your regularly scheduled discussion: How should OpenTTD handle the SETX and SETXY string codes in newgrfs?

[andythenorth]

Did this one come to a resolution?

I ask because I am about to start resolving a little graphical trauma with FISH in buy menus. I'd like to set the offsets in a sane and future-robust way

FISH_menus.png (29.59 KiB) Viewed 1096 times

[eis_os]

Hello

Let's break the silence a bit, there wasn't a real answer. We again face the problem that TTDPatch goals and OTTD goals are fundamental different, you can't match both with the same commands. The GRF format try to provide a way to let the grf author change much of the way a TTD(Patch) works. If OTTD start to create other functionality there will be problems.

My thoughts: If OTTD want to provide a better user experience, thats ok. I still think OTTD should start their own proper file format. From the OTTD point of view the gui behaviour and the presentation is up to the programmer / gui artist, not the grf author.*

So there should be two options (selectable by the user):
1. Keep TTD(Patch) behaviour with TTD glyphs, try the best you can even if it will look a bit ugly. So SETXY should work as in TTDPatch.
2. Font and GUI rendering is up to OTTD. Find a format that set authors can use in a way it's not bound to a specific font. You should add tables, paragraph control and stuff if you really want the artist give that power or provide other ways so set authors can set additional information fields, this won't allow all additional info but it will end up maintainable in the long run. **

You can't automatic convert from one form to the other, so a set author has to add the necessary bits.

* TTDPatch as example forces a ViewWindow for station graphics, because I didn't like artist trying to create havoc with the gui.


** \t isn't a good solutions. Tabs are error prone...

[Rubidium]

The major problem we have (had) in OpenTTD w.r.t. SETX (and SETXY to some extent) is that the usage of SETX is primarily to work around problems caused by longer vehicles. This workaround is in the NewGRF and not a fix in (O)TTD(P), like offsetting all text based on the widest sprite. This makes it harder to do the proper thing now. We have thought about just removing all SETX from strings, but nothing has come from it yet.

Removal of SETX(Y) would have made RTL languages much easier to implement, though now we have added SETX(Y) support for RTL languages too. However the behaviour might (at the moment at least) be incorrect, but that is primarily because the GUI hasn't been fully rewritten yet.

Basically the SETX stuff caused a backward compatability issue w.r.t. auto aligning strings in the vehicle lists, which is AFAIK the place where SETX is most used. Although we can fairly easily detect SETX in vehicle names and just don't do the autoaligning for the NewGRFs with SETX, though that might cause bug reports about misaligned vehicles. But there is nothing that can be done to prevent that because of SETX being allowed in the past in GRFs.

This thread was originally meant to identify the places where SETX/SETXY were used in NewGRFs and to find a more flexible solution, but I quickly found out that lots of people are against that.
And what is the use of a "proper file format"? It would kill all NewGRFs to be useable in OpenTTD, or we must maintain 2 formats which is a b**** and it might cause a significant reduction in TTDP capable graphics sets.