Oblivion does a very good job handling these internally. It would make cross-mod listings harder to work with, but there are definitely ways of dealing with that. But if he can just prepend the mod index to the MGEF's code, that would work great, I'd think.

DragoonWraith's idea is excellent. The highest byte of the mgefCode can be reserved as a mod index, and resolved with the same routines that the game uses for formID's. The catch is that it would require some tricky coding in order not to break the existing effect codes, which obviously can't follow this scheme.

Even so, there is no reason that there can't be a standard list of additional effects, which might be distributed as a companion obme.esm. I was planning to do that anyway, eventually.

Oh, now that's a great idea. Perhaps leave them unimplemented (and with descriptions to that effect), but reserve the names... then even if all else fails, TES4Edit will see that the existing record has been modified.

So, what belongs on that list? Suggestions, including a few already mentioned:

POIS - Poison Damage
MARK - Mark
RECL - Recall
MKRE - Mark/Recall as a single effect (i.e. Daggerfall-style Recall)
INTR - Divine Intervention
JUMP - Jump
LEVI - Levitate
SLWF - Slow Fall
PUSH - Force Push
PULL - Force Pull

Selected for being in previous games, and/or being such undeniably popular effects that there WILL be multiple implementations.

Oh definitely, I can't wait!

Haha, honestly, that wasn't what I was thinking - but it's a much better idea that what I'd had in mind.


Awesome.

Sounds good to me :goodjob:

Only catch would be that TES4Edit would no longer be able to detect MGEF conflicts. The conflicts won't matter as much since they'd have to be deliberate with the mod index in place, but there will still need to be a way to track them down. I'll have to add that conflict report to Bash once the data format is finalized...

Wow this is epic! :goodjob:

Ah , one of those threads where all the cool kids converge Awesome to see this and can't wait for the end results of it use

I gave it some more thought, and it seems Waruddar was right after all. "Resolving" mgefCodes based on load order works fine for spells and the like, since OBME can intercept the mod/savegame loading and perform the resolution. It fails with scripts, however. Since OBME v0010 or so, it has been possible to operate on effects by code, with the code stored in a numeric variable or array element. It's flat-out impossible to perform any resolution on such values, because only the script writer knows whether a particular variable holds an effect code or some other numeric value.

So - how about a compromise? OBME can still maintain a table of global, unchanging mgefCodes. The original magic effects would still be identifiable through the table, as well as any new effect whose modder chose to give it a code. Any effect with a code would be prone to conflicts with other mod files, but would also be completely compatible with all existing scripts. It could be *strongly suggested* that modders register their codes in some central location before using them, and of course the most popular ones can still be included with OBME itself.

By default, though, new magic effects might have only a temporary mgefCode, assigned on loading and valid only for one session in the game/CS. Spells,enchantments, etc. will point to them by formID instead. Scripts that want to use them will store them in ref variables (which work on formIDs as well), and use an improved version of GetMagicEffectCode to get the temporary code and use it in the older script functions. These effects might not be 100% compatible with all existing scripts, but would benefit from the sophisticated conflict resolution available through formIDs, and would require no centralized maintenance. Also, with this scheme it should be possible for scripts to create their own magic effects in-game using something anologous to CloneForm.

On the fly MGEF creation via scripts? Sign me up!

Now we just need an OBSE function or two to let us add these from in-game. ^_^

Create-a-summon anyone?

I hate to say it, but I think the dynamic effect codes are a bad idea. If they won't work with the existing OBSE commands, you're breaking something no matter what you do: your "improved GetMagicEffectCode" will only be present in mods compiled with OBME. But other OBSE mods are likely to encounter these effects when scanning through spells/effects created with them, and they need to function.

He can overload the existing GetMagicEffectCode function to perform as necessary even when called by non-OBME mods when OBME is loaded.

