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

» Thu Nov 25, 2010 3:35 pm

I don't suppose there's any way to tell when all your OBSE mods have finished their "start-up" scripts after a game load?

Nope - OBSE wouldn't know what scripts do what and which ones were supposed to be of the "startup" type. In most cases, a duration 5 seconds after game load would be sufficient enough to run gameLoaded/Restarted blocks and initialize quest scripts on first run.

» Thu Nov 25, 2010 2:16 pm

Currently I'm only interested in Player.OnHit, but this might change so I'm interested in the OnHit-Information for several NPCs.
Maybe I (or anyone else) will be interested in other Begin-Blocks, but for my current projects OnHit should be enough.

I'm pretty sure almost every combat overhaul mod would like to see a non-BeginBlock OnHit function. Perhaps one for OnMagicHit too. I myself might like an onActivate although that one can be relatively easy be worked around by tracking the crosshair ref and the activate control.

Nope - OBSE wouldn't know what scripts do what and which ones were supposed to be of the "startup" type. In most cases, a duration 5 seconds after game load would be sufficient enough to run gameLoaded/Restarted blocks and initialize quest scripts on first run.

What I would love to see is a fix for the delay with quest scripts after a game load/restart. I'm not talking about the delay while you wait for whatever fQuestDelayTime you have configured kicks in.

» Thu Nov 25, 2010 6:00 pm

I'm pretty sure almost every combat overhaul mod would like to see a non-BeginBlock OnHit function. Perhaps one for OnMagicHit too. I myself might like an onActivate although that one can be relatively easy be worked around by tracking the crosshair ref and the activate control.

Not to forget OnDeath for all Mods that plan to add an XP-System.

» Thu Nov 25, 2010 3:50 pm

Hey guys!

I'm trying to figure the best way to identify Caves/Ruins/Forts as opposed to house interiors. Well, actually, I'm trying to separate underground interiors from upperground interiors.

Why does the GetParentWorldspace function "generally" return 0 in interiors? When doesn't it?

The next bit doesn't quite belong here, but I thought someone might have an idea since this theme seems quite popular these days.

Unless I'm missing some useful function, I think I'll have to compare the string name of the cell with certain pre-defined ones such as "upstairs", "house", "livingQuarters". Problem with this is that I'm not sure all underground cells have such tags.

let ref := player.getParentCellForEach uppergroundName <- uppergroundStrings     if (ref.NameIncludes uppergroundName)           let bUnderground := 0           break     endifLoop

As a failsafe, I could check for the music type - if it's Dungeon, it's surely underground, if it's Public or Default, it must be a house.

Thanks!

cc

» Thu Nov 25, 2010 9:52 pm

Hey guys!

I'm trying to figure the best way to identify Caves/Ruins/Forts as opposed to house interiors. Well, actually, I'm trying to separate underground interiors from upperground interiors.

Use the method I used in SPAWN - Scan statics and compare their model names.

» Fri Nov 26, 2010 1:07 am

Use the method I used in SPAWN - Scan statics and compare their model names.

That's how You Are Here works, isn't it? May I ask why you chose to implement your own system by using the same mechanic? Just curious, to be honest.
Scanning the static meshes seems like it would be more resource intensive and you're still comparing the name of it with a string.

Also, for AnvilCastleDungeon, the rooms are made out of InteriorNarrow. There's one "PrisonCell" and two markers with the word "Dungeon" in them. Taking into account the dominant mesh wouldn't suggest this location is underground. But I admit I haven't looked at the inner workings of SPAWN. I'm only asking if it's not over complicating things by going after all the static meshes instead of a cell name.

Thanks for the reply!

cc

» Thu Nov 25, 2010 10:58 pm

That's how You Are Here works, isn't it? May I ask why you chose to implement your own system by using the same mechanic? Just curious, to be honest.
Scanning the static meshes seems like it would be more resource intensive and you're still comparing the name of it with a string.

Mostly because YAH's heuristics weren't good enough to account for mods that mix tile sets. You shouldn't be concerned about performance in any case, as you're only going to be ref. walking once per cell.

Also, for AnvilCastleDungeon, the rooms are made out of InteriorNarrow. There's one "PrisonCell" and two markers with the word "Dungeon" in them. Taking into account the dominant mesh wouldn't suggest this location is underground. But I admit I haven't looked at the inner workings of SPAWN. I'm only asking if it's not over complicating things by going after all the static meshes instead of a cell name.

You point out a valid issue. Yes, static walking will fail to return a correct type in such a scenario. I'd say that the best implementation would be to use both methods.

