http://www.tesnexus.com/downloads/file.php?id=31981

Comments and suggestions welcome. For specific bug reports, please send me a private message.

Requirements:
=============
NOTE: using OBME with the wrong verison of Oblivion or the CS will, *at best*, cause it to crash.
- Oblivion v1.2.0416
- TESCS v1.2.404 (only if you are planning to make mods using OBME)
- OBSE v0018 or higher

Description:
============
OBME extends the Oblivion magic system to make it more general and open to mod makers. In a nutshell, it is a pair of plugin libraries for OBSE that hack the game/CS code to change it's behavior. Note that this is the same principle behind OBSE itself - it's quite safe, and will not alter Oblivion.exe or TESConstructionSet.exe in any way.
In this version, the key feature is that it allows a mod (*.esp or *.esm) file to add new magic effects (e.g. Fire Damage or Soul Trap). Note that this isn't some clever scripting trick; the effects are actually added to the internal tables used by the game and construction set. New effects have their own names, effect codes, costs, models, sounds, shaders, etc., and can be flagged for use in spellmaking, enchanting, and alchemy exactly like the built-in effects.

Feedback:
=========
This was/is a *very* complicated mod to build, and very time consuming. I would be surprised if there aren't bugs, and there simply isn't enough time in the day for me to catch them all by myself. If you encounter problem, something that is confusing or doesn't seem to work as expected, *please* *please* *please* do the following:

1. Read this readme carefully. Often I've addressed the problem already, or at least included a warning.
2. Reproduce the problem. If it's a crash, restart the game or CS and try to make it crash again.
3. Narrow down the cause. Try to figure out the circumstances that lead to the problem. Specific bug reports are easy to fix, while bug reports like "the game crashed after I installed OBME" are just a waste of my time.
4. Send me a PM on TESNexus or the Forum. Include the details, and attach the log files "OBME.log" and "OBME_CS.log", which can be found in your "Oblivion\" folder.

Included Demo Mods:
===================
Included are several small demo mods with names like "OBME_*_example.esp", each of which contains a new Magic Effect and an assortment of spells, items, etc. that can be used to test it. See the individual mod descriptions for details.

Instructions:
=============
For installation and usage instructions, read the Readme.txt included with the mod.
This is important, so I'll say it again: READ THE README.

The readme is good reading :hubbahubba:

Very promising work!

This sounds like it could be very, very useful.

Impressive work! I've also read the readme and I concur with Waruddar above... Very promising future ahead!
Hoping that some of magic overhauls makers would take a look to this! Looking forward to see what they can come up when using this new tool

Good work, and cheers to the release! :foodndrink:

I noticed in the comments section that you changed the esp format slightly:


Could I get the details on this, so I can make CBash compatible? I 'could' just dig through the record with a hex editor, but I'd prefer not to

Extremely impressive :thumbsup: Keep up the bad work, mate!

EDIT: Where is that section ?

The TESNexus comment section

D-oh :facepalm: Took a quick look - Looks like most of the plugin's hooks are centered around the run-time. AFAICT, only a couple are placed in the editor environment (at the main window's procedure and at the call to the EffectSetting dialog's creation) and that leaves me enough room to maneuver.

PS : Sorry about that, JRoush I was talking about my CSE OBSE plugin which modifies the CS too.

Wow this looks infinitely useful! Thankyou soooo much!

At the moment, I've changed the length of the DATA chunk in the MGEF record from 0x40 to 0x60. At offset 0x40 is the EffectHandler code, and at 0x44 is a new flag field. The rest of the extra space is reserved for later additions. This makes working with editors like Wryebash and TES4Edit tricky, but surprisingly the game/CS loading routines don't have any problem with it.

In the future, I'm planning to implement a few other changes. Should I keep you posted, Waruddar?




Oblivion is very object-oriented. Most of the hooks are in the member functions of the various magic-related classes - EffectSetting, ActiveEffect, EffectItem, EffectItemList, and MagicItem. As the mod grows, I'll eventually have to hook most or all of the code related to these classes. It shouldn't interfere with the scripting system, though.

Also shademe, the CSE looks like a real gem. It's a shame I didn't hear about it before.

Good to hear. I was more interested in your hooks to the UI, as I've been fiddling around with the editor's code outside the script editor and was concerned about one of your patches overwriting mine.
Hey, thanks! More so for providing your findings - It's going to make my life easier

I wonder if the OBSE team had thought of implementing new MGEFs the way you have, when they were investigating into the matter. Then again, there probably wasn't much info exposed at that time to have facilitated it.

Thanks. That's enough for a quick compatibility fix.

I'd also like to add support for reading/writing to those fields:

• Are all the EffectHandler codes listed in the readme?
  
• What are the values of all the new flags?

Please do.

sweeet!

