For the 2nd, those seem quite straightforward to me.

Is there a reason they can't use the standard OBSE MagicEffect functions for those checkboxes? I believe we have most (if not all) of them exposed.

just go with the flag... and write out a handy reference of what each flag is on the wiki
I really really like #2's possibilities and I think they seem fine.
Glad to see some more great looking progress.
Pacific Morrowind

I'm comfortable with a bitfield. (Which I assume your function would basically be; 2048 is an example with only one bit set, right?) However, if the OBSE functions can be used that'd be handy. Also, perhaps you could provide a set of intuitively-named constants which contain the appropriate bit values? "aresGetMagicEffectFlag aresFlagSPELLMAKING"

Edit: Re-reading I see that this particular function probably doesn't work with a bitmask. How about aresGetMagicEffectFlags (plural) just returns the entire mask, aresSetMagicEffectFlags asserts the entire mask, and we can do things like this:

aresSetMagicEffectFlags ( aresGetMagicEffectFlags & !(aresFlagSPELLMAKING | aresFlagENCHANTING) )
(Clear enchanting and spellmaking flags, leave the others intact.)

Or to see if the enchanting flag is set,
if (aresGetMagicEffectFlags & aresFlagENCHANTING)


"AffectWielder" / "EnhanceAttack"


We can build two different affix lines which use the same effect but have different sequence and item type lists, right? If so I see no issue, even hypothetically.

Eh, I feel weird using abbreviations in the non-abbreviated versions.

By the way, how do people feel about aliases that aren't exactly consistent with the long form? Like, "aresGetAffixLineWeaponAffectsSelf" and "aresGetALWepOnSelf" - is this going to annoy/confuse people? This sometimes irritated me when I was working on the magic effect functions for OBSE.


You're missing NoRecast, not that I know where that is. You're also missing the projectile type (ball/fog/bolt/spray) field, which I tried to find but couldn't. At any rate, I can't use those because these are not actually EffectSetting's - without knowing the constructor for those, I couldn't really use them (and Scruggs advised against it, in any case). So the GetMagicEffectValue and each of the individual functions would have to be replicated for my pseudo-EffectSetting class objects.


Of course.


Cool, cool.


Yes, it is a bit-field, and yes, I can write those functions. OK, sounds good, and I can probably put those constants in the esm.


Hmm. I like those.


Yes, every effect can have multiple affix lines (limited only by the storage space in a 32-bit integer, which is probably pointless because I'm not sure ObScript is capable of passing a number that high back and forth...

So, everything except the AffixList stuff, and the actual enchantment spawning/calculation (most of which I have done in ObScript and just need to port to C++), is done as far as the plug-in goes. So tomorrow should see a lot of testing.

Also, for those who are interested, I just looked: The original .esp I created when I started working on this has a creation date of May 27, 2007. Yeah.

Great job on the progress, I have been looking forward to this since you announced it!

Holy...
Its been a long road! Must feel good to finnaly be nearly done

ARES ARES ARES YAY

:D

Can't wait for this mod. Thanks for the hard work!

I would love to help this mod come to fruition in any way possible! I don't have much experience with the Modding software but I am kinda a quick learner when it comes to code. I'd do anything you could possibly need I'll even come up with prefixes for the items or something.

Hey DW, a question and a repeat-prodding.

First: have you seen any indication in your engine-digging of how spell effectiveness is applied? Does the engine automatically pass a reduced magnitude to the effect, or will ARES spells need to handle this explicitly?

Second: you were skeptical of the possibility the first time I brought this up, and I know it's not a release priority, but I cannot begin to describe how many doors would be opened if the built-in MGEFs could be gutted and replaced. Pretty pretty please with a sensible Dispel mechanic on top!

Tejon,

not sure exactly what you are asking here on spell effectiveness. For all my custom scripts (like burden that stacks), I had to apply spell effectiveness in the script. Of course Spell Absorbtion and Spell reflect are properly applied before the script is called.

-dan

On question the first: excellent question, I do not know. Can check. I do know that the formula for Spell Effectiveness is known (it's in an OBSE thread somewhere, Ian posted it), and that NPCs are not affected by it (the function that uses Spell Effectiveness correctly calculates the NPC's effectiveness, and then throws out the number and just uses 100%). But I have no idea if it's automatically done for scripted spells.

On question the second: I don't know how to do it, if it is possible (I truly doubt it). At least, not without removing all of X effect and replacing it with an appropriately scripted SEFF - which you could easily do yourself in ObScript, A., and has all kinds of its own problems, B.

As for progress, well, all but seven functions work. Those seven cause mysterious CTDs when used. Investigating this currently.

A little confusing... I assume you mean finding every magic item which contains DSPL and replacing it with my own ARES-custom DSPX, which is plausible but very heavy-handed. The biggest concern I have with this is NPC behavior, actually. If there's enough control to tell them that DSPX is the proper counter to things, it's probably a viable solution...

This isn't the only effect I'm hoping to replace, BTW. It's just the most flagrant violator.

That's precisely what I'm saying you could do. You could do that without ARES (though the effect database may be easier to store the appropriate data), and I can't really help you with that. I don't know if it's possible to get NPCs to understand scripted effects (I know they generally don't), but yes, that's what I had in mind as the most notable problem.

