I don't know if anyone else has looked into this yet, but I can confirm that this item from beta 2 has been fixed:


I did a test involving allocating lots of strings and then making a clean save to see if they go away (looking at .obse file size and string IDs returned by later sv_Construct calls). Strings allocated under v0017 persist even after a clean save; strings allocated under v0018b5 do not.

(I didn't even know this'd been fixed until I tested it out of curiosity and found the problem present in v0017 but not in v0018b5. I was about to write a detailed description of my findings, until I looked back to the beta 2 thread and saw that it was known and intentionally fixed. )

BTW, string IDs returned by sv_Construct seem to count by twos in v0018b5 for some reason.

I downloaded it, and will look at where in EE the error occured (thanks to scruggsy for the ScriptViewer which has helped me several times already).

Also thanks for the array updates. I'm an old C/C++ programmer so the * notation seems simpler to me.


Then onto some problems that I would appreciate help with:

There have been a few bug reports from users of Enhanced Economy that leads me to think that the errors used by EE has been messed up a bit, and I've started to suspect that the problem is related to your known issue about OBSE when loading a savegame. EE has a two-dimensional array, and just after savegame load (when GetGameLoaded returns true), I loop through the array and removes some of the entries. Is it possible that OBSE's issue could lead to problems with this?

Then I've got a bug report for Real Sleep Extended. The mod uses several arrays and one of them is an array of references to objects (bedrolls) that have been placed in the world using PlaceAtMe, but later been disabled. I thought PlaceAtMe'd objects would never be removed even after a disable, but one user reports a CTD when such an object is re-used (ref.MoveTo + ref.Enable), and the conscribe log shows that the reference is 0. This leads me to two questions:

1. Is it possible that such an object is cleaned out by Oblivion when its cell is reset, or is it a bug that one array entry of a reference suddenly is 0?
2. How is it best to check for it? I added what I thought was a fix, with the following code:

			let realBedroll := RSE.unusedBedrolls[i]			ar_Erase RSE.unusedBedrolls i			if realBedroll				realBedroll.moveTo player				DebugPrint "RSE:placed unused bedroll %i at index %.0f", realBedroll, i			else				let realBedroll := player.placeAtMe BedrollSideEntry, 1, 0, 0				DebugPrint "RSE:Added new bedroll %i and remove illegal unused at index %.0f", realBedroll, i			endif

But the code still ends up writing "RSE:placed unused bedroll 00000000 at index 0", thus indicating that "if realBedroll" is true even with realBedroll equal 0. I thought that was not possible, but I guess I can add a second test: "if IsFormValid realBedroll" too. Is this assumption correct?

I haven't encountered any problems.

I've had crash on exit using Streamline's fast quit, but I cannot confirm that I haven't had that before.

Here's hoping for another beta.

It is quite possible. If they're using beta 4, ask them to try it with beta 5. If the problem persists with beta 5 let me know and I'll take a look at the scripts.

From the looks of it the problem is you're trying to access a reference that isn't loaded in memory. PlaceAtMe refs aren't persistent, so while they persist in the savegame indefinitely they are only present in memory when their parent cell is loaded. The value in the array and in realBedRoll is the formID of a reference, and if you were to use it within the bedroll's parent cell you should see no problems; using outside of that cell will cause an error (unless the cell is still cached e.g. you recently visited it). DebugPrint prints the formID as 00000000 because it can't find the ref in memory; that doesn't reflect the actual value of the array element or ref variable.

IsFormValid will tell you if the ref is loaded in memory. However it won't solve the larger problem of potential savegame bloat. You may want to consider using a fixed set of persistent bedroll refs hand-placed in the editor, or using DeleteReference to get rid of dynamically placed bedrolls when they are no longer needed.

Thanks for the error logs.

I'll ask, but the problem seems to be so rare that it's not possible to say if it persists or not. I can start asking though.


That explains it. The person encountering the bug mentioned he was in Windfall, so it wouldn't surprise me if the bedroll had been last used in Tamriel. Thanks for the explanation, I really learned something

Yes, I guess I need to do one of the other two. I went the route of using 30 persistent map markers for the player-added map markers in Map Marker Overhaul, so doing something similar for the bedrolls would be quite easy. But using DeleteReference does seem even better. One additional question then: Will Disable, DeleteReference etc. work on a PlaceAtMe reference that isn't loaded? If not, the fixed number of persistent bedrolls is my only option.

No, it won't (like any other script command, it requres the calling object to be in memory).

Some more requests for v19, function(s) to get (maybe, maybe set) the various info of a worldspace (the X/Y dimensions aswell as the NW and SE Cells X/Y). Maybe all in one function which returns a stringmap-array.

This could be a request or something.

