I just remembered a bit of testing I did with shadeMe. We were looking at how the CS handles unknown GRUPs, records, subrecords, etc.

In specific, the subrecord testing was rather interesting; the vanilla CS will load and save an unknown subrecord without any fuss. TES4Edit will fuss about an unknown subrecord, but will still save it just fine.

So if you move your esp changes to an entirely new subrecord (perhaps with the OBME identifier), players will be able to still edit the plugin in the vanilla CS, TES4Edit, etc. Would be more work for you to move the data field around, but I think it'd be worth it for compatibility with TES4Edit.

Err... not quite. The game/CS will load known subrecords without a fuss - subrecords of a type they expect in the main record. For example, the loading routine for the EffectSetting record (MGEF) will load extra FULL or DATA subrecords without complaint, because it expects those subrecord types in an MGEF record. But if they find an unexpected subrecord type they simply move to the next record.
Edit: My mistake, the game/CS will indeed load any subrecord type without a fuss.

You still have a point though - it should be possible to add unexpected chunks to the end of the record, since at that point the game/CS loading routine would be jumping to the next record anyway. I wasn't aware that TES4Edit would actually load and save unknown chunks, but if so I'll definitely attempt this approach in the next version. Thanks very much to you Waruddar (and shadeMe) for the suggestion.

Gah! Can't believe I forgot what this plugin does :blush:

oo: oo: oo: oo: oo: oo: oo: oo: oo: oo:

Wow.

Woooow.

Uhm. Wow.

This... well, this saves me a lot of work on ARES.

Huh... does that return the magnitude as modified by resistance and effectiveness? I must admit I've never checked to be sure.

Regardless, the "magic variable" would make it a hundred times easier, especially if GetScriptAEIndex doesn't work with non-SEFF SEFF's (which is where this is most needed). I don't think there's a need for anything but magnitude; duration and area are handled by the engine. Make it a fake global and you shouldn't have to do anything to the compiler... hadn't thought about whether you'd be able to hook it at runtime without interfering with OBSE, though.

I'd offer to do the legwork coordinating that with the OBSE team, but at the moment I'm not qualified. It's becoming obvious that in the near future I'm going to have to roll up my sleeves and get my hands dirty with C++ so I can offer more than theoretical suggestions for all these amazing plugins.


I KNOW, RIGHT?


:woot:

OK, now that my shock is over...

Do you think there might be anyway to mass-import MGEF's without having to manually define them? Because I have... a lot of them.

Should be able to with CBash. Though JRoush said that he would look into changing the esp format again, so you may have to import them all over again with the next update.

What format are they being imported from? If it's a csv spreadsheet, it'll be trivial to adapt some code from Bash.

It's a CSV, or at least it can be pretty trivially.

Send me a copy of it via pm, and I'll take a look. Depending on what's there, I may have to get you to add some data to it...one thing that comes to mind is that every MGEF will need a unique 4 char identifier (though I can add that programatically if needed).

Heh, I may very well do that, but I'll need to take a look at the data; I haven't touched it in quite a while, so just tossing a file at you probably won't do either of us any good, as it is a massive Excel spreadsheet with a ton of data. You don't want to sift through it, trust me.

Bug report: The CS plugin prevents OBSE from dispatching the PostLoad message (the Dispatch call raises an exception apparently). This is probably why DW couldn't get NifSE to register with CSE. I'm yet to take a look at the code but it might have something to do with your temporary hook to the main window's wndproc.

I've been unable to reproduce this. I tested by installing the obse_example.dll plugin alongside OBME, and according to their logs both plugins received the PostLoad message during a session in the CS. I'm not familiar with how the OBSE message system works, but it sounds like you know what you're talking about shadeMe. Can you think of a reason you'd be having this problem but I wouldn't?

For that matter, is anyone else having this problem? You can check by opening Oblivion\OBME_CS.log after an editor session and looking for the line

OBME_CS MessageHandler: MsgType 00 from 'OBSE'

If it's there, OBME received the PostLoad message.

Not entirely sure. But I am using an updated version of OBSE (v19-ish, so to speak) that changes stuff a bit and adds a new interface to the PluginAPI. I'll try to reproduce the issue in v18.

Also, that's definitely not the cause of the issues I was having, because I hadn't installed OBME at the time.

It does return the actual magnitude as is active on the actor (exactly what is shown in the active effects page).

Out of curiosity, is there anything actually restricting the MGEF identifier to alphanumerics? Or would any 4 byte value be valid? The latter would obviously allow for far more unique identifiers (14,776,336 vs. 4,294,967,296). Admittedly, in practice, I doubt it'll make any difference.

Considering the possibility of modders having conflicting four-char IDs, might it not be a good idea to establish a listing of modders using a given prefix? Like, I could use DWxx for mine, and Warrudar could use WAxx or whatever. This would allow 675 modders to each create 675 effects...

Rather, it would allow 816 modders to each create 1156 effects -- numbers are valid for all but the initial character (see summons). Might be valid for initial too, though I doubt the script compiler would like that.

If we're going that route, dibs on the TJ prefix. However, I'm pretty sure I saw a comment about removing that four-character restriction somewhere down the line and allowing full-length EditorIDs?

At the moment, only alpha-numerics are acceptable because the mgefCode doubles as the editor name. This also means it's case insensitive.
I'll be separating the two in the next release, so that the editor name can be any valid string and the mgefCode can be (almost) any 32-bit number.


Centralized registration is probably a good idea. Any ideas on how or where to establish one?

Ahh, because mgefCodes are a shared resource even if we have unrestricted EditorIDs, check.

CS Wiki seems quite appropriate for the registry.

Thought that might be the case. Good to know that you're planning on separating them.

The wiki does sound like a good idea for the registry.

On a related note, rather than everyone having their own magic effects and end up duplicating some, it might be good to have a list of "common" new effects registered (poison, mark/recall, levitation, etc) so that people can override them if they want.

Also, I'm wondering if you've found out the reason why the lock and darkness mgef's are marked not to be used. Is it simply that those handlers don't do anything, or are they actually unsafe/partially implemented?

I believe Lock was removed because it screwed up the AI too badly, and Darkness was removed... well, I don't know why, but it doesn't really work. You'd expect it to be the opposite of Light, but instead it just causes whatever you cast it on to become black. It's kind of a neat effect, but doesn't do what you'd like it to.

Interesting idea, with obvious points in favor.

Playing devil's advocate: what if the user winds up installing two mods with different versions of an effect, without realizing it? I'm assuming Bash won't properly handle those records (yet?), nor will TES4Edit show the conflict; whereas if they're all unique, there might be duplicates but at least you know you've got the one you want. So what if they're getting unexpected behavior because of the other mod, but attributing it to mine? With no easy way to gather evidence to the contrary, I could wind up on a fruitless bug hunt. (This isn't far-fetched paranoia, I've had very similar things happen on multiple occasions!)

I've been experimenting with this, Its one of the most groundbreaking plugins I have ever seen. Its valuable enough in the fact that it lets you make custom summons that work properly. :clap:

The registry idea is good, but if this gets as popular as OBSE (considering the summon ability, it might), there might be real problems keeping everything organized.
The best solution would be to use the same load order technique that normal form IDs use, would that be a possibility down the road?

tejon, it'll need testing, but TES4Edit will probably show the conflicts just fine. I know that it does so for GMST records, and those are also identified by editorId. Unless ElminsterEU hardcoded the MGEFs...which is possible, but unlikely.

In the odd case that TES4Edit doesn't work, it'd be trivial for Bash to generate a report of conflicting MGEFs.

Also, if you don't want your mod to be overridden, simply choose a new MGEF and not one of the "common" ones. Though someone could still deliberately choose your MGEF to override...having "common" ones would discourage that by stating that they're fair game for overriding, and the rest should be completely hands off. :shrug:

SpeedyB, having the MGEF identifier be based on load order would complicate matters. Considering the amount of possible identifiers, and the relatively low likelyhood of randomly chosen identifiers conflicting across mods, I'm not sure it would be worth the effort. OTOH, JRoush actually knows the code, so he may think differently.