You mean how you linked it statically ?

:o

...I blame C. Again.

Recently I found a possible bug with string_vars that leads to a small memory leak. I got a quest script in which I initialize svPrefix. Then I got a user function (which runs on the player) with this code

PrintC "UserFunc - Prefix [%g]", SRQuest.svPrefixset SRQuest.svPrefix to sv_Construct "%e"PrintC "UserFunc - Prefix [%g]", SRQuest.svPrefix

Each time the line runs svPrefix gets a new ID. But the old ID never gets sv_Destruct'd (cause I assumed svPrefix kept its ID). When I change the line to this the problem goes away.

let SRQuest.svPrefix := ""-or just-let SRQuest.svPrefix := sv_Construct "%e"

A problem with sv_Construct?? :unsure:

-kyoma

Just wondering, does anyone think it would be possible for OBSE to get the actor ref of what the NPC is "head tracking"?

I am working on a new spell-less version of my "Dead Bodies Alert The Actors" mod, and this would be extremely useful to limit when I trigger Cell walking for each NPC. Right now I am using GetAIProcedure to trigger the Cell Walking. But I have noticed sometimes the NPC head tracks a dead body as they walk by it but never set off ANY of the AI Procedures past 0 (0 is traveling). At this time just for the design phase of the mod I am testing for ALL OF THEM expect "travel".

And I started thinking of many other mods that I could also use that for as well.

