Name: Oblivion Magic Extender
Version: v1.beta2
Date: 2010-07
Category: Magic - Gameplay
Author: JRoush
Source: http://www.tesnexus.com/downloads/file.php?id=31981
Previous Version: http://www.gamesas.com/index.php?/topic/1099722-relz-oblivion-magic-extender-v1beta1/
Contact: jroush.tesmods@gmail.com

Partial Readme:

This is the second beta release. Comments and suggestions welcome. For specific bug reports, please send me a private message.
In particular, I'm open to suggestions on ways to expand the existing effect handlers.

Many thanks to everyone who took an active interest in the previous version.

Cool, but um, the file is hidden according to TESNexus.

[edit]
Oh and a few questions until I can download the actual file....

[quote]1. Expanded SummonActor effect handler to allow custom summoning limits

2. Expanded Dispel effect handler to allow....

3. "Reclaiming" of some of the lost magicka
[quote]1. I assume this means you can set a custom limit for a specific summon effect? Can this be a variable (of sorts) for when you have a group of summon effects? Although not really nessecary, just easier for when you wish to change the custom limit.

2. These new dispel options, they're in the form of flags for an induvidual magic effect with the Dispel handler? If so, how customizable is it (especially with regards to dispelling on a effect-code-basis)?

3. This too is a flag (or value) for a magic effect? Can it be configured as to how much magicka is 'reclaimed' (percentage-based)?

Sorry for the questions but I might not even be able to try things out, even after downloading. My pc broke and this one doesn't really like Oblivion or the CS. :brokencomputer:

-kyoma

Me want!

Lol, sorry.

See, it's a chicken-or-egg thing: I want the forum link in the readme, but the readme has to be included with the mod archive, so...

Anyway, it's up now.

Edit: Kyoma - The answers to your questions *should* be in the "Features.pdf" included with the mod. I'm not a very good writer at 5am, though, so feel free to tell me it's crap and you still have questions.

Ah yes ofcourse, should have guessed as it is exactly what I always do.

Thanks for the new update

Crap? Oh far from it! The reason I asked these questions here was because I never expected such a large and comprehensive readme. It is alot of text to read but atleast now I have something to keep my mind occupied while I wait for my computer to get repaired. I even managed to get the cs up and running (took 5 minutes though ) .

Cheers! :foodndrink:

-kyoma

Looking at the format changes.

For MGEF, the new chunks are EDDX and DATX? Are those the only new chunks? EDDX appears to be a non-null terminated string. Is DATX a fixed size of 32, or is it variable?

For the EFIT changes, you state in the readme that they can be followed by additional SCIT / FULL chunks. Is it one possible new SCIT / FULL? Or can multiple new SCIT / FULL's follow the EFIT? The new chunk appears to be DATX again. Presumably the same format as the DATX in the MGEFs? Is the DATX associated with the EFIT or with the record (can there be more than one DATX per record)?

Lastly, do you expect any further format changes? Or is this pretty much finalized?

Edit: It also looks like the old EDID field is now the formID for the MGEF. Presumably this was easier to implement since the game code was already checking the EDID as the record's identifier. Should this be treated as a regular formID for conflict resolution? Or are they effectively a separate pool of formIDs that can only conflict with other MGEFs?

Edit2: That previous edit may be wrong. I was looking at OBME_SEFF_example.esp at the time. Looking at OBME_SMAC_example.esp, the EDID has a normal 4 char identifier in the EDID field.

For the MGEF record, the new chunks are:
EDDX - variable size, contains the editorID of the effect (the EDID chunk would normally hold this, but for MGEF it holds the effect code instead)
DATX - fixed size (0x20 bytes), contains the handler code (4 bytes, offset 0x0), a secondary flag field (4 bytes, offset 0x4), and a secondary handler parameter (4 bytes, offset 0x8). The rest is zeroed out and reserved for future use.

For the magic item (SPEL,ENCH,INGR,ALCH,SGST) record, the new chunks are:
DATX - fixed size (0x20 bytes), zeroed out, reserved for future use. It's essential that it be there, though, for technical reasons.
FULL - variable size, comes right after the DATX chunk. Holds a second copy of the item name. This is also necessary for technical reasons.

