News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Using Placeholders in Makeobj

Started by Leartin, June 03, 2019, 08:43:18 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

I propose to add a "search and replace" function to makeobj.

Allow to define a keyword at the top of a dat-file and a block of text that will be in it's stead. For example: (And really, just a generic example - I do not know which syntax would make sense.)
placeholder=!common
obj=building
type=res
climates=rocky
/placeholder


Later in the dat, instead of repeating the strings, you simply write the placeholder:
!common
name=res_cl5_E0_01_03
intro_year=1800
[...]


Which would be replaced by makeobj to be
obj=building
type=res
climates=rocky
name=res_cl5_E0_01_03
intro_year=1800
[...]


Which then can be packed as usual.

Because the definition would have to be read first, and it would be a hassle to have definitions in different files, a definition only works within one dat file.


How is it useful?
Usually, if you have several objects in the same dat file, they have quite a bit in common. In the case above, it would be residential buildings in the rocky climate - not too much in common, but there would be so many of them, even shortening three lines to one would have quite the effect.
In other cases, it would be more specific. For example, let's use a truck. You need a copy of the same truck for each good, but the stats (speed, gear, weight, introduction date,...) are consistent among all of them. So in the dat for that truck, you first define everything that's common within a placeholder, then for each object just define name, good, payload and graphic. If you find out it's too cheap in testing, you only have to up the costs once.

To a degree, this also helps with constraints. At least within one dat file, you don't have to repeat constraints over and over again if they are the same, and can change them more efficiently.

Now I'm not saying that this is the best way to achieve these things, and it shouldn't stop advances in the actual games code. Rather, this would only simplify what's already possible. Since it only affects Makeobj, it can't break the game, and just like shorthand dats it's backwards compatible and completely optional.

makie

how about "include <file>" as it works in many program-language

Ters

The easiest solution is just to use a pre-existing tool to do this as a preprocessing step, just like the C preprocessor does file inclusion and macro expansion for C.

Leartin

Quote from: Ters on June 04, 2019, 05:22:15 AMThe easiest solution is just to use a pre-existing tool to do this as a preprocessing step, just like the C preprocessor does file inclusion and macro expansion for C.

I like your comparison there. Instructions for the C preprocessor are part of the C standard. If you write "#include", you don't write a comment that magically gets transferred into C-code by a random third-party-program, you are already writing standardized C code. I don't think you run your code through the "preprocessor program" to run the result through the "compiler program", rather, preprocessing is a step of what the compiler does nowadays.
That means you basically suggest not only to expand the preprocessor makeobj already has (string manipulation for shorthand dat), but also to add an option to output preprocessed dat files, which would help getting them into the simutranslator. All for it!

(Now, if you meant "just think up your own placeholders and use some random tool", that's the easiest solution just as much as copypasting instructions a thousand times is easier than learning how a loop works. Everybody can do it and it technically works, but it's not a good idea.)

Ters

I didn't mean any random tool, but one which is meant to be used generically (so not the C preprocessor itself as it is tied to C, however loosely in practice; Linux uses it with assembly code) and isn't part of some huge package. Something that means that one doesn't have to wait for someone capable of writing a complex preprocessor for makeobj.

prissi

That will inhibit portability a lot. And it makes harder for other people to understand and debug dat files. Finally, you could just use a macro in your text editor, that will achieve the same.

Ters

Quote from: prissi on June 15, 2019, 02:31:17 AMThat will inhibit portability a lot.
That depends on the portability of the preprocessor. I was hoping that somewhere, someone had written a nice little utility that was just a simple executable. It is possible that GPP (which is heavily inspired by the C preprocessor) boils down to that, but I found no prebuilt Windows executable and it is LGPL. The only other such tool I could quickly Google was m4, but that looks more complex to learn.

Quote from: prissi on June 15, 2019, 02:31:17 AMFinally, you could just use a macro in your text editor, that will achieve the same.
Forcing a particular text editor upon everyone working on and building a pak set seems more of a portability issue. Macros I've seen in text editors are also one-off. Once run, you can't change it and have the effect appear where the macro has already been used. That is at least very useful for constraints.

prissi

No, I mean using a text editor macro while writing the files. Usually those dat files are never ever touched after editing in most places ...

Leartin

Quote from: prissi on June 15, 2019, 10:01:28 AM
Usually those dat files are never ever touched after editing in most places ...

That's simply not true. If it was, why keep sources in the first place, rather than just paks?
I recently added a horse and a horsecart to pak192.comic. To do so, I had to edit all other horses and horsecarts to match constraints.
I also recently added additional good-graphics to open cars. Each car has the same good graphics with the same numbers corresponding to the same goods, but the legend which to which has to be copied over and over again, despite always being the same.


If I did that with a text editor macro or something like that, I would have to keep the files with placeholders and only convert them to readable dat-files when I pak them to keep them easily editable - that's why we keep them rather than throwing them out once we have a pak. That means there would be no .dat files in the pak192.comic repository, but .lear-files that first need to be converted by a macro for a text editor, stuff not everyone has readily available and is probably windows-only if I do it myself. Which makes it really hard for other people to understand and debug those files.

The point here is not to write one file once and forget about it. Good old copypaste has me covered for that. The hard part is to change things later. If I have 10 different Opel Blitz because I need one for each good, I can simply copypaste one to get the 11th and change which good it's for. But I don't want to go through all of them if I want to make them 5km/h faster.

Much of which could be solved by changing game mechanics (Eg. having only one Blitz-Object which can be fitted for different loads; having constraint-groups etc. - stuff that was already talked about) - but that's not as versatile and not as easy to do.

I think everyone learns in their very first programming class not to use magic numbers and not to repeat yourself. Why would you be against tools that allow exactly that?




Note: I wouldn't mind the preprocessor idea if it there was an 'official' tool and 'official' rules attached. I just don't want to go solo on this and produce files that later nobody knows how to use after I left the community. Would be a shame, wouldn't it?

prissi

Search and replace is existing since ages, and would do the same trick as changing a macro at the beginning of a file. (In your constraits example).

Adding such stuff to makeobj slowly converts it to its OpenTTD counterpart, which in the end needed another program to generate the input files. But if you are really bothered, make a patch or find another programming inclined person who finds this worth her/his time.