Is it possible, within an OBSE plugin, to pass a variable as an argument to a command retrieved from the command table interface? I've looked over the command argument list, with the ParamInfo's etc., and I can't see it. All I've got to work is to pass the plugin function arguments straight to the obse command with the PASS_COMMAND_ARGS macro.

The PASS_COMMAND_ARGS macro is merely a shorthand; you could hard-code the text of PASS_COMMAND_ARGS into your function and it would work equally well - which means you can also replace parts of it with your relevant arguments.

If you're asking how to extract the arguments for your use, see the various uses of ExtractArgs() and ExtractArgsix() (the latter may not be available for plugins; I can't recall).

Yeah, I understand all that. What I meant (as a simple example, not actually what I'm trying to do) is this:

Now, I was stuck, as I couldn't find any source code for the ExtractArgs function to give me some clues on how the actual argument data is, well, extracted. I had guessed that the actual argument must be somewhere in arg1, but as it was a void*, I couldn't work out what format that data was in.

But I have now found the code for ExtractArgsix, and consequently have been able to get this to work (at least for this simple example), though I would still like some advice from those who know better whether or not this is a safe thing to do, as it's a bit of a hack. From my reading of the code, arg1 is a pointer to the data for the whole calling script, and opcodeOffsetPtr indicates how far into the script data in arg1 lies the argument data for the current script function call. ExtractArgsix then retrieves the function arguments from the script data, taking into account different argument passing mechanisms, such as if the value is simply hardcoded, or is being passed by different variable types etc. The actual format for the argument data consists of 2 bytes for the number of arguments, and then for numeric arguments, 1 byte for the type of format that the number is being given as (hardcoded or variable type), then sizeof(double) or sizeof(UInt32) bytes for the actual argument value if its hardcoded (not a variable), depending on whether its a float or integer. I haven't looked at other argument types as yet, as I'm only interested in numbers at the moment (a cursory glance at passing strings suggested 2 bytes for length of string, followed by the string data in the given size, but I haven't tested it).

So what I did was create my own script data to pass in as arg1, containing the argument data that I want to pass in, and just leave the opcode offset at 0. Again, a bit of a hack, but it did work, at least for this example. Here's the code:

It works. The question is, as long as the data in fArgs is in the right format, is it safe?

But wouldn't it present problems if the function you are calling doesn't use ExtractArgsix?

Well my understanding is that the ExtractArgsix function simply extends the ExtractArgs functionality to cope with OBSE's additional data types. So for non-obse data types (all the vanilla ones), the data format would be the same regardless of which extract function is used. The obse ceil function only uses ExtractArgs, not ExtractArgsix, and as I said, it works, as its just passing a float, which is a standard data type. Of course, you could mess things up by trying to pass an obse extended data type to a function that isn't expecting it and only uses ExtractArgs, but that would be bad anyway and its not a problem with my method above.

The only reason I mentioned ExtractArgsix is that its the one I could find source code for so that I could work out the data format from it. It appears to me that ExtractArgs is just a function pointer to an address in the oblivion executable (I think...?) so there's no source code for it. But as I said, the underlying data format for vanilla data types should be the same for both.

Ah yes ofcourse, should've thought about it before I posted. Anyways, yes, ExtractArgs is just a function pointer, you'll find many of them in the OBSE source.

[edit]Which functions do you intend to call? [/edit]

At the moment getfirstref(incell)/getnextref.

The way things are set up now, it may be easiest to simply reproduce the behavior of the function yourself (e.g. get the TESObjectCELL*, and iterate through the references in it). You will need to be a little familiar with the class hierarchy, which will take some poking around. But if you're up to deciphering ExtractArgsix, I don't see why you couldn't decipher GetFirstRef/GetNextRef as well.

I certainly don't speak for the obse guys, but they usually redirect questions about obse plugins elsewhere (to keep this thread focused on scripting). Perhaps you could start another thread with this question?

If your args are limited to literal string/numeric, yes. Otherwise the script and event list will be needed (well, they will be expected to be non-null and crash when dereferenced) in order to access references and variables.

Yeah, this, particularly because the ref-walking cmds maintain state between calls under the assumption that only one script is using them at a time.
You can probably pretty much copy-paste the relevant code from Commands_MiscReference.cpp to your plugin and use it directly rather than invoke the cmd handlers.

It's gotten some upgrades along with Update3D since 0019's release. Still no support for first-person skeleton. Send me a PM with any issues you're currently having with it.

Weird. Thanks.

Thanks.

I can look into it. Right now Update3D just calls into game code to handle the model reloading. There are some reasons it works the way it does; in particular animations have to be reset because they may have been changed along with the model.

Sorry to distract the topic, but wondering if anyone monitoring this topic could apply there expertise and help Wrinkly with a problem here ....http://www.gamesas.com/index.php?/topic/1140299-relz-weather-all-natural-thread-30/page__view__findpost__p__16688005
Wrinkly put a call out for anyone with help just after that post

Hey, Scruggsy, just had another request for your http://home.comcast.net/~scruggsyW/obse/ScriptViewer.zip (in regards to the issue above). Can you post the link in the opening thread? I've reposted it here, so it should stay around for a bit.