For the individual effect items, the complete format is:
EFID - same as vanilla, required, holds the effect code
EFIT - same as vanilla, required, holds effect magnitude, duration, etc.
SCIT - same as vanilla, *optional*, holds effect info override. If present, must come immediately after the EFIT chunk. In vanilla Oblivion, only 'Script Effect' effect items had this chunk, but with OBME, *any* effect item may have it.
FULL - same as vanilla, *optional*, holds effect name override. If present, must come immediately after the SCIT chunk (cannot be present w/o an SCIT chunk). Again, in vanilla Oblivion only Script Effects had this, but with OBME any effect can.

Only one SCIT/FULL pair should follow any given EFIT chunk.

I don't expect to any further changes to the chunk layout, although I may eventually find a use for those extra fields in the DATX chunks.

Finally, just to be clear, the effect codes are not formIDs, and in general should not be treated as such. Dynamic effect codes (those greater than 0x80000000) are a bit special, for them the lowest byte is the index of the mod that created them (instead of the highest byte, as in formIDs).

Whew. Hope you can make good use of all that.

When viewing the content of an esp (in the plugin selection menu by clicking the 'details' button) I noticed that it doesn't list the editorIDs for any MGEF added or altered by the mod. Although I'm not 100% sure this isn't simply default behaviour even without OBME.

Also, been looking into dynamically creating a MGEF and I was wondering if the various http://obse.silverlock.org/obse_command_doc.html#Magic_Effect_Setting from OBSE will work as they should? And are there plans to add additional functions to get/set all the new settings added by OBME for a MGEF. Right now it is possible to dynamically create a MGEF but there is limited control over all of its settings ingame. Or atleast when you compare it to all of the new, interesting stuff that's been added.

-kyoma

Looks good to me. I'll make CBash compatible with loading / saving the new format tonight or tomorrow, but won't allow editing just yet. I'll add the ability for CBash to edit those fields some time later on.

I noticed in OBME_SEFF_example.esp that TES4Edit has an unknown actor value in spell 01009E39 (RshObmeSpellOriginalSEFF). It appears to be the formID of the RshOBMEScptEFootloose script. Are there any other changes like this I should know about?

Short answer is yes. But it's been hard to get a hold of scruggs lately (technically I don't even have an opcode base assigned for the functions I have added).
The thing with the mgef editorIDs is indeed the original behavior - probably a side effect of using the EDID chunks weirdly.


I'm amazed you can do it that quickly. Look forward to using it, poor TES4Edit has been a bit unstable with the new file formats.

I've sort of turned the 'Actor Value' field on effectitems into a general purpose field (call it the 'efitParam'). The contents will depend on the handler of the effect. For ModAV effects, it will still be a single actor value. For ScriptEffects, it will be the script to execute, or a "free" parameter that has meaning only to the script author. Other handlers might eventually make use of it as well. If an SCIT chunk is present, I make the 'script formid' field an exact duplicate of the 'efitParam', or vice-versa. This is why you see a script formid where you would ordinarily expect an actor value.

I'm making similar changes to the 'AssociatedItem'/'ActorValue' field on EffectSettings (call it 'mgefParamA'). Again, the contents are handler specific. In addition, I'm "repurposing" some of the unused or unecessary EffectSetting flag bits, and the extra space in the SCIT 'hostility' field.

So, long story short, it might be best to treat all of the 'parameter' and 'flag' fields as very general 32-bit numbers for the time being.

That should do it for me as far as the format stuff goes.

It's fairly simple to add new chunks to CBash's record definitions. Just have to change add the chunk to the record (1 line), add it to the loader (3 lines), add it to a GetSize() function (2 lines), and finally add it to the serialization function (2 lines). So about 8 lines of code or so per chunk per record type with most of it being copy/paste after initially writing it for one record. Plus another 20'ish lines for the new chunk definitions. I'll also have to add support for resolving dynamic effect codes (~10 lines, using the same routine that I use for formIDs) since they'll have to be kept updated with any change in the mod's masters. So maybe 80-100 lines of code total.

