This likely comes from OGE. Looking at the source SEOD and SEOF terminator records are saved as 1-byte, but not read as such. This is harmless, as OBSE code seeks at the correct position after each chunk.

Whoops. Yes it looks like you are right. I'll fi it in my next release. (Just because the API is robust enough that it lets me get away with doing something stupid it doesn't mean that I should do it).

Ok. I'll start plugging away at this, but it's going to take time. I'd like to finish the home page reformat first, since it won't take nearly as long to complete and can start being used as a resource sooner. I probably won't be including examples or notes (other than the notes included on the home page, that is). It will probably be easier and faster for you to add them yourself since I'm not 100% sure how all of these functions work and I don't want to mislead anyone. I'm just a scribe.

Incidentally, what happens if I create a page and someone creates the same page before I pass the document along to you? Will it overwrite the existing page or be ignored?

Absolutely agreed on all of the above. Even, I think, mentioned about the notes and stuff. Definitely do the OBSE page first, and definitely don't worry about including any new information - just transcribing it to Wiki format would be huge.


The bot can be directed on what it should do in that case; presumably we'd want to ignore.

Yes, ignore, definitely.

I'll keep you up to date on my progress and probably ask a few more questions, otherwise, assume I'm working on this.

Thanks scruggsy, that did clear things up quite a bit (now if I can just make a time machine and have Cobl always require OBSE )

Excellent, thank you so much!

Bug report : adding a cloned item to an actor within some loop structures (while and forEach but not label/goto loops) seems to cause the game to freeze or crash.

here an example of some script that always causes my game to crash:

Scn aaaTesterItemref		actorref		clonearray_var	setBegin GameMode	if (actor)		ForEach set <- actor.GetItems 20 22			if (condisions)				let clone := (cloneform (set["value"]))			;	Do stuff with clone				actor.additemNS clone, 1			endif		loop	else		let actor := getContainer	endifEnd

Oddly enough, simply commenting out 'actor.additemNS clone, 1' will cause the script to function as expected.

Do:

let clone := set["value"]let clone := cloneform cloneactor.additemNS clone 1

The cloneform line as written should not compile; the parens induce it to compile anyway.

Question about the documentation:

If the documentation claims that a reference is required, but the script compiles without an explicit reference, is the reference actually required?

I noticed this discrepancy when I started compiling a condensed list of functions. One of the first functions I added was ModAV2. In the OBSE documentation, the reference is written in a normal monospace font, indicating the reference is required, but it obviously isn't. I assume this is an error, as scripts compile fine without it. I then noticed several other functions that had similar discrepancies between documentation and implementation. Can I always assume that if a function compiles fine in an object script without a reference that the reference is not required, or are there occasions in which a function may compile without a reference but fail when called? I'd like to know how best to go about correcting clerical errors like this in the documentation.

If you don't use an explicit Reference in an Object Script, the Reference which "holds" the Script is assumed as the Calling Actor (Magic Effect Scripts use the Target). Change the type to a Quest Script and the CS will complain if a Calling Actor is required, but not specified.
Quest Stage/Dialog Result Script should work, too.

^ this. If "ref" is in italics it indicates a calling reference (implicit or explicit) is optional (e.g. for most inventory item commands) and a base object can be supplied as an argument instead - but either one or the other must be supplied for the command to execute, and the base object argument always takes precedence if both are supplied.

er...what?

What is the default reference in a quest stage script?

The player?

Is the player and OR the "other" NPC (who ever the NPC is talking to) the default reference in a Dialog Result Script ?

As far as I know there is no default reference, that's why I think they should be an ideal "playground" for your tests.

This still causes the game to crash. Even cloning an apple and adding it to the player inside a loop causes my game to crash.

foreach set <- actor.getitems	let clone := cloneForm apple	actor.additem clone 1loop

Everything compiles, but the game just crashes when it runs the script. As I said, the same script seems to work if I replace the forEach loop with a label/goto style loop.

Scn aaaTesterWorksref		actorref		cloneshort		iarray_var	itemSetBegin GameMode	if (actor)		let itemSet := actor.GetItems 20 22		label		if eval (itemSet[i])			let i := i + 1			let clone := cloneForm apple			actor.additemNS clone 1			goto		endif	else		let actor := getContainer	endifEnd

Thank you. I understand how references work but for some reason I was misinterpreting the documentation. Since object scripts always run on references they don't need to be declared in the script. For some reason this is how my brain was interpreting 'optional'; as in: you don't have to explicitly type it into your script. These references are supplied implicitly, but obviously still required. Functions which operate on base objects don't require a reference, though one may be supplied in lieu of a base object. That means that functions supplied with base objects change the object for all instances, but functions supplied with a reference change only that single instance. Correct?

That clears things up for me. Thanks, guys.

Edit: Here's an updated version of the list -> http://i279.photobucket.com/albums/kk146/TheMagicianFromOblivion/obsefunctionlist.jpg (WIP)

As usual, suggestions, criticisms, and requests are appreciated.

Man, is my timing awesome or what?

On the other hand, sorry for copping out on the beta feedback, Scruggs.

@popcorn - IIRC, CloneForm only works on variables. See what happens if you instead use:

foreach set <- actor.getitems	let clone := apple	let clone := cloneForm clone	actor.additem clone 1loop

Yes.

The docs are getting better by the day :thumbsup:

Is there a debug...ring mod around? Maybe I am just imagining things, but I thought I have seen people recommending the user post their console out put with ConScribe and to also use a ring in conjunction. Most of the time these issues are related to mods that use OBSE, that is why I have posted here.

Would you be talking about the Console ring mod ?

I might be, but that is only for helping users who cannot use the tilde key to open the console, right? I just added ConScribe to http://sites.google.com/site/oblivionpoinfo/troubleshooting/troubleshootingmods. Thanks.

This is copied strait from the documentation

So yes cloneForm should work on base object passed directly to the function and not just variables.

And, no, writing the script like you suggested does not fix my crash. Although Im assuming you tested it before posting? Please tell me I'm not the only one having this problem

I can't duplicate the crash using the posted code or other variations.
Please post the full script.

Is there a limitation to the name of an object (length, content, size of which is stored in the save (if it's a clone))? Other than the global max string size (or should I say buffer).

Not sure if I read you right.
Rephrasing:

Functions that operate on references require a reference (explicit or implied).
Functions that operate on base objects will use the supplied objectID or, if one is not supplied, will use the base object of the reference (explicit or implied). But it will still operate on a base object, regardless of how the function is written.

Take Health, for example. The base object of a weapon has a Health and references may have, each, a different Health.
GetObjectHealth operates on base objects, therefore "GetObjectHealth WeapIronLongsword" will return 140 (the base Health). "IronSword01.GetObjectHealth" will also return 140, regardless of the current Health of IronSword01.
To get the Health of the reference, you need a function that operates on the reference: GetCurrentHealth.