The error message it threw up before was pretty loony. For some reason, the error handler seemed to think that the <- / ForEach operator / function was getOBSEVersion. And then, out of the blue, it fixed itself.

From my OBSE Steam loader log:

clearing large-address-aware flagrecorrecting exe checksum (00793BFD -> 00793BDD)crc = A2408F04dll = c:\program files (x86)\steam\steamapps\common\oblivion\obse_1_2_416.dll

Does "clearing" mean that OBSE is undoing the work of the utility that added the large address aware flag? When I decided to try the address space hack, I wondered if OBSE was going to like it or not.

gothemasticator

The CRC is calculated as if the large-address-aware flag were disabled, that's all the line means. When running Oblivion the flag is still enabled.

This makes a major (but not necessarily bad) change. I'm writing it here because I don't remember all the particulars and in case anyone uses the trick (or any variation) that this shortcircuits.

As stated above, scripts run during the Load/Waiting menu, even if the game is just being loaded from a save. That is, if you have a script

scn aaaTestScriptlong  Workingbegin GameMode	if Working != -1		if Working == 1			message "Working"			printc "Working"		else			message "Not Working"			printc "Not Working"		endif		set Working to -1	endifendbegin MenuMode	if Working == 0 || Working == 1		set Working to 1	endifend

With Beta 4, you'll see "Working". With Beta 5, you won't see anything at all. If the script was running in GameMode block, then Working would be 0 and you'd see "Not Working".

It's really late (and has taken a while to write), so I'll give one specific example I think this would affect. My old Inventory Tracker mod would keep linked lists of every item you picked up. To do this, I stored references to each item on rings on a remote NPC. When I needed to look through these lists, I'd have to set a variable on the NPC to get his script running and all item scripts that he was carrying. Then I'd unequip the first ring, which would give me a piece of the list (could only store 50 or so references on each ring). It would unequip the next ring to give me another piece of the list, and this would continue for all rings. This process would occur over several frames (5-20). Thing is, the player could save (say, using Streamline's AutoSave feature) during any one of those frames. When the player re-loaded the game, Oblivion would seem to "forget" which script was running when I saved the game, and thus the process would be interrupted. I don't remember exactly how I fixed it (and really need to sleep), but I believe what was happening was - Oblivion kept a list of which scripts should be running when the game was reloaded, however it started them in MenuMode, they didn't do anything in MenuMode and so never kept going.

As a note, I really believe that this helps more than hinders. The vanilla is truly unexpected behavior that's probably tripped up a number of people (including myself), and should never have been allowed into the final version of Oblivion.

I got a question, when I compile a script with a new OBSE expression (and thus use the different byte-storage or however it's called) and then remove it again and recompile, will it still work without OBSE or will the script continue to require OBSE v18 even though it no longer uses its advanced expressions? :unsure:

Thanks for the detailed anolysis. The real question for us is whether we'll break existing mods with this change. Additionally, we could potentially break non-OBSE mods with this behavioral change. It would move us to being a suspect of problems, even with no OBSE-mods loaded. I agree that this isn't proper behavior and things probably shouldn't work this way - but for the past few years this is the reality of how it does work. We'll have to figure out if this is the right change to make.

I believe that we could probably hook in a different place to fix our array/string loading issues - but that would leave the token script crashes active. But that might be a better solution. I am not sure. It is a tough call.


Every time you compile a script it produces completely new output. Removing all OBSE-based functionality of a script will let it compile and be used without OBSE. So if you remove the expressions, the script will no longer require OBSE v18. This is true both for scripts which no longer use any OBSE functions, or for scripts which use earlier OBSE functions (say v10) which will still require OBSE, but not v18.

Cool, thanks. All I needed to know.

Quick request for in the future, a function that returns an array with all the (potential) combat targets of the actor. Based on their priority. Atleast, I assume there is such an internal list that Oblivion uses to determine which target an actor picks.

I've been aware of this 'feature' for a while, and though I've never had a use for it, it's always been something I was aware of as possibly something I could use. As such, I tend to side with the thought that it should not be changed...

Just for the record, Strategy Master replied my post above on the Supreme Magicka thread.

Why make the call yourselves? Either make it a commandline switch (default to compatible behavior) or, if possible, a plug-in.

That is a possible approach - but the problem is that without additional changes, anyone using mods with arrays and strings and tokens (say any of your mods) will need the new behavior or have problems. I'm not convinced that we don't need to fix that problem without this change. Then we could potentially apply the fix just for the token crash. But it would still mean more work for us now.

That's actually what I meant to imply... find another fix for the main issue, and provide the token fix as an option. Work, work, work.

Function request, a IsInteriorCell (or IsixteriorCell or GetCellType). Current methode I'm using is scanning for a ref in the cell and then using IsInInterior. Would be nice to have a function for it in the future.

Hello, quick question: how do I find out if a string variable contains an empty string?

Use http://obse.silverlock.org/obse_command_doc.html#sv_Length.

Thank you. Strange thing: an empty string seems to have a length of 1. I can use it anyway, though.


EDIT:

I can't get sv_Compare to work. This is the script:

let compare1 := "Hello"let compare2 := compare1let comparison := (sv_Compare compare1 compare2)Print "Compare1: " + compare1Print "Compare2: " + compare2Print "comparison: " + (ToString comparison)

This is the in-game result:

Compare1: HelloComapre2: Hellocomparison: -1

According to the docs, sv_Compare should have returned 0, right? I am using OBSE v0018 beta 4.

Thanks for the update, been way back at 1.6

sv_Compare takes a string and a variable - i.e., sv_Compare "Hello" Compare1. Would be cool if it can be changed (but that might be feasible).

Is breaking existing mods really a good solution? I can't even imagine how much trouble that would cause
I hope you guys are able to find some sort of compromise, this sure has been a long beta

Thanks, sv_Compare "%z" compare1 compare2 works!

Of course, breaking existing mods is not a good solution. But the question is if there exists even a single mod that will be broken by that fix.

Anyway, keep up the work. I look forward to 18 going final, especially as my three main mods all depend on it now

Wow so you guys don't even know, I can see where the problem would be then Sounds like a big mess

I don't know much about it - but I think haama and the OBSE team know quite a lot. If I understood it correctly, they know what the possible solution mean, and it has a side effect that theoretically could break mods, but only mods that depend on a very, very special situation, and they're not even sure a single such mod exists.


Anyway, I have a question: When testing Enhanced Economy, I got a surprising error in my mod, which was cause by using ForEach on an array that was not initialized. But the mod check at GetGameLoaded whether the array is initialized using "if eval (myarray)". This condition returned true, even though "ar_Dump myarray" reported that the array wasn't initialized and "ar_size myarray" returned -1.

So I thought "eval (myarray)" was the best way to check for an uninitialized array, but it seems not to be the case. So is checking if ar_size returning -1 the best way to check?

That would be it, and, actually, I think the OBSE team is discussing ways around the problem (i.e., load the OBSE data at a different point, start up the scripts that were "supposed" to start at GameMode instead of MenuMode).

Maybe use if myarray instead of if eval myarray - the if statement tests for myarray as a simple integer (and I'm pretty sure it's working for me). Eval may try to do something completely different (probably expects an index and is a bit confused).

I am cruuently working on some customized meshes and textures for a mod I am working on to be a alternative to the horse armor DLC I calling http://www.gamesas.com/bgsforums/index.php?showtopic=1042704&hl=.
I amthinking of using this to make the horse armor to affect the original horses instead of replacing them and is wonderring how is the best way to do this to keep checks in place to remove the added meshes if they eve want to remove the mod