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

» Mon Nov 01, 2010 10:20 pm

Bad news, I'm afraid. Sorry for not catching this sooner, but it seems there's a bug in v19 that wasn't present in v18 to do with reading string input. I think this is the relevant script (not mine, so I'm not really sure about it):

scn zzOBGETextInputOS; text input activatorshort sActivatedshort sButtonfloat fValuestring_var svTextbegin onActivate	let svText := zzOBGECoreQ.svText	openTextInput $svText 0 120	let sActivated := 1endbegin menuMode 1001	if ( sActivated )		updateTextInput	endIfendbegin gameMode	if ( sActivated )		let sButton := getButtonPressed		if ( sButton == 0 )			set zzOBGECoreQ.svText to getInputText			closeTextInput			let fValue := zzOBGECoreQ.aShaderInfo[ zzOBGECoreQ.svShaderName ][ zzOBGECoreQ.sKey ][ "value" ] := toNumber $zzOBGECoreQ.svText			print "OBGE Support : " + zzOBGECoreQ.svShaderName + "." + zzOBGECoreQ.aShaderInfo[ zzOBGECoreQ.svShaderName ][ zzOBGECoreQ.sKey ][ "identifier" ] + "  >> " + sv_Construct "%0.10f" fValue			let zzOBGECoreQ.sShowTextInput := 1					let sActivated := 0		elseIf ( sButton == 1 )			closeTextInput			let zzOBGECoreQ.sShowTextInput := 1					let sActivated := 0		endIf	endIfend

Is there any reason why this should stop working in v19?

» Mon Nov 01, 2010 8:14 am

Is it possible for a plugin function to have a normal string parameter and then a formatString? I have a group of functions which are very similar and it would be nice if I could combine them into 1 and just using a string parameter to specify which variant is wanted.

» Mon Nov 01, 2010 12:43 pm

Is it possible for a plugin function to have a normal string parameter and then a formatString? I have a group of functions which are very similar and it would be nice if I could combine them into 1 and just using a string parameter to specify which variant is wanted.

How would you pass a string if not as a format string ? In the same vein, what would be a "normal string parameter"

» Mon Nov 01, 2010 8:11 am

How would you pass a string if not as a format string ? In the same vein, what would be a "normal string parameter"

A normal string would be a string without any extra/formatting parameters, simply kParamType_String.

[edit]
Ok, solved. It seems I can use ExtractFormatStringArgs but with using 1 instead of 0 for the first parameter (which is the starting index for the formatString parameters).

	char stringArg[kMaxMessageLength] = { 0 };	char typeArg[kMaxMessageLength] = { 0 };	ExtractFormatStringArgs(1, stringArg, paramInfo, arg1, opcodeOffsetPtr, scriptObj, eventList, kCommandInfo_Kyoma_Test.numParams, &typeArg);	Console_Print("Kyoma_Test >> TypeArg: %s - StringArg: %s", typeArg, stringArg);

[/edit]

[edit2]
On second thought, that messes up when there are parameters following the formatString.

In this case, after adding two integer parameters the first is always clipped and somehow used by the initial (normal) string parameter.
[/edit2]

-kyoma

» Mon Nov 01, 2010 8:41 am

I've seen something similar on the active effects page. For instance, when I was testing nGCD v2, at one point I noticed a birthsign bonus was missing from that screen. (Birthsigns were vanilla for the test, so no chance of mod involvement.) However, nGCD was still detecting the bonus, so this was definitely just a display glitch.

I recently installed MenuQue, so that was my first hunch as to a possible culprit, but I haven't done enough testing to know for sure. Morbid, do you have MenuQue?

No I don't use MenuQue.

I discovered that if I drop the items that were affected and then pick them up again the problem is fixed. If I load up the "infected" saves I still have the same problem they disappear (from my inventory but not my character) and reaper when I load saves made with an "infected" save as a "parent". But If I drop them and pick them up they stop behaving strangely and I can be on my merry way. So the problem's fixed for me (at least for the time being).

