[RELz] Oblivion Script Extender (OBSE) 0020 : IV - Oblivion

» Wed Mar 30, 2011 3:56 am

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

Yeah, but to answer my question, I tested it, and no, if you specify 1 as the damage parameter, it will not trigger the script if you take more than 1 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.

Okay. Thanks.

» Wed Mar 30, 2011 9:02 am

What's wrong with my script? It isn't working (unless "PrintC" doesn't work from within the script.)

Quest script excerpt:

If Player.GetBaseAV2 Blade >= 150		If rShield == 1			Return		ElseIf sWeaponType == 0 || sWeaponType == 1			If Player.IsBlocking == 1					SetEventHandler "OnHealthDamage" FnOnDamageTaken 			EndIf		EndIf	EndIf

Function script:

ScriptName FnOnDamageTakenfloat vMaxHealthfloat vCurrentHealthfloat vDamageTakenfloat vDamagePercentfloat vDamageref vPlayerref vConfirmedBegin Function {vDamage, vConfirmed}		Set vPlayer to Player.GetSelf	Set vMaxHealth to Player.GetBaseAV2 Health	Set vCurrentHealth to Player.GetActorValue Health		If vPlayer.GetIsReference Player == 1		Set vConfirmed to vPlayer	EndIf		If vDamage >= 1		If vCurrentHealth < vMaxHealth			Set vDamageTaken to (vMaxHealth - vCurrentHealth)			Set vDamagePercent to vDamageTaken * 0.40			Player.ModActorValue Health vDamagePercent			PrintC "Damage %.2f Health return %.2f", vDamageTaken vCurrentHealth				EndIf	EndIfEnd

» Wed Mar 30, 2011 6:40 am

Another thing the OBSE devs should know:

ModActorValue2 does NOT work for Fatigue.

» Wed Mar 30, 2011 2:36 am

What's wrong with my script? It isn't working (unless "PrintC" doesn't work from within the script.)
...snip...

Try placing a PrintC just before calling SetEventHandler to make sure it is executed. On another note, what type of variable is rShield, if it is a ref variable you cannot use "if rRef == 1". Also try placing some PrintC lines inside the function script to see which parts are executed and which parts aren't.

P.S. If you are only interested in when the player takes damage you can use this to filter out any other actor's damage

SetEventHandler "OnHealthDamage" FnOnDamageTaken object::playerRef

» Wed Mar 30, 2011 10:51 am

For example, Oscuro's Oblivion Overhaul.esp will be deactivated and all of its contents will be merged into the bashed patch.

In this particular case at least, OOO should get tagged as nomerge via BOSS so this won't happen. There are far too many patch files that depend on the OOO.esp file being loaded to allow it to drop out of sight this way.

» Wed Mar 30, 2011 3:51 am

In this particular case at least, OOO should get tagged as nomerge via BOSS so this won't happen. There are far too many patch files that depend on the OOO.esp file being loaded to allow it to drop out of sight this way.

But the original question is still important. Many of my mods rely heavily on IsModLoaded and GetFormFromMod - Map Marker Overhaul in order to replace generic icons from other mods with the new ones, Dynamic Map to decide which map components to display, Enhanced Economy for lots of things, etc. If those mods start disappearing into the Bashed Patch, there will loss of functionality at best, and severe incompatibilites at worst.

To fix this, I guess the Bashed Patch would need to somehow include a list of all the mods that are merged into it, either inside the Bashed Patch itself or as a separate file. Then OBSE would read this list (if there is a Bashed Patch) and use the list for IsModLoaded and GetFormFromMod. So a call to GetFormFromMod would then:
1. See if the mod is really loaded, and if so use that directly
2. If not, see if the mod is in the merge list. If it is, look up the formId in the Bashed Patch.esp

Sounds simple, but it's of course not that easy to make.

Btw, I think it is important that this gets into OBSE proper and not just an OBSE plugin, since lot of people would need it without knowing.

» Wed Mar 30, 2011 12:18 pm

Try placing a PrintC just before calling SetEventHandler to make sure it is executed. On another note, what type of variable is rShield, if it is a ref variable you cannot use "if rRef == 1". Also try placing some PrintC lines inside the function script to see which parts are executed and which parts aren't.

P.S. If you are only interested in when the player takes damage you can use this to filter out any other actor's damage

SetEventHandler "OnHealthDamage" FnOnDamageTaken object::playerRef

rShield is a numeric variable (at least I think it is...). I set the variable using IsShieldOut.

Okay, I'll add the PrintToConsole functions in more places. One question about the EventHandler suggestion: is the format exactly as you specified? Do I set "object::playerRef", or do I set "object::"?

Sorry, I'm still very much a noob scripter.

Thanks kyoma.

EDIT:

Okay. I figured out the filter through trial. It is formatted exactly as you specified.

» Wed Mar 30, 2011 8:37 am

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.

In this particular case at least, OOO should get tagged as nomerge via BOSS so this won't happen. There are far too many patch files that depend on the OOO.esp file being loaded to allow it to drop out of sight this way.

Jut to clear up this one case - OOO.esp will never become mergeable. For the simple reason that the next version of OOO will include all the resources in a bsa, and OOO.esp will therefore need to be active to load the bsa. Bash will recognise this, and will not mark OOO.esp as mergeable.

To fix this, I guess the Bashed Patch would need to somehow include a list of all the mods that are merged into it, either inside the Bashed Patch itself or as a separate file. Then OBSE would read this list (if there is a Bashed Patch) and use the list for IsModLoaded and GetFormFromMod. So a call to GetFormFromMod would then:
1. See if the mod is really loaded, and if so use that directly
2. If not, see if the mod is in the merge list. If it is, look up the formId in the Bashed Patch.esp

Could this not be done by reading the list of the BP's masters? You could have a 'IsModMaster childMod parentMod' type of command, which returns true if parentMod is a master of childMod.

But won't all mods that define new objects remain non-mergeable anyway?

Eloise

» Wed Mar 30, 2011 6:50 am

Just a a note to the devs:

It seems that using ModActorValue2, when formatted exactly like that, doesn't work on fatigue.

If you format it like ModAV2, it does work.

» Wed Mar 30, 2011 12:43 pm

Alright, kyoma. It works. The only thing I had to do was remove the ">=" condition on my damage variable.

Thanks again for your help.

» Wed Mar 30, 2011 6:59 am

Just a a note to the devs:

It seems that using ModActorValue2, when formatted exactly like that, doesn't work on fatigue.

If you format it like ModAV2, it does work.

ModActorValue2 and ModAV2 are two different names for the exact same command - if one works, they both do; if one has a problem, the other has the same problem.
If you continue to find it behaving unexpectedly with fatigue please post details.

» Wed Mar 30, 2011 12:01 pm

Ok. I also noticed that ModAV2 was finicky with speed.

I'll test some and post back the results.

» Wed Mar 30, 2011 8:33 am

Greetings.

I experienced an Oblivion issue last night that repeated itself this morning. I initially wrote about it on a long-neglected weOCPS thread, since the issue triggers an weOCPS bell ding. Due to resent input I have decided to quote myself here, in hopes some OBSE guru can offer insights.

Here be my original post:

I still run weOCPS, not necessarily to play through what would otherwise have been game-ending crashes, but because when the weOCPS bell dings, it indicates that my prevented crash was/is caused by a know issue, and has been documented in the program's log. Not that this info normally helps me much, being a near-total ignoramus when it comes to the inner workings of mods.

My Oblivion install is reasonably stable. weOCPS rarely kicks in. Once every few months seems about average. However, it kicked in last night and again this morning at the same point. Here be details:

We (Vilja and my decrepit avatar) had collected taxes-due from the Roxey Inn and were traveling on foot (a rarity for us) from there to Cheydinhal on a Merchant Guild package delivery assignment. We followed Red Ring Road until it intersected the Blue, which we took and began the trek east toward our destination. We had fought a number of minor encounters while on the Red, and passed several NPCs. Almost immediately after joining the Red we passed a merchant and his guard from PTRoamingNPCs heading west. So far so good. Then, about a minute later, we chanced upon a roaming Argonian Battlemage from the same mod. As we neared him weOCPS dinged.

It happened first last night (real-life time). I decided to exit the game, delete my last several saves, and call it a day. This morning we repeated our steps, ran into the same Argonian (at a slightly different spot in the road due to minor variance between sessions), and again experienced a weOCPS ding.

Here is an excerpt from my weOCPS log, showing both Argonian Battlemage dings:

Thu Apr 28 19:13:02 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d00)!
eax=00000000 ebx=206c4d00 ecx=21fa1370 edx=0064b040 esi=22759500 edi=21fa1370 esp=0018f4a0 ebp=206c4d00

Fri Apr 29 06:35:29 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c5480)!
eax=00000000 ebx=206c5480 ecx=21f884a0 edx=0064b040 esi=227a6c00 edi=21f884a0 esp=0018f4a0 ebp=206c5480