But to actually change the functioning of DSPL effects, I neither know how nor expect that it is actually possible.

Okay, just to make absolutely sure that I understand what you've done and haven't blown it out of proportion in my head: the ARES interface lets me give my script effects the full range of individual flags and values posessed by a MGEF, and will pass magnitude and duration information to them so that they can be used like normal MGEFs and not be subject to the normal limitations of a SEFF, correct?

I've been running under the assumption that you've hacked directly into the MGEF list and are literally adding new ones, which I suppose is not strictly essential for the above to work. And I figured, if you're already in there, perhaps you can just intercept calls to the built-ins. But perhaps all of this is wrong.

Anyway, just the ability to pass magnitude is a bajillion times better than using a non-ARES SEFF for nearly anything.

No, I have not hacked into the EffectSetting list (EffectSetting is the internal C++ class for MGEF's); behippo has already looked into this, and my understanding is that there is nothing to be done with it, as too much is hard-coded to make it plausible to change.

I have instead created a list of effects, which is separate from the normal EffectSetting list, containing my own C++ classes, which I've labeled MGEF, AffixLine, and Affix, and which are not directly related to EffectSetting in any way (other than sharing similar members). I have populated that list with MGEF-class objects that mirror the EffectSetting objects, and to which additional effects can be added. Additional effects are MGEF-class objects, and no EffectSetting-class object is created for them (I briefly toyed with the idea of doing so, but the consensus was that Oblivion would likely freak out and die if new EffectSetting objects were constructed). Because MGEF contains many of the same members as EffectSetting, it's effectively my own copy that I can do with as I please, without Oblivion spazzing out.

MGEF does not perfectly match EffectSetting, because some of the options are useless. Namely, instead of the myriad visual options that EffectSetting has, MGEF simply has a VisualStyle field, which contains an EffectSetting code (which, by the way, are simply the 4-byte char arrays converted into 4-byte unsigned integers). This is because all I'm doing is creating an SEFF effect, which, as you know, can have a visual style specified, but not all of the various precise details. Same goes with sound, and there's no icon field, either. While you're free to specify any and all of the checkboxes (and several other boolean values that don't actually appear in the MGEF menu, besides), only some of them are actually going to do anything, based on the limits of what I have access and control to.

The database, really, doesn't let you do anything you can't do right now. It's merely organizational. It's primary purpose is inter-mod communication - share scripted effects in a standardized way so that a variety of mods can use them. You plug in the various settings for your effects and affixes, and it stores them. You can then ask it to churn out an effect for you, and it will do so - which will just be your standard SEFF that you could have constructed yourself with the EffectItem functions already in OBSE.