» Mon Nov 01, 2010 7:58 pm

A quick question about event handlers (my god I only just noticed they exist! :facepalm: ):

Say I want to set certain eventhandler for every NPC in the loaded area.

1. Is it costly to set the same eventhandler on the NPC every, say, second, or should I keep track of who has been treated already?

2. Is the handlers ever auto-removed? i.e. should I be very careful to remove them from every NPC once the player leaves the cell*?

*can I even remove handlers from references that just got cleared from memory?

I would appreciate some "best practice" tips on this. In essense I′m about to upgrade DR′s elemental magic effects so that any NPC that get hit by a certain magic effect can get treated by the special effects, without the need for "getcrosshairref" target acquiring and other "hit approximations".

So the question is how elegant a system I need to build to tag all NPCs in the memory with "onmagiceffecthit" handlers?

» Mon Nov 01, 2010 10:46 pm

A quick question about event handlers (my god I only just noticed they exist! :facepalm: ):

Say I want to set certain eventhandler for every NPC in the loaded area.

1. Is it costly to set the same eventhandler on the NPC every, say, second, or should I keep track of who has been treated already?

2. Is the handlers ever auto-removed? i.e. should I be very careful to remove them from every NPC once the player leaves the cell*?

*can I even remove handlers from references that just got cleared from memory?

I would appreciate some "best practice" tips on this. In essense I′m about to upgrade DR′s elemental magic effects so that any NPC that get hit by a certain magic effect can get treated by the special effects, without the need for "getcrosshairref" target acquiring and other "hit approximations".

So the question is how elegant a system I need to build to tag all NPCs in the memory with "onmagiceffecthit" handlers?

1. Not really. The code will notice the handler has already been registered and do nothing.
2. No, a handler isn't removed unless you explicitly remove it via script.

Best practice:
If you're only interested in an event affecting one or two specific actors/references, register an event handler for the specific refr(s).
If (as in this case) you are interested events affecting a larger number of actors/refrs, register a generic handler without specifying the refr. In your handler filter out refrs you're not interested in if necessary.

If you're too specific and register a large number of handlers for a particular event, than every time such an event occurs OBSE needs to check against each registered handler to determine if it should be invoked.
If on the other hand you're too generic and register a single handler or small number of handlers for a particular event, when you're not interested in the majority of those events, then OBSE has to create and execute your handler script for every event.
So the question is: of all the events of a specific type which are likely to occur, what percentage of them do you expect to be interested in processing? If it's a large percentage, use a generic handler. Small percentage, use one or more handlers for specific reference(s).

In this case it sounds like you're interested in OnMGEFHit events affecting any actor in the currently loaded area, which is pretty much what you'll get with a generic handler. You shouldn't need to explicitly target any actors.

Bad news, I'm afraid. Sorry for not catching this sooner, but it seems there's a bug in v19 that wasn't present in v18 to do with reading string input. I think this is the relevant script (not mine, so I'm not really sure about it):

[snip]

Is there any reason why this should stop working in v19?

At first glance, no. What's not working - GetInputText is returning an empty string? Was this reported elsewhere before you posted it here?

On second thought, that messes up when there are parameters following the formatString.

In this case, after adding two integer parameters the first is always clipped and somehow used by the initial (normal) string parameter.

Can I see the ParamInfo for the command in question?

» Mon Nov 01, 2010 10:47 pm

1. Not really. The code will notice the handler has already been registered and do nothing.
2. No, a handler isn't removed unless you explicitly remove it via script.

Best practice:
If you're only interested in an event affecting one or two specific actors/references, register an event handler for the specific refr(s).
If (as in this case) you are interested events affecting a larger number of actors/refrs, register a generic handler without specifying the refr. In your handler filter out refrs you're not interested in if necessary.

If you're too specific and register a large number of handlers for a particular event, than every time such an event occurs OBSE needs to check against each registered handler to determine if it should be invoked.
If on the other hand you're too generic and register a single handler or small number of handlers for a particular event, when you're not interested in the majority of those events, then OBSE has to create and execute your handler script for every event.
So the question is: of all the events of a specific type which are likely to occur, what percentage of them do you expect to be interested in processing? If it's a large percentage, use a generic handler. Small percentage, use one or more handlers for specific reference(s).