Notice that they are quite similar, as is proper. I loaded the mod's esp in TES4edit both singly as well as with my entire load-order. Nothing obvious jumps out. With the entire load-order in place, there are a grand total of two Roaming NPC entries with red backgrounds. In both cases the actual mods with red text are not Roaming NPC but either Elsweyr-Anequina (water height variance) or Kvatch Watch Towers (greeting variance). In both cases those variances are overwritten by later loading mods that restore them to "normal".

Admittedly, I've no idea how to look up the two NULL-pointer reference packages seen in the log, or how "MiddleHighProcess::Unk_156" fits in the mix. But this seems like something our more knowledgeable gurus might understand. If so, please chime in with info on how to fix this (via TES4edit if possible since I don't have CS installed).

Speaking of TES4edit, I should point out that applying its two auto-cleaning procedures to PTRoamingNPCs found nothing amiss.

I suppose I should also mention that PTRoamingNPCs is one of my most recent installs. That said, I encounter Roaming NPCs quite often. None has ever before triggered a ewOCPS ding. (Or if so, it was covered by louder environmental sounds.) Can't recall if I have chanced upon that particular Battlemage before. I know I've met at least one of 'em, but not necessarily all.

Here's an excerpt from my second post providing a tad more info:

I did more digging in TES4edit but found nothing obvious. But as stated I'm not even should what I'm look for.