I was just wondering if that kind of thing (getting the actor ref of what the NPC is "head tracking) is a pipe dream or is possible at all based on the OBSE teams experience with Oblivion's code.

Hey, so this is a total vanity request, but is there any chance of a GetGameSetting2 which doesn't spam the console log?

(Or is there a technique I don't know? Even better, that...)

That I don't remember - the memory is that either scruggsy or Ian tried and immediately picked up on some errors.

Wait, GetGameSetting spams the console? :huh:

If called from a MenuMode script, yes. Because the console is MenuMode, but doesn't have its own mode number. :banghead:

Edit: To clarify, the spam only happens when the console is actually open. Basically, if you've got a script which keeps an eye on a setting when a specific menu is open (which is actually better than just checking it once, because other mods on different fQuestDelayTimes might change it), AND you open the console WHILE in that menu, you get spammed.

Assuming you're fine with just pausing the script while the console is open you can just use IsConsoleOpen. Otherwise, well, there are a ton of vanilla functions that cause console spam. :shrug:

No, sv_Construct is working correctly: it constructs a new string and returns its ID, nothing more. It has no control over what the ID is used for, e.g. assignment or whatever.

When you use "let" to assign to a variable, the right-hand side of the assignment is evaluated as an OBSE expression. What that means, as far as I can tell, is that any strings created by the expression are flagged as temporary, to be destroyed automatically at the end of the frame. When you assign to a string_var with "let", it modifies the existing string. So in your "let" example, if svPrefix currently refers to string ID #1, sv_Construct will create string #2, "let" will copy the contents of string #2 into string #1, and then string #2 will be released automatically. Note that svPrefix still refers to string #1, but the content of that string has changed.

When you use "set" to assign a variable, on the other hand, it doesn't know anything about strings so it just assigns the numeric value. You end up storing the number 2 into svPrefix, replacing the number 1, resulting in string #1 being leaked.

(Note, I'm not 100% certain about the details of "let" assignment because it's been awhile since I did a bunch of testing of its behavior. It might actually allocate a new string and free the old one at the same time, rather than modifying the contents of the existing string; I'm not sure. But the point is that "let" knows that string_vars are more than just integers, and "set" does not.)

Didn't know about IsConsoleOpen, that'll do for me. (Now just gotta get other people to use it... and figure out whose mod is causing that spam...)

Meanwhile, documentation correction:

(hasEffect:bool) MagicItemHasEffect effect:chars actorValue:chars
should be
(hasEffect:bool) MagicItemHasEffect effect:chars magicItem:ref actorValue:chars

This also applies to MagicItemHasEffectCount, and the Code versions of each.

Dope, ofcourse. I was mixing things up with how array_vars work. :facepalm:

More, where the hell I found the .def/.lib/.h files necessary to do so. It's only officially distributed as a source, which I can't figure out how to compile myself, and the only download I can find for "Windows static versions" seems to be out of date and incomplete. Very frustrating.


I assume the shock and the fault for which C is being blamed is my not understanding something as important as lambdas? I get that they have some historical significance, and a quick read-through of the Wiki page seems to indicate that they're often the only (or best) way to perform operations on functions, but it seems that C++'s system of using pointers to functions for that task works just as well (again, according to that article), and therefore I don't see why C++ would have to add lambdas...

Why don't you use the precompiled Win32 DLL instead ? You can link it at runtime and reduce overhead. At any rate, http://dl.dropbox.com/u/2584752/zlibstat.lib - Compiled with the latest source (1.2.5/Apr 19 '10). You should be able to link it with either the pragma comment directive or through the project's property page (Linker > Input > Additional Depends).

Try the http://www.truancyfactory.com/obse_function_index.html. Let me know what you think.


Corrected. Thanks. If anyone else spots any errors, let me know via pm or a reply in the thread. I've corrected a couple other errors as well.

So how does MatchPotion work, exactly?

I've got a script which goes about like this:

if (dummyPotion == 0)	; Should only be true on first run	let dummyPotion := tejonArsDummyPotion		; Has no effects	let dummyPotion := CloneForm dummyPotionendif...CopyAllEffectItems thing dummyPotionCopyIconPath thing dummyPotionCopyModelPath thing dummyPotionCopyName thing dummyPotion...(some operations are performed on certain MGEFs in dummyPotion, if present)...let index := player.GetItemCount thingplayer.RemoveItemNS thing index	; Out with the oldlet thing := 0	; Just in case? Tried with and without thislet thing := MatchPotion dummyPotionif (thing == dummyPotion) || (thing == 0)	; Zero check just in case too	let thing := CloneForm dummyPotionendifplayer.AddItemNS thing index	; In with the new; re-empty dummyPotion for next time --let index := (GetMagicItemEffectCount dummyPotion)while (index > 0)	let index -= 1	RemoveNthEffectItem dummyPotion indexLoop...(price and weight of thing are adjusted)

Everything here works, except that I get a new CloneForm every time. (They don't stack, which makes it obvious.) These operations are always performed on a fresh player-made potion, which due to modified GMSTs is guaranteed to have a weight of 0; I moved the price/weight adjustment to the end specifically to verify that I'm not pulling that one back up with MatchPotion. I'm not, making the same potion again shows it still at 0 gold. Same results whether or not a potion had any effects altered.

OK, I'm a complete newb when it comes to linking. I don't know how it works, and honestly, thus far I've had exceedingly little desire to learn how it works. DLL means dynamically linked, which is how zlib was initially tied into the project, which means everyone had to download zlib separately, which is a pain. Niflib can fall under the same category. So I linked it statically, which as far as I understand it basically means everything I need from zlib and Niflib are included into my NifSE.dll. That seems fine to me - having people run around to get zlib.dll and Niflib.dll just doesn't seem worthwhile. We have enough trouble with people installing UV as it is, without making them download and install two more things...

Anyway, potentially stupid question - don't I need a .h file to go along with the .lib? Possibly also a .obj?

You don't need a header file to link, but you do need it to compile, regardless of whether you're using static or dynamic linking. Otherwise all your calls to zlib functions will fail to compile because the functions aren't declared.

An .obj file would work instead of a .lib, but if zlib consists of multiple source files, it'll produce multiple .obj files, and you'd need to link with all of them. The .lib just combines all the .obj files into a single file for convenience.

OK, all that makes sense. I suppose I can just use the zlib.h file that I downloaded, huh?

As long as it's binary-compatible with the header that your .lib was compiled from, which should be the case unless they're significantly different versions or something. (Certain changes in a header, such as changing the size of a struct by adding or removing members, cause code compiled against the new header to be incompatible with code compiled against the old header.)

@tejon I use a regular trick whenever I do cloneforms (which I do a fair bit in potions for example making fused/charged/prox trap potions). I just store an array of all the cloned potions I make, then scan though and check if a new one i'm about to make has already been made before, and if so I use that one. This gives me correct stacking.

HeX

I'm still getting unresolved externals... boo. I feel so dumb. Anyway, this conversation should probably happen in the NifSE thread, since we're not really talking about OBSE. If you have any thoughts on my unresolved externals, I'd appreciate advice - but it should probably go in the NifSE thread. Thanks!

I do that too with spells in a couple of mods, and if that's the final solution I've got a nice robust boilerplate for it (though to work with the entire gamut of possible player-made potions, it will need Significant Expansion™). Was just really hoping to make use of that nice compact function which appears to be intended for exactly this.

See the http://www.gamesas.com/index.php?/topic/1091139-relz-oblivion-script-extender-obse-0018/page__gopid__15917338&#entry15917338