I most often quit Oblivion by using Pluggy's Halt feature. The problem is that doing so doesn't save changes made to Oblivion's .ini so in next playing session if I take screenshot it overwrites older pictures because the .ini counter wasn't changed.

Streamline has nice feature of re-initialising in game.

Could it be done with Oblivion's .ini?

Thanks. Just one more (almost) off-topic question (since you're so helpful). If I have persistent objects instead, will commands (Enable, Disable, MoveTo) work then, or need I check with IsFormValid valid first then too?

AAAAAAAAAGGGHHHHHHHH!!!!!!!!

I just found out that a large portion of my armor stand mod doesn't work because of this. My testing methods need work obviously, because I completely failed to catch this.

Sigh. Well, at least I think I can fix it.

I would suggest using Fast Exit 2 OBSE plugin for quitting, as it does just that - before halting it saves the ini. Furthermore, you quit Oblivion using the standard way (Esc, then quit), but with lighning fast result.

OBSE exposes Oblivion's saveINI console function for use in scripts, so yes.
You might want to take a look at FastExit as mentioned above.

"Persistent" means the object is always loaded in memory, so you can call commands on it from anywhere and IsFormValid is not necessary.

Its best to use one of the newer fast quit mods rather than streamline's option, for stability reasons as evidenced by your crash.

EDIT: posted this after reading your first post on this page and didn't scroll down enough to see the other answers.
fast exit2 is good

I would just mention that the Enhanced Economy errors found in Baphometal's log, was an error introduced in EE 2.1.3 and fixed in EE 2.1.4, and certainly not an OBSE problem.

The error was that I had three lines adding index 0, 1 and 2 of an array, and then had removed the one adding index 1 - thus adding an entry at index 2 of a 1-size array.

Does this just let you look at scripts or edit them too?

Would it be possible to catch the 73-bytes bug at compile time and throw an error message ?

Installed the beta 5 to test it and the game seems much smoother... placebo effect? Maybe OSR works better? : )

Placebo. Only change between betas 4 and 5 is the disabling of scripts when loading a savegame.

Only for viewing. It shows you the offset of each line of script text in the compiled bytecode, which is useful for debugging. (Errors reported by OBSE include the offset at which the error occurred).

Yes but it'd be a tricky hook. I don't want to introduce any new hooks at this point unless they're necessary to bring 0018 to a stable release.

If I have an array (e.g. StringMap) containing a reference to a function script, and I try to do

Call myArray["MyFunctionRef"]

I get an "invalid user function" compile error, followed by "cannot parse this line".
Of course, if I do

let myFunctionRef := myArray["MyFunctionRef"]Call myFunctionRef

that works, but I'm planning on doing this sort of thing a lot and would prefer to avoid creating all those extra local variables if possible.

Would it be feasible to support this syntax? (If not now then maybe in v0019, but if it'd be impractical then don't worry about it.)

Sorry if this has been mentioned already, but I ran into an odd CS bug. I got a "Invalid Begin/End block structure on line 33" with this script and OBSE v18b4

;--DO NOT MODIFY THIS SCRIPT!!!;  DOING SO WILL CAUSE CTDS AND STRANGE BEHAVIOR FOR USERS.;  If you need this script to do more, have a suggestion, or an alteration:;  contact the Cobl team at: [src="http://forums.bethsoft.com/index.php?/topic/1047306-beta-oblivion-script-extender-obse-0018/http://www.uesp.net/wiki/Tes4Mod:Cobl/Modding/Board"]http://www.uesp.net/wiki/Tes4Mod:Cobl/Modding/Board[/url];--VERSION HISTORY;  v1.63  Change eid.;  v1.60  First version. This dummy version will be overridden in MMM patch.scn cobPatchMMMQS;--Patches various MMM things. Mainly it replaces inventory items.;--Internalfloat fQuestDelayTimelong sleepMode ;--Will do quick return when in sleep modelong count long statelong converted;begin menuMode 1002;	set sleepMode to 0;	set fQuestDelayTime to 0.1;end;;begin gameMode;	if sleepMode;		return;	endif;;	;--Done;	set fQuestDelayTime 1;;end

Everything but the variables are commented out, and I could save it without OBSE. I didn't test much further than that, let me know if I need to.

everytime i download the Beta versions i have NO problems, and i always forget to come here and say that xD

Try an end at the end without comment and not a comment at the end, but before the end you need a begin. :hehe:

...which I don't think I have thanked you enough for. The EE error bug that was reported yesterday was just to look up using ScriptViewer and I immediately understood the error when I had the correct line. Finding and fixing the error took me about 2 minutes, but would probably have taken at least an hour without ScriptViewer.

If what Baphometal suggested doesn't work try adding a space after the last line or a whole new line with a space.