Yep, it will be.

And it won't be too much of a problem with older versions of Bash. They'll throw an error as soon as they come across an unknown subrecord (EDDX, etc), and the patch won't ever be completed. Hopefully that will prompt the user to update Bash, but at least he won't end up with a broken patch.

Now, there could be a problem with formIDs in actor value fields if the plugin is structured so that there happen to be no new subrecords. In that case, Bash wouldn't realize that there was anything odd, and would create a broken patch. As long as there is guaranteed to be at least one unknown subrecord in any OBME enabled record, this won't be an issue. This is most easily resolved by the proposed OBME marker subrecord.

In that case: JRoush, could you please add a OBME subrecord directly after the EDID one in all records that you save with a different format? (No need for the record header flag in that case). You could even make it an uint32 to contain a version number instead of just an empty marker. Every time you make a change to the format that you store a particular record in, just increment the version number you store in the OBME subrecord.

Not sure why I'm following this so closely as I don't understand a word of what you guys are talking about. But it's just awesome to see ElminsterEU around again I guess. Really looking forward to this.

As it happens, all records saved by obme do contain a 'DATX' chunk - that's what I use internally to determine whether or not the record is obme formatted.
I can move this chunk to immediately follow the EDID chunk. Let me confirm, though - this will make the use of a flag in the record header unnecessary?

It has been rather technical, lately. But it's good to hear feedback on the *ahem* finer points of my somewhat convoluted format scheme.

DATX would work fine for my purposes then.

It isn't strictly needed on my end, but I do like the idea of having a version number available since that would give you more freedom to change the record format. You would be less bound by the need for backwards compatibility; Bash and CBash would be able to have routines in place to auto-update older version formats to newer versions as needed.

Edit: Just to be clear, Bash and CBash don't care where the DATX appears. It can be left at the end of the record. As long as there's always an unknown subrecord somewhere within the OBME enabled record, older versions of Bash will error out properly. For that matter, Bash and CBash don't care if the "xxx is a form ID" flag appears before or after the variable field. Bash only expands the form IDs to their load order corrected values as needed, and CBash expands the form IDs immediately after the entire record has been read. It sounds like TES4Edit expands the form IDs immediately as they're read, thus the need to know if its a form ID beforehand.

That should work, yes. Just make sure that the contents of the DATX doesn't depend on any flags in a record which is then after it.

But having a OBME subrecord with just a version number at the beginning looks "cleaner" to me...

I agree. This is something I should have considered, and implemented, from the start.

No worries, took Beth long enough to realise the same thing.. one of the format changes between TES4 and FO3 was the introduction of a version field in the record header... (which is the reason why the record headers got 4byte larger between TES4 and FO3).

hi JRoush!

(at last i managed to start CS with obse...probably i missed something before i couldn't track back, so i re-installed everything and it works.)

let me say, this is a great tool! obme is exactly what i need for my mod and i think without it i wouldn't able to make it the way i want.

making the mod i realized a "problem": i want to remove the starting spells of the choosen schools AND give others. in vanilla CS spells has a flag "PC Start Spell". if i uncheck them (and you are in tutorial dungeon BEFORE creating class) these spells are removed. but if i check others as starting spells the PC won't get them at all. so "PC Starting Spell" flag only works one way, when i uncheck the already checked flags. is it possible to add a function to obme that "corrects" this "issue"?

i tried to find out what srcipt or other vanilla function gives the starting spells to PC when creating class. nothing i find so far and i couldn't find ANY mod that does it.

[otherwise when i edit (in CS in the spell list) the default "heal minor wounds" spell it's ok but when i try to edit the so called "default" "flare" spell nothing changes. so i think the PC gets ANother (a copy of the) "flare" spell identical but i'm not able to track how or where. but i know in OOO it works.]

It appears OBME breaks Invisibility and Chameleon. When I cast an Invisibility spell the shader doesn't play and actors can still detect me. The Chameleon shader does play but there is something wonky with the detection and one time it killed me when the Chameleon spell wore off. When I remove the three plugin DLLs everything works fine.

This is an issue with the unpatched beta3. Have you installed the latest hotfix? It was uploaded a few days ago.


I'm not entirely sure what the "PC Start Spell" flag does, but as you found it does not seem to give the player the spell. The best way to accomplish what you're trying to do is probably a script that monitors main quest progress or the pc's class to determine when a class has been chosen. You could also use a script with a "Menumode 1030" block, which will only run while the class selection menu is open.

The PC Start Spell flag does give the player that spell, if starting skill in the relevant school is >= iPCStartSpellSkillLevel (default 25).

Flare and Heal Minor Wounds are added in a different way: they're on the base spell list of the "Player" NPC record. Removing them directly has been reported to cause various bad things; better to just run a DoOnce quest script that removes them.

I've actually heard that removing Flare and Heal Minor Wounds from the Player even by script can do bad things...

I did not know that . Thanks.

Yes I did install the hotfix.

thx all the answers regarding PC Start Spell flag, all of them was useful.

Err ... could you double check? Not that I'm questioning your word, but the patch definitely fixed the problem in my own testing.

If it is indeed installed, would you mind sending me a copy of obme.log, and perhaps a copy of your savegame?

Yeah I double checked and even redownloaded the hotfix, no dice. I have a savegame and obme.log, just tell me where to send it.

jroush.tesmods@gmail.com

Feature request: modified Detect Life handler which can discriminate by creature type (Creature, Daedra, Horse, NPC, Undead), and which allows you to specify the shader rather than being hardwired to LifeDetected.

Huh, I wonder if Night Eye could be jiggered into a poor man's OBGE for full arbitrary screen shader effects...


I've heard this too, which is funny, because AFAIK I've done more extensive testing on it than anyone, both privately and long-ago-released. I'm not even convinced that there's an issue with removing them from Player in the CS, except for the specter of incompatibility looming over any Player edit. Of course, I haven't tried that because when I did all this testing I didn't realize I could find Player in the CS, and since what I have works, I've been too lazy to go back and check. :rolleyes: Anyway, script-removing it is absolutely safe.

The thing that is not safe is marking DefaultPlayerSpell (Heal Minor) as deleted. Even if it's not on the player, it's used as the fall-back spell when e.g. you use a scroll; there's no such thing as "no active spell," so when the scroll is consumed your active spell becomes DefaultPlayerSpell even though it's not on your list. You can safely edit it, though, e.g. to an empty script effect which costs 99999 Magicka and is called "No Spell Selected" -- which is what the old nGCD Character Generation did, and what Ars Gratia Artaeum will do.

Flare is a plain old everyday spell. Nothing special at all about it, other than being on the base Player form.

Email sent.



There is a Night Eye shader replacer OBSE plugin already, so that's definitely possible.

After a look at the offending plugin, the problem was indeed what was addressed by the hotfix. However:
Since the invisibility spells were created with the unpatched v1.beta3, they remained broken, even after the hotfix was installed
I hadn't considered that, but I'm afraid anyone who worked with ModifyActorValue effect items using v1.beta3 will have to delete & recreate those effect items after installing the hotfix. My apologies to all for the inconvenience, and my thanks to Kamikaze for bringing it up.


Both handlers are on the short list for expansion. Hopefully the real OBGE will prove a good resource for hacking the shader system.

I'm glad you found the problem, but something doesn't make sense to me.

I made two plugins with invisibility spells, the first one without using OBSE/OBME. The spells didn't work even though they are saved in the original format in the .esp.

I created a second plugin by copying the first and saving it with OBSE/OBME enabled, but I didn't delete the spell effects as you've now discovered we should. I assumed saving the plugin would save the spells in the OBME format. I definitely had the hotfix installed the whole time.

I tried it again by deleting and recreating the spell effects and now it does work correctly.

What I think happens is that something goes wrong when loading spells saved in the original format. When I saved the second plugin I didn't modify the spells and so OBME must not have saved it in the new format, so they were again loaded wrong.

Edit: Oh I just saw the email reply you sent me.

:facepalm:
You're right about this as well. Due to an unrelated, but similar problem with the vanilla initialization code.

I think I need to re-examine the ModifyActorValue handler, as well as the file formats and OBME's internal version control.

If anything, I suppose this proves the importance of beta testing ...

Ok, http://www.gamesas.com/index.php?/topic/1110827-relz-oblivion-magic-extender-v1beta4/ with some bug fixes.