Changes made by OBME to gameplay mechanics are all controlled by new game settings, and disabled by default. Unless the user installs a mod which specifically enables the feature, it will not interfere with other mods.

For the record, I make no claims of originality for the present or planned features of OBME - many are taken directly from other sources. The idea is to offer both new and existing mechanics as direct modifications to the engine rather than scripted workarounds. I'm not trying to compete with, or make obsolete, anyone else's work. And if I include a concept that has been pioneered elsewhere, I hope it will be taken as homage rather than competition.

That being said, I'm largely unwilling to turn down requests or drop planned features unless they prove a technical or practical impossibility.

Oh, I didn't mean competition to have any negative connotation, just as a statement of status. OBME really is making some things obsolete, and that's good! And when it makes something obsolete, it probably doesn't matter if it also breaks the old thing. You won't need the old thing anyway.

Competition is fine too (and good for everyone in the way it spurs creativity); it's just that in this venue, where there are a lot of far-reaching overhauls and users generally won't take "incompatible" for an answer, it's important to make sure that competing ideas are either completely stand-alone, or can be disabled with an obvious switch. My biggest concern is farther down in the paragraph you quoted: the switch might not be obvious, specifically because it's a GMST and any mod can enable or disable it.

Granted I may be spending more text on it than the real danger warrants.

Hmm... can I set one of the new GMSTs from a script without breaking anything if the mod is used without OBME? If so, everything's good. My MBSP script can just disable the OBME feature preemptively, so a rogue mod setting it still won't matter.

JRoush could add a function that returns the multiplier, problem solved.


The increment reported by GetSkillUseIncrement shouldn't be changed by this feature. I don't see how OBME would "probably" be thrown off by anything, since I have no doubt that JRoush would implement it properly (if he is going to add it). You're making things too difficult.


You could say that about practically anything in Oblivion modding. Incompatibilities are inevitable, that doesn't mean you shouldn't add feature X or Y.

Not for mods which aren't aware of OBME, which is where the problem lies in the first place.


When a skill use increment is changed, that change persists until you quit Oblivion. It is not reset by loading a game. If a script makes what it intends to be a temporary change, but the player reloads before that change is reverted, there is no way to tell whether it was intended to be temporary or permanent. It doesn't matter how well OBME is coded, the necessary data simply isn't there. This is not some theoretical outside case, it is a common problem which so far has only been solved by storing the intended "base" skill rate in an .ini file, and forcing that value on every game load.

Anyway. I'm pretty sure SetNumericGameSetting works uses the literal string name of the GMST at runtime, since it doesn't throw up compile errors if I typo the name. So I'm 90% sure my solution last post will work, making this topic moot so far as any direct consequences to me. Theoretical concerns about other peoples' mods aren't worth further argument.

There will be no need to alter skill use increments, temporarily or otherwise. Spellcasting triggers an increase in experience by the appropriate increment, OBME can simply multiply this by an appropriate factor before it is applied to the player. Scripts that try to reverse experience gains will run into trouble, but only if they don't check how much experience was actually been gained before removing it.

Game settings are referenced by name, so a script may attempt to change a setting from any mod or plugin. In fact, because they're reference by name, one can override the setting directly in the mod (like any vanilla gmst) and still not be dependent on OBME. This is the recommended approach, because it allows the player to control which mod takes precedence via their load order. This flexibility is precisely why I'm using game settings instead of an ini file.

For the record, the same principle applies to all other OBME features - just having them in a mod doesn't make it unplayable in vanilla Oblivion.

Yes, this is the thing which occurred to me above. Good to have it confirmed. I have officially ceased grumbling.

Yes this is exactly how it should work.

Personally I prefer a game engine related solution to Exp gains diminished or otherwise -> as I would never use a scripted always on gamemode solution.

----

Would it be possible to add an Option to Magic Effects to create a PIO (Placed Impact Object) so its easier to have an object be placed at the point of a magic effect collision without having to use GetFirstRef/GetNextRef secondary scripting as this method while mostly reliable does have a tendency to cause heavy lag when a scene is full of actors calling it leaving spells that need this functionality to be forced rare use.

Also if I wanted to choose to go back and not use OBME is it possible to just delete all of the new magic effects/spells created and resave the esp will those changes be undone so that I can go back to my old way of doing new spells ?

This, or something in that vein, is planned for future versions. The basic idea will be to have the spell detonate on a dummy target, so that all of it's normal effects (including summons) are run. Combined with a new 'summon random object' handler for summoning non-actors, it should serve your purpose.


Yes. At least, that certainly *ought* to work; it's something I'm actively testing.

Under Effect Item Properties could the Magic Effect entry show both the ED ID and the Name as trying to figure out what you want with 4 letter ED ID's gets you cross eyed over time.

also

Could we have a flag to turn Magnititude/Area/Duration into an AV School Multiplier, like if the Mag was 2 and your skill was 1 you would do 2 dmg or if skill was 100 you would do 200 dmg, would require allowing to insert floats instead of only whole numbers into these fields they could always be rounded to Wholes before they get passed to the game engine itself.

I would like to be able to only ever have to create 1 spell for each new effect and have that 1 grow with your character and apply to NPC's as well without any huge scripting or heavy use of OBSE's magic based functions.

Maybe even add a way to scale the Nif's in use based on skill or Area as well so a lvl1 fireball is tiny while a lvl 100 fireball would be fairly large

I would like to see this as well, and I'm working on a system that will allow it to some degree. But don't hold your breath, that is still some ways off.

That's something I always wanted to implement, too. My latest approach was to replace e.g. the fire damage effect by a scripted effect that behaves this way, but this idea sounds far more practical^^.

@JRoush: Sorry for not answering your pm, but when I noticed it, the new OBME version with the fix included was out already. I was not around this forum for a while.

I've also thought about implementing scaling spells, though rather than using a skill multiplier for magnitude, my idea has been to give them a fixed magicka cost. When your skill makes other spells cheaper, this one stays at the same cost but gets more powerful.

How will OBME custom effects interact with OBSE's GetMagicEffectCharsC?

Not sure, I haven't yet tested it.

Let me know if there's any way to make this consistent across load orders, even if it's not printable and/or more than 4 characters.

I had a look at the obse code (as of v19 beta 2, and I don't think this code has changed for beta 3). It interprets the effect code as a c-style string of 4 ascii characters. Because the 'Null' character 0x00 has special meaning in c-style strings, this function generally will not work for new effects. At least, I can say it definitely should not work; I didn't actually bother to test it after seeing the code.

I don't think this is terribly important, though. I know of no use for the resulting string value except the v17 'MagicEffectFromChars' function, and as shorthand for debugging output.

Actually, the command only exists because I requested it. :spotted owl: Formulator, my cloneform management tool, needs to be able to uniquely identify a magic effect for its database keys. Until GetMagicEffectChars was implemented I was using the full text name of the effect, but of course with OBME there's a reasonable likelihood of duplicate names. (Even within one mod -- but Formulator can encounter every mod's effects.) And while I can sanitize a FormID with GetNthModName, there's no clean way to handle a dynamic effect code with only OBSE commands.

Effect codes are the only (trust me on this) reliable way to identify magic effects. I'm not particularly happy about this, but then it wasn't my decision.
The 'effect chars' are just the effect code by another name. They contain no addition information, and I don't see how they would be useful to you. If you want a string to uniquely identify the effect, why not just convert the effect code to a string using the $ operator?

I'll admit that dynamic effect codes will greatly complicate your database, for which I'm sorry. They weren't my first choice. To sanitize them safely, I'd suggest something like this:

;; get the mgef code currently stored in the databaseif (GetGameLoaded) && (IsPluginInstalled OBME)  ;; game reloaded since last frame, and OBME is present - resolve mgef code  set storedMgefCode to (ResolveMgefCode storedMgefCode)endif;; put the sanitized code back in the database, use it for something, etc.

I know that conditional support for other mods is tacky and difficult to maintain, but if you choose to support dynamic effect codes then I'm afraid it will be required (again, trust me). Note that you'll need OBME to compile the script, but not to play the mod itself.

I'd been using the characters because this is stored as plain text and I'm trying to make it shorter, but you're right, the integer values are an option.

Problem is, it's the key which relies on this, not the data. The keys are S-expressions which fully and uniquely describe the stored object. The DB does consistency checking when it looks something up so mismatched keys will never cause the wrong form to be returned, but they can cause an existing form to be ignored, which largely defeats the purpose of keeping track of them.

Now, I do have a database rebuild mechanism. If nothing else works, I can just rebuild on game load if OBME is detected (or was but now isn't). I'm sure that'll cause a noticeable stutter, but it's better than incompatibility. Thanks for pointing out ResolveMGEFCode, that'll probably be enough. The whole mod is made of function scripts with one quest script that's just a variable container, so I can add the conditional code at a couple of points in the initialization and key generation functions and forget about it.

Still haven't figured out what to do about the fact that OBME can make individual spells override their MGEFs...

Tejon, why not convert 4byte integer effect code to 8char hexadecimal? if effect code is readable it will turn into asci code, if not it will still match 8char string? or is that something that should be asked on OBSE thread? (lacking command making this impossible?)

The problem is when the load order of mods changes, and an existing save game has string keys which no longer match JRoush's dynamic effect code IDs. With FormID's, I can work around this by replacing the first two hex digits with the literal string name of the origin mod. Unfortunately these aren't FormIDs.

Rebuilding the DB at game load is a good enough solution, I think. At worst there'll be a short stutter right after loading, but regular gameplay will be smooth.

any word about the new release? just interested. :foodndrink:

Sorry to keep you waiting. I'm reluctant to release until I manage to reproduce some of the reported problems (CTD's with scripted abilities being the main one).

no problem, of course. thank you and good work! :icecream: