Hi guys, I'm popping in from the Wrye Bash forum because I had a thought while testing an experimental version of Wrye Bash. In the future, more mods will become mergeable -- that is, their .esp plugin contents will be combined and copied into a single Bashed Patch plugin mod and the original mod will be deactivated. For example, Oscuro's Oblivion Overhaul.esp will be deactivated and all of its contents will be merged into the bashed patch. This will make the IsModLoaded command much less effective. Is there a way we can work together to provide OBSE with the list of mods that have been merged? Is there interest from the mod community in knowing which mods are merged into the bashed patch?

Some initial thoughts:
We could write a list into a text file
We could write the data into a record in the bashed patch

Yeah, it is pretty hefty. I plan on shaving some corners and lessening it, but yes, in the end it will be a behemoth three-tiered array

Main array:
Array of array references, representing every unique Leveled List the user has.
|
Sub arrays, each representing a Leveled List:
contain a ref,
some ints,
and then more array references, each representing an entry
|
Sub-sub arrays, each representing a Leveled List entry:
contain a reference to the creature and a few ints

Link is in my signature, the latest version 2.03

I've had the debate with myself and others a few times, and yes.. DLL does need some sort of backup array to work as intended. If people have lots of LLists, it grows to be large.

Thanks! 8)

Sorry, that was kind of a vague post. I've found three mods that are displaying problems: TQP, Keychain, and Ren Creature Mod. With the keychain mod, it keeps unhooking the keys when I close my inventory. Several people have posted complaints about it not working properly on the Nexus, so it makes me wonder. With Ren's, it's just creatures sometimes attacking when they shouldn't (the mod makes normal animals like wolves, rats, and lions non-aggressive). TQP... this one I found only after some testing. I'm experiencing the same problems I had back with OBSE 19 (or was it 18?) and SR Super Hotkeys - the game will randomly crash on transitions or when I open a container. Downgrading from TQP 3.2 to TQP 3.1.1 fixed the problem, but since the other two were still giving me problems, I downgraded to OBSE 19. Keychain still isn't working right, but I'm not sure if this is because it's broken with 19 (it worked before, so not likely) or because I was using 20 and went back to 19. I've never downgraded OBSE in the middle of a game before, so I don't know what effect it could have.

I would be ever-so-grateful if you decided to add them for 0021.


That would also be awesome, but my drinkable poison approach has the added bonus of being somewhat funny, so I have no qualms about using it.

Thank you very much for your time.

Thanks for V20, been a V19 user for a long time! :thumbsup:

Hi OBSE team

I am very interesting from your OBSE work.

I would like to understand how you creat this plugging for Oblivion, i am interresting to learn to creat my own plugging for script extention or adding fonction to OBSE (but i saw to much C file i don't know how all work and what file modify)

I already know programming in C and C++

Take a look at PluginAPI.h and the example plugin project, they are heavily commented with examples to get you started.
As far as the API goes it depends on what you're trying to do with your plugin. If you need to interface with game objects take a look at GameObjects.h and GameForms.h for class layouts.

Hmm. You didn't have to downgrade to a previous version of any of those mods in order to revert to 0019, did you?

Thanks, I'll take a look.
I've been meaning to replace the data structure we use to store string/array variables for 0021 to make lookup faster (constant time vs. logarithmic). If you've got a huge number of arrays then that could be a factor - I'll have a better idea after I've looked at your scripts.

I had brief PM discussion about this with somebody a while ago. It'd be useful, I think, but it'd probably need to be made to also work with things like GetFormFromMod, GetModIndex, etc. I'll have to think about options for addressing it.

Any chance for a GetHitLocation? Oblivion evidently knows which part gets hit, as it applies health damage to the armor piece there..... (I think?) Or is that just applied randomly?

As far as I know, the game uses the http://cs.elderscrolls.com/constwiki/index.php/IArmorDamageXXChance-Gamesettings to determine which armor piece will be damaged.
You could try http://www.tesnexus.com/downloads/file.php?id=11732; not sure how this works, but it sounds like the thing you are looking for.

Edit:
Or rather http://www.tesnexus.com/downloads/file.php?id=20163, since TheTalkieToaster deprecated Locational Damage.

Yeah, it might be beneficial for OBSE to deal with the "virtual" load order, especially since one of the stated uses of the mod functions is to verify load order at runtime. This would let OBSE present the merged mods in their effective places in the load order. However, this would also cause the "index" not to line up with the first two digits of the formids. There is also the somewhat tricky question of how to treat mods that have particular elements imported, but are not merged...

Nope. They're all OBSE 17. Now that I think on it, I believe that one of them (possibly TQP) was acting up with OBSE 19 as well - I started a new game, and it was crashing every 20-30 minutes - I'd hoped that going to 20 would fix it. I'm going to test with TQP 3.1.1 and OBSE 19 to see how it works.

Ok, thanks - let me know what happens with that.
Any errors popping up in the console or obse.log in conjunction with these issues?

Has any thought been put into providing an obse plugin (.dll) for use with Wrye Bash to try and address this?

Not to my knowledge. Perhaps we could start with a poll: to the modders here: what kind of information about the bashed patch would be useful at runtime? Is there anything in the past that you've needed to know about it but haven't been able to find out? How useful is it anyway to know which mods are merged? They don't add new formids; they just modify the records of their masters. Do you care about mods that don't add new formids?

Just want to say that I've had no such issues (including the ones you mentioned in the previous post) with TQP and any version of OBSE. Using TQP 3.2.

I played for an hour and a half straight last night with no problems. Even then I quit because I was too tired to concentrate any longer. I was running around the IC doing a couple quests, as well as delving into Fatback Cave - sort of a stress test, with opening lots of containers and going through a few dozen transitions.


I never thought to look. Next time it crashes, I'll check.


Hmm. I also disabled the Keychain mod before playing last night; I'll try it tonight with TQP 3.2 and see what happens - maybe I misidentified the problem.

I am confused about the Event Handlers stuff. Specifically how to format the script the event calls.

I'm going to use the "OnHealthDamage" event. But I don't quite get the script format. Is this right?:

Begin Function {1 GetSelf}      Do stuffEnd

Is that correct? Using "Begin Function", the brackets, 1 for damage taken (I actually want it to be 1 or more damage taken triggers the script), and "GetSelf" for the reference?

Alrighty. 8) I tried to write somewhat legible code on the go, but it's on my list of things to do the clean it up for other people.

And, just FYI, I've decided to migrate to storing my backup data in a pluggy file. Just do some I/O instead of looking to the in-game OBSE array.
It may be slower, but it provides infinite scalability without the issues of a 10MB OBSE array. Even if the freezing issues were fixed, the save/load time was getting ridiculous.

Nonetheless, I'd still be interested in finding out what was causing those freezeups. 8)

BTW, I would love to have some sort of file system like Pluggys in OBSE. Just drop the pluggy requirement altogether, since that's all I use it for.

The things between the brackets should be variables, they will hold any info for the event (when it is called). In itself a function script does absolutely nothing, if you wish to use it for an event you need to register it with SetEventHandler. For example, a function script like this:

scn FuncOnHealthDamageref rAttackerfloat fDmgBegin Function {fDmg, rAttacker}      if (fDmg >= 1)            ;do stuff, rAttacker is      endifEnd

And registering it with this

SetEventHandler "OnHealthDamage", FuncOnHealthDamage

Thanks. Can I access variables within the function script from other scripts like quest scripts can?

hi, I have a question about event handlers. I used in a script the example code I found on the obse site

SetEventHandler "OnHit" FnOnHitByPlayer object::PlayerRef

but when I save the script I get the message "unquoted argument 'object' will be treated as a string by default...". Is that normal? Because apart from that message all works fine ingame. Thanx

It's just a warning. Some people find it convenient to omit quotation marks when typing strings, e.g. myArray[someString] is easier to type/read than myArray["someString"]. But typos can lead to OBSE interpreting an unquoted argument as a string when you really meant to type a variable name, objectID, etc.
If you click "Cancel" in the warning dialog you won't see it again for that session.

No. The variables only exist while the function script is executing. The next time the function script is executed they will have been reset to zero, except for the variables in the argument list, which get initialized to whatever values were passed to the function.

Thanx for quick answer. And thanx for version 0020.

If I set the damage variable in an OnDamageTaken event to 1, will the event still process if it is greater than 1? Or do I have to specify >??

Dumb question, maybe, but I want to be sure.


EDIT:

I could just test it, I suppose.

Another event handler question:

Will the OnHit event register if an actor collides with another actor?

The example script kyoma posted will allow you to execute code whenever an actor takes 1 or more in damage.

No. The event types corresponding to vanilla script block types (OnHit, OnDeath, etc) are triggered by the same things that trigger the script blocks - in this case, by the actor getting hit with a weapon.