Requests have been added to the todo list.
Yet another issue with the stringVar API. My command doesn't support the
%z format specifier even after registering the interface. Reg. code :
g_stringvar = (OBSEStringVarInterface*)obse->QueryInterface(kInterface_StringVar); g_stringvar->Register(g_stringvar);
The new command is basically a copy of PrintToConsole.
PS : What's the
result pointer used for ?
result is used to store the command's return value.
*result = someFloatValue; // return a numeric value*((UInt32*)result) = someObject->refID; // return a form
AssignToStringVar() stores a stringID in
result for you.
Please PM me with full code for your Cmd_Execute handler, CommandInfo, and ParamInfo.
(I know the documentation says "function scripts should never be attached to any object", but these are dummy objects whose only purpose is to point to a script, not game-world objects that the player will interact with.)
The documentation is serious when it says this, and ...
I put a persistent object with a function script into a cell (as mentioned in my previous post) and it seems to run once when the game is loaded, even though nothing has called it yet. I get a "SetFunctionValue statement failed" message on the console, presumably because there's no caller to receive the return value.
...that is why you get the above error.
Have your clients pass the function scripts directly rather than attaching them to objects. A ref variable containing a script basically *is* a function pointer.
"Could not parse function definition."
I've been fighting one of these for a couple of hours. Some info on the scenario:
Error in script 1500ba9bCould not parse function definition.Error in script 1500bd59Could not parse function info for function script 1500ba9b File: QQuix ------ [wip] Anvil Red Light District.esp Offset: 0x000004C7 Command: Call (0x1883)
Script 1500bd59 has the calling line:"Call zzInitRooms"
Script 1500ba9b has been stripped down to this:
scn zzInitRoomsarray_var arrbegin Function { } let arr := ar_construct stringmap let arr [zrefDoorPackage] := aaaaqqxxGotoRoom00Doorend
aaaaqqxxGotoRoom00Door is a Travel AI package that is broken because the target ref has been deleted.
Missing a target, it defaulted to "Near editor location"
I changed it to "Near current location location" - no change - same error
I set it to a specific reference and the runtime error vanished!!!
Changed it back to "Near editor location" and, of course, everything is fine. I suppose I somehow fixed the package.
Weird. Even if the AI package was broken, the script is not trying to run it. Just assigning the ref to an array element.
Hope it helps.
Sounds like the bad package reference was contaminating the script data/preventing the script from loading correctly.
CalcLeveledItemNR doesn't seem to be working in OBSE expressions:
Thanks, fixed.
Hi, I had a few questions.

- Array FormMaps, now I know it has been mentioned alot before and I won't repeat any arguments. All I'd like to know is if they'll be in v19 or not (aka, what the final verdict on them is).
- In the past, only the latest version of OBSE is available for download. Since v18 changes the the way a script is compiled it automatically requires v18 or higher. Now for OBSE scripts this shouldn't matter, a user should always be using the latest OBSE. But for non-OBSE mods or dual mods it quickly becomes a problem. Yes, I can just load the cs without OBSE but that is a bit of a hassle when I'm working on two scripts at once, one is OBSE-powered and the other isn't. For dual scripts (where the OBSE code is in the same script as the normal code) this won't work. So the only way around this right is installing v17 again whenever I need to change that particular script. Then change it back to v18 again. So it's probably a good idea to keep v17b up for grabs.
- To add to #2, is it possible (in theory) to add a flag or switch or whatever it's called to the command line that forces OBSE to use the older bytecode stuff in the cs?
-kyoma
There is no final verdict. Can't make any promises about 0019 yet.
I'll have to look at the differences between bytecode representations between the current and previous versions to see how much of a problem this is.