Perhaps I should clarify - no matter what, at runtime every effect *must* have a valid mgefCode. So if an effect doesn't have a code when it's loaded, one would have to be assigned to it from a pool of available codes. This means that, no matter what, all effects will always have an effect code, which can be used with all existing script functions as normal.

The incompatibility comes if the script saves an effect code in an integer variable, and uses it in a later frame. Because the game might have been saved/loaded between frames, a dynamically assigned code would "suddenly" have become invalid, leading to obscure bugs.

The solution (for new scripts) is to store the effect in a ref var instead, since these are resolved during saving and loading. The new GetMagicEffectCode would be necessary to convert the ref var back into an effect code for use with those older OBSE functions that won't accept the effect in a ref var as a parameter. And it wouldn't be implemented by OBME; I think the guys over at OBSE could be convinced to add it in v0019.

At any rate, existing scripts might be broken, and this is a serious and unavoidable problem with dynamic effect codes. The question is how serious? There are a lot of mods with scripts that look at effect codes, but how many save them between frames? If it's not that many, it might be easier to for your average modder to just use dynamic effect codes and declare their mod incompatible with the older ones.

Clear on this, though I wasn't sure whether the existing OBSE command reads that code directly or converts it from the characters; I'd seen comments which I thought implied the latter.

But if it does indeed work, scripts won't halt just because they scanned over a new effect, and that's most of the problem. Codes stored between frames are probably fetched explicitly from the vanilla MGEF letter name (DRHE, FIDG, etc.) rather than gleaned from a magic item or effect, and those won't break.

This game will oficially NEVER get old because of you and the OBSE team. Well done, well done indeed.

On a diferrent note, dynamically created Magic Effects sounds like an fantastic idea. Just imagine the posibilities...

I just found a problem in my game. After a trip to Rielle I had the Chills and found that Cure Disease (in all it's forms spell, shrine, potions) wouldn't work. Without the OBME.dll cures work and with it they don't.

Has anyone else seen a problem with Cure Disease?

Thank you for reporting this. The problem was a bug in the code that created the 'Cure' type ActiveEffects. It's been fixed for the next version.

Popping in to say that the bug I'd reported earlier had nothing to do with OBME - It was caused by a blunder of mine. My sincere apologies.

Almost ready for beta2. Major changes to how magic effect codes are handled - they'll no longer need to be the same as the editorID, and may optionally be 'dynamic'. Added the 'CreateMgef' script function to allow creation of new magic effects in-game, which are stored in the savegame like custom potions or spells.

My thanks, JRoush, for making this great mod! I had some ideas for spells of my own but wasn't sure if I could handle it, but this mod inspired me to try my hand at adding my own spells and magic effects.

On a side note, does anyone know how I might recolor the particle effects of some of the magic effect .nifs? From my understanding, this is a relatively new idea because before OBME trying to edit the vanilla effects was a bad idea, but now I'm trying to make my own effect based on the Damage Health effect but with a blue shader and particle effect instead of a red one. If anyone has any experience on changing this, drop me a pm please.

Thanks

Leold

Can't wait for the new version!

How exactly does the dynamic codes work when modding, what are the limitations?

Also in-game effect creation = epic win!

Sorry to keeping you waiting then - I'm delaying until I hear back from the obse guys about my compatibility requests.

Dynamic codes are like formids - one part of the code will be the index in the current load order of the mod that added the effect. This is nice, because it means that you (the modder) can just toss new effects into your mod the same way you'd add new items, cells, etc. Basically, dynamic codes mean that the average modder never has to think about effect codes at all.

There are a couple catches. First, some of the existing obse functions that return effect codes can't actually handle full 32-bit integers, so the codes are corrupted (I'm asking for a fix for that). Second, you generally can't store dynamic effect codes in scripts for use in later frames, because the player might save & reload with a different load order, making the codes invalid. You can still save the code in a variable & all, just don't use it in a later frame. There are workarounds, but more on that when its released.

Ok that sounds great.
Cant wait until the finished plugin!

amazing work, jroush

this mod blew me