[BETA] Oblivion Script Extender (OBSE) v0020 : IV

» Fri Sep 03, 2010 11:04 am

Continuing from the http://www.gamesas.com/index.php?/topic/1142593-relz-oblivion-script-extender-obse-0019b/.

The Oblivion Script Extender, or OBSE for short, is a modder's resource that expands the scripting capabilities of Oblivion. It doesn't make any modifications to oblivion.exe, TESConstructionSet.exe, or any other files in your oblivion install, so don't worry about permanent side effects. As of v0017, OBSE requires the 1.2.0.416 version of Oblivion.

http://obse.silverlock.org/download/obse_0019b.zip - current stable version, recommended for general use
http://obse.silverlock.org/beta/obse_0020_beta.zip - beta version, recommended for testers and mod developers only
http://obse.silverlock.org/
http://obse.silverlock.org/obse_command_doc.html - newly reformatted documentation

0020 is now available for beta testing.

What's new:

Spoiler

0020 beta:
-Compiler override for passing OBSE expressions and data types as arguments to any command
-Get/SetCellLighting
-IsNthActiveEffectApplied, GetNthEffectItem
-GetMapMarkers
-PlayIdle
-ar_CustomSort
-GetPathNodesInRadius/Rect
-Is/SetPathNodeDisabled
-GetPathNodePos
-PathEdgeExists
-GetPathNodeLinkedRef
-Get/SetCellClimate
-SetCellBehavesAsixterior, SetCellHasWater
-IsCellPublic, SetCellIsPublic
-IsOblivionInterior/World, IsInOblivion
-(Set)CanFastTravelFromWorld
-GetBoundingRadius, GetEditorSize
-GetTerrainHeight
-ResolveModIndex
-SetPos_T, SetOwnership_T, ClearOwnership_T
-GetRequiredSkillExp
-HasEffectShader
-Get/SetLightDuration, Get/SetTimeLeft
-SetCreatureSkill
-SetInputText, SetTextInputControlHandler, SetTextInputDefaultControlsDisabled

Readme (abbreviated):

Spoiler

Oblivion Script Extender v0020
by Ian Patterson, Stephen Abel, and Paul Connelly
(ianpatt, behippo, and scruggsywuggsy the ferret)

Additional contributions from Timeslip, The J, DragoonWraith, SkyRanger-1, badhair, JRoush, shademe, and kyoma.

The Oblivion Script Extender, or OBSE for short, is a modder's resource that expands the scripting capabilities of Oblivion. It doesn't make any modifications to oblivion.exe, TESConstructionSet.exe, or any other files in your oblivion install, so don't worry about permanent side effects. It is compatible with the 1.2.0.416 Oblivion patch, as well as the 1.2 version of the Construction Set. Versions of Oblivion downloaded via Steam are supported as well.

[ Installation ]

If you are using a retail (non-Steam) version of the game:

1. Copy obse_1_2_416.dll, obse_editor_1_2.dll, and obse_loader.exe to your Oblivion directory. This is usually in your Program Files folder, and should contain files called "Oblivion.exe" and "OblivionLauncher.exe".
2. Run oblivion by running obse_loader.exe from the Oblivion directory.

If you use a desktop shortcut to launch Oblivion normally, just update the shortcut to point to obse_loader.exe instead of oblivion.exe.

If you are using the Steam version of the game:

1. Copy obse_1_2_416.dll, obse_editor_1_2.dll, and obse_steam_loader.dll to your Oblivion directory. This is usually "C:\Program Files\Valve\Steam\SteamApps\common\oblivion".
2. OBSE will automatically be run along with Oblivion when launched. To disable this, rename or move obse_steam_loader.dll. You do not need to use obse_loader.exe unless you are running the editor.

Scripts written with these new commands must be written via the TESConstructionSet launched with obse_loader. Open a command prompt window, navigate to your oblivion install folder, and type "obse_loader -editor". The normal editor can open plugins with these extended scripts fine, it just can't recompile them and will give errors if you try.

For mod developers:

