81 replies to this topic

[the bigg]

Blindness fix: I'd leave this one for tweaks or third-party mods - erring on the side of caution.

IMHO, by the Fixpack 'developer intention' criterion, the tweak that makes the effect work as per spell description could be classified as a fix.

Allow 99 spells per level: am I right in thinking that the ToBEx component only allows the possibility of this happening, and the functionality is enabled by modifying the relevant 2DA file? If so, is it possible to leave it as an extension, so that mods can enable it by editing the 2DA file? (Or am I just confused?)

Yes, this is another of those externalize deals... except that the current ToBEx also alters the 2da.

Assassin and Bounty Hunter penalty: this is a prime case of something where I'd include it by default but allow a mod to edit tobex.ini to change it if required for compatibility.

Personally, I'd say that it could be on by default, since no mod has a credible reason to use the BH/Assassin unusability bits in their kit - if they do, they deserve their kit to suddenly malfunction.

Correct Experience Gain: in 2nd edition AD&D, the majority of characters have a 10% XP bonus due to having high statistics. Is it possible that's where Bioware is coming from?

I'm pretty sure they didn't code such a multiplier by mistake, either, so (in Fixpack terms) the current behavior is developer intent (irregardless of the source of that XP boost). Of course, the 'incorrect report' bit classifies as a fix IMHO.

Enlarge Tooltip Scroll: moot, as it depends on investigations

Fix (after the crashing bug is solved, obviously): in Italian, 'Spell Immunity: Abjuration' is translated as 'Immunità agli Incantesimi: Scongiurazione', which is truncated to 'Immunità agli Incantesim...' in the tooltip, leaving you with no way to know which of the eight spells is SI:A (short of memorizing the icons).

[DavidWallace]

Blindness fix: I'd leave this one for tweaks or third-party mods - erring on the side of caution.

IMHO, by the Fixpack 'developer intention' criterion, the tweak that makes the effect work as per spell description could be classified as a fix.

Sold.

Assassin and Bounty Hunter penalty: this is a prime case of something where I'd include it by default but allow a mod to edit tobex.ini to change it if required for compatibility.

Personally, I'd say that it could be on by default, since no mod has a credible reason to use the BH/Assassin unusability bits in their kit - if they do, they deserve their kit to suddenly malfunction.

Isn't that what I said?

[Wisp]

Level One Proficiency Restrictions - [i]now this would never affect a vanilla BG2:ToB because you don't create Level 1 dudes, so I would feel safe putting

This sounds like the very definition of a flavour tweak to me. Since this isn't even relevant unless the player is using a mod where you start at level 1, the only effect of including this would be to have a non-configurable impact on Tutu/BGT/CA/etc games, whether the player wanted it or not.

Most of the ones you have listed under "equivocal" sound like pretty good material for tweaks to me.

The fix for EquipRanged wouldn't be out of place among the fixes, I'd say. Say what you will, but using a one-handed throwing weapon with a shield is legal, and NPCs can do it if you set them up with such from the start, rather than relying on scripts.

I would agree the launcher fix is a fix, but that's precisely the sort of thing that will rub some the wrong way (i.e. the sort of thing I would prefer to see remain optional).

Making it possible to bundle the PickPocketFailed change with mods wouldn't be unwelcome (but not necessarily having it enabled by default). That way I think I could retire tob_hacks from Rogue Rebalancing, for example.

[the bigg]

Assassin and Bounty Hunter penalty: this is a prime case of something where I'd include it by default but allow a mod to edit tobex.ini to change it if required for compatibility.

Personally, I'd say that it could be on by default, since no mod has a credible reason to use the BH/Assassin unusability bits in their kit - if they do, they deserve their kit to suddenly malfunction.

Isn't that what I said?

I also mean that there's no reason to leave it configurable (if we decide to let some components be configurable and some be not) - if a mod requires it to be off, then it using unsound coding and design, and it should be recoded rather than having it attempt to tweak tobex's ini.

[cmorgan]

Slightly offtopic - recheck for my own ineptitude at reading - I don't see the 'charmed dialogs enabled'. Is that still separate from ToBEX? Should I be posting this request in the 'requests' thread? (I am under the assumption that ToBEX will also be able to make EasyTutu much better, as well.)

[ydfhdsfh]

If it were intentional, it would be mentioned somewhere in the readme or the spell description, so your argument about developer intent doesn't hold.