There's a Bashed Patch "Import Names" settings for the mod. It is selected. I thought about rebuilding the Patch without it. But I've used that setting from day-one without issue. Seems odd that after several weeks of reliable service it would act up. Then again, PTRoamingNPCs might be an innocent victim in all this.

And lastly here's the input that led me to repost here:

It's got something to do with an AI pack is about the best I can tell from the output. Did a Google hunt for MiddleHighProcess::Unk_156 and landed on a page with http://www.qwerty-games.com/viewvc/OblivionReborn/obse/obse/GameProcess.h?annotate=1 on it. You may have some luck asking the OBSE gurus if they can help with the bug report you have.

There you have it. These mysterious weOCPS bell dings might in some manner be OBSE related. It's all beyond me, that's for sure.

Thanks in advance!
-Decrepit-

» Wed Mar 30, 2011 2:20 am

@TheNiceOne: I wasn't meaning to dismiss the issue, I am aware it will need to be addressed at some point. I have mods of my own now that rely on IsModLoaded to make things work.

The only reason OOO is even an issue is because every last record in the ESP is injected into its master. That means CBash by default with the current version of OOO wants to merge it. Tagging it in BOSS is a workaround, but it would work, and then CBash would not be inclined to merge it. A more permanent fix would be to clear up a single injected record. Some rock or something unimportant that won't matter if the formID is changed. Then CBash won't want to merge it at all.

@Shadowborn: The BSA would resolve issues for the next version, yes, but there will still be a lot of people who don't upgrade or don't know they need to upgrade, and they'll hit this issue regardless.

@Decrepit: Clarification - I wasn't pointing to this being an OBSE issue. Merely that since OBSE source code covers the function that they may know enough to help track down a cause.

» Wed Mar 30, 2011 7:24 am

There you have it. These mysterious weOCPS bell dings might in some manner be OBSE related. It's all beyond me, that's for sure.

The MiddleHighProcess stuff belongs to the game, OBSE just documents it - presumably that's where weOCPS got its information in the first place.
If you can provide me with a simple way to reproduce it, I can look into the cause, but it's 99% likely to be a vanilla bug.

» Wed Mar 30, 2011 12:49 pm

@Decrepit: Clarification - I wasn't pointing to this being an OBSE issue. Merely that since OBSE source code covers the function that they may know enough to help track down a cause.

Aye, I knew that. My entry was typed in haste. Soon after leaving the house on an errand run it came to me that that statement was poorly worded.

The MiddleHighProcess stuff belongs to the game, OBSE just documents it - presumably that's where weOCPS got its information in the first place.
If you can provide me with a simple way to reproduce it, I can look into the cause, but it's 99% likely to be a vanilla bug.