In this case it sounds like you're interested in OnMGEFHit events affecting any actor in the currently loaded area, which is pretty much what you'll get with a generic handler. You shouldn't need to explicitly target any actors.

Thank you very much for the quick reply - that answers my question perfectly!

You got it right - I realised that via event handlers, I can easily make the DR′s magic critical effects global and more compatible overall. So yes I want a full coverage, so a generic handler is a perfect solution. I′ll just make sure the script returns as soon as possible.

» Mon Nov 01, 2010 5:26 pm

At first glance, no. What's not working - GetInputText is returning an empty string? Was this reported elsewhere before you posted it here?

I haven't tested to see if it's GetInputText returning an empty string or ToNumber failing. I'll find out and get back to you. Someone reported inputting values with no change when using the OGE support plugin on the OGE thread, but there's no more detail over there.

EDIT: Weird. When I add "print zzOBGECoreQ.svText" below the TextInput line, it suddenly works, but when I remove it, it stops working again...

» Mon Nov 01, 2010 12:27 pm

At first glance, no. What's not working - GetInputText is returning an empty string? Was this reported elsewhere before you posted it here?

I know GetInputText was one of the few commands in v18 that required a "Set" to work, and always returned an empty string with "Let". I haven't tested that with v19 yet, but can it be something about this?

» Mon Nov 01, 2010 9:53 pm

Hi - how did you calculate the CRCs for oblivion.exe (Adler32 ?) - any app that will do this for me the way you did it ?

Thanks

lol edit : obse_loader -crconly right ?

» Mon Nov 01, 2010 6:07 pm

Thank you for the new version 19 (October 26th, 2010).

The version number of this OBSE and its minor version number are:
- GetOBSEVersion => 19
- GetOBSERevision => 4
Are these values correct?

The next will be :
- GetOBSEVersion => 20
- GetOBSERevision => 1
???

» Mon Nov 01, 2010 3:15 pm

Can I see the ParamInfo for the command in question?

Even better, here's the function, ParamInfo and some console examples

Spoiler

static ParamInfo kParams_MultiString[SIZEOF_FMT_STRING_PARAMS + 3] ={	{	"typeString",	kParamType_String,	0	},	FORMAT_STRING_PARAMS,	{	"menuType",		kParamType_Integer,	0	},	{	"float",		kParamType_Float,	0	},};static bool Cmd_MultiString_Execute(COMMAND_ARGS){	char typeArg[kMaxMessageLength] = { 0 };	char stringArg[kMaxMessageLength] = { 0 };	UInt32 menuType = 0;	float floatVal = 0;	ExtractFormatStringArgs(1, stringArg, paramInfo, arg1, opcodeOffsetPtr, scriptObj, eventList, kCommandInfo_MultiString.numParams, &typeArg, &menuType, &floatVal);	Console_Print("MultiString >> typeArg: %s - stringArg: %s - menuType: %d - floatVal: %.2f", typeArg, stringArg, menuType, floatVal);	return true;}DEFINE_COMMAND_PLUGIN(MultiString, testing function with multipl stringarguments,					  0,NUM_PARAMS(kParams_MultiString),					  kParams_MultiString);

multistring "Active" "ComponentPath" MultiString >> typeArg: Active - stringArg: ComponentPath - menuType: 0 - floatVal: 0.00multistring "Active" "ComponentPath" 1004MultiString >> typeArg: ì - stringArg: ComponentPath - menuType: 0 - floatVal: 0.00multistring "Active" "ComponentPath" 1004 30MultiString >> typeArg: ì - stringArg: ComponentPath - menuType: 1106247680 - floatVal: 0.00

As you can see without the last two parameters both string arguments are extracted correctly but with adding more arguments things get a bit messy.

