Macros and LVARs usage
Closed this issue · 4 comments
Greetings! I was planning on rewriting scripts, replacing hardcoded base functions and magic numbers with already defined values in headers for better readability. Should I do that or it's fine by everyone involved? Cause I've already encountered some bugs in scripts because of that.
Also, I was wondering about overwhelming usage of LVARS for basic features instead of using originally planned LVAR_Flags, since LVARS are saved in SAV files - thus unnecessary increasing it's size.
Hi.
- If you have encountered bugs, please report them according to instruction, one per issue.
- Some macro optimization is planned, see #33, rotators/ReDefine#6. If you want to help, that is welcome.
- I'm not aware of any evidence that using one or two or a dozen or a hundred extra LVARs reflects upon user experience negatively. If you have some, please share.
Save size is measly anyway, so it's the last of my concerns.
If you're planning on using ReDefine – seems reasonable to wait out and replace some code afterwards (if left any ;)).
As far as LVARs usage - perhaps I may sounded a bit drastic. I just wanted to know what's your stance on LVAR usage for things LVAR_FLAGS was invented to replace: hostility and personal enemy tracking, since it's the most commonly used pair in scripts:
#define LVAR_Hostile (5)
#define LVAR_Personal_Enemy (6)
which could be replaced by it's LVAR_FLAGS variant
#define set_hostile set_lvar_bit_on(LVAR_Flags, hostile_bit)
#define set_personal_enemy set_lvar_bit_on(LVAR_Flags, personal_enemy_bit); set_hostile
which are commonly used in Den and New Reno NPCs.
I don't have any particular stance on that. In general, it's good to have the code uniform, yes. However, this particular inconsistency hasn't bothered me once since I started working on UP. And I only have so much time, so I focus on issues that actually do bother me (maintenance burden).
Gotcha! Closing the issue then.