Okay, I think I get that. You've built a wrapper for SEFFs, but they're still SEFFs at execution time. So, two questions remain.

First, and most important as a guidepoint for what I should be planning to do with these: I'm clear that your MGEFs aren't identical to Oblivion's, but are they a fully compatible wrapper so far as their interfacing with effect items is concerned? Most importantly, can magnitudes be specified via the normal interface, allowing these effects to function as expected for spellmaking, player on-hit enchanting, and potion creation? I've been under the impression that this is the case, but you might have meant that the magnitudes were pre-defined as separate entries in the database.

Second, on the "getting NPCs to use SEFFs" front: AFAIK most of the NPC knowledge of how to use spells is wrapped up in the "counter effects" list, the specified actor value, and the Hostile checkbox. Will access to those be available?

First question: I'm not certain what you mean. The database does not keep magnitudes, it keeps base costs. Magnitudes are calculated from base costs when an EffectItem is requested from ARES - it gives you an EffectItem with an SEFF effect set with the appropriate script, school, and visual style, and sets its magnitude, duration, and area appropriately. You can get this magnitude with GetNthEffectItemMagnitude, which is how I expect the scripted effects to know their own magnitude. ARES itself doesn't actually do anything with the magnitude, that is up to the individual effect scripts. Those scripts should work with both spells and enchantments (provided the script author has done things correctly; in cases where it is not possible to make the effect work with spells or enchantments, they should register that through the "isSpell" and "isEnchantment" flags (which are distinct from the "forSpellmaking" and "forEnchantment" flags, as an effect may work just fine as a spell but for whatever reason the player is not allowed to make effects of that type at the spellmaking altar).

I do have... tentative plans to try to add these effects to the Spellmaking and Enchanting menus, but this would be something a la kyoma's X-Skills, not a native use. Since I know nothing about the XML files, I cannot say when that will actually be completed.

As for your second question: Access to the EffectSetting counter list is already available in OBSE. MGEF-class objects have the same list, which I added at your request, IIRC, but I don't do anything with it. Someone (again, I think it was you) mentioned a plan to allow NPCs to use SEFF effects by keeping a list of counters, which ARES could help for. So they have a counter array, but it's up to someone else to teach NPCs how to use that.

Further note: the functions I'm writing, when applied to MGEF's that also exist as EffectSettings, i.e. are default effects, will simply redirect your queries and commands to those EffectSettings. So if you call aresGetMagicEffectBaseCost on FIDG, the code looks up the FIDG EffectSetting, and returns its base cost. This is functionally identical to GetMagicEffectBaseCostC (with a little bit of added overhead, though not much). Same with the set versions. Under no circumstances should the two diverge. There are some EffectSetting values that cannot be gotten or set with my functions, for which you will have to use OBSE's functions, but those functions affect or return values that my MGEF-class objects do not have.

Right... good. This is what I'd thought, I just wanted to make sure.


I'm a little vague on it myself, but I've done some fiddling; I think I may be the first person to have individually changed the multipliers on the three spellmaking sliders, though that's probably because nobody else cared. Unless there are back-end reasons that the menu simply can't be forced to display, my scant understanding seems to suggest that you'll be able to do this reasonably well. Almost-natively.

Anyway: I think the utility in my head matches the one you're writing fairly closely now. Further details can wait until I've got my grubby little paws on it.

Which may be soon. The utility will be available (by e-mail to specific people) as soon as I get those kinks worked out. You guys can therefore start working on your effects (and give it some extra testing) while I write up the rest of ARES.

Oh and feel free to ask questions, they often help me realize how the utility will be used and what features it should have.

This sounds fantastic. I eagerly await!

*pops head out of the ground* :spotted owl:

sounds great, I really look forward to this, could be one of my must have mods.


now..........keep up the bad work.. *runs off before shade gets him*