Fallout New Vegas GECK & Scripting Help 101

[jaam]

Don't define vars in dialogue script

 

I don't think the engine has a way to allocate them to the quest script so they reuse the same slot from the quest script.

I would say, if the first variable in the quest script is not a ref bad things will happen. In fact, bad things will always happen. Try creating self as a var in the quest script and use it in the dialogue script, which I realized now you already saw works.

 

[prideslayer]

Well that works and yet it doesn't... because the NX functions will only accept local vars, not vars from a quest.

 

'NX_SetEVFl "foo" somequest.somevar' does not work.

 

This makes it impossible to use the NX calling convention for sexout in the result scripts.

 

Maybe that's something I can fix in NX. Not sure what the issue is there.

[jaam]

You can work around that, by calling an UDF that will call the NX_ func.

 

As for fixing it, that's a current limitation of the vanilla compiler I think, and you cannot activate compiler override in result scripts.

[prideslayer]

Ok.. well two things.

 

First, I know it can be worked around... but this is more for me to issue a 'heads up' I guess to modders. I didn't know before now that it didn't work.

 

Second, ignoring the quest script potential for disaster right now, why doesn't it work? I made a quest script and crammed like 8 dummy ref vars into it just to test this, and still doesn't work.. heh. I think it should, even if 'dangerous', shouldn't it?

[astymma]

I think getself executed in a script fragment is attempting to reference the script fragment itself.

 

Also, according to the geck:

 

 

GetSelf will return 0 if called on a reference that has been created dynamically (for example, created via PlaceAtMe, or dropped from an inventory into the game world).

[prideslayer]

The getself itself works, as pointed out by the fact that setting a quest var works just fine. For *me* this is just in building a test mod for sexout that is doing a variety of calls -- including testing sexout calls in dialog result scripts, both before/after, and in quest stage scripts.

 

It works fine with a classic call (e.g. set Sexout.Male to getself....) but using a local var doesn't work. I know they are frowned upon, but I figured if you knew the risks and avoided the problems, they were ok. Turns out that does not seem to be the case.

 

So I'm just trying to figure out if there's a workaround that actually works, or if I need to post a big "don't do that" about using the NX calling style in the result scripts. I haven't setup the UDF call tests yet -- can a UDF that has a ref argument take an expression/function like getself, or does it require a ref var?

 

I am kinda expecting it to not work either, because if it does, why doesn't NX? "NX_SetEVFo "blah" getself" does not work, due to the script engines distinction between vars and expressions (I think).

[astymma]

Hmm maybe if I'd actually read your post closely I would have noticed it HAD worked with a quest var hehe

 

What about:

 

ref self
set quest.questvar to getself
set self to 0
set self to quest.questvar
;NX call to NX_SetEVFo "blah" self

?

 

Hideously ugly...

[astymma]

Does the "this" keyword store a 0 in a script fragment?

 

I mean it's basically shorthand for:

 

ref this
set this to getself

[prideslayer]

The hideously ugly thing might work.. i'll try it just for science sake. I have no idea about the 'this'.

 

My recommendation to modders for a few months now has already been to just have them make their own UDF(s) to call when they want to initiate sex from a fragment, but I'm really curious about why this doesn't work. The local vars were working 'fine' when this thread started, provided you followed the rules.

 

My time being mostly focused on the backend stuff though, I really have no idea what's going on in more player facing script things these days.

 

Not using a UDF and trying to do it with the sexout NX/UDF interface seems doomed to failure, or lots of weird work -- which is 'bad' in the sense that none of the new features beyond the original NG ones (actor A/B/C, callbacks, etc - in the SexoutNG quest) are available.

[astymma]

I take it that the real goal here is to uniquely identify a call to Sexout EVEN if it comes from a script fragment?

 

Couldn't the implementation of "call" include an internal hash generator that's modindex based?

[DoctaSax]

So I'm just trying to figure out if there's a workaround that actually works, or if I need to post a big "don't do that" about using the NX calling style in the result scripts. I haven't setup the UDF call tests yet -- can a UDF that has a ref argument take an expression/function like getself, or does it require a ref var?

Dunno, something like

call SexUDF Getself, playerref

looked kinda accident-prone to me when I considered it for Lust 7. It might work though, maybe if GetSelf is in parentheses. Odessa has more experience with one-lining things in nvse4 - I think I saw some examples with UDF returns as parameters to another UDF, so technically the same should be possible for regular functions.

 

What I ended up doing instead is:

 

let LustQst.rLinedUp := GetSelf
call LustSexCall LustQst.rLinedUp playerref 0

to match a udf that takes {ActorA ActorB isRape} as parameters. The quest ref var is actually set in the topic leading up to the one making the call there, just to make sure it sticks.

 

For another functionality, I've just got

call LustSexCallEscape 2

where it is assumed the implied ref of the UDF, the actor talking to the PC, is gonna be the dominant one (ActorA), and the int is sex type. I think this is still a pretty viable approach to most 'generic approach'-type mods, just do the getself in the udf and you're set. In other mods where the actors to an act are fixed, there's no issue, and people doing NPC-on-NPC sex rarely start it from dialog between those NPCs.

[Halstrom]

Is there something 'odd' about GetSelf and local vars (in particular) in a dialog begin/end script?

 

This works fine:

 