http://home.comcast.net/~scruggsyW/obse/ScriptViewer.zip - View offsets into compiled scripts to help debug errors reported by OBSE at run-time

» Fri Sep 03, 2010 10:34 am

:ahhh: Now I'm in trouble!

» Fri Sep 03, 2010 7:59 am

You guys are updating quickly. I hadn't expected be nearly two versions behind after three months. This is sweet!

Congrats on the progress!
- Tomlong75210

» Fri Sep 03, 2010 11:06 am

Now I'm in trouble!

So am I!

» Fri Sep 03, 2010 2:43 am

:ahhh: Now I'm in trouble!

I've been in trouble for 2 versions now

Just call it a Beta... we need someone else with XP so I can finally load my scripts

» Fri Sep 03, 2010 7:20 am

PlayIdle sounds interesting. Does it mean I will no longer have to deal with the nightmare of setting oh so special conditions on an idle and hope that it plays with PickIdle?

Another question, I found a mod using something SetPlayerSkeletonPath, and though I can imagine what it does, I can't find documentation about it. Any info? Or have is it secret?

Finally, I'm probably the least indicated to suggest something given I have no idea of how programming actually works... the thing is, the Detect Life magic effects is hardcoded to play the LifeDetected shader, FormID 192, as you might know. Thing is, you can change the appearance of LifeDetected as you wish and Detect Life will always play it perfectly no matter if its membrane, particle, fancy, dull... but it seems impossible to replicate perfectly the behavior of Detect Life through PlayMagicShader every few frames with reference walking scripts. The partcle shaders tend to pile up on the reference until it looks radioactive unless you set the particle lifetime to something very low, and membrane shaders flick in and out or don't appear at all no matter how they are set. I was wondering, is it possible to make a command that replicates the effect of Detect Life?

I hope I made some sense. Maybe there is no problem with PMS, and I just need to fiddle a bit with the shaders to tune them well enough. Anyway, thank you for unlocking so much potential in the Oblivion modding endeavor.

» Fri Sep 03, 2010 7:45 am

Yay it's out! Awesome! Thanks a lot OBSE team!

» Fri Sep 03, 2010 11:47 am

PlayIdle sounds interesting. Does it mean I will no longer have to deal with the nightmare of setting oh so special conditions on an idle and hope that it plays with PickIdle?

Another question, I found a mod using something SetPlayerSkeletonPath, and though I can imagine what it does, I can't find documentation about it. Any info? Or have is it secret?

Finally, I'm probably the least indicated to suggest something given I have no idea of how programming actually works... the thing is, the Detect Life magic effects is hardcoded to play the LifeDetected shader, FormID 192, as you might know. Thing is, you can change the appearance of LifeDetected as you wish and Detect Life will always play it perfectly no matter if its membrane, particle, fancy, dull... but it seems impossible to replicate perfectly the behavior of Detect Life through PlayMagicShader every few frames with reference walking scripts. The partcle shaders tend to pile up on the reference until it looks radioactive unless you set the particle lifetime to something very low, and membrane shaders flick in and out or don't appear at all no matter how they are set. I was wondering, is it possible to make a command that replicates the effect of Detect Life?

I hope I made some sense. Maybe there is no problem with PMS, and I just need to fiddle a bit with the shaders to tune them well enough. Anyway, thank you for unlocking so much potential in the Oblivion modding endeavor.

PlayIdle includes an optional "force idle" argument that causes the anim to play regardless of the conditions associated with it. You don't need to use the flag if you don't put any conditions on your idle anim in the first place, but it's useful for playing idle anims defined by Oblivion.esm, which typically do include conditions.

SetPlayerSkeletonPath is a semi-secret, semi-beta command which pretty much does the same thing as Player.SetModelPath + Player.Update3D. I'd use those cmds instead as the skeleton path cmd instead officially supported. None of the commands currently supports modifying the player's first person 3D.

