Which is most likely due to the vanilla function SetItemValue.

Nope, he used the OBSE function SetGoldValue - but I guess the reason is that the implementation of SetGoldValue calls the same internal functions as SetItemValue.

Some OBSE functions can operate on a variety of object types but the parameter types Oblivion's scripting system allows are somewhat restrictive. There is no generic "object" parameter type so functions like SetName, which can take any named object, are defined as taking an inventory object. The upshot of this is that you can pass an inventory object to that function directly, but will get a compiler error trying to pass in some other type of object (like an actor) unless it's stored in a ref variable. The vast majority of affected commands use Inventory Object because it's the closest OB has to a "generic object" param type.

I can't think of any situation where the calling ref would be required to be in a reference variable.

Scripts should use editorIDs, not integer formIDs. FormIDs are of use in the console; any OBSE command that works from the console will accept them.

Either (1) a mod edits a vanilla script directly, adding string variable functionality to it, or (2) the OP used the 0018 beta which briefly broke the string ownership system.
The warning was introduced with this release because we had a handful of mods during beta which leaked string var's massively. It's just that - a warning - and doesn't necessarily mean there's actual leakage (it's conceivable a mod really does need > 100 string variables). Basically if someone complains about excessive load times, we can quickly check their obse.log to determine what mod(s) might be contributing to the problem.

@TheMagician: Looks good. I agree with TheNiceOne's suggestion about sv_Construct and MessageBoxEx. I can try to find some time to compile a list of commands which make persistent changes to objects.

Yes, that's what I ment.

As long as this is clear in the function's description (as is in SetName's desrcription) all is clear. Maybe the Function Calling Conventions section should then make clear that :

base = ref.getBaseObjectdoSomething base

is there for those that do not get the difference between a base record and a generic record (reference) - and not because one has to actually serve the base record wrapped in an rVar. If one must use an rVar then the function description must say so (as in SetName) - and if the compiler says so too, :celebrate:

An urban legend then
EDIT : there are some functions that require a refVar (as opposed to an editorID which some (99.9%) persistent references have) - but this seems clear from the docs

        (valid:bool) IsFormValid refVar:var

I know - just curious - the obse functions that can be used from the console do clearly state this in their description, don't they? Would be nice to have them listed someplace.
Thanks indeed for clarifying all this.
I still do wander if there is an isRemoved function (method) - and I believe the docs on isFormValid should be a little more anolytic.
Thanks again

I think I have found a bug that leads to savegame bloat of un-referenced arrays - or I have misunderstood how array cleanup works, which isn't too unlikely

Below are a few lines of a Function script:

let ar := GetTileChildren "map_background\map_contents_3_4_5\map_log_window\map_log_window_pane" 1023...ForEach ar <- qd[2] ...Loop

What happens is that the first array that ar refers to (the result of GetTileChildren) does not get destroyed, but gets added to the .obse co-save file for each time this function reaches the "ForEach" line. By adding a "let ar := ar_Null" between the two, the bloat goes away.

Is this intended behaviour, or is it something you need to look at? Is it maybe possible that an array_var that already refers to an array when it gets used on the left side of a ForEach, doesn't get its reference count reduced?

And yes, I use the latest version of OBSE.


OK, I see it now

Speaking of deprecated functions, isKeyPressed is another one that shouldn't be. To my knowledge, it is the only input function that catches mouse button presses before that game does.

Is it possible to get a SaveExists function to go along with LoadGameEx? The latter seems to display the "savegame is corrupt" message when the save does not exists. I tried using FileExists but that only works for the Oblivion install folder, not the My Games\Oblivion folder

Adding MessageEx to the list, because it's required for http://www.obse.silverlock.org/obse_command_doc.html#SetMessageSound.
Or is this just an Error in Documentation and a normal Message will be "Iconed" and play a sound?

Is the page working for everyone? Any suggestions for improvements (other than the ones put forward already re: deprecated functions and functions that make persistent changes)? Would people like the document broken up over several pages or left as it is? How about the navigation? Would people like 'TOC' links every so often for returning to the table of contents at the top?

The consensus appears to be that some of the deprecated functions are still useful, so perhaps the descriptions should provide examples of where they might still be required and areas where they are, in fact, deprecated and should be avoided. In other words, which particular usage is deprecated and which is still allowed. Any functions which are totally deprecated can then be moved to the Deprecated section at the end of the document to prevent them from cluttering up the rest of the document and functions which are only partially deprecated can have deprecation status applied only to specific usage which can be appropriately marked up.