Holy hell... this is the thing I kept pestering DragoonWraith to investigate while he's working on ARES. One important question before I download this and devour the readme: do you see any possibility of re-implementing existing MGEFs? Dispel, in particular, needs fixing.

Regarding changing the .esp format -- couldn't you use a companion file instead, like OBSE's co-saves?

This looks pretty darn amazing. :drool:

Maybe you can change the effect handler of Dispel to SEFF and simply take over the whole behaviour.

But that leads me to a question of my own, what part of the whole magic business (EffectHandler -> EffectSetting -> EffectItem -> MagicItem) determines which spells are casted by NPC? Is it based on the EffectHandler? If so, and the above is possible without a CTD, would that mean NPCs stop casting dispel spells? :unsure:

-kyoma

This sounds awesome, but I'm going on the responses from people understanding which possibilities it opens up on this. Can someone sketch out what might be possible with using these extenders for us, uhm, code challenged?

Entirely new magic effects, without overriding any existing ones. And these new effects would literally be new effects, not just a scripted effect.

[edit]
Oh and I should commend you, JRoush, for being able to figure stuff out using IDA Pro. :foodndrink: I tried it myself for a little while and although I had minor success it wasn't long until I started going crazy. :wacko:
[/edit]

[edit2]If I may ask, how long have you been working on this? [/edit2]

-kyoma

Short version: it's like script effects that can be used at the spellmaking altar.

And, it looks like the answer to my question above is kind-of-yes... just need a way to convey a magnitude to a script. Might this be within the realm of next-beta, JRoush? Perhaps (shot in the dark) a special keyword that looks like a global variable to the compiler (so no new OBSE plugin commands have to be registered) but is modified to match the calling effect at runtime? I assume this would be able to properly handle things like target resistance and diminished caster effectiveness.

I have been waiting for this since OBSE began and I am glad this has finally been created.

That does indeed sound awesome.

Truly revolutionary! Good work! :touched:

I've been waiting for this for a long time.

I'm unsure. I would assume that NPC's look at the spells in their spell list and choose based on magicka cost, range, and hostility, etc. I have a shrewd suspicion that the counter-effects lists play some role in how NPCs choose their spells (since they don't seem to have any direct impact in the magic system). In any case, it is perfectly possible for me to overwrite the Dispel handler to be more usable without causing CTDs. In fact, this is one of the things that got me started on this project. Sadly, it's not a high priority at the moment compared to the ScriptEffect, ModActorValue, and Summon handlers.


It has long been possible, using Script Effects, for modders to make spells/enchantments/potions/etc. that do almost anything (for example, the 'Stark Reality' spell that makes the target dance naked). But these custom spells had drawbacks - they can't be used in spellmaking, enchanting, or alchemy, they all use that d*** Burden icon, and, most seriously, can't have a magnitude.
So if you wanted, for example, an 'Inebriation' effect on alcoholic drinks to make the drinker act drunk, you had to make a unique script for every different strength of drink. Believe it or not, this is a real deal-breaker for a lot of clever mod ideas.
This mod sidesteps these issues by allowing the player to create new 'Magic Effects' that use the basic behaviors of the old effects, but with different parameters. Eventually, this will be incredibly powerful, but even in this version it's useful. New effects can inherit the Script Effect behavior (or at least most of it, see the 'Limitations section of the readme), but this time allow a magnitude, provide their own icons and base costs, and be used in spellmaking, enchanting, etc. So, in a nutshell, you can make a new, fully realized magic effect that can do anything a script can do.


Thanks. It turns out, luckily, that I'm pretty good at reading assembly code. Even so, I've been working on this project since march to get this far.


You can fetch the magnitude of an SEFF effect item now, using OBSE v0017 functions GetScriptActiveEffectIndex and GetNthActiveEffect*. You just had to be a bit careful if there were many spells using the same script. I used this trick quite a bit, although now that I think about it I may never have released those mods. Even before OBME, you *could* give scripted effects a magnitude if you were handy with a hex editor.

I'm not sure if this will work with new effects that use the ScriptEffect handler, but sadly I doubt it. In any case, I think it might be possible to implement a 'magic' variable that will be detected and set before the execution of the script so that you can reliably retrieve the magnitude, area, etc. This might have to wait a few versions, since I'll need to consult the OBSE guys about modifying the scripting engine.

Oh that's not as long as I had expected. I mean, sure it's alot of time but looking at what you have accomplished I expected a much longer developement time. This just makes me even more impressed of how you made OBME!

It would be a cinch to get the Magnitude textbox enabled for script effects - I could add that to CSE. Or does the CS doesn't perform a sanity check to keep invalid attributes from being saved ? Will take a look.

I'm not sure you've actually taken a peek at this. No need for that effort on your end, it's all wrapped up in a neat little checkbox and it becomes a valid attribute. The only problem is conveying the magnitude to the script. It may require a custom EffectHandler, not sure. But it's the only notable feature I see missing right now.