It gets a bit more complicated to add editing support since I have to expose the new fields with the API, add them to the python interface, and handle creation / deletion of the chunks based on whether OBME is in use for that mod.

I wonder if changes to (or completely new?) effect handlers should perhaps be broken out to a secondary plug-in architecture?

That last one also strikes me as more mod than tool, but I haven't read the readme yet.

All of those things are in the form of flags and settings, meaning you can use them for a magic effect but they aren't used by default for the standard magic effects. It'll take a mod to actually implement any of these things.

Oh, I understood that to be the case. I was actually suggesting a plug-in architecture for handlers because I can immediately think of other changes I'd like to see happen (especially to Dispel!) and while many if not all of them could be done with careful scripting, it would be nice to have the extra flexibility!

Guilty as charged, I suppose. I originally planned to do a magic overhaul mod, and OBME evolved out of the groundwork for that. So some of the features are for my own use. They are all optional, though, or at least they ought to be.

I actually agree about a modular design being more friendly, but most of obme (or obse, for that matter) is actually behind-the-scenes infrastructure and type libraries that would have to be duplicated for every module. So, for the time being, a big single package is just easier.

I meant OBME having its own module structure. You'd have an OBME subdirectory containing DLLs for each handler, which are dependent on (and loaded by) OBME.dll, so they shouldn't have to reproduce anything. The main OBSE plugin handler won't try to load stuff in a subdirectory. Just in case you eventually want to do some other sort of plugin, I'd probably do either OBME\EffectHandler\ or specify it in the filename like EFFH-Dispel.dll.

Of course, this can all be done later and I certainly don't want it delaying release.

I think, for the time being, I can at least take advantage of the message-passing functionality in obse to allow other plugin dlls to register or override effect handlers.

It won't be for the faint of heart, though, so perhaps it would be easier for me to just implement your desired changes myself? There's quite a bit of space for more flags on the Dispel handler .

Well heck, if you're willing to do it that way...

Dispel: currently, the magnitude of a dispel effect is checked against the cost of an effect on the target to determine whether that effect is a candidate for dispelling. The target effect's cost is modified by the relevant skill of its caster. This means that the more powerful the caster of a spell, the easier it is to dispel. Many people find this quite ridiculous. If you can provide multiple options, the following seem like reasonable alternatives:

• Use the CS cost of the spell. This is the most obvious one, and probably what was actually intended: consider that by default the dispel magnitude is multiplied by 5 before it's checked against the target effect -- and by default, a Master pays 1/5 cost for his spells.
  
• Calculate the cost of the effect as if it were cast by the caster of the dispel. The better you are at Destruction, the better you are at dispelling Destruction effects; etc.
  
• As above, but always use the caster's skill in whichever school the Dispel-handled effect belongs to. I probably wouldn't use this for reasons of double-dipping, but it does make sense.

Conveniently, that's four options including the vanilla behavior; two checkboxes behind the scenes, though probably best to use a drop-down in the UI. (Projectile type does the same. BTW, has anyone figured out how a Spray projectile is actually supposed to work?)

Now, while you're at it... two other broken effects, which I've produced patches for in script but would love to see in code, are Feather and Fortify. Both of these are handled by ModifyActorValue, so I'm not sure if all of it can be done. Feather's more important since the script fix is imperfect.

Feather is broken in two ways. The first is that in the inventory UI, it reports an increase in your carrying capacity; this is not actually what it does. Really, it reduces your carried weight, which is a much better effect because certain things are based on your carry percentage, and Feather can reduce that to zero. Fixing how the UI reports it would be nice. Even more importantly, though: to prevent causing negative encumbrance, there's a cap on Feather equal to your actual carried amount. Cast a 50-point Feather with 40 units of encumbrance, and you get a 40-point Feather. Drop 10 units, and the effect reduces itself to 30. But pick stuff up and it's still 30! The AE record itself is updated to the lower value, so the only way I could fix this in script was to look up the source magnitude; unfortunately that means that my fix always gives you full magnitude, regardless of anything that might have reduced the spell's effectiveness when it was cast. A fix which maintains cast-time adjustments would be awesome.