@Scruggsy: Whenever you have the list ready, just pass it along with the text you'd like to appear and I'll update the page. Also, if you want to reconstruct the listings for any deprecated functions you want added back in you can send those along, too. I don't feel competent to write these at this point. If you are happy with the document, of course, you can always just copy the page on truancyfactory and update it directly for silverlock. You'll need a copy of the stylesheet, though.

Edit: Dibs on the claim for making the first web site mod!

My vote : left as it is (and no images, external sheets etc so it saves as a single file). Very handy for checking multiple functions and having it open in one tab. Actually broken up = broken, lol. No toc links, one can always press Home. The more minimal the better.

Good point about the external style sheet. That can be incorporated into the main document header. Thanks for the feedback.

I've encountered a CTD problem when running OBSE 0018.

The problem occurs with the script in MannimarcoRevisited.esp from Mannimarco Revisited that fires when you take the robe off of Mannimarco's body (I believe the script is aMiltKOWRobesAbilityScript). The script causes an animation sequence in which the body rises from the ground and then dissolves.
(Edit: note this mod does not require OBSE).

When running OBSE 18 I consistently get a CTD at the point where the purple smoke appears and the body dissolves.

After trying various things, I first tried running the normal Oblivion.exe rather than the OBSE wrapper/launcher and loaded a save right before taking the robe. I get a warning from COBL about OBSE not running (expected), then take the robe and the animation sequence finishes normally without a CTD.

Next I tried reverting to OBSE 17. I got a warning from COBL about reverting to an older version of OBSE (expected), then take the robe and the animation sequence finishes normally without a CTD.

So it appears this problem is a specific conflict resulting when running OBSE 18.

At the moment I'm just doing various testing with my mod list so this was just a test scenario/game I was running so I don't mind further breaking things if you need me to try something else.

So, what's up with this silliness? http://www.tesnexus.com/downloads/file.php?id=31437

edit: All gone now.

Nevermind. An upload of the 18/6 beta that someone was literally recommending over the final, stable 18 has been removed from TES Nexus.

See what happens when you disable every other mod, but still launch with OBSE 0018.

OK, so I disabled everything except Oblivion.esm and MannimarcoRevisited.esp then started a new game and used console to go to that location and kill Mannimarco, then took the robe.. Behavior with OBSE 0018 is the same, i.e. it CTDs when that script runs every time. With 0017 it's fine.

Hey scruggy, I recall you making a small OBSE plugin that removed certain ingame messages. I can't seem to find it on TESNexus or anywhere else, is my memory failing me or am I just missing it? Ofcourse if someone else knows what I'm talking about then they can anwser too.

P.S. Would it be possible to disable the equip/unequip messages for hotkey items? Or was that also part of the formentioned plugin? :unsure:

-kyoma

Expanded hotkeys and spell delete (my all times favourite "meta-mod") - had an Expanded hotkeys brief equip message.esp bundled with it.
:shrug:

SpamMustDie, 'twas called. It nops out the individual calls to the QueueUIMessage (or patches a few conditional jumps, can't remember) function in the Add/Equip commands (and their alternatives). Assuming hot-key equipping goes through the same channels, it should be handled too.

Add sv_construct to non deprecated functions - any other way to do :

		let svVar := sv_construct "%z" svText

cause let svVar := svText would make both vars point to the same string, no ?

Got a download link somewhere?

Using

let svVar := $svText

should also result in two different strings.


Anyway, sv_Construct is the easiest way to get the string-version of a number with a specific format, e.g.:

let sv_var := ( sv_Construct "%.04f", fNumber )

Does this crash happen 100% of the time for you? I tried 30 or so times, and only managed to get it to crash once, somewhere inside NetImmerse. At that point I was running fullscreen, with the 0018 release dll. I also tried a locally compiled copy in both windowed and fullscreen modes, plus a few tries without OBSE. Since the crash happened on the second time I guessed it would keep happening, so I didn't look in to it in detail when I had the chance, unfortunately.

edit: the crash occurred right as the body disappeared, fwiw

The "MannimarcoRevisited.esp" (the esp with chargen bug fix) has a script error - script: aaMannimarcoFixScript too much "endif"
Don't know if this is the reason for the ctd.