Try ReDefine
Closed this issue · 19 comments
Stumbled upon ReDefine, apparently it allows to find an compress raw expressions into their shorter header equivalents. Need to try and see what comes out of it.
Hey, can i take a look on your config?
Here
ReDefine.cfg.txt
I'd remove [Variables]->Critter_script and [Variables]->Critter_type; both names are heavily connected to FO1@2 encounters scripts, and might do unwanted/confusing changes in other mods if they use variables with same names.
That's not a case in UP currently, but better safe than sorry :)
Sure, I'll check that. I'm going to make comparisons anyway.
I've tried ReDefine`ing scripts and my god it is really good, just have to get accustomed to its config syntax. Highly recommend on using it, but it MUST be done by maintainers first!
Caution @burner1024: your current config contains rules for modified header values which are not present in UP but are in Fo1in2 i.e. self_run_to_tile, so resulting scripts are not suitable for an instant import.
UPD: Ok, I may not be thinking straight, but I suggest this: I'll gather all header defines and
- meticulously convert them all to ReDefine.cfg by hand
OR
- I'll try and reverse engineer config syntax (since there's obviously no documentation for ReDefine) and just create config generator based on extracted defines.
I've already written SSL script parsing & extraction so the hardest part would be config. 😕
I know, yes. If you want to take a shot at this, feel free to (I mean only redefine config and minimal required header changes, not resulting scripts - need to test them first).
I'm not looking to integrate ReDefine into the builds for now, just make a one-time cleanup.
Testing them is fairly simple: preprocess both versions & diff, no big whoop.
No need to even bother running the game.
Preprocessing is not perfect, as there are some whitespace inconsistencies, as you can read in the linked issue. Actual compilation should do fine, though.
meticulously convert them all to ReDefine.cfg by hand
I wouldn't go overzealously at this. Making scripts perfect is too much of a task, just making them better is good enough.
However, if you want and can add define extraction from header logic, you probably could submit that to ReDefine itself, thus everyone would benefit.
Preprocessing is not perfect, as there are some whitespace inconsistencies, as you can read in the linked issue. Actual compilation should do fine, though.
That's the best part, they don't have to transpile char-to-char, just comparable enough. After all - we could compile & decompile them and contents would be nearly identical.
However, if you want and can add define extraction from header logic, you probably could submit that to ReDefine itself, thus everyone would benefit.
Sadly, I'm not a c++ programmer, so not in the foreseeable future. Although my version is too regexp based, so who knows.
That's the best part, they don't have to transpile char-to-char, just comparable enough. After all - we could compile & decompile them and contents would be nearly identical.
The best would be if they were identical, then there would be no need for manual comparison with a chance of mistake.
Anyway, let me know what comes out of it. I'm hoping to include this and CoP fix into the next release.
The best would be if they were identical, then there would be no need for manual comparison with a chance of mistake.
Well, judging by my manual macro replacements - main differences are optional braces around expressions, but I get you. I'll see what I can do to minimize diffs as much as possible.
One single oot question: do someone use those COND & FORK macros? Cause they sure are quite useful, but not with those horrendous names.
a quick grep: scripts_src/headers/command.h:#define dude_wearing_vault_suit COND019(1)
can't see any others, but I didn't look too hard
a quick grep:
scripts_src/headers/command.h:#define dude_wearing_vault_suit COND019(1)
can't see any others, but I didn't look too hard
No, I meant in the wild. Nevermind then.
There's no in the wild, really. Each mod uses it's own set of headers (likely with roots in UP sources). It's an unfortunate legacy of the dark days. I don't know if anyone uses current UPU headers.
(I do use RPU ones in FO2tweaks, though, but mostly for PID defines).
I've got good news and bad news.
Good: I've written my own ReDefine that doesn't need no config since it's working as some sort of a preprocessor. It reads script contents, includes all headers, parses defines and replaces them if applicable substitutions found. As I said before: preprocessing/compilation/decompilation shows just extra braces here and there, otherwise – everything works as intended, since it's not modifying code, just replaces text as the preprocessor would, just in reverse.
Bad: It is greedy. If there's a defined macro for any value – it will replace it. When compiled – apart from extra braces, there's no difference, but since it has no sense of context – it can replace values with unintended constants. I have currently disabled macro constant replacements, but you get the idea.
I'll create a repo soon with source scripts, preprocessed and decompiled ones and then commit modified versions for you to check them out.
Context is important. The whole point is to make the scripts make more sense, not less.
Sadly, it is absolutely impossible to replace values to constants programmatically without refactoring headers for each script.
Result is identical either it's "wait 2 hours" or "wait SMILEY_RETURNED hours", that's why I disabled constants replacements.
Result is supposed to be identical.
I'm pretty sure it is possible, at least to some extent, as headers are grouped: for example, item pids are all in itempid.h. But it's really not a big concern, as there isn't that many magical numbers.
Anyway, the whole ReDefine endeavour for UP/RP is just a chance to get an almost free script quality impovement at FO1in2 project's dev cost. After all, 20% of effort yields 80% of result, so I'm fine with using their config almost unchanged.
You do you. I'll gather a repo with my variant anyway, it's just taking so long to recompile, since it requires wine for every compilation/decompilation call after each fix.