I'll think on it, but this one might be impossible to replicate on another computer, depending as it does on a roaming NPC being at a certain spot at a certain time, and your avatar being there at the same time. Then too the roaming NPC might be incidental, though that seems unlikely. About all I can say at the moment is the mod in question is http://www.tesnexus.com/downloads/file.php?id=32747. I think (but do not know for sure) the NPC is PTrider03: Battlemage "Wih-Ju", to use his Bashed-Patch given name.

I wonder if the NPC might simply have spawned corrupt?

I think I'm gonna try removing that Bashed-Patch naming feature and rebuild my patch. I doubt it'll do any good since no other PT Roaming NPC is afflicted and they all have names. But I've nothing to lose except a bit of time.

» Tue Mar 29, 2011 11:20 pm

All bets are off. I seem to be having some sudden serious issue with my installation (or last few saves) that those weOCPS dings are only part of. For what it's worth, here are two more of 'em. Only, this time it was not the Roaming Battlemage who triggered 'em (if he did) but rather the merchant with bodyguard I encountered on the Blue Road slightly earlier. (We're talking maybe a minute difference.)

Fri Apr 29 17:54:24 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d00)!
eax=00000000 ebx=206c4d00 ecx=21fa2b60 edx=0064b040 esi=2271d7c0 edi=21fa2b60 esp=0018f4a0 ebp=206c4d00

Fri Apr 29 18:02:38 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d00)!
eax=00000000 ebx=206c4d00 ecx=21fa1880 edx=0064b040 esi=2271c100 edi=21fa1880 esp=0018f4a0 ebp=206c4d00

The first of these occurred after I removed the Bashed Patch naming import. The second occurred with it restored.

Oddly (or not), once that initial DING sounded I was able to approach the Battlemage without further issue.

I decided to load that save again, only this time walk AWAY from the NPCs so as to not encounter them. We headed west toward the Imperial City on the NR+B road. We hadn't gotten very far with the (and encountered no visible NPCs) when the game black-screened. I reloaded and tried the same maneuver again. Black-screen. Something odds is going on, that's for sure. I'm gonna delete my most recent three saves. Load the save made in Weye Manor (AFK_Weye) when all still seemed well, go to the uppermost floor private bedroom, and rest four game-days. After that we shall see.

» Wed Mar 30, 2011 6:00 am

snip

I had a look at the relevant game code. It appears that one or more NPCs in your mod have an AI package with an invalid reference as the target. The game looks at the target type for the package, sees it's supposed to target a reference, and tries to use the reference, which is fine unless the reference happens to be null (it doesn't check). If it is null, the game promptly crashes.
Why the reference should be null, I can't really say. The game generates dynamic packages for things like combat and dialog, so it's possible it did so for one of your actors and the mod containing the package target was removed from your load order. That's one possibility, anyway.
If problems persist I wouldn't mind taking a look at a savegame exhibiting the problem, if it's not dependent on a bunch of mods.
Alternatively if you can get the formID of the NPC(s) you suspect, use the console to get info on what packages/procedures they're running.

» Wed Mar 30, 2011 1:33 pm

I am setting an onhit event handler from a token script for every actor in the game.
So far it works fine. But reading this made me wonder if I can do the same thing by only setting ONE in a quest script and NOT using any filters?

like so:

SetEventHandler "OnHit" aadpOnHitTrigger

Or am I already doing it the right way with a token script:

SetEventHandler "OnHit" aadpOnHitTrigger ref::ME

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

» Wed Mar 30, 2011 11:02 am

I am setting an onhit event handler from a token script for every actor in the game.
So far it works fine. But reading this made me wonder if I can do the same thing by only setting ONE in a quest script and NOT using any filters?

like so:

SetEventHandler "OnHit" aadpOnHit

Yes, if you want the handler invoked for a large number of actors that's the way to go.
If you don't want to do stuff for *every* actor, you can register a global handler and do something like:

scn FnOnHitbegin function {target, attacker}  if target.getItemCount yourToken ; or whatever condition    ; do stuff  endifend

The filters are useful if you've got one or a small handful of targets you're interested in; otherwise a single catch-all handler is preferable.

» Wed Mar 30, 2011 12:31 pm

Well I had in mind to detect it during the attack, the other way sounds more versatile, but also way more "heavy" as I would need to detect all the attacks somehow and then get the name/path of the animation file. Then store that data for use later.

So yes, best would be the first way where you detected the duration and other data at the time it is about to play or as it is playing.

scruggsywuggsy the ferret:

I guess a better question would have been: do you expect your scripts to be asking for information about an animation only when an actor is playing (or is about to play) that animation? For example, your script detects the player is performing an attack animation, and at that point you want to know the duration of the attack anim.
Or, do you want to be able to ask "what's the duration of attack_onehand.kf" whenever you want, regardless of whether or not it's currently in use by an actor?

» Wed Mar 30, 2011 7:04 am

sorry I for got to ask, do you think there is data in the animation file that would tell the script that it was a thrust or not? Like the way the bones are set or the sound used or the range it reaches?

WOW if there was I could then do Damage type verse Armor type scripts. I am already doing that now in my WIP mod but only with blunt and blade categories. If I could detect thrust somehow, then I could include piercing category for arrows and thrusts. Then go one to fire and cold damage and so on!

» Wed Mar 30, 2011 8:45 am

I had a look at the relevant game code. It appears that one or more NPCs in your mod have an AI package with an invalid reference as the target. The game looks at the target type for the package, sees it's supposed to target a reference, and tries to use the reference, which is fine unless the reference happens to be null (it doesn't check). If it is null, the game promptly crashes.
Why the reference should be null, I can't really say. The game generates dynamic packages for things like combat and dialog, so it's possible it did so for one of your actors and the mod containing the package target was removed from your load order. That's one possibility, anyway.
If problems persist I wouldn't mind taking a look at a savegame exhibiting the problem, if it's not dependent on a bunch of mods.
Alternatively if you can get the formID of the NPC(s) you suspect, use the console to get info on what packages/procedures they're running.

Whoa! Thanks for your work on this!

I just had it happen again, after deleting and number of saves and resting four game-days. Went through basically the same steps I had before, and DINGED at almost the same spot when encountering a Roaming NPC merchant. You can get more details, including my latest ewOCPS log excerpts, from the recent weOCPS thread.

I can most definitely send you a save. I can send either a save made just before the DING occurs or load the game and make a save right after it DINGs. (A disadvantage of the latter is that it seems to only DING once so might not happen again.) Or I could send both. Warning...me saves are getting fairly big... nearly 11mb each. I do have a fairly decent number of mods installed. Not in the hundreds as some here run. My Bashed Patch is 5D. Nor do I run any of the big overhauls. I do run some fairly hefty stuff though, mods that require COBL, Tamriel Resource Pack, or DCRP/CURP. And of course Elsweyr-Anequina.

Let me know here how to send either or both saves to ya, or PM me with the info.

-Decrepit-

» Wed Mar 30, 2011 6:37 am

Well, this is interesting... I started playing earlier with TQP 3.2 active (still OBSE 19). Played for about a half-hour, game crashed (not exactly sure of the cause). Started up again, crashed about a half hour later (probably too many processes - I was near the IC, and it tends to do that). Third time around, I got about 20 minutes in, and I found a dead guard on the road. I open up his inventory, hit Shift to pick up his 2 platinum coins... and I get a prompt. WTF? I tried again - same thing. I tried Control to take one coin - prompt. Totally puzzled now, I saved, quit, checked that TQP was still active - yup. Went back and tried again. When that didn't work, I clean saved and tried a third time, but it's apparent that TQP has stopped working entirely and I have no idea why.

The OBSE log has no errors in it; the only thing I could find that looks even vaguely suspicious is the bolded line:

Reading mod list from co-save
Loading strings
Loading array variables
plugin has data in save file but no handler
DoLoadGameHook: C:\Documents and Settings\Owner\My Documents\My Games\Oblivion\Saves\SavedBeforeWaiting.ess

Which is there every time I check the log. Likewise, the console has nothing.

» Tue Mar 29, 2011 10:05 pm

I started getting short freeze ups (studders) just all of the sudden in the middle of working on my Combat Magic mod back with with OBSE 19. At first I thought I was overloading the game with too many script loops in my CM mod. But I could never find what was causing it in that mod and no other players reported such "studders" so I decide it was not the Combat Magic mod. I also had tried OBSE beta 20 at about the same time, but that was one night only and then switched back to 19.

I still get them, I have striped my load order down to almost nothing (took out the CM mod as well) and still get them. Once I am done on my current project I will be looking more deeply into this. Please let me know if you find out anything about your issue ok?

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)