Now: Fortify Health, Fortify Fatigue and Fortify Magicka. The problem with these is simple: when they wear off, the fortified stat can go to zero. (Actually negative? Don't recall.) Not a big issue for Magicka; but Fatigue knocks you out and Health kills you. Fortify Health in particular is 99% useless because of this. A checkbox to prevent the removal of this effect from dropping the modified AV below 1 would fix everything.

Thinking about it, a simple "Not Below 1" checkbox could also apply to initial reduction effects, couldn't it? So a 1-second, 100-point Drain Health would no longer be "kill anything with 100 Health for super-cheap." You'd still have to hit them once with something else.

One more thing while it's on my mind: Rally is also done by ModifyActorValue. Calm, Frenzy and Demoralize all have their own handlers, and are level-based. Is it possible to create a new Rally handler which works like its siblings? Alternately, could one or two of the other handlers be made generic? Basically all they do is force a particular AV to either 0 or 100, right? Being able to select which AV, or being able to select "maximum" or "minimum" with a checkbox, would seem to mean only two handlers are necessary for all four effects. Being able to do both prunes it down to just one.

Actually, the obme dispel handler has already changed this. The "equivalent magicka" of an ActiveEffect is calculated like the base magicka cost of an ordinary EffectItem, using the current magnitude and time remaining (i.e. after resistances, previous dispel attempts), zero area, and onself range. The source spell, effectitem, and caster are not considered at all. This means that if you see a "Fire Damage 10 pts" effect with 4 sec remaining on your character, it will *always* cost the same amount to dispel, regardless of where it came from or who cast it.

I didn't mention this explicitly because it breaks my cardinal rule about obme not changing anything directly. Future versions will contain an option to use the "true' vanilla behavior, but I seriously hope nobody will use them.



There are several possible fixes. The best is probably to alter the game code to allow negative encumbrances; any value below zero would be considered zero for all intents and purposes. This preserves the existing mechanics without requiring any new actor values (which might be impossible). I have an uncomfortable feeling that negative encumbrances will wreck someones script somewhere, though, so I'd appreciate feedback.


Wonderful idea. I'll include this in the next release.


I haven't decoded those handlers yet, but I've a shrewd suspicion they have to tweak the target's AI in addition to just modifying an actor value. I'll look into how it's done and report back at some later date.

Personally, though, I'd like to do away with the all-or-nothing behavior of these effects entirely. As far as I know (which isn't far), combat behavior in Oblivion boils down to either "Geronimo!" (melee), "Sniper" (ranged), or "Coward" (fleeing). There doesn't seem to be much gray area in between. It would be nice, for example, if a character who's aggression and disposition were very close would attack, but halfheartedly, maybe only swinging or shooting half as often or something. And it would be nice to see characters making a tactical retreat, instead of just tucking tail and bolting. If combat behavior were more fluid, then being able to magically affect it would be much more intuitive and useful.

Very likely. I've got at least one (Unfettered, from the Steed in Birthsigns Expanded) which would be affected... don't know if it would break per se from the user's perspective, but it might get a little confused about what magnitude of Feather it should be applying, especially when other Feather effects are in play. More to the point, there are a couple of actual encumbrance overhauls out there which are fairly popular and would probably be where you'd see serious issues pop up.


Great ideas! And also more blocking/avoidance from actors who don't really want to hurt you, or are on the verge of flight. This stuff would be amazing. It would also be entirely out of place here, unless you just go ahead and change the name to "The Oblivion Re-Engineering Project." Which is an attractive thought, but might be too much to chew. Definitely something to keep on the to-do list, though. Meanwhile, I'm curious what you find when you do crack open those handlers.

Oh good lord yes, and out of my area of expertise as well. That's a job for someone who knows and loves the AI system.

Heh, I'm fairly certain no one does that.

That was my thought also. Especially those who know it...