Repeated calls to PMS will add additional instances of the shader to the target, which may explain the behavior you're seeing. You might find 0020's HasEffectShader command useful - it returns the number of instances of the shader playing on the calling reference. If you want a command to override the shader used by the Detect Life effect, that's within the realm of possibility.

» Fri Sep 03, 2010 2:15 am

SetPlayerSkeletonPath is a semi-secret, semi-beta command which pretty much does the same thing as Player.SetModelPath + Player.Update3D. I'd use those cmds instead as the skeleton path cmd instead officially supported. None of the commands currently supports modifying the player's first person 3D.

Repeated calls to PMS will add additional instances of the shader to the target, which may explain the behavior you're seeing. You might find 0020's HasEffectShader command useful - it returns the number of instances of the shader playing on the calling reference. If you want a command to override the shader used by the Detect Life effect, that's within the realm of possibility.

Wouldn't repeated calls to SetModelPath and Update3D on an actor cause crashes? It did happen to me when using SetModelPath on actors, but I solved it by using ModModelPath and some fancy string construction. I might use ModModelPath for the player too then.

As for HasEffectShader, that might solve my problem. Thing is, the actor needs to have no trace of the shader on him, not even the remnants from the shader's fade out timer?
What I'm trying is not overriding the shader used by Detect Life, but to replicate Detect Life through scripts, and leaving the LifeDetected shader as invisible so that Detect Life doesn't really play it. It would allow me to have different references play different shaders, like in Supreme Magicka mod. So far I've had success using particle shaders with low particle lifetime, but no luck when trying to use membrane shaders.
I might be wrong, but I think there is something in Detect Life, probably in the Detect effect handler, that avoids the problems from having multiple instances from the same shader playing on the target. It's probably a job for JRoush and his OBME plugin to unearth the Detect handler though.

» Fri Sep 03, 2010 3:36 am

Wouldn't repeated calls to SetModelPath and Update3D on an actor cause crashes? It did happen to me when using SetModelPath on actors, but I solved it by using ModModelPath and some fancy string construction. I might use ModModelPath for the player too then.

Dunno, haven't heard anything like that. You don't want to be calling Update3D frequently on the same reference - the 3D gets reloaded in the background and is likely to take at least one frame to load.

I might be wrong, but I think there is something in Detect Life, probably in the Detect effect handler, that avoids the problems from having multiple instances from the same shader playing on the target. It's probably a job for JRoush and his OBME plugin to unearth the Detect handler though.