» Thu Nov 25, 2010 9:14 pm

Hi - question on isFormValid.
Using :

scn UDUNcTQUESTscriptset tomeAppr to UDUNcTApprenticeREF	; a *persistent* ref...IF isFormValid tomeAppr == 0	printc "stoooooooooooops"	stopquest UDUNcTQUESTENDIF

never ever saw "stoooooooooooops" even when UDUNcTApprenticeREF is placed in a container, and even when I use remove all items on the container - shouldn't I ? the docs are rather minimal on this - only found this : http://cs.elderscrolls.com/constwiki/index.php/OBSE_Wishes_Fulfilled
Actually a function that could differentiate between the cases - item in container || item removed from game - would be quite handy
Is there a way to check the second case in particular ?

Hi - still stuck on this one. Changed the code to :

IF isFormValid tomeAppr == 0	printc "stoooooooooooops"    ; still never saw this	stopquest UDUNcTQUESTELSEiF tomeAppr.HasBeenPickedUp	printc "HasBeenPickedUp == 1 !"ENDIF

HasBeenPickedUp returns 1 as expected (when I pick up or put the book to a container) but when I save quit and reload returns 0 (I never see "HasBeenPickedUp == 1 !", while I do see other printc's messages from my quest script). Is this the way it's supposed to be ?

» Thu Nov 25, 2010 5:15 pm

Nevermind.

» Thu Nov 25, 2010 4:47 pm

Hi - still stuck on this one. Changed the code to :

IF isFormValid tomeAppr == 0	printc "stoooooooooooops"    ; still never saw this	stopquest UDUNcTQUESTELSEiF tomeAppr.HasBeenPickedUp	printc "HasBeenPickedUp == 1 !"ENDIF

HasBeenPickedUp returns 1 as expected (when I pick up or put the book to a container) but when I save quit and reload returns 0 (I never see "HasBeenPickedUp == 1 !", while I do see other printc's messages from my quest script). Is this the way it's supposed to be ?

This is expected behavior - in that it's what I'd expect based on the game code, but not in that it's what you'd naturally expect.
When you activate a reference in the gameworld to pick it up the reference remains in the gameworld, but is disabled and marked for deletion from the savegame (unless it is a dynamic ref with mod index 0xFF, in which case it is deleted immediately).
When you save, quit, and reload, what happens depends on the persistence of the reference:
-if non-persistent, the reference no longer exists (isFormValid returns false).
-if persistent, the reference still exists (isFormValid returns true) and is no longer marked for deletion (hasBeenPickedUp returns false).

My suggestion:

short tomeWasPickedUpif tomeWasPickedUp  printC "you picked up the tome at some point."elseif tomeAppr.hasBeenPickedUp  set tomeWasPickedUp to 1  printC "you just picked up the tome"endif

Alternatively, you might include the variable and logic in a script attached directly to the tome - but I have not checked to confirm that scripts continue executing on persistent refs after they are picked up by an actor.

» Thu Nov 25, 2010 5:09 pm

Scruggsy, what's your take on exposing the ScriptEventList to scripts without valid parent refs. ?

» Fri Nov 26, 2010 12:11 am

Scruggsy, what's your take on exposing the ScriptEventList to scripts without valid parent refs. ?

Dunno. Elaborate.

» Thu Nov 25, 2010 6:32 pm

This is expected behavior - in that it's what I'd expect based on the game code, but not in that it's what you'd naturally expect.
When you activate a reference in the gameworld to pick it up the reference remains in the gameworld, but is disabled and marked for deletion from the savegame (unless it is a dynamic ref with mod index 0xFF, in which case it is deleted immediately).
When you save, quit, and reload, what happens depends on the persistence of the reference:
-if non-persistent, the reference no longer exists (isFormValid returns false).
-if persistent, the reference still exists (isFormValid returns true) and is no longer marked for deletion (hasBeenPickedUp returns false).

Thanks indeed- I will add this info to the wiki article. Problem is that when I use removeallitems on the container isFormValid still returns true (persistent ref, don't know on non persistent). Save quit reload (still true) - used player.moveto persRef and here I am in my test cell (where the ref was placed in my esp initially). Is there an isRemoved function ? Isdeleted I guess would act like isFormValid on persistent refs.
This is actually kind of a problem with isFormValid - "valid" is a bit of overstatement for a ref that got removed

My suggestion:

short tomeWasPickedUpif tomeWasPickedUp  printC "you picked up the tome at some point."elseif tomeAppr.hasBeenPickedUp  set tomeWasPickedUp to 1  printC "you just picked up the tome"endif

Alternatively, you might include the variable and logic in a script attached directly to the tome - but I have not checked to confirm that scripts continue executing on persistent refs after they are picked up by an actor.

Scripts on objects have some http://www.gamesas.com/index.php?/topic/1089574-script-processing-when-object-unloaded-the-script-runs-once/page__view__findpost__p__15885012 - quest scripts do (should) not run every frame. Anyway the code above should be modified to care for dropping the item again in the world. The difficult part though is to track the container.

» Thu Nov 25, 2010 10:36 pm

Just finishing up the basic reformatting for the OBSE home page (just have the function index to do, but that's being replaced with a table--and that's going to take a while). Just wondering if anything in the document changed in the last update other than the eight additional functions at the end of the New Features list. Was anything rewritten? I'd hate to lose any improvements that might have been made to the text, but it's hard to spot these sorts of things in a document this size.

I'll host the renovated file on my web site so people have a chance to check it out and report errors/omissions/requests/etc. Still have a few more things to do first, though.

» Thu Nov 25, 2010 5:09 pm

Dunno. Elaborate.

I guess I should stop mix-matching identifiers from the source meaninglessly just to sound cool. What LowPost suggested.

» Fri Nov 26, 2010 12:33 am

Here is the new page -> http://www.truancyfactory.com/obse_command_doc.html (?)

I still need to go through it with a fine-tooth comb for minor formatting/typos/organization/etc. Let me know if you spot any errors or if it doesn't work for you for some reason. I use Firefox, so it might not look as good on IE or another browser, but it should work just fine.

Note that I still haven't done the Function Index; that's next. Once I have that complete, I'll start transcribing some of this new info to the CS wiki.

Fun facts:

- the original document is 12855 lines of text; the new one is 5462 (including the stylesheet). That's a lot of extra line breaks!
- the original document is 696954 bytes; the new one is 525485 (including the stylesheet). And that's after adding links to the cs wiki for every function! That's a lot of unnecessary formatting!
- macros were used to delete/replace much of the unnecessary/invalid formatting, but every line still had to be edited by hand. Excluding deleted line breaks, that's almost five and half-thousand lines of hand-editing.

» Fri Nov 26, 2010 1:33 am

That's really nice magician. It's going to make my constant use of that document a lot less painful.

» Fri Nov 26, 2010 1:47 am

That's really nice magician. It's going to make my constant use of that document a lot less painful.

QFT.

» Thu Nov 25, 2010 10:45 pm

Yes, it looks much better

I'll take the opportunity to ask for a couple of changes to the documentation:

1. Move some functions from the Deprecated Functions list back to the main documentation. I'm especially thinking of MessageBoxEx and sv_Construct that have very useful features that cannot be replaced by other means (at least not for MessageBoxEx)
2. Make clear which "Set..." functions that stick in the saved game after use. I know (have learned) that most do not and know a few that do, but I haven't seen this documented anywhere, and this is very important when using the functions. I know that this is some work, but maybe a doable solution is to have a clear statement that the altered values are NOT stored in the savegame unless the function description explicitely states so?

» Thu Nov 25, 2010 10:09 pm

So examining my OBSE log in order to report http://www.gamesas.com/index.php?/topic/1077019-relz-enhanced-economy/page__view__findpost__p__15891495.

I also see this section that concerns me:

Loading strings
WARNING: substantial numbers of string variables exist for the following files (may indicate savegame bloat):
Oblivion.esm (2574 strings)
QZ Easy Menus.esp (1842 strings)
kuerteeInventoryIsABackpack.esp (1254 strings)

I ran remove bloat and it has 27 Null Ref Objects - hardly seems drastic.

Is this something I should worry about. I've had those mods installed forever (especially the first one) and this is the first I've seen of this warning. I recently added refstuff plugin (for Duke's Double Nock mod)- could that be the cause? Just to be thorough here is the last obse.log from the last load (with no crash!!):

Spoiler

OBSE: initialize (version = 18.6 010201A0)
oblivion root = I:\Games\Oblivion\
plugin directory = I:\Games\Oblivion\Data\OBSE\Plugins\
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\ConScribe.dll
SetOpcodeBase 000025A0
RegisterCommand Scribe (25A0)
RegisterCommand RegisterLog (25A1)
RegisterCommand UnregisterLog (25A2)
RegisterCommand GetRegisteredLogNames (25A3)
RegisterCommand ReadFromLog (25A4)
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\ConScribe.dll (00000001 ConScribe 00000007) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\Elys_USV.dll
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\Elys_USV.dll (00000001 Elys_USV 0000005D) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\FastExit2.dll
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\FastExit2.dll (00000001 FastExit 00000002) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\OBSE_Elys_Uncapper.dll
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\OBSE_Elys_Uncapper.dll (00000001 OBSE_Elys_Uncapper 00000062) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\refstuff_plugin.dll
SetOpcodeBase 00002350
RegisterCommand DropNthItems (2350)
RegisterCommand GiveNthItems (2351)
RegisterCommand GetItemsCount (2352)
RegisterCommand GetNthItemsCount (2353)
RegisterCommand GetItemsChangedCount (2354)
RegisterCommand GetCount (2355)
RegisterCommand SetCount (2356)
RegisterCommand ModCount (2357)
RegisterCommand DestroyRef (2358)
RegisterCommand DestroyClonedForm (2359)
SetOpcodeBase 0000236E
RegisterCommand DumpItem (236E)
RegisterCommand DumpContainer (236F)
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\refstuff_plugin.dll (00000001 refstuff 00000002) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\sr_Oblivion_Stutter_Remover.dll
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\sr_Oblivion_Stutter_Remover.dll (00000001 sr_Oblivion_Stutter_Remover 00004100) loaded correctly
checking plugin I:\Games\Oblivion\Data\OBSE\Plugins\\weOCPS.dll
plugin I:\Games\Oblivion\Data\OBSE\Plugins\\weOCPS.dll (00000001 weOCPS 01328DD8) loaded correctly
patched
DoLoadGameHook: ---censored save game location--- by me.\Save 44 - John Patmos - Weye Manor - Private Quarters, Level 18, Playing Time 201.50.11.ess
loading from ---censored save game location--- by me.
Loading strings
WARNING: substantial numbers of string variables exist for the following files (may indicate savegame bloat):
Oblivion.esm (2574 strings)
QZ Easy Menus.esp (1842 strings)
kuerteeInventoryIsABackpack.esp (1254 strings)
Loading array variables
**
Dumping Array #168 **
Refs: 1 Owner 2C: Enhanced Economy.esp
[ 0.000000 ] : 20000.000000
[ 1.000000 ] : 100000.000000
[ 2.000000 ] : 0.000000
[ 3.000000 ] : Door (0001496F)
**
Dumping Array #172 **
Refs: 1 Owner 2C: Enhanced Economy.esp
[ 0.000000 ] : 100000.000000
[ 1.000000 ] : 100000.000000
[ 2.000000 ] : 0.000000
[ 3.000000 ] : Wooden Door (00024621)

[edit] interestingly that string warning did not show itself on the next time I loaded the game.

» Thu Nov 25, 2010 9:30 pm

So examining my OBSE log in order to report http://www.gamesas.com/index.php?/topic/1077019-relz-enhanced-economy/page__view__findpost__p__15891495.

I also see this section that concerns me:
I ran remove bloat and it has 27 Null Ref Objects - hardly seems drastic.

Is this something I should worry about. I've had those mods installed forever (especially the first one) and this is the first I've seen of this warning. I recently added refstuff plugin (for Duke's Double Nock mod)- could that be the cause?

I think the cause simply is that those mods (and Oblivion.esm) creates new strings now and then, and this slowly builds up. But I'm pretty sure that at least the two mods have some string leaks which potentially should be fixed. You get rid of any such string leaks by making a clean save without said mod.

The string leaks aren't harmful in themselves, but will probably slow down your game (at least save/load) if too large.

» Fri Nov 26, 2010 2:17 am

@ TheMagician

Beautiful !!

Content-wise the addition :

base = ref.getBaseObject	doSomething base

is very to the point. So indeed one has to always pass the rBaseObject to an rVar when passing in a base object (in vanilla scripts "formID" syntax is valid - is it valid in obse ? What about editorIDs ?) ?
Similarly I read that "most functions must be called on a reference variable rather than on a reference" somewhere in the forums - if this is indeed the case I think now is a nice opportunity to update the info - write something like rVariable.doSomething instead of ref.doSomething in the Function Calling Conventions section or in some particular functions syntax as necessary. The syntax for passing in a particular ref id should be explicitly mentioned (getIsID "00000191" is valid for instance, no ref variable required, while an editor id would also work (and probably also a syntax involving a variable). Is this syntax possible in obse ?)

:foodndrink: for obse and the new docs

» Thu Nov 25, 2010 5:23 pm

Psymon: Strange to see QZ Easy Menus.esp in that list, are you using the 'updated' version? If so then I'll need to look at what I did wrong. Assuming it's actually a problem with the mods and not some strange bug with string_vars not being destroyed correctly. :shrug:

[edit]More of a question to the OBSE team, how is it possible there are that many string_vars assigned to Oblivion.esm? Wouldn't that only happen if a vanilla script were to create the string itself? :unsure:[/edit]

-kyoma

» Thu Nov 25, 2010 5:11 pm

Thanks for the positive responses.

1. Move some functions from the Deprecated Functions list back to the main documentation. I'm especially thinking of MessageBoxEx and sv_Construct that have very useful features that cannot be replaced by other means (at least not for MessageBoxEx)

That's on the To Do list. I can reconstruct the data for MessageBoxEx and any other entries that have been made for the CS wiki, but sv_Construct and others don't have an entry there and I don't feel competent to reconstruct them.

Would people prefer to see these entries relocated to their original position in the document with clear markup indicating their deprecated status or have links from those sections to a general Deprecated section collecting all of the deprecated functions together? My vote is for a link to a separate section along the lines of: "This function has been deprecated. For function details, click here." or something along those lines. That way, the current entries won't be cluttered up with old data.

2. Make clear which "Set..." functions that stick in the saved game after use. I know (have learned) that most do not and know a few that do, but I haven't seen this documented anywhere, and this is very important when using the functions. I know that this is some work, but maybe a doable solution is to have a clear statement that the altered values are NOT stored in the savegame unless the function description explicitely states so?

I'd be happy to add this information if someone wants to provide me with a list and an appropriately generic statement regarding it. I'm still in kindergarten when it comes to actually scripting.

Content-wise the addition :

base = ref.getBaseObject	doSomething base

is very to the point. So indeed one has to always pass the rBaseObject to an rVar when passing in a base object (in vanilla scripts "formID" syntax is valid - is it valid in obse ? What about editorIDs ?) ?
Similarly I read that "most functions must be called on a reference variable rather than on a reference" somewhere in the forums - if this is indeed the case I think now is a nice opportunity to update the info - write something like rVariable.doSomething instead of ref.doSomething in the Function Calling Conventions section or in some particular functions syntax as necessary. The syntax for passing in a particular ref id should be explicitly mentioned (getIsID "00000191" is valid for instance, no ref variable required, while an editor id would also work (and probably also a syntax involving a variable). Is this syntax possible in obse ?)

The code snippet was taken directly from this thread. Thank Scruggsy for it. (I hope I haven't mangled it too much in the translation.) As far as your question goes, one of the pros will have to field the questions for me. I'm just a typesetter.

» Thu Nov 25, 2010 11:04 pm

That's on the To Do list. I can reconstruct the data for MessageBoxEx and any other entries that have been made for the CS wiki, but sv_Construct and others don't have an entry there and I don't feel competent to reconstruct them.

Would people prefer to see these entries relocated to their original position in the document with clear markup indicating their deprecated status or have links from those sections to a general Deprecated section collecting all of the deprecated functions together? My vote is for a link to a separate section along the lines of: "This function has been deprecated. For function details, click here." or something along those lines. That way, the current entries won't be cluttered up with old data.

For the two I mentioned, I would strongly prefer to have them relocated to their original position, as as far as I understand, labeling them deprecated was a mistake. I think they were labeled deprecated because newer functionality cowered them, but for those two, part of their functionality is unique and not covered by newer functionality.

Ex: MessageBoxEx was created in order to allow string_vars in message boxes, and with OBSE18, a string_var can be "converted" to string by using the "$". But MessageBoxEx has another, very important advantage compared to MessageBox - that it can be used to create varying number of buttons. I have messageboxes where the number of buttons is dependent on some variables, and for this MessageBox is no alternative to MessageBoxEx.

I'd be happy to add this information if someone wants to provide me with a list and an appropriately generic statement regarding it. I'm still in kindergarten when it comes to actually scripting.

I know a couple of OBSE functions that affects the savegame (and lots that don't), but only know about the ones I've used myself. So I guess I was kind of hoping that the OBSE team had a complete list. Writing with BIG letters that most functions don't affect savegames, but apply until you restart the game (even if you load an earlier save) would be a big help for those new to OBSE scripting though, even if the few exceptions isn't stated.

Currently, this info is there for a few functions, but nowhere near complete or consistent, which IMHO is a big trap for people new to OBSE scripting. As an example, Duke Patrick had no idea (until I told him) that of the changes he made to Bows, the gold value got stored, but not the name, damage or health.