Also, something else, I had a suggestion and/or request for the PluginAPI. Currently OBSE has the HandleMainLoopHook for things that need aditional stuff in the following frame, right? Would it be possible to register (and unregister) a listener for this so plugins can request a "Tick()" too? It seems useful for functions or other features that need to do something over the course of two or more frames without having to setup a completely new structure (or whatever it's called).

-kyoma

» Mon Nov 01, 2010 6:59 pm

*** This text is machine translation. I'm sorry when there is a wrong expression. ***
Hello, I have a question.
Doesn't the more familiar one teach an answer?

Question :
"When ToggleSpecialAnim is used to Player, is there how to reflect it in a game immediately? "

I understand that I can reflect the result of "ToggleSpecialAnim" immediately using "Update3d" to NPC.
However, currently, "Update3d" is not effective in Player ( QUOTE: "This command does not currently work correctly on the player" ).
If there are other methods of reflecting the result of toggleSpecialAnim immediately to Player, please let me know.

Thank you for reading.

» Mon Nov 01, 2010 10:03 am

I keep getting a message in the console window (ie not in-game) saying...

OBSE ver was modified 18.6 => 19.4

I don't know if this is generated by OBSE or one of the plugins I am using, but thought I would ask here in case it is OBSE.

The message is displayed many times during play (ie when I go to the console there are many of these messages). They do not appear in the OBSE log, so perhaps it is being produced by another plugin or mod.

Any thoughts or comments will be very much appreciated.

» Mon Nov 01, 2010 10:51 am

OBSE ver was modified 18.6 => 19.4

I have seen the message.
There is the completely same contents of a letter as the script written by me.
-------------------
printc "OBSE ver was modified. %2.0f . %1.0f => %2.0f . %1.0f" obseVer obseRev tmpObseVer tmpObseRev
-------------------
If you have installed EDialog or Estrus, they are outputting the message.

In that case, please perform following either.
A. Reinstallation of those MOD.
B. Execution of "Reset" in the menu of Configuration.
Then, it is no longer outputted.

» Mon Nov 01, 2010 6:47 pm

If you have installed EDialog or Estrus, they are outputting the message.

Many thanks - I have EDialog installed - will do as you suggest.

» Mon Nov 01, 2010 10:55 pm

Quick question: I know that with v18 there was a requirement for users to have v18 if you'd made a mod with v18 even if you didn't use any new commands. Something to do with the way OBSE now store strings or arrays or whatever.

Is this also true of the transition from v18 to v19? That is, if I make a mod with v19 installed but don't use any v19 commands, can the user get by with only having v18 installed? (I assume they need at least v18, as noted above.)

» Mon Nov 01, 2010 8:37 pm

Quick question: I know that with v18 there was a requirement for users to have v18 if you'd made a mod with v18 even if you didn't use any new commands. Something to do with the way OBSE now store strings or arrays or whatever.

Is this also true of the transition from v18 to v19? That is, if I make a mod with v19 installed but don't use any v19 commands, can the user get by with only having v18 installed? (I assume they need at least v18, as noted above.)

Yep, you need v19 if you compiled using v19, even if you used no new stuff.

» Mon Nov 01, 2010 5:39 pm

Hello all,

I do not wish to start another thread, so I hope you will not mind (too much) me using this one to ask for a favor related to an OBSE mod.

I remember using http://www.tesnexus.com/downloads/file.php?id=26892 successfully in the past.

Having recently switched over to OBSE v19, I now experience CTD's whenever this mod is activated in my game, usually a few seconds after it finishes loading, and it attempts to change a track.
My game is perfectly stable if I deactivate it.

I went as far as http://http://www.nirsoft.net/utils/installed_codec.html to prevent it from crashing, but it wouldn't work.

Other players seem to experience the same behavior (check the comments section of http://www.tesnexus.com/downloads/file.php?id=19772, one of the requirements).

I do not wish to abuse. If the fix seemed like a very complex and time-consuming operation to me, and if the mod was not of such an outstanding quality to start with, I promise I wouldn't ask.
My feeling however is that it should only be a matter to adapt some of the required components below to the new OBSE version :

http://www.tesnexus.com/downloads/file.php?id=19772 (strong suspicion about this one being the real culprit)
http://www.tesnexus.com/downloads/file.php?id=16288

Would someone be so kind to look into this issue ?
Thank you in advance

» Mon Nov 01, 2010 11:23 am

Hello all,

I do not wish to start another thread, so I hope you will not mind (too much) me using this one to ask for a favor related to an OBSE mod.

I remember using http://www.tesnexus.com/downloads/file.php?id=26892 successfully in the past.

snip

I believe the issue lies with the Enhanced Music Controls (?) OBSE plugin, which causes a number of problems for lots of people, including me. I don't think there's anything in OBSE itself that causes the issue.

» Tue Nov 02, 2010 12:14 am

I remember using http://www.tesnexus.com/downloads/file.php?id=26892 successfully in the past.

Having recently switched over to OBSE v19, I now experience CTD's whenever this mod is activated in my game, usually a few seconds after it finishes loading, and it attempts to change a track.
My game is perfectly stable if I deactivate it.

I went as far as http://http://www.nirsoft.net/utils/installed_codec.html to prevent it from crashing, but it wouldn't work.

Other players seem to experience the same behavior (check the comments section of http://www.tesnexus.com/downloads/file.php?id=19772, one of the requirements).

I do not wish to abuse. If the fix seemed like a very complex and time-consuming operation to me, and if the mod was not of such an outstanding quality to start with, I promise I wouldn't ask.
My feeling however is that it should only be a matter to adapt some of the required components below to the new OBSE version :

http://www.tesnexus.com/downloads/file.php?id=19772 (strong suspicion about this one being the real culprit)
http://www.tesnexus.com/downloads/file.php?id=16288

Yeah, that plugin has never been 100% stable, but for it to suddenly become unstable for you (I'm assuming no other changes to your system?) is fishy. Looking into it now.

Quick question: I know that with v18 there was a requirement for users to have v18 if you'd made a mod with v18 even if you didn't use any new commands. Something to do with the way OBSE now store strings or arrays or whatever.

Is this also true of the transition from v18 to v19? That is, if I make a mod with v19 installed but don't use any v19 commands, can the user get by with only having v18 installed? (I assume they need at least v18, as noted above.)

Short, easy answer: yes, if you compile with 0019 you should expect your users to have 0019 or later installed.
Long answer: Between 0018 and 0019 we changed some internal code for handling assignment to strings. So if you have code that does:

let someStringVar :=

or

let someArray[index] :=  ; where someArray[index] is a string

then the short answer applies; otherwise you should be able to get away with requiring 0018.

I understand that I can reflect the result of "ToggleSpecialAnim" immediately using "Update3d" to NPC.
However, currently, "Update3d" is not effective in Player ( QUOTE: "This command does not currently work correctly on the player" ).
If there are other methods of reflecting the result of toggleSpecialAnim immediately to Player, please let me know.

I don't know of any other methods right now, sorry.

Even better, here's the function, ParamInfo and some console examples
[snip]
Also, something else, I had a suggestion and/or request for the PluginAPI. Currently OBSE has the HandleMainLoopHook for things that need aditional stuff in the following frame, right? Would it be possible to register (and unregister) a listener for this so plugins can request a "Tick()" too? It seems useful for functions or other features that need to do something over the course of two or more frames without having to setup a completely new structure (or whatever it's called).

Thanks. Yeah, currently it's an either-or proposition: you can have extra params before or after the format string but not both.
What kind of things does your plugin need to do during the main loop hook?

Thank you for the new version 19 (October 26th, 2010).

The version number of this OBSE and its minor version number are:
- GetOBSEVersion => 19
- GetOBSERevision => 4
Are these values correct?

The next will be :
- GetOBSEVersion => 20
- GetOBSERevision => 1
???

Revision number starts at zero so it'll be 20.0.

@wrinklyninja: PM'ed.

» Mon Nov 01, 2010 8:15 pm

Thank you for all the answers, it is nice!

» Mon Nov 01, 2010 9:50 pm

That is more than I had hoped for, since I agree that the instability of the mod most probably doesn't come from OBSE itself.

Thank you very much for your time.

PS : No other changes to my system : almost clean Windows XP system, with SP3, Oblivion fully patched to latest version. I remember it working fine with a previous version of OBSE, but I can't recall which one exactly it was. Sorry

Yeah, that plugin has never been 100% stable, but for it to suddenly become unstable for you (I'm assuming no other changes to your system?) is fishy. Looking into it now.

» Mon Nov 01, 2010 9:43 am

Thanks. Yeah, currently it's an either-or proposition: you can have extra params before or after the format string but not both.

Bummer, awell, I'll think of something else then. Thanks.

What kind of things does your plugin need to do during the main loop hook?

Right now, nothing. In the future I'll need/want to call a function every second or so (at a predetermined interval) and perhaps also call a set of functions to do stuff like sliding a menu popup (for example). The latter would ofcourse require a frame-by-frame configuration (but only during a certain time).

[edit]
For some reason I can't get OBSEArrayInterface::GetElement to work. The element always has a kType_Numeric and the value seems to be 1. Here's my full code, cs snippet and console output.

Spoiler

Function Code

static bool Cmd_Kyoma_Test_Execute(COMMAND_ARGS){	UInt32 var0 = 0;	UInt32 var1 = 0;	ExtractArgs(paramInfo, arg1, opcodeOffsetPtr, thisObj, arg3, scriptObj, eventList, &var0, &var1);	OBSEArray* arr;	if(!var0){		std::vector vec;		vec.push_back(*g_thePlayer);		vec.push_back(100);		vec.push_back("Hello World");		arr = ArrayFromStdVector(vec, scriptObj);		if (!arr)			Console_Print("Kyoma_Test >> Couldn't create array");		if (!g_arrayIntfc->AssignCommandResult(arr, result))			Console_Print("Kyoma_Test >> Couldn't assign array to command result.");		Console_Print("Kyoma_Test >> Dummy array created");		var0 = *result;	} else		Console_Print("Kyoma_Test >> Argument array used");	OBSEArray* lookie = g_arrayIntfc->LookupArrayByID(var0);	if(lookie){		UInt32 size = g_arrayIntfc->GetArraySize(lookie);		Console_Print("Kyoma_Test >> Array size: %d", size);		OBSEElement element;		for(UInt32 i = 0; i < size; i++){			g_arrayIntfc->GetElement(lookie, i, element);			if(element.GetType() == OBSEElement::kType_Invalid)				Console_Print("Kyoma_Test >> Index %d is invalid", i);			else if(element.GetType() == OBSEElement::kType_Numeric)				Console_Print("Kyoma_Test >> Index %d is numeric: %.2f", i, element.Number());			else if(element.GetType() == OBSEElement::kType_String)				Console_Print("Kyoma_Test >> Index %d is string: %s", i, element.String());			else if(element.GetType() == OBSEElement::kType_Form)				Console_Print("Kyoma_Test >> Index %d is form: %08x", i, (TESForm*)element.Form()->refID);		}	}}

CS snippet

let arTest := ar_Construct Arraylet arTest[0] := playerReflet arTest[1] := 100let arTest[2] := "Hello World"let arTest[3] := Kyoma_Test arTest

And console output

Kyoma_Test >> Argument array usedKyoma_Test >> Array size: 3Kyoma_Test >> Index 0 is numeric: 1.00Kyoma_Test >> Index 1 is numeric: 1.00Kyoma_Test >> Index 2 is numeric: 1.00kyoma_test               ;This was typed in the consoleKyoma_Test >> Dummy array createdKyoma_Test >> Array size: 3Kyoma_Test >> Index 0 is numeric: 1.00Kyoma_Test >> Index 1 is numeric: 1.00Kyoma_Test >> Index 2 is numeric: 1.00

[/edit]

-kyoma