And further to my last (following The Nice Ones answer in the same thread), would anyone be interested in a save game?, going cheap, get it while you can Edit: PM noticed, ess and obse save zipped in the post.

Thanks. Will look into it.


Sorry. Didn't realise. Will keep that in mind in future. I've got the answers I need for the time being.

Yeah, they would be. Designing a plugin function that attempts to use a script variable in a function call sounds like a very bad idea to me.

Another case of OBSE array problems has been http://www.gamesas.com/index.php?/topic/1138371-relz-enhanced-economy/page__view__findpost__p__16689731 in Enhanced Economy's thread. This one got error messages from EE, All Natural and Soulgem Magic at the same time.

Is there any way these state-keeping functions could be made reentrant, say by keeping state in an opaque pointer that is passed back to the caller (like how C libraries do it)? Assuming that only one script is calling a particular function at a time sounds like a trap for hard-to-reproduce bugs...

Thanks, saw that earlier.

Yes but I don't see a compelling reason to do so atm. They maintain state to make them more efficient than the GetNthXXX-style cmds, which have to walk a linked list up to the requested index each time they're called. The docs clearly state GetFirst/NextRef should only be used within loops for this reason, and also because the references within a cell can change from one frame to another. If users follow this guideline then there's no problem. I guess I can envision a situation where a scripter might do something like:

while (r := getNextRef) != 0  call someFuncloop

scn someFuncbegin function {}  getFirstRef  ...

which will break things when we get back to the main script's loop. If somebody has a reason to write code like that, let me know and I'll see about updating the cmds (they were written long before function scripts existed).

Just loaded my game up (first time since yesterday fault finding with AN and the Array problems) - Instant CTD as soon as the game loaded ....

OBSE log for this startup


I have had a very un-usually stable game for about 7 months prior to OBSE 19, (the only CTDs previously experienced from personal error updating complicated mods requiring steps for clean save routines - otherwise myself and three other user on the desktop can run around for hours with no problems).

A problem now presents itself - AN 1.1 requires OBSE 19, my saves are now dependant on OBSE 19.

The only solution would appear to be revert to OBSE 18, drop AN 1.1 and all users start a-fresh. Not ideal but this current problem is rather annoying even more so that it should not be happening at all, I noticed that it is increasingly becoming noted in other mods utilizing arrays ...

Hope you guys can resolve this problem, and hope the information I provide here will lend a hand or clue to the resolution of the problem.

Edit: After posting this gave loading the game another run, continue from last save, loading, CTD. OBSE log reads exactly the same as the previous one spoilered above - @ Scruggsy , just about to zip up this current ess and obse save and post link in the previous PM

Edit2: Uploaded

Is there anywhere we can get hold of OBSE 18 at the moment?

I need to revert. All my current saves are useless, a couple of steps back in time will load but eventually after ten minutes I CTD, so I believe my current setup is a lost cause.

Edit: Just remembered I have a backup on the usb hd - but still ... may be useful for others if the same situation develops.

http://obse.silverlock.org/download/archive/
I'll be looking into this as soon as i get my psu replaced. Apologies for the inconvenience.

No problem, OBSE has to advance and its a complicated affair that is bound to have the odd hiccup, I very much appreciate the work going into this because it enables such a wealth of function and ingenuity.

I was hoping to continue with the odd errors occurring and provide even more feedback/saves to help solve it ... but this situation has just become a show stopper because I cannot continue at this stage. So I am afraid I will have to revert not just for myself but also in supporting the setup I have for the family machine. Fingers crossed I can get away with not going back too far in their save history to a safe place to resume but I have my doubts. My youngest has had a few CTD's in the last couple of days which had me wondering - now I am positive, I now find the same errors have been occurring on the desktop as on my laptop - Just checked the most recent obse log. The situation is grim

Anyway, dropped AN 1.1, Better Benirus manor AN plugin un-installed, using streamline for its streamsight function again which AN took over with its new fog, obse 18 re-installed and now for the testing on each user account .... fingers crossed.

Edit: I have been lucky, only had to rewind one user by three saves (a manual save not overwritten by streamsaves and not too far back), and another by two saves (again lucky to find a manual save) - All accounts running okay (fingers crossed), cobl had a moan about the reversion to obse 0018 but I think they will all be stable from now, moved them all indoors and did a three day wait, console force clear weather etc. Did a reload of each after a further save and in each case after exit checked the obse.log - seems to be no problems.

Edit2: Even more fortunate, grabbed an old save of mine off the desktop and transferred to the laptop (same BAIN setup so no problems)

I've noticed version 19 contains a very serious bug that makes it totally unusable for me. Namely, as a few others have reported, it is causing stolen items to not stack properly in inventory, causing massive clutter and triggering another bug to occur (where the sheer amount of clutter causes non-stolen items to not show up). And I know it's version 19 OBSE that's causing this because as soon as I went back to 18, the bug was gone and everything was stacking correctly again. This is no good at all.

Ok, that makes sense. I had been more concerned about scripts from two mods interleaving calls, even when used according to guidelines, but I had forgotten the critical point that Oblivion runs all scripts in a single thread : )

Inventory/stolen flag breakage bad.

Yes, it is.
Here is a fix: http://obse.silverlock.org/download/obse_0019a.zip
Fix for the array issue in progress.