Why would devs mention their intentions in the readme. Yes that would be nice.

Besides, stacking isn't prevented in general by the engine: if you were to obtain two identically-fast sources of regeneration (E.G. by casting multiple copies of Regeneration on yourself) the effect WOULD stack.

As for stacking same spells, thats the first thing all the fixpacks have been fixing from the beginning of time, from Baldurdash to G3fixpack. How is this now ok for regeneration. This is another thing to fix not to advertise. Besides, there is a difference between obviously exploiting the engine, like casting same spells on itself, cloudkilling unaware targets etc. And legit looking technique made possible through patches. And stacking regen will make chars easily unkillable with just a few buffs. 60hp/rnd regen. This doesnt look like an intended core behavior at all.

PS it doesnt matter how it is working in the engine, the result counts and module balancing. Saw Diablo II mentioned, just throwing some words here(absurdly broken): Manaburn, Souls lightning damage, FE mobs(lol).

Edited by ydfhdsfh, 02 February 2011 - 08:50 AM.

[Wisp]

Slightly offtopic - recheck for my own ineptitude at reading - I don't see the 'charmed dialogs enabled'. Is that still separate from ToBEX? Should I be posting this request in the 'requests' thread?

ToBEx calls it "Disable Silence on Charm."

[the bigg]

Why would devs mention their intentions in the readme. Yes that would be nice.

The standard we use in the Fixpack is that in-game text (dialogue, spell/item descriptions, etc.) are a closer representation of developer intent than what is implemented in the game, hence dictate how the Fixpack should behave.

As for stacking same spells, thats the first thing all the fixpacks have been fixing from the beginning of time, from Baldurdash to G3fixpack. How is this now ok for regeneration. This is another thing to fix not to advertise. Besides, there is a difference between obviously exploiting the engine, like casting same spells on itself, cloudkilling unaware targets etc. And legit looking technique made possible through patches. And stacking regen will make chars easily unkillable with just a few buffs. 60hp/rnd regen. This doesnt look like an intended core behavior at all.

An evil CHARNAME Fighter/Thief in ToB can achieve over 100% resistance to melee damage and thus regenerate from being hit:
25% from Jan's Adventurewear
20% from the Defender of Easthaven
25% from one of the Hell tests
40% from Hardiness
---
110% total resistance

As such, one is either to assume that the devs intentionally coded a counter-intuitive anti-stacking system to prevent some exploits while leaving other exploits open, or that simply the non-stacking Regeneration was an oversight (which is likely, given the explanation Ascension gave for the cause). Besides, even if one were to stack all possible sources of Regeneration on a character, the Regeneration spell still provides two thirds of the character's total regeneration rate, so it's not like preventing stacking that spell with other sources changes much (you could simply cast Improved Haste on yourself for a greater regeneration rate increase):
0.2 Pearly White Stone (1 for Wong Fei Ioun Stone, which is only available in late ToB and Monk / Use Any Item -only)
1 Ring of Regeneration
1.2 Blackrazor
2 Ring of Gaxx
2 Potion of Regeneration (stacks, but limited quantity)
3 Axe of the Unyielding
---
9.4

vs
18 Regeneration Spell

Oh, and the fixpack does NOT prevent the Regeneration spell (or the potion) from stacking with itself.

PS it doesnt matter how it is working in the engine, the result counts and module balancing. Saw Diablo II mentioned, just throwing some words here(absurdly broken): Manaburn, Souls lightning damage, FE mobs(lol).