I'm looking at it now. The effect is hard-coded. I guess I'm not really clear on why you would call SMS every few frames to re-apply the shader to actors which already have it (is that what you're doing?) as opposed to calling SMS once per target , and PMS once per target.

» Fri Sep 03, 2010 3:20 pm

Here is the script I'm using, I should probably try to post only the relevant parts but the format gets garbled every time I try to edit a post:

Spoiler

;*****************************************************************************************************************;  Controls the new detect life system and shaders ;*****************************************************************************************************************scn zzSMDetectLifeQuestScriptfloat fquestdelaytimeref rCasterfloat ftimerlong indexref spellfloat fDetectIntervalfloat iSDurationshort iTypefloat fDistancelong  iDurationshort iCellDepthref   rItemlong  iEffectlong  iItemshort isdeadranameshort isundeadnamestring_var daedrafloat fFoot2Unitref rDetectLifeCustomShaderBegin GameModeIf GetGameLoaded	Set fQuestDelayTime to 0.05	set fDetectInterval to 0.25	set iSDuration to 0.5*fDetectInterval	set fFoot2Unit to 21.3		set iType         to 69	;For actors	set iCellDepth    to 1EndifIf Player.GetTotalActiveEffectMagnitude DTCT <= 0 || SMDetectLifeOn == 3	returnelseIf Player.GetTotalActiveEffectMagnitude DTCT > 0 && SMDetectLifeOn	set rCaster to Player	set fDistance to (Player.GetTotalActiveEffectMagnitude DTCT) * fFoot2Unit	set ftimer to ftimer - GetSecondsPassed	If ftimer <= 0		set ftimer to fDetectInterval		set rItem to Apple		set rItem to getFirstRef iType iCellDepth		while(rItem)		sv_destruct daedra		let isdeadraname := 0		let daedra := $ (rItem.GetRace)		if eval (sv_Count "Aureal" daedra > 0 || sv_Count "Mazken" daedra > 0 || sv_Count "Seducer" daedra > 0 || sv_Count "Xivilai" daedra > 0 || sv_Count "Golden Saint" daedra > 0)			let isdeadraname += 1		endif		let isdeadraname += rItem.CompareName "Clannfear"		let isdeadraname += rItem.CompareName "Daedroth"		let isdeadraname += rItem.CompareName "Atronach"		let isdeadraname += rItem.CompareName "Hunger"		let isdeadraname += rItem.CompareName "Jyggalag"		let isdeadraname += rItem.CompareName "Mehrunes Dagon"		let isdeadraname += rItem.CompareName "Scamp"		let isdeadraname += rItem.CompareName "Daedra"		let isdeadraname += rItem.CompareName "Sheogorath"		let isdeadraname += rItem.CompareName "Xivilai"		let isdeadraname += rItem.CompareName "Knight of Order"		let isdeadraname += rItem.CompareName "Golden Saint"		let isdeadraname += rItem.CompareName "Dark Seducer"		let isdeadraname += rItem.CompareName "Gatekeeper"		let isundeadname := 0		if eval (sv_Count "Zombie" daedra > 0)			let isundeadname += 1		endif		let isundeadname += rItem.CompareName "Undead"		let isundeadname += rItem.CompareName "Banshee"		let isundeadname += rItem.CompareName "Lich"		let isundeadname += rItem.CompareName "Ghost"		let isundeadname += rItem.CompareName "Wraith"		let isundeadname += rItem.CompareName "Spectral"		let isundeadname += rItem.CompareName "Shambles"		let isundeadname += rItem.CompareName "Skinned Hound"		let isundeadname += rItem.CompareName "Zombie"			if(rItem.getDistance rCaster <= fDistance && rItem.GetDead == 0 && rItem.GetIsReference PlayerRef == 0)				if SMDetectLifeOn == 0					rItem.playMagicShaderVisuals zzLifeDetectedBright iSDuration				elseif(isundeadname || rItem.GetCreatureType == 2 || rItem.IsSpellTarget AbGhostNPC || ((rItem.GetFactionRank UndeadFaction >= 0 || rItem.GetFactionRank LichFaction >= 0) && (rItem.IsSpellTarget AbUndeadBoneResist || rItem.IsSpellTarget AbUndeadEtherealResist || rItem.IsSpellTarget AbUndeadFleshResist || rItem.IsSpellTarget AbLichResist || rItem.IsSpellTarget AbLichNetherResist || rItem.IsSpellTarget SEAbSkinnedHoundResist))) || rItem.GetVampire	;Undead					if (Player.GetVampire || PCVampire > 0 || DetectLifeUndead)						rItem.playMagicShaderVisuals zzSMShaderAzure iSDuration					endif				elseif isdeadraname || rItem.GetCreatureType == 1 || rItem.GetIsRace Dremora ;Daedra					rItem.playMagicShaderVisuals zzSMShaderOrange iSDuration				elseif((Player.GetVampire || PCVampire > 0) && rItem.GetIsCreature == 0)					rItem.playMagicShaderVisuals zzLifeDetectedVampire iSDuration				elseif SMDetectLifeOn == 1					rItem.playMagicShaderVisuals zzLifeDetectedBright iSDuration				elseif SMDetectLifeOn == 2					rItem.playMagicShaderVisuals zzLifeDetected iSDuration				endif			endif			set rItem to Apple			set rItem to getNextRef		loop	endifEndifEnd

Edit: it didn't! must have been some bug now squashed.
So basically, the script checks for an actor every 0.25 seconds and orders a shader to be played for 0.125 seconds. But I don't think PMS accepts floats as duration.

» Fri Sep 03, 2010 12:03 pm

So the motivation behind the short duration is to avoid having to keep track of actors affected by the shader in order to remove the shader when the effect wears off or they wander out of range?
Have you considered marking each target with a token the first time the effect is applied? Then on subsequent ref walks you can check for the presence of the token, skipping a ton of CompareName checks. Token can call PMS when added and SMS when out of range/effect wears off. And you would no longer have issues with multiple instances of the shaders piling up on each actor.

EDIT: Yes, it accepts floats. But the actual duration may or may not include ramp-up/down time.

» Fri Sep 03, 2010 9:43 am

So the motivation behind the short duration is to avoid having to keep track of actors affected by the shader in order to remove the shader when the effect wears off or they wander out of range?
Have you considered marking each target with a token the first time the effect is applied? Then on subsequent ref walks you can check for the presence of the token, skipping a ton of CompareName checks. Token can call PMS when added and SMS when out of range/effect wears off. And you would no longer have issues with multiple instances of the shaders piling up on each actor.

EDIT: Yes, it accepts floats. But the actual duration may or may not include ramp-up/down time.

And as always, the most simple solution is the best one...
Oh man, I'm so sorry for having wasted your time and talents for turning up which such a simple solution to my 'PMS problem'. I can't believe I hadn't thought of the almighty tokens before. So, no need to 'unearth handlers' anymore. Again, sorry, and thank you very much.

» Fri Sep 03, 2010 4:06 pm

And as always, the most simple solution is the best one...
Oh man, I'm so sorry for having wasted your time and talents for turning up which such a simple solution to my 'PMS problem'. I can't believe I hadn't thought of the almighty tokens before. So, no need to 'unearth handlers' anymore. Again, sorry, and thank you very much.

Not a problem, hope you get it working the way you want.

» Fri Sep 03, 2010 2:13 pm

Have there been any changes for plugin writers? I seem to recall that there were going to be some. Also, did you figure out how I could use Oblivion's BSA reading code?

» Fri Sep 03, 2010 11:48 am

Have there been any changes for plugin writers? I seem to recall that there were going to be some.

Yeah, a few.

Spoiler

OBSEConsoleInterface got RunScriptLine2, which can take a calling ref and optionally suppress console output.
A PostPostLoad message was added to the messaging interface (?)
kParamType_Array was added to CommandTable.h to allow plugin cmds to accept arrays as arguments directly (instead of accepting by integer ID). See below about ExtractArgsix().
OBSEScriptInterface got GetFunctionParams(), which returns info about the params for a function script.

Most significantly, ExtractArgsix() and ExtractFormatStringArgs() were transferred from GameAPI.h to OBSEScriptInterface, and PluginInfo::kVersion was incremented. This is to enable 0020's compiler override feature to support plugin commands. If you build your plugin with 0020 or later, scripts will be able to pass OBSE datatypes/expressions as args to your commands; if not, your plugin's commands will instead be compiled by the default compiler as before. This is what allows your commands to accept arrays as arguments, too. This all happens automagically and transparently as far as your code is concerned.

The example project contains a couple of macros which will make updating your plugin to support this extremely easy.

Details are in PluginAPI.h.

» Fri Sep 03, 2010 8:18 am

OK, that's very cool. And as long as I copy those macros over to, say, NifSE, it should compile fine and accept arrays as arguments? Heh, changing all of the functions to natively accept arrays rather than go through the array interface with the ID will be a little tedious, but very worth it. Oh, question there - if someone wrote scripts with a pre-v0020 version of OBSE, passing integers that are array IDs, will those functions still work if the installed version of NifSE uses the array parameter? NifSE's still a beta thanks to the BSA-reading troubles, so I'm not going to lose any sleep about breaking old scripts (plus I'm sure I can coordinate release with Skycaptain), but it'd be neat if they did.

