Add some Fallout-style defines for IE

[burner1024]

I'm getting tired of having to comment magical constants manually all the time:

Not to mention, this is prone to errors. We could instead define those constants and use them in code:

The actual definition would be either in an external weidu lib - bunch of SET/SPRINT, or could be handled by a preprocessor.

[4Luke4]

Minor nitpick: it should be parameter2 = EFFECT_poison // param#1 is irrelevant for opcode #101

Anyway, yes, I get what you mean, even if that can be achieved via lots of OUTER_SET, e.g.:

OUTER_SET immunity_to_opcode = 101
OUTER_SET save_vs_death = BIT2
OUTER_SET save_vs_breath_bypass_mirror_image = (BIT1 | BIT24)
OUTER_SET CRE_save_vs_death = 0x54
...

The only difference would be related to syntax highlighting, i.e., purple vs white (user-defined variable)

[burner1024]

OK, so I got this to a point where it at least compiles. Something like this:

Regarding actual define names, I tried to shorten them for the most part, but some were skipped for the sake of clarity. (Dropped "Stat: ", "State: ", but kept "Colour: ", etc). I may change my mind about some of those after using them for a while, or based on feedback. So the lib is fluid for now.

Also, I just took BG2 opcodes, disregarding engine variants. I'm not even sure how to take those into account, this is postponed until such an issue actually arises.

Lastly, having to repeat same vars in each LPF bums me out as well, so I might yet think of something to work around that.

[4Luke4]

@burner1024

A little bit off-topic, but parameter2 = EVAL ~%icon%~ // Is there a way to do this without an implicit EVAL?

Yes, look at AUTO_EVAL_STRINGS.

Lastly, having to repeat same vars in each LPF bums me out as well, so I might yet think of something to work around that.

You might want to look at this function...

In so doing, your code would read as follows:

FOR (h = 1; h <= 20; h = h +1) BEGIN
  SET duration = h * 6
  SET savebonus = "-5"

  TEXT_SPRINT codes "op=267,p1=14017"
  TEXT_SPRINT codes "%codes%;op=267,p1=14662"
  TEXT_SPRINT codes "%codes%;op=169,p2=6"
  TEXT_SPRINT codes "%codes%;op=169,p2=137"

  LPF a7_auto_apply_spl_effect
  INT_VAR
    def_header = h
    def_power = 4
    def_target = 2
    def_resist_dispel = 2
    def_probability1 = 99
    def_duration = duration
    def_savetype = BIT1
    def_savebonus = "-5"
  STR_VAR
    effect_codes = EVAL ~%codes%~
    function_name = "ADD_SPELL_EFFECT"
  END
END

[burner1024]

There is an AUTO_EVAL_STRINGS in the code, still doesn't work for some reason.

Thanks for the second link, I'll take a look and see if it can adopted.

[4Luke4]

Thanks for the second link, I'll take a look and see if it can adopted.

Yeah, that would be great.

As you can see, ADD_CRE_EFFECT is not fully supported and ADD_ITEM_EFFECT only works with header_type = 3 // Magical, so these 2 aspects should be improved, without possibly having 3 different functions, one for ADD_ITEM_EQEFFECT, / ADD_SPELL_CFEFFECT / ADD_SPELL_EFFECT, one for ADD_ITEM_EFFECT and another one for ADD_CRE_EFFECT....)

[4Luke4]

Thanks for the second link, I'll take a look and see if it can adopted.

Alternatively, you could take some inspiration from SFO. Here's the remaining documentation.

As you can see, it's definitely more complicated/difficult, but probably also more powerful...

[burner1024]

Yeah, that would be great.

So I considered it and the A7 one is definitely a no. Shorter is better, but only without sacrificing readability.

Alternatively, you could take some inspiration from SFO. Here's the remaining documentation.

This does look both powerful and complicated. Unfortunately, the doc is lacking: the intro promises 3 chapters, but only the first one is completed, and it only has simple mod examples. Without having more complicated ones it's hard to say when it will be actually useful. I'll try to wrap my head around SFO (and SSL) some time later.

Also, interestingly and more on-topic, it does more or less the same thing for spell names as IElib does for opcodes and stuff:

However, there’s a useful trick here that’s worth noting. Spell names like “sppr401” aren’t exactly easy to remember, so IE games give many of them (basically, all the ones with names like “sppr”, “spin”, or “spwi”) a more memorable name that lives in spell.ids – sppr401, for instance, is CLERIC_CURE_SERIOUS_WOUNDS. When SFO is loaded, it creates a variable for each such memorable name and sets it equal to the spell filename. So any time you use “%CLERIC_CURE_SERIOUS_WOUNDS%”, or \~%CLERIC_CURE_SERIOUS_WOUNDS%\~, in a command=>argument patch (or anywhere else, in fact), WEIDU will automatically substitute the correct filename.

So I guess I'm not only one who got tired of magical values.

[4Luke4]

So I considered it and the A7 one is definitely a no. Shorter is better, but only without sacrificing readability.

I see. Well, I don't think it's that bad (as far as readability is concerned): you can factor out common values, its syntax it's quite simple and it's just one patch function. Things get bad when you need to add lots of effects with very few values in common...

This does look both powerful and complicated. Unfortunately, the doc is lacking: the intro promises 3 chapters, but only the first one is completed, and it only has simple mod examples. Without having more complicated ones it's hard to say when it will be actually useful.

Yeah, you're right, the doc is pretty lacking. The key point is that it requires you to know functional programming (this should not be a problem for you...). On top of that, it was written when WeiDU lacked ADD_ITEM_EFFECT, ADD_SPELL_EFFECT, ALTER_AREA_ACTOR and the like. You can read about it here.

I'm reasonably confident that it's possible to learn it by looking at what we have, i.e.: a full example about STO files and ARE/CRE/KIT/2DA/extra tools docs. SPL and ITM are missing, but as I said, it should be possible to reverse-engineer all those library files.

SFO does sound great for editing/cloning/creating multiple resources and adding multiple effects in an elegant way (e.g., clone_effect_inline=>"match=>opcode=232 opcode=>221 parameter1=>10 timing=>1 number_to_add=>3 duration=>0 resource=>null parameter1=>10 parameter2=>~entry_index from [%sectype1% %sectype2% %sectype3%]~ clone_above=>1")...

[4Luke4]

I'll try to wrap my head around SFO some time later.

Did you happen to start looking into it?

[burner1024]

No, why?

[4Luke4]

No, why?

Just asking...