Then go make your mod (or police yourself and don't stack 300 regeneration effect on the character). We don't want bugs breaking mods (for example Aura effects) because of your balance concerns.

[Galactygon]

As for stacking same spells, thats the first thing all the fixpacks have been fixing from the beginning of time, from Baldurdash to G3fixpack. How is this now ok for regeneration. This is another thing to fix not to advertise. Besides, there is a difference between obviously exploiting the engine, like casting same spells on itself, cloudkilling unaware targets etc. And legit looking technique made possible through patches. And stacking regen will make chars easily unkillable with just a few buffs. 60hp/rnd regen. This doesnt look like an intended core behavior at all.

An evil CHARNAME Fighter/Thief in ToB can achieve over 100% resistance to melee damage and thus regenerate from being hit:
25% from Jan's Adventurewear
20% from the Defender of Easthaven
25% from one of the Hell tests
40% from Hardiness
---
110% total resistance

Now with expanded stats, it might be possible to define non-cumulative stats externally in .2da tables, and discard the whole "non-cumulative effect ID" idea I was toying around with. These stats would be accessed via the new stat change opcode.

Here are examples:

STAT_NAME           STAT_NUM  STAT_OPCODE  SIGNED             STACK_TYPE
HPMODVAMPIRICTOUCH  301       18           UNSIGNED_POSITIVE  LARGEST

This will make vampiric touch non-cumulative with itself, and grant the largest amount of hitpoints if more than one such effect sets the stat. The only limit is that

STAT_NAME           STAT_NUM  STAT_OPCODE  SIGNED    STACK_TYPE
STRENGTHDRAIN       302       44           SIGNED    SMALLEST

Multiple overlapping effects that set/change strength yield the smallest possible value in strength. This stat needs to be signed if we accomodate negative strength modifiers.

-Galactygon

[Miloch]

Animation Attack Sounds: tweak

This is almost certainly a fix, as the mbam.2da files have referenced sounds that never fire, or fire inappropriately, due to some sort of math-related bug in the engine. (Now a mod that adds more sounds to the 2da files to take advantage of this fix would be a tweak.)

[Ascension64]

You are speaking of technical correctness, im speaking about game balancing, given the engine at hand.

As for stacking same spells, thats the first thing all the fixpacks have been fixing from the beginning of time, from Baldurdash to G3fixpack. How is this now ok for regeneration. This is another thing to fix not to advertise. Besides, there is a difference between obviously exploiting the engine, like casting same spells on itself, cloudkilling unaware targets etc. And legit looking technique made possible through patches. And stacking regen will make chars easily unkillable with just a few buffs. 60hp/rnd regen. This doesnt look like an intended core behavior at all.

PS it doesnt matter how it is working in the engine, the result counts and module balancing. Saw Diablo II mentioned, just throwing some words here(absurdly broken): Manaburn, Souls lightning damage, FE mobs(lol).

Game-balancing is ideally a tweak. Obviously, sometimes the line is blurred because one can argue that a obvious bug that prevented things from being uber shouldn't be fixed.

As for regeneration, I wish to extend the facts we know about this by re-iterating what is stated in TobEx_ini.txt under 'Regeneration Fix', which applies to poison fix, disease fix, repeating eff fix, etc.

Fixes a bug with the regeneration opcode where a creature with multiple instances of disease, poison, wing buffet, regeneration and/or repeating effect opcodes would only have the highest frequency instance applied

Now, I give you an example of vanilla behaviour. Your character gets at time zero:
1. hit by a zombie - 1 damage per second for 60 sec
2. shot with a poison arrow - 1 damage every 2 sec for 40 sec
3. gets wing buffeted by a dragon - hard-coded to apply every 2/15ths of a second for 2 sec
4. You have an item equipped with regeneration of 1 HP every 6 sec.

What happens?
0-2 seconds: every 2/15ths of these two seconds, you get wing buffeted. Disease (58 sec left), poison (38 sec left), and regeneration (no expiry) do not apply.
3-61 seconds: you get 1 damage per second from disease (58 damage only, not 60). During this time poison expires (you never ever get poison damage). Regeneration (no expiry) does not apply.
62+ seconds: Only regeneration is left, you get 1HP every 6 sec.

Intended? I think not.

This is the stacking I am talking about: it is not just within effect, but between effect as well.

OK, comments as requested. First a meta-point: I continue to think that you might do better to continue distributing a .ini file (at least for some modifications) and just stopping supporting user modifications, rather than removing it entirely. (Maybe have various options set to 1 by default, i.e. unless the relevant line is included in the .ini. Maybe even put the file somewhere less immediately-visible, like in the ToBEx folder.) That way, if you break compatibility with some obscure mod, and the modder knows what they're doing, they can disable the relevant fix (at their own risk). And that way if someone absolutely hates something then they can write a "revert" mod. In many cases I'd rather go down that route than re-route something into Tweaks that really should be a fix. (You might also find that leaving a user-accessible .ini helps you with debugging.)

Fair idea. We must then though draw the line between what is likely to break compatibility and what is not, which adds another layer of complexity onto things. The way that I have approached TobEx is to be conservative as possible with maintaining vanilla compatibility, so ideally 'break compatibility with some obscure mod' should never happen. Leaving .ini options available to help with debugging sounds exactly like what the current incarnation of TobEx is - that means I have to be prepared support and debug 2^n combinations of code, where n is the number of configurable hacks. It is far easier for me to debug one group of code than to account for all combinations of activated/deactivated code.

The idea of putting fix/extension/debug as non-configurable, and moving tweak to a completely different mod makes things a lot simpler, because I can remove all that code that checks whether .ini stuff is enabled/disabled in the former, and therefore reduce the number of code execution pathways possible. Tweaks don't get that advantage, obviously.

Blindness fix: I'd leave this one for tweaks or third-party mods - erring on the side of caution.

Remember that the existing blindness opcode is bugged because of stacking of 10 THAC0 penalty. The question is: which one is 'the fix'? Is it correcting this stacking behaviour, or is it correcting the entire blindness fix opcode to match the spell description.

Allow 99 spells per level: am I right in thinking that the ToBEx component only allows the possibility of this happening, and the functionality is enabled by modifying the relevant 2DA file? If so, is it possible to leave it as an extension, so that mods can enable it by editing the 2DA file? (Or am I just confused?)

Yes, you are correct. We can have TobEx leave SPELLS.2DA alone.

Correct Experience Gain: in 2nd edition AD&D, the majority of characters have a 10% XP bonus due to having high statistics. Is it possible that's where Bioware is coming from?

I'm pretty sure they didn't code such a multiplier by mistake, either, so (in Fixpack terms) the current behavior is developer intent (irregardless of the source of that XP boost). Of course, the 'incorrect report' bit classifies as a fix IMHO.

Point taken.

PickpocketFailed Trigger: best left (if possible) as something third-party mods could enable. It's only relevant to someone who actually wants this behaviour in their mod.

Making it possible to bundle the PickPocketFailed change with mods wouldn't be unwelcome (but not necessarily having it enabled by default). That way I think I could retire tob_hacks from Rogue Rebalancing, for example.

The thing that errs me towards tweak is that it replaces the Attacked() trigger that is sent in vanilla. Therefore, failed pickpockets may end up not provoking a hostile reaction in creatures with AttackedBy() -> Enemy() scripts. We can modify this to allow both triggers to be sent, thus maintaining vanilla behaviour, as a customisable thing.

Fix (after the crashing bug is solved, obviously): in Italian, 'Spell Immunity: Abjuration' is translated as 'Immunità agli Incantesimi: Scongiurazione', which is truncated to 'Immunità agli Incantesim...' in the tooltip, leaving you with no way to know which of the eight spells is SI:A (short of memorizing the icons).

I am more inclined to call this extension more than fix, although that is a moot point in itself, because I intend both fixes and extensions to be non-configurable. Anyway, it's not a crashing bug, just an assertion warning and a window redraw bug.

This sounds like the very definition of a flavour tweak to me. Since this isn't even relevant unless the player is using a mod where you start at level 1, the only effect of including this would be to have a non-configurable impact on Tutu/BGT/CA/etc games, whether the player wanted it or not.

Point taken. So we would like to TCs a choice as to whether enforce custom proficiency restrictions at level one.

Now with expanded stats, it might be possible to define non-cumulative stats externally in .2da tables, and discard the whole "non-cumulative effect ID" idea I was toying around with. These stats would be accessed via the new stat change opcode.

If I had to choose between this and the ID idea, I'd stick with the ID idea. The reason being that the former globally modifies the stat, whereas with IDs you can configure stackability at the effect-level, as opposed to the stat-level.

Animation Attack Sounds: tweak

This is almost certainly a fix, as the mbam.2da files have referenced sounds that never fire, or fire inappropriately, due to some sort of math-related bug in the engine. (Now a mod that adds more sounds to the 2da files to take advantage of this fix would be a tweak.)

Clarification here, Animation Sound Fix fixes the math error. Enable Animation Attack Sounds enable ATTACK_SLASH/BACKSLASH/JAB. Let's have an example (MDEM.2DA):

SOUND
ATTACK          		demo01 demo01a demo01b
ATTACK          		2 0 0
...
ATTACK_SLASH    		demo03 nosound
ATTACK_SLASH    		2 0
ATTACK_BACKSLASH		demo04 nosound
ATTACK_BACKSLASH		2 0
ATTACK_JAB      		demo05 nosound
ATTACK_JAB      		2 0
...

Vanilla: ATTACK_SLASH/BACKSLASH/JAB never play on attack. Only demo01 or demo01b will play.
Animation Sound Fix: ATTACK_SLASH/BACKSLASH/JAB never play on attack. One of demo01, demo01a, or demo01b will play.
Add Enable Animation Attack Sounds: ATTACK_SLASH/BACKSLASH/JAB play depending on slash/backslash/jab. One of demo01, demo01a, or demo01b will also play.

Edited by Ascension64, 03 February 2011 - 12:45 AM.

[DavidWallace]

The idea of putting fix/extension/debug as non-configurable, and moving tweak to a completely different mod makes things a lot simpler, because I can remove all that code that checks whether .ini stuff is enabled/disabled in the former, and therefore reduce the number of code execution pathways possible. Tweaks don't get that advantage, obviously.

Understood. Let me reiterate the request, though, that if ToBExTweaks is working just by configuring a .ini file to be parsed by the main ToBEx executable, that third-party mods should also be able to configure that .ini file. (I guess that might just be the case automatically, come to think of it.) There are a small number of tweaks (exact number depends on the fix/tweak boundary) that I'd like to be able to enable directly in SCS.

[Ascension64]

The idea of putting fix/extension/debug as non-configurable, and moving tweak to a completely different mod makes things a lot simpler, because I can remove all that code that checks whether .ini stuff is enabled/disabled in the former, and therefore reduce the number of code execution pathways possible. Tweaks don't get that advantage, obviously.

Understood. Let me reiterate the request, though, that if ToBExTweaks is working just by configuring a .ini file to be parsed by the main ToBEx executable, that third-party mods should also be able to configure that .ini file. (I guess that might just be the case automatically, come to think of it.) There are a small number of tweaks (exact number depends on the fix/tweak boundary) that I'd like to be able to enable directly in SCS.

That is the idea. I am still thinking about how updating an .ini file would work (and keep old settings) if a mod decides its version of TobEx is newer than an existing mod's. I believe APPEND ~some tweak name~ UNLESS ~some tweak name~ is the way to go here.

[Miloch]

Clarification here, Animation Sound Fix fixes the math error. Enable Animation Attack Sounds enable ATTACK_SLASH/BACKSLASH/JAB. Let's have an example (MDEM.2DA):

SOUND
ATTACK          		demo01 demo01a demo01b
ATTACK          		2 0 0
...
ATTACK_SLASH    		demo03 nosound
ATTACK_SLASH    		2 0
ATTACK_BACKSLASH		demo04 nosound
ATTACK_BACKSLASH		2 0
ATTACK_JAB      		demo05 nosound
ATTACK_JAB      		2 0
...

Vanilla: ATTACK_SLASH/BACKSLASH/JAB never play on attack. Only demo01 or demo01b will play.
Animation Sound Fix: ATTACK_SLASH/BACKSLASH/JAB never play on attack. One of demo01, demo01a, or demo01b will play.
Add Enable Animation Attack Sounds: ATTACK_SLASH/BACKSLASH/JAB play depending on slash/backslash/jab. One of demo01, demo01a, or demo01b will also play.

Well, the first is certainly a fix. I'm inclined to think the second (enabling _SLASH, _JAB etc., which were pointless before) is as well. However, what do you mean both ATTACK and ATTACK_SLASH will fire with both fixes? At the same time, one after the other or what? I suppose this is something that should (or could) be configurable (i.e. give the option for one or the other to play, A then B or B then A). There's a conflict otherwise, as both ATTACK and ATTACK_SLASH are designated to fire at frame 2 of the animation, which would probably sound crappy. There's another complication in that a creature's equipped weapon will also fire a sound (like a sword swooshing). More notes here.

There is probably more to be addressed, like ATTACK (etc.) sounds on CRE files only work in some cases (page down from that link a bit). I'm not really sure what the developers "intended" here, but clearly they intended something, since they've got sound entries on both ATTACK and ATTACK_* lines in nearly all 2da files. Perhaps some random factor is (supposed to be) involved?

[Ascension64]

And I graciously reversed the attack sound code at http://www.shsforums...ost__p__486355. You'll notice that if a weapon sound plays, the animation attack_slash/backslash/jab sound doesn't.

Have you tried this in-game? I didn't personally find the enmeshing of ATTACK with the ATTACK_SLASH/BACKSLASH/JAB messy. Sometimes the ATTACK sound is a taunt like the annoying Ogrillon's ogre taunt 'I will crush, crush you to goo!'

Edited by Ascension64, 03 February 2011 - 02:32 AM.

[Miloch]

And I graciously reversed the attack sound code at http://www.shsforums...ost__p__486355. You'll notice that if a weapon sound plays, the animation attack_slash/backslash/jab sound doesn't.

Have you tried this in-game? I didn't personally find the enmeshing of ATTACK with the ATTACK_SLASH/BACKSLASH/JAB messy. Sometimes the ATTACK sound is a taunt like the annoying Ogrillon's ogre taunt 'I will crush, crush you to goo!'

I haven't tested anything in-game related to TobEx, but I did try different combination of CRE sounds and 2da settings (as mentioned in that link). As I said there, when there's a combination of weapon and creature sound, it usually sounds ok. I looked at several vanilla 2da files and most of them had the ATTACK sound the same as BATTLE_CRY (and/or SELECTION). That would indeed be annoying, because the battle cry should only fire when the creature *first* attacks, not on every single weapon swing. In the 2DAs for Infinity Animations, I usually made ATTACK a summary of the ATTACK_* sounds (in case those weren't enabled). So it'd be redundant (at best) to fire them off simultaneously. I think there should be some random factor, possibly with configurable weighting thrown in (toward the ATTACK_* sounds firing more often, if I were the one configuring it). Feel free to move that to the "wish list" or whatever.

[Galactygon]

Now with expanded stats, it might be possible to define non-cumulative stats externally in .2da tables, and discard the whole "non-cumulative effect ID" idea I was toying around with. These stats would be accessed via the new stat change opcode.

If I had to choose between this and the ID idea, I'd stick with the ID idea. The reason being that the former globally modifies the stat, whereas with IDs you can configure stackability at the effect-level, as opposed to the stat-level.

I was thinking it might be easier for you to manage non-cumulative stats instead of the old "ID" thing. With virtually unlimited stats, it doesn't matter from a modder's POV whether we configure stackability at the effect level or stat level. The only limit with the latter is that stat modifiers cannot go over 255 (unsigned) or 127 (signed).

-Galactygon

[Ascension64]

Here is a little taste of what is to come. When you download TobEx standalone (like this package), it will contain a TobEx_redist folder you put in your mod directory. All you need to include in your mod is this directory, and some .tp2 code akin to the standalone TobEx.tp2 example here.

OUTER_SPRINT TOBEX_MOD_DIRECTORY "./TobEx"
ACTION_INCLUDE "%TOBEX_MOD_DIRECTORY%/TobEx_redist/TobEx.tpa"

You need to specify your mod's directory (don't be fooled; TOBEX_ is just a prefix to make the variable unique. It should be set to your mod directory, so if your mod is in the SCS folder, you should set TOBEX_MOD_DIRECTORY to "./SCS".

The current limitation at the moment is languages, and the use of LOAD_TRA, which at the moment will overwrite your tra strings.
@the bigg: What's the biggest tra number possible? I may plan to use some ridiculously large numbers so to reduce conflict of using tra strings. Language-specific TobEx_redist may be a problem, because there will a whole variety of %LANGUAGE% variables floating around in mods. Oh yeah, feel free to critique my use of WeiDU code.

Afterwards, when you want to activate tweaks, just to REPLACE_TEXTUALLY on TobEx_ini/TobExTweak.ini.
You shouldn't be touching TobEx_ini/TobExCore.ini.

Obviously, this isn't final, so the settings in this attachment are all over the place, but it does work if you want to muck around with it. Don't go including it in your mod though.

Make sure you uninstall old TobEx and remove it from your game directory first.

Edited by Ascension64, 03 February 2011 - 04:33 AM.

[the bigg]

Tra numbers are stored as a 31 bit signed integer, so the valid range is -1073741824 ~ 1073741823.

Edited by the bigg, 03 February 2011 - 04:40 AM.

[Wisp]

The current limitation at the moment is languages, and the use of LOAD_TRA, which at the moment will overwrite your tra strings.
@the bigg: What's the biggest tra number possible? I may plan to use some ridiculously large numbers so to reduce conflict of using tra strings. Language-specific TobEx_redist may be a problem, because there will a whole variety of %LANGUAGE% variables floating around in mods. Oh yeah, feel free to critique my use of WeiDU code.

You could wrap it in a function. I don't know how that would affect tra strings, but it should keep variables like LANGUAGE from escaping.