set somequest.someref to getself

This doesn't.

ref self
set self to 0
set self to getself

Seems to always be 0/null. The initial set to 0 is there to avoid the actor/quest var stomping issue with local vars in result scripts.

[Halstrom]

i found a few issues with get container to and so i always make sure that i sEt self or actor or whatever rèf to something like partyhat or golfball or my own null actor/token setting a ref to 0 never seemed to work

[Odessa]

Lateral thinking: Create a dummy reference called "DialogueSpeaker". The compiler will allow you to pass this as the UDF parameter, within which you can do 'if Actor == DialogueSpeaker: set Actor to GetSelf"

 

NVSE also has GetDialogueSubject/Target/Speaker.

---

 

On 1-lining: Being a python programmer I went crazy when I first discovered the CO.. then scaled back, from my experience:

- Array access and functions are safe, I use (Ar_List X, Y) etc as a parameter to functions all the time. (note: the '&' operator boxes anything into a 1-element array .)

- Rand is safe, and you don't need to floor it for int parameters.

- Most other functions work either all or most the time. Need more testing to be specific. Be wary.

[prideslayer]

I take it that the real goal here is to uniquely identify a call to Sexout EVEN if it comes from a script fragment?

 

Couldn't the implementation of "call" include an internal hash generator that's modindex based?

That's an entirely different goal, heh.

 

This stuff is purely so I can put an 'official' word out on the sexout APIs, and how to use them in result scripts.

 

I find it extremely odd that the local var in the fragment doesn't work, at all, where getself is concerned. Obviously they work in other cases, provided one follows the guidelines you put forward in the first page of this thread.

[prideslayer]

i found a few issues with get container to and so i always make sure that i sEt self or actor or whatever rèf to something like partyhat or golfball or my own null actor/token setting a ref to 0 never seemed to work

That's interesting, I'll try that as well. I tried setting it to 1 instead of 0, no change there. I'll try setting it also to the player first, then doing the getself.

[prideslayer]

I really should have pointed out that I'm not making a 'playable' mod, or trying to find a 'different' way to make the calls. I really just want to know why this doesn't work, and if there's a way (barring total refactoring/replacement) to make it work. This is a test mod (like a unit test for sexout), to determine what things work (with minor workarounds) and what don't. As such, getting too 'creative' with the code defeats the purpose.

 

My intention is to start with 12 different options. These are all the combinations for classic/nx/udf interfaces tested in dialog begin/end scripts and quest stage begin/end scripts.

 

Getting them to work with a minimum of fuss, or simply saying they do not, are really the only options. Getting 'crazy' with the script to call UDFs in the test mod isn't really viable here.

[prideslayer]

Ok a little more digging and I have this solved.

 

I was testing in a dialog begin/end, and stupidly checking the quest vars rather than vars in the NPCs script. Everything works as expected if the NPC script has the appropriate vars in the appropriate order.

 

So first step is going to be (as expected I guess) a "don't do that" when it comes to local vars in the dialog begin/end fragments. For quest stage begin/end they are fine, provided it's your mods own quest, and you make sure the variables match up.

 

On to testing the UDF interface.

[prideslayer]

Well, this compiles (unlike trying to use NX), but the var is still null.

call fnSexoutActPrep
call fnSexoutActSetRef "actorA" getself
call fnSexoutActSetRef "actorB" playerref
call fnSexoutActRun

Edit: setting a quest var to getself and then using that works as expected. Yeesh.

[jaam]

At some point I'll find the time and remember to track what exactly happens both in the Geck and in the runtime when using local variables in dialogue (or package for that matter).

 

[prideslayer]

It would be appreciated jaam.

 

I'm also interested in why NX can't take quest vars as params. Are those all some kind of weird call by (local) reference rather than by value or something?

[jaam]

 

Does the "this" keyword store a 0 in a script fragment?

 

I mean it's basically shorthand for:

ref this
set this to getself

 

this is an alias for GetSelf

I doubt this would compile.

 

[astymma]

Heh I know it wouldn't compile, I was saying if "this" wasn't a keyword alias for getself, the code for "this" would be what you quoted.

 

Technically it's more than an alias for getself. It's variable declaration and initialization in one, vs getself being only initialization, you need to declare your own variable. However, I'm sure it has all the weaknesses of getself. My thought was that if getself is returning 0, this will be 0 as well.

 

To be more clear... using getself you need to do something like...

 

ref rSelf
set rSelf to getself
rSelf.FunctionCall

When using this, you can simply do the following (the getself call is implicit)

 

this.FunctionCall

Although I would definitely add...

 

if this
    this.FunctionCall
endif

[jaam]

No, no it is an alias, just like GetAV is an alias for GetActorValue. You should be able to use one wherever you use the other, or somebody at Beth put himself in a bind by reserving the same word more than once.

 

It's just that I was going through the command list yesterday and I found this out when I still had your example fresh in my mind. And by the way, I was trying to follow what was going wrong with dialog script and I got pissed because... everything worked!

 

 

[astymma]

Hmm, if it's a true alias... then I'm misremembering using it... not the first time

 

Yup, checked the nvse.log, it's a pure alias. Odd.. oh well.

 

Hmm, if everything worked for you and not for Pride, maybe it's the speaker of the dialog. Er... or target... whichever runon is set to.