nkAlex

I was checking random stuff, so the calling quest did contain only some of the variables. Even when randomly typing something like "if HasVariable "hguryw3kuh" rQuest" and "let fVal := GetVariable "jb435g3jk7" rQuest" it did return true and 0 in case rQuest was a null reference.

The reason I've noticed it was that I forgot to call rQuest initializing function first and then was trying to debug why did I always get zero instead of an actual value?

Hmm, I think I've found a bug. Running:

ref rQuestfloat fValif HasVariable "SomeVar" rQuest  let fVal := GetVariable "SomeVar" rQuest  DebugPrint "SomeVar = %.5f" fValendif

on a null reference (i.e. rQuest hasn't been initialized yet) will always return true for HasVariable.

Odessa, thanks, I think I'll try a few things...

The initial idea was that instead of constantly running a background script use recursive calls on actors (i.e. on act end they release themselves from locked state and fire a new act), but it looks like it may be not quite reliable.

Another thing — sometimes actors get stuck in InUse state forever even when the act doesn't fire, or sometimes on act end. May there be any particular reason to that? Is SexoutNGFinishNow for forcing them free? And for some reason the player gets stuck in that state more often than anyone else.

 

---------

EDIT

 

All right, I cheated. Right after calling fnSexoutActRunFull I cast on all participating actors a 4-seconds spell with a ScriptEffectFinish block which checks if an actor is in use by Sexout, and if not, it supposes the act has failed to start and forcibly kicks the actor out of action, releases him and places back on the queue. Works fine for now...

Me again, sorry

Just wondering, is there a way to know for sure whether a Sexout act has actually started or not. Everything seems to be fine with single acts, but when there are multiple in parallel or in sequence they sometimes just don't fire.
I was trying to implement a sort of a pool/queue of actors to be picked by a function which then fires fnSexoutActRunFull(...) on them. Basically the logic is this:

1. there is a "rotating" queue of actors for a function to pick from;
2. each picked actor is marked as "reserved" so that he can't be picked again;
3. each actor is checked for all the usual stuff, including fnSexoutActorValid and fnSexoutActorInuse;
4. if everyone is valid, Sexout is executed: fnSexoutActRunFull(Ar_Map "ActorA"::rActorA "ActorB"::rActorB ... "CBSpellA"::SpellA "CBSpellB"::SpellB);
5. if the act was executed successfully, spells SpellA and SpellB are being cast, which apart from other stuff release actors from the "reserved" state so that they can be picked again;
6. GoTo 1

Everything should work fine theoretically, but sometimes step 4 just doesn't run (especially if the same actors are being picked again), so the spells are not cast and the actors stay "reserved" forever, and the queue is never exhausted.

Is there some catch, or maybe some warmup — cooldown period between calls on the same actors?

On fnSexoutActRunFull execution are the actors being immediately marked as "in use", so that this check can be used instead of reserving them manually, or may it fail if run immediately after a Sexout call?

When you use:

 

Array["key"]

 

NVSE expects "key" to exists, I am surprised you don't get a runtime error in the console, you usually do.

 

You should use either:

 

if Ar_HasKey Array, "key"

 

or

 

if TestExpr Array["key"] ; sort of like Try/Catch

 

if you are unsure whether "key" exists.

Thanks for the tip on checking for keys, although what I meant was checking whether an array SomeQuest.SomeArray["key"] was initialized or not (the keys are auto created on Quest first run, but the enclosed array may be null under certain conditions). So the question was why eval doesn't work correctly for "SomeQuest.SomeArray["key"]" but works for "SomeArray2" when the second just references the first?

The arrays are supposed to exist and be filled with data at the point of execution (unless they're not, hence the check) and I've noticed this inconsistent behavior when a cleanup function never fired. But after introducing a "shortcut" variable everything started to work fine. I don't know, maybe eval just doesn't support the "long" syntax, but it's not mentioned anywhere...

In your first function, you pointlessly initialize the nested arrays, then overwrite them with Ar_List- which creates a new initialized array.

Hmm, I'm still not quite sure about the correct syntax on how to create an empty stringmap array with specific keys which should be filled with data later on. Which way will be the most correct?

let arrMapArray := Ar_Map "key1" "key2" ;will this even work?

let arrMapArray := Ar_Map "key1"::Ar_Null "key2"::Ar_Null

let arrMapArray := Ar_Map "key1"::(Ar_Construct "array") "key2"::(Ar_Construct "array")

Another unobvious issue.

Let's say I have a stringmap array:

scn SomeQuestScriptarray_var arrActorsArraybegin GameMode  let arrActorsArray := Ar_Map "refs"::(Ar_Construct "array") "values"::(Ar_Construct "array")  let arrActorsArray["refs"] := Ar_List PlayerRef SunnyRef ButchRef  let arrActorsArray["values"] := Ar_List 10 20 30end

And then I have to access it from some function. This:

scn SomeFnbegin Function {}  if eval (SomeQuest.arrActorsArray) ;Check 1    if eval (SomeQuest.arrActorsArray["refs"]) ;Check 2      ;do stuff    endif  endifend

will fail the second check (or maybe crash on it internally, I'm not sure, no errors are given).

And this:

scn SomeFnarray_var arrActorsbegin Function {}  if eval (SomeQuest.arrActorsArray) ;Check 1    let arrActors := SomeQuest.arrActorsArray["refs"]    if eval (arrActors) ;Check 2      ;do stuff    endif  endifend

will evaluate as expected (i.e. passes both checks).

Is it a bug or a supposed behavior? Because this, for example:

foreach arrEntry <- SomeQuest.arrActorsArray["refs"]

works just fine...

A.J., as far as I remember there was a note somewhere that formatting doesn't work on buttons for vanilla MessageBoxes. Well, whatever, it's just easier to switch to MessageEx and MessageBoxEx, which at least don't cause CTDs

 

pepertje, from a noticeable lag on opening a heavily populated container I'd say it evaluates its total value on every open. Can be easily done with a "foreach rItem <- rContainer" and maybe stored in some cache until the container is updated? If it's a custom made container you could probably assign some events to it, I'm not sure, speaking from a-sorta-programmer's point of view, the game most of the times has its own apprehension on how things should run, which is frustrating at least

Mmmh could it be because ShowMessage is a vanilla function while %n was added by the extender, so vanilla doesn't expect it? or you mean it's a matter with Let, because if you Set it works?

Let is OK, it only crashes on ShowMessage. According to http://geck.bethsoft.com/index.php?title=ShowMessageit should support all the formatting, I think...

I think I'm going to create a sort of an "orientation manager" (we were discussing it in another thread) which will work independently and should be compatible with any mods that use Sexout's, Lust's or SOI's systems, but may take some time, I still need to do my actual job and everything

Another weird thing.

If I create a message in GECK, for example, MyMessage: "%n doesn't like you", and then try to bring it up with a script:

ref rActorlet rActor := SunnyRefShowMessage MyMessage rActor

leads to an instant crash to desktop.

I know I can use MessageEx instead, just wanted to know if this is a bug or a feature.

I've added new a UDF, 'fnSexoutGetOrientationSt' to '95 beta 1, a counterpart to 'SetOrientationSt'.

 

Also, when you use SetOrientation on an actor, it also sets an 'orientation:init' NX var, so '0' no longer counts undefined as well as 'bisexual'.

 

If you call GetOrientationSt on an NPC with nothing defined, it returns the MCM default option for their gender.

Great! And I can still use "Sexout:Orientation" and "Sexout:Orientation:Init" directly, right? Just for the reasons of not being hardlinked to Sexout functions on that matter but retaining compability.

Scanner sounds cool, consider using the new 'fnSexoutGetLocalActors' UDF in '95, which caches the scanner result for performance and saves you having to validate actors.

Sounds cool, I think I'll get to it... unless I have to do my actual job or something

Odessa, thanks for the explanation!

 

So, from what I see, Sexout doesn't actually change any NPC's orientations, it just adds default values to PlayerRef and processes NPCs from the lists if there were any. And actual setting is supposed to be done externally by mods, am I right?

 

 

except 0 is also undefined, so you can't tell if it was actually set or not. This is something I will fix in '95.

I was thinking about implementing a sort of a low priority scanner which will scan player's surroundings in background and if it finds an NPC with unset orientation it will pick some value randomly with a bias based on SO MCM setting. So, maybe add some NX var like "Sexout:Orientation:Set" = 1/0 alongside "Sexout:Orientation"?

You found a bug in NVSE. Guess I forgot to check string_var when I tested it before. I'll let jaam know.

 

There are two workarounds you can use:

 

set my_string_var to GetModLocalData "whatever key" ; # use set instead of let.

 

let My_Array := GetAllModLocalData

let my_str := My_Array["whatever key"]

Oh, OK, good to know. I've spent about 20 minutes randomly changing stuff trying to figure out where I'm stupid. Thanks!

Btw, are you checking up on "The Sexoutng Api" thread? I've had a question there regarding some of the Sexout internals (managing NPSs orientations), an answer from the developer's point of view would be really appreciated

All right, a little bit of frustration... again

 

This:

SetModLocalData "MyMod:Version" 1int iMyModVersionlet iMyModVersion := GetModLocalData "MyMod:Version"

Works fine.

This:

SetModLocalData "MyMod:Name" "Some Name"string_var strMyModNamelet strMyModName := GetModLocalData "MyMod:Name"

Gives an in-game error on let.

What am I doing wrong?

I think it appears to be 0.0 always because that's what you have it set to in MCM?

Nah, I moved the slider here and there... A bug maybe?

 

 

An orientation manager would be tits!

Ok, I already have some specific ideas on its features and methods of realization anyway

Although I'm currently stuck inside UnethicalDeeds.esm. Wanted to fix a couple of bugs and ended up completely reworking some of its insides %) Wanted to add this manager there 

I'm not sure if Lust is where you want to look though.  You might want to look at Spunk because it is now at the heart of Lust.

As far as I could figure out, Spunk doesn't use any predefined orientation lists since it doesn't push any NPCs into action directly. Lust, on the other hand, does.

 

I thought that SexoutNG added them to a list, or maybe SCR did?  Frankly I haven't used the SexoutNG NPC orientation settings for many many iterations (over 2 years).  We had a long discussion about coordinating things in a thread somewhere.  In that thread we came to several conclusions, some of which was implemented, other things I think we forgot about.

 

So the bottom line I think is it's really up to you.  You can't ultimately be responsible for every other mods settings if they don't build cooperation into their mods.  I think the agreed upon methods are generally a few NX settings and some lists in SCR.

 

Someone feel free to expand or correct me where I'm wrong.

Well, that's kinda the whole point. I was hoping that someone from Sexout developers team could give a specific answer since it's not documented anywhere, and there is a ton of scripts in Sexout.esm, some of which are supposedly legacy anyway, to figure it out in reasonable time

There's a fnSexoutGetOrientation function, but it only checks the "Sexout:Orientation" NX variable, which appears to be 0.0 all the time anyway.

 

Speaking for Intimacy, it will always be a secondary mod, preferring to take a back seat to the settings in other mods (especially directed scenes).  So yes, you could set things on the fly and it will do what you tell it to do.  ie. It takes the 'shouldn't break' position on your question, even though the actual functionality isn't completely there yet.

Oh, that's good

That's more of a question of which mod should take precedence over which than anything else. Most mods usually either assume default orientations or disregard them completely.

I think I'm going to implement a sort of an "NPC orientations manager" anyway. Shouldn't be too hard, writing an MCM menu for it seems like the most tricky and boring part

I think the main reason Lust and Intimacy use separate settings is because they both keep track of orientation on an individual level.  Further (and Lust may do this too), NPC orientation in Intimacy can be altered via game play.

Yeah, I got that part about Intimacy, so I get why it uses its own system But from a quick look into Lust with FNVEdit I can tell that it only uses its two lists to check if NPCs match and doesn't add to them. There are only a few vanilla NPCs in there by default. It also disregards any Sexout lists and settings from what I can tell from a quick peek into its scripts.

So for Lust it seems that some background function to periodically check Sexout lists and synchronize is required.

 

 

Whereas, setting SexoutNG orientation on NPCs sets every valid NPC to that orientation.

But how does it do it exactly from a modder's point of view? I.e. sets a variable, adds to list, or does it just work internally for Sexout itself? How do I pick an NPC's orientation from an external mod? Aren't those supposed to be randomly distributed around the setting in MCM, or am I just putting too much math into it?

 

 

If you want coordination between mods, the most obvious way is to use the orientation form lists.  ie. Regardless of what settings you use, you can always place the NPC into the 'Gay' list to let other mods know that the NPC is gay.  Intimacy will do this eventually, I just haven't put it back in yet.

Is it supposed to be the default way? What about the "Sexout:Orientation" NX variable? I just don't want to add an N+1 method to the whole mess

Speaking about Intimacy, if I alter "SOIntimacy:Heterosexual", "SOIntimacy:Lesbian", "SOIntimacy:Bisexual", "SOIntimacy:Gay" variables (and nothing else) from an external mod for already "in-system" NPCs will it break something or is it OK?

Hi!

Wanted to ask if there's any type of convention between Sexout modders regarding managing NPCs sexual orientations. Because as of now I see a lot of contradicting options.

• First, we have Sexout with two options: NX variable "Sexout:Orientation" set via MCM (I presume), plus 3 FormLists: SexoutNGListStraight, SexoutNGListGay, SexoutNGListBi.
• Then, we have SexoutLust which implements its own 2 lists (LustSameSexOK, LustSameSexOnly) and completely disregards default Sexout ones.
• Then, we have SexoutIntimacy which disregards both and uses its own system based on 4 NX vars ("SOIntimacy:Heterosexual", "SOIntimacy:Lesbian", "SOIntimacy:Bisexual", "SOIntimacy:Gay").
• There may be many more I'm not aware of.

I was thinking of basing on Sexout's system, but it seems that those lists are empty by default, and I completely don't get what do orientation sliders in MCM do. I tried tweaking them, but NX_GetEVFl "Sexout:Orientation" always returns 0.0 for random NPCs.

So, checking and/or setting NPCs orientations looks like an unordinary task from where I stand. Just checking an NPC's orientation requires using a function like this:

scn alxActorFnGetOrientation; Gets sexual orientation for an actor; Returns int:; -1 - for Gay;  0 - for Bi (default);  1 - for Straightref rMyselfref rListBiref rListGayref rListStraightfloat fSexoutOrientationbegin Function {}  SetFunctionValue 0  let rMyself := GetSelf  if rMyself == PlayerRef    ;Some special handling or using Sexout setting    return  endif  if rMyself.GetIsCreature    ;Ignoring orientation for creatures    SetFunctionValue 0    DebugPrint "__UD: %n's orientation: assumed Bi (creature)." rMyself    return  endif  ; Sexout.esm  if alxSexout.bIsLoaded    let rListBi := alxSexout.rSexoutNGListBi    let rListGay := alxSexout.rSexoutNGListGay    let rListStraight := alxSexout.rSexoutNGListStraight    if NX_IsInList rListBi rMyself      SetFunctionValue 0      DebugPrint "__UD: %n's orientation is: Bi (in Sexout List)." rMyself      return    elseif NX_IsInList rListGay rMyself      SetFunctionValue -1      DebugPrint "__UD: %n's orientation is: Gay (in Sexout List)." rMyself      return    elseif NX_IsInList rListStraight rMyself      SetFunctionValue 1      DebugPrint "__UD: %n's orientation is: Straight (in Sexout List)." rMyself      return    ; SexoutLust.esp    elseif alxSexoutLust.bIsLoaded      let rListBi := alxSexoutLust.rLustSameSexOK      let rListGay := alxSexoutLust.rLustSameSexOnly      if NX_IsInList rListBi rMyself        SetFunctionValue 0        DebugPrint "__UD: %n's orientation is: Bi (in SexoutLust List)." rMyself        return      elseif NX_IsInList rListGay rMyself        SetFunctionValue -1        DebugPrint "__UD: %n's orientation is: Gay (in SexoutLust List)." rMyself        return      endif    ; SexoutIntimacy.esm    elseif alxSexoutIntimacy.bIsLoaded      if eval (rMyself.NX_GetEVFl "SOIntimacy:Gay") == 1 || (rMyself.NX_GetEVFl "SOIntimacy:Lesbian") == 1        SetFunctionValue -1        DebugPrint "__UD: %n's orientation is: Gay (set by Sexout Intimacy)." rMyself      elseif eval (rMyself.NX_GetEVFl "SOIntimacy:Bisexual") == 1        SetFunctionValue 0        DebugPrint "__UD: %n's orientation is: Bi (set by Sexout Intimacy)." rMyself      else        SetFunctionValue 1        DebugPrint "__UD: %n's orientation is: Straight (set by Sexout Intimacy)." rMyself      endif    ; Sexout.esm NX vars    else      let fSexoutOrientation := rMyself.NX_GetEVFl "Sexout:Orientation"      if fSexoutOrientation <= -0.95        SetFunctionValue -1        DebugPrint "__UD: %n's orientation is: Gay (set by Sexout:Orientation)." rMyself        return      elseif fSexoutOrientation >= 0.95        SetFunctionValue 1        DebugPrint "__UD: %n's orientation is: Straight (set by Sexout:Orientation)." rMyself        return      else        SetFunctionValue 0        DebugPrint "__UD: %n's orientation is: Bi (set by Sexout:Orientation)." rMyself        return      endif    endif  endif  DebugPrint "__UD: %n's orientation is: Bi (default value)." rMyselfend

And the something similar but vice-versa — for setting orientation. That is apart from an idea of using floats and finding orientation match based on how far apart on the scale two actors are, plus some random multiplier thrown in )

 

Any tips maybe?

By default it will leak. If you are worried, just store the rQRef in a quest variable.

Ok, thanks

A certain amount of NVSE documentation was written by a daemoness who gathers power more you struggle and bang your head against the monitor. 

And another amount was written by Odessa, so careful to what you write or I'll shoot you on sight.

Ookay, shutting up

I think I've read most of the mentioned tutorials. Probably I'm just kinda spoiled by mainstream programming languages, in part of documentation department

TempCloneForms persist until you quit game, so you would need a GetGameRestarted block to handle save/loads. You would also need to use the 'Get|SetVariable' functions to access its variables externally (and store them elsewhere if they need to persist).

 

Its something I've been wanting an excuse to use for a while, but there are usually better suited alternatives.

Okay, GECK/NVSE really needs some well organized manual, otherwise you just tend to learn a useful function after you've already created a couple of ugly script crunches

About that TempCloneForm. What I meant to ask — if I do something like this:

scn SomeFunctionref rQRefbegin Function {}  let rQRef := TemCloneForm SomeQuest  ;do stuffend

what will happen to this cloned quest since it won't be accessible any more? I'm just thinking from a programmer's (which I'm actually not) point of view: memory leaks and all

I think you could duplicate the quest with TempCloneForm. Things would get deep though .

Hmm, hadn't thought of this, thanks!

Didn't know you could do that to a quest and reference it, well, as a reference either

And if I do a TempCloneForm of a Quest inside a function call will it auto-destruct on function end?

I know you can restore some windows default settings erasing GECK inis inside My Documents - so in the same way, maybe there are specific lines to add to the inis so that the windows are bigger?

Nah, it's hardcoded, the inis only store information to say last window size and position (which also works only for some of the windows).

 

I really don't know, I never had reasons to poke with that...

I usually prefer most of my open windows fullscreen It is very annoying to scroll through small lists with a large number of items instead of maximizing them to see more at once. Well, whatever...

And speaking of that MessageBox menus — made it with a pseudo-quest with pseudo-stages. Works fine on debug tests, haven't tested it in actual action although. Main disadvantage — you can only have one copy at a time (i.e. no nesting), otherwise the quest variables will be just overwritten. Could be probably implemented with nested arrays, but I think I've had enough of GECK-induced frustration for now

Well, I know a thing or two about programming in general, but GECK is mostly a whole new thing to me (the last time I've opened it was somewhere around the time FNV was released), so it is kinda frustrating to get stuck in completely unexpected places because of such limitations.

Is there another way to create menus? Or are you talking about completely another way, like terminals?

Also, I completely don't get it — just why, why did they do unresizable windows for most information heavy features, like dialogues? Seriously, I've got two large (30" and 24") monitors and I have to work inside a postmark-sized window, this is ridiculous. This is apart from it being extreeemely slow...

Well, anyhow, that's more or less sorted out by now. There's another thing I'm now stuck with: I just wrote a neat paginator function for MessageBoxEx, i.e. it takes in an array of elements and splits them into a number ten-or-less-itemed message box menus with page counter and next/previous/cancel buttons on every appropriate page... and now instead of using it nicely like a function returning a value I'll have to stuck it somehow into a token because I have to listen to GetButtonPressed, which has to be run from GameMode block repeatedly... Grr, stupid GECK! I love C#...

It wouldn't be a big problem, since the dialogue would trigger and you would compare the arrays anyway.

...unless somebody adds them via console