Also, I think you missed my edit above?

» Fri Sep 03, 2010 11:31 am

OK, that's very cool. And as long as I copy those macros over to, say, NifSE, it should compile fine and accept arrays as arguments?

Yes. They make use of a global OBSEScriptInterface* which you'll need to initialize in your plugin's load routine. Beyond that they are plug-and-play.

if someone wrote scripts with a pre-v0020 version of OBSE, passing integers that are array IDs, will those functions still work if the installed version of NifSE uses the array parameter? NifSE's still a beta thanks to the BSA-reading troubles, so I'm not going to lose any sleep about breaking old scripts (plus I'm sure I can coordinate release with Skycaptain), but it'd be neat if they did.

No.

Also, I think you missed my edit above?

I did some poking around, but I don't have anything particularly usable for you yet.

» Fri Sep 03, 2010 4:19 am

Was just about to ask about the PluginAPI changes, sounds very simple indeed. Good work!

» Fri Sep 03, 2010 11:08 am

*** This text is machine translation. I'm sorry when there is a wrong expression. ***

Thanks a lot for the release of OBSE 0020beta, and responding to my request (update3d of player in 0019b).
To tell the truth, I have one more request to OBSE.

SetForceSpecialanims:
"If Specialanims is defined about the motion of any "NPC", always do the motion of Specialanims."

---------------------------------------
ex: npc.setForceSpecialanims 1

if npc has,
_male\ onehandattackleft.kf onehandattackleft_chop.kf
_male\specialanims\ *** nothing ***
=> then perform former group of ATTACKLEFT.

if npc has,
_male\onehandattackleft.kf onehandattackleft_chop.kf
_male\specialanims\onehandattackleft_forAnyWeapon.kf onehandattackleft_chop_forAnyWeapon.kf
=> then perform latter group of ATTACKLEFT.
---------------------------------------

I am making MOD to which any NPC perform a unique attack motion for every own weapon.
( I checked equipment of NPC by OnActorEquip-event and have implemented it by "npc.toggleSpecialAnim weapontype/any.kf => npc.update3d." )
However, since motions, such as Attackleft or recoil etc... , are selected at random, NPC sometimes tries to perform the motion of Vanilla.

My MOD's WIP(youtube): http://www.youtube.com/watch?v=dE_rsWl7yjI

For the moment, if it is AttackLeft, for example, I defined dummy OneHandAttackLeft1.kf ... OneHandAttackLeft8.kf, and have lowered the probability that the motion of Vanilla is selected.
However, if possible, I would always like to have Specialanims selected.
Is this possible?

Thanks for reading.

» Fri Sep 03, 2010 2:47 pm

Wow, that sounds like Pluggy no longer needs a mini-OBSE. Very nice Scruggsy and now I'm in trouble too

» Fri Sep 03, 2010 6:26 am

*** This text is machine translation. I'm sorry when there is a wrong expression. ***

Thanks a lot for the release of OBSE 0020beta, and responding to my request (update3d of player in 0019b).
To tell the truth, I have one more request to OBSE.

SetForceSpecialanims:
"If Specialanims is defined about the motion of any "NPC", always do the motion of Specialanims."

Well the mod looks awesome.
I'm not sure exactly what would be involved in fulfilling the request but I can take a look. Can you send me a link to the mod?

Wow, that sounds like Pluggy no longer needs a mini-OBSE.

If it wants to support 0020's new features it's going to *need* to jettison mini-OBSE. If doing so is not an option, no biggie; it will continue to function as before.

» Fri Sep 03, 2010 6:47 pm

Well the mod looks awesome.
I'm not sure exactly what would be involved in fulfilling the request but I can take a look. Can you send me a link to the mod?

Thank you for the answer !
I have not uploaded the data of the MOD yet.
However, since there is a file, I prepare it immediately and PM it to you.
( I'm sorry, there is not a README now. )

» Fri Sep 03, 2010 9:43 am

Ah, damn, time to get back to work :frown:

Seriously, a big thank you for this :hugs: Very nice Christmas present!

» Fri Sep 03, 2010 12:05 pm

Congrats for the new Release. Awsome as always. :woot:

As for the trouble-topic: Since I was in trouble before there's no real change for me. Got kinda good ignoring it.