Just an addition to the "not below one point" suggestion for the modav handler: how about using a percentage instead? Maybe one that depends on a global variable like the separated summoning limits? That would have the advantage of finally making the drain effects balanced. A "not below one point" option would help that much in my opinion, because a drain health spell for 3 sec and a single weapon hit could still kill an enemy instantanously. With an option that health can't be drained to a value below (e.g.) 30% this wouldn'tt be a proplem anymore. This would also fix the "drain speed" problem. Currently, if an actor's speed value reaches zero (which is very likely on some creatures, even with a very weak drain spell) he drops out of combat and slowly walks away :-/.

A 3-second Drain Health is still three times as expensive as a 1-second Drain Health. That's an order of magnitude, euler-wise. And in the implementation I'm working on, custom drains are forced to 15-second intervals. (I've already got this functional, without the help of OBGE.) So for me, the percentage option would be useless whereas the just-one-point option is actually something I've already implemented (in scripts) for Fortifies wearing off -- and this absolutely, positively should not be a percentage. So I'm going to toss a meaningless but emphatic veto on "instead." Of course, if there's room, nothing wrong with "also."

Now, a completely separate ModAV handler where the magnitude is a percentage in the first place... that could be interesting.

Ok you're absolutely right. This would be great. But drain health 100% could still be a problem then ^^

I can implement both a percentage and hard 0-or-1 pt limit, provided you don't want too much precision in the percentage.

How much room is there? Are we crowding out the possibility of future booleans? (If adding new handlers is a sure thing in the future and just on the back burner while this is beta, ignore this concern.)

Personally I liked the 1s Drain Spells - one of the magic overhauls just made them really expensive, and all the pre-made versions were 1s and were balanced for that - and they were just Kill spells. "Kill a creature with less than X health" works out pretty nicely, in general.

After the limit fractions, there are 4 bits left for future flags. New handlers are always an option, but do you have any particular behavior in mind?

Did you determine what the various Unknown flags in MGEF records were, by the way?

All but 2 (more or less). They're laid out in an enumeration in Source\RSH\GameForms\MagicEffects.h

Have you told Scruggs about that? OBSE's GameForms.h's EffectSetting class doesn't seem to have that updated. Probably should do that.

Yeah, probably B)

I've been meaning to do that for a while, actually, just haven't gotten around to bugging him about it.

No, I just wanted to make sure there's not a cap on expansion if new ideas do arise!

Speaking of new ideas: I'm sorry for bothering you with percentages again JRoush, but I always disliked that the actual effect of a 'disintegrate' spell depends so much on the absolute durability value of the opponents weapon/armor. One and the same spell can instantly destroy a dagger, effectively disarming a thief/assassin character, but is only of minor concern to a warrior swinging a big battleaxe . A flag that causes the magnitude of the effect to work as a percentage of the item's base value instead of an absolute value would be great in my opinion. Just a suggestion, of course .

Seems reasonable, although I'm not sure a dagger wouldn't be easier to damage than a battleaxe.

Fair warning, though - it will be a while before I tinker with the Disintegrate handler. So far as I know, nobody really understands the 'extra data' objects that keep track of things like weapon health. This has held up a lot of requests for obse too, so hopefully somebody will look into it soon.

The problem in this case isn't undecoded data, it's that items in inventories are not referenced in the same way as items in the game world. If someone's carrying three daggers, a script which does something to a dagger will have no idea which one it's affecting. As of OBSE v0017, equipped items can be safely singled out; and 0019 will be able to create virtual references for an entire inventory, which only last one frame but should safely allow a lot of manipulations which are currently broken.

Anyway, adjusting the durability of something that's currently equipped is already script-safe -- otherwise Lock Bash Omega wouldn't damage weapons, and Armorer's Advantage wouldn't be released! So I think you're clear on fiddling with Disintegrate.

Guess "as far as I know" wasn't very far ...

Anyway, it sounds like once obse v0019 is relatively stable I can borrow their code. My plan for the Disintegrate handler was to allow it to affect all inventory items, not just those that are equipped, and to affect more than just item health. This would open up options for effects that, say, charge your soul gems, or temporarily increase the quality of you alchemical apparati, or forcibly unequip a weapon.

Was looking over the source code when I found the OBME Design v1_beta2.txt file and I noticed it had alot of stuff that would be more in the area of mods than a plugin. I take it this file explains what you initially planned to do with OBME (before it grew/changed into the OBSE plugin that's currently released)?

Also, has anybody tried how this works with Custom Spell Icons (the most recent version)? I recall reading something about how OBME uses the actorValue field for SEFF (or was it for the SEFF handler?) and I know CSI also uses the actorValue field to determine if it should be unique or not. Or something like that. :unsure:

-kyoma

That file is a sort of roadmap of everything I'd like to do (not necessarily in chronological order). The three basic features are

• New & expanded magic effects and effect handlers
  
• New 'meta' magic properties for magic items
  
• Creation of temporary, 'altered' spell instances at cast time

As of beta2, OBME is about 40% of the way through #1. There will probably be several more betas - some fundamental behind-the-scenes stuff left to implement - before a true release of 1.0. After that, regular stable releases will implement the rest of the planned content.

Keep in mind that OBME is not intended as a library of script functions, but as an extension of the magic system itself.

There are also a few things in the file - ideas for actual magic effects - that may eventually find their way into a separate 'mod' at some point as well.


EDIT: Ok, here it is:

I'd like to dream that all script effects worthy of their own icon will someday be implemented as real magic effects. That kind of acceptance for OBME is a looooong ways off, though. In the meantime, it is obviously very important to make OBME compatible with existing mods that fix this issue, especially when they do it as well as CSI does.

I can, with some help from the obse team, ensure that OBME is fully compatible with CSI and any other mod that uses the 'extra' parameter on SEFF effect items.

Moreover, I can also allow modders to directly set an icon path override for any effect item, in the same way they set the 'Name' for script effects now. This won't supersede CSI, which lets the player customize icons in-game. It would, however, let an OBME-dependent mod give icons to the spells in existing mods like Midas, MM, etc.

Apologies if this has been covered, but what's "Neutral" hostility? Vanilla CS only has hostile or not...

And on that note, two ideas. First: Dispels that target only hostile or only beneficial effects. Second: effects that do not flag as criminal when used as spells, but which are treated as poisons when brewed alchemically. (No urgency on the latter... it can be emulated by creating two copies of the effect, one hostile and one not.)

The expanded Dispel handler already selectively targets hostile/neutral/beneficial effects depending on whether the dispel effect itself is hostile, beneficial, or neutral. For details, see the notes on hostility and the dispel handler in the 'Features' pdf. The DSPL example plugin has a new effect 'Cleanse' that illustrates this nicely (only removes effects from hostile spells).

Basically, for most purposes 'neutral' and 'beneficial' are the same. They are treated differently by the dispel handler, and will be treated differently by the 'selective targeting' meta-magic feature when that is implemented (should be next version or so).

As for the potion/poison thing - another planned feature is to allow the mod maker / alchemist to manually decide whether a given spell/enchantment/potion/etc. is hostile. That should put a permanent end to the problem of not getting a poison when you want one.

Ha, and I see there's an option to go by individual effects instead of entire magic items... so that's two scripts that can be removed from Birthsigns Expanded.

...well, assuming that if you dispel by effect, the effect definition is checked for hostility rather than the MI.

Huh. There's still an odd little complication there for one thing I want to do, and now that I think about it, perhaps it could be solved in an completely different way. Could you decouple "hostile" from "illegal," allowing the latter to be set or cleared independently?

I suppose it's possible, although I'm running out of flag bits that I can safely overwrite. Could you elaborate a bit more on what this is for? I wouldn't tell you how to write your mods, of course, but their may be an cleaner distinction than 'illegal' (for instance, a 'Stealthy' flag that doesn't trip any AI reactions ...).

Exactly this. A way to have an effect that is hostile for selective-Dispel and is-it-a-poison purposes, but isn't perceived as an attack by the target or witnesses.

I think, in the long run, this might be more of an AI thing than a magic thing (like the combat behavior discussed before). But I'll see what can be done.

I have been having some trouble with OBME. It seems to have some saving trouble, when I tried to make a new summon (with a new icon and dynamic code) the cs fails to save, it says that it can't find the path specified. I also had some trouble with the game, I would save the game but when the game was exited and restarted the saves would either crash or the game would sort of reset, I would still be in the location i saved at but all quests would be reset and I would be reset to the default player, the way you start out in the prison.

Removing the OBME dll files fixed the problem.