Fallout New Vegas GECK & Scripting Help 101

[prideslayer]

It "works fine" if the dialog speaker has a script assigned, and that script has the vars the fragment needs. I was testing with Sunny and it didn't work -- edited her script to just add a ref var declaration at the top, and it started working. Obviously not a real solution, but it definitely depends on the script assigned to the speaking NPC.

[astymma]

Well, I see no problems with leveraging the bad behavior of the engine to stomp on actor's vars in their script. Normally I preach to NEVER rely on engine behavior because it might change. In this case, I think we all know that Fallout New Vegas has been "finalized" hehe. But you're right, not a real solution. Be a funny plugin though... SexoutKludge.esp... adding a ref var to every actor in the game

[Odessa]

foreach Actor <- SexoutScanner

   if Actor.GetScript == 0

       Actor.SetScript KludgeScript

 

(not a solution, I know)

[jaam]

No I was testing with the Doc (Doc Mitchell) and he definitely do not have the two ref variable present in my topic test. Plus, by tracing the code execution I could see the script had a proper set of variables and references attached to it.

 

[Guest]

Can the Subject / Target which are used in conditions be used as aliases in scripts?

 

 

...

(Vanilla never uses anything else than quest.vars, globals and ref.vars on dialogue scripts. However if the goal is just the need to store a GetSelf on dialogue, there are workarounds for that. Or I do miss the point?)

[Guest]

It "works fine" if the dialog speaker has a script assigned, and that script has the vars the fragment needs. I was testing with Sunny and it didn't work -- edited her script to just add a ref var declaration at the top, and it started working. Obviously not a real solution, but it definitely depends on the script assigned to the speaking NPC.

 

Because I think the implicit reference inside a dialogue script is "Subject"

[DoctaSax]

(Vanilla never uses anything else than quest.vars, globals and ref.vars on dialogue scripts. However if the goal is just the need to store a GetSelf on dialogue, there are workarounds for that. Or I do miss the point?)

 

I guess the point is to theorize about how to actually store it in a result script local var - nevermind that in practice you'd be inviting a shitload of conflicts by adding or altering scripts to vanilla forms in the process.

[Guest]

By the way, GECK started crashing bad and often, when I make syntax errors in scripts and PU returns the error, the window freezes and CTD. With consequent paranoia everytime I write a chunk of code. It doesn't sound normal, one month ago wasn't acting like that. It's not specific to an ESP because it happens with new ESPs too. Someone else has a similar "feature"?

[jaam]

That should not be a permanent condition. I would say it happens once in every 20 or so GECK scripting session. It might also come from a specific error, but I don't have enough statistics to form an hypothesis.

[prideslayer]

 

It "works fine" if the dialog speaker has a script assigned, and that script has the vars the fragment needs. I was testing with Sunny and it didn't work -- edited her script to just add a ref var declaration at the top, and it started working. Obviously not a real solution, but it definitely depends on the script assigned to the speaking NPC.

 

Because I think the implicit reference inside a dialogue script is "Subject"

 

I didn't use any implicit refs. To be clear / summarize, this little chunk of code:

ref self
set self to getself
printC "%n (%i)" self self

Will NOT work if the subject doesn't have a script assigned to them, or does but it doesn't have any vars (like sunny).

WILL work if there is a script with at least one var declared on it. It probably works no matter the var type, since it's just stomping on some memory location.

 

 

 

(Vanilla never uses anything else than quest.vars, globals and ref.vars on dialogue scripts. However if the goal is just the need to store a GetSelf on dialogue, there are workarounds for that. Or I do miss the point?)

 

I guess the point is to theorize about how to actually store it in a result script local var - nevermind that in practice you'd be inviting a shitload of conflicts by adding or altering scripts to vanilla forms in the process.

 

That is correct. We'd all benefit from being able to declare vars there safely. As it stands, as far as sexout is concerned, the NX interface is "not supported" in result scripts. The classic interface works fine, and the UDF interface works fine IF you use a quest "scratchpad" to hold vars.

 

Don't do this:

ref self
let self := getself

call fnSexoutActPrep
call fnSexoutActSetRef "actorA" self
call fnSexoutActRun

Do this instead:

let myScratchPadQuest.someRef := getself

call fnSexoutActPrep
call fnSexoutActSetRef "actorA" myScratchPadQuest.someRef
call fnSexoutActRun

[prideslayer]

Also, more for jaam but astymma if you feel like diving into the NX code go ahead..

 

I'm still completely in the dark about why this doesn't work:

NX_SetEVFo "somestring" somequest.someRefVar

Trying it, it won't even save/compile in the GECK. The NX_Set* functions only work with "local" vars, which is why the NX interface is "unsupported" in result scripts.

[jaam]

That's the vanilla parser. The NX_SetEvFo definition call for a var here and doted notation (quest.var) is interpreted as a ref here, not a var.

 

[jaam]

Succes! I have an error!

In fact the version similar to Prideslayer example (

ref self
set self to getself
call someUDF self

) entered in a loop, just like if the info start script was being called over and over as long as the topic subtitle was displayed, each time with a different value for self.

 

By using let instead, I could trace the issue to the eventlist (the object containing the instance value for every script run) not containing any var data.

 

Next step is to find where in the engine a dialog script gets instantiated.

 

[Guest]

That should not be a permanent condition. I would say it happens once in every 20 or so GECK scripting session. It might also come from a specific error, but I don't have enough statistics to form an hypothesis.

 

Can't say 1 every 20, but I can tell you one of my common mistakes, which just CTDed when I wrote my previous post:

If MyVar := something

I use := on If as for Let

[Guest]

 

I didn't use any implicit refs. To be clear / summarize, this little chunk of code:

ref self
set self to getself
printC "%n (%i)" self self

Will NOT work if the subject doesn't have a script assigned to them, or does but it doesn't have any vars (like sunny).

WILL work if there is a script with at least one var declared on it. It probably works no matter the var type, since it's just stomping on some memory location.

 

 

As I intended it, the implicit reference in dialogue scripts is Subject (and Target is PlayerREF)

So if you are talking with MyNPC and you write something like Set Self to GetSelf, it would be like if you write Set MyNPC.Self to GetSelf.

This is why I think it requires a script with vars declared. But you can see the code more in depth and see if my feeling's true

[prideslayer]

That's the vanilla parser. The NX_SetEvFo definition call for a var here and doted notation (quest.var) is interpreted as a ref here, not a var.

Is this something I can change by modifying the NX definition then? Ignoring for a moment the havoc that would cause with existing NX using scripts. Really NX doesn't care what type of value it's given, ideally I'd like a single Set and Get (I realize the Get will be more difficult, or impossible) that can handle any var type -- without all these different functions for floats, integers, arrays, forms, etc.

[prideslayer]

 

I didn't use any implicit refs. To be clear / summarize, this little chunk of code:

ref self
set self to getself
printC "%n (%i)" self self

Will NOT work if the subject doesn't have a script assigned to them, or does but it doesn't have any vars (like sunny).

WILL work if there is a script with at least one var declared on it. It probably works no matter the var type, since it's just stomping on some memory location.

 

 

As I intended it, the implicit reference in dialogue scripts is Subject (and Target is PlayerREF)

So if you are talking with MyNPC and you write something like Set Self to GetSelf, it would be like if you write Set MyNPC.Self to GetSelf.

This is why I think it requires a script with vars declared. But you can see the code more in depth and see if my feeling's true

 

Ah I understand. Yes it looks like that's what it's doing, running the script fragment in the context of either the Subject ref (in dialog), or in the context of the quest script itself (in quest stage scripts). Regardless of the reason though, it would be nice if it were "some other way." For now, my recommendation is to just use UDFs there and nothing else, unless it's very simple like additem or whatever.

 

In the first few pages, when astymma first brought the problem to light, we didn't have UDFs. The only option was really "watch your ass."

[Guest]

you know what, for SO you could make it easier. When you talk with someone, you "could" need to start sex. So why don't just put an event OnActivate that stores the destinatary of your speech, always, on a quest.var, everytime you start a dialogue. Then, if you won't have sex, no matter, that ref will be overwritten next time you speak with someone else

[prideslayer]

Heh.. I'm trying to explain this isn't for "me" or for sexout itself -- it's for other people using sexout. They often like to start sex scenes, and do other things, within the dialog result scripts.

 

I'm just trying to get to the bottom of what works, and what doesn't, so I can update the documentation. I think I'm there now.

[astymma]

you know what, for SO you could make it easier. When you talk with someone, you "could" need to start sex. So why don't just put an event OnActivate that stores the destinatary of your speech, always, on a quest.var, everytime you start a dialogue. Then, if you won't have sex, no matter, that ref will be overwritten next time you speak with someone else

 

Which is pretty much exactly what SmallerTalk used to do before being rewritten.

 

You don't want to do it in OnActivate, far too susceptible to problems. It's simpler, and more stable, to check for the keypress for activate and record the ref of whatever the GetCrosshairRef return value is. That way you never stomp on other OnActivates or on the default activate.

 

Of course this still doesn't help the situation, as you'd have to declare a local to put the value in to send it via NX since it's not accepting quest.questvar syntax.

 

[Guest]

Yeah, mine was a suggestion.

So the one who makes the SO mod, should simply write this in the End Result Script:

Call START_SEXOUT_UDF PlayerREF MyRefWhichWasAlreadyStoredBySexOutItSelf,WhenIClickedOnTheNPCToSpeakWithHim,AndIt'sCalledSomethingLike"SexOutQuest.MyDialogueDestinataryRef"

 

Excluding the name I gave to the variable, I think it wouldn't be a bad idea to avoid problems from modders

 

Astymma, I assume you would check on key press (E) and the crosshair ref, and if it's actor and if it can really talk etc.etc. in a quest script with something like 0.01 script delay. I say an OnActivate Event Handler which triggers when you actually activate the ref seems more reliable.

[jaam]

 

That's the vanilla parser. The NX_SetEvFo definition call for a var here and doted notation (quest.var) is interpreted as a ref here, not a var.

Is this something I can change by modifying the NX definition then? Ignoring for a moment the havoc that would cause with existing NX using scripts. Really NX doesn't care what type of value it's given, ideally I'd like a single Set and Get (I realize the Get will be more difficult, or impossible) that can handle any var type -- without all these different functions for floats, integers, arrays, forms, etc.

 

 

Unfortunately not that I can think of at the moment. Do anybody know of a custom command that accepts quoted args in that context ?

 

[prideslayer]

jaam,

The only thing I know of that even comes close is the array iteration operator, but it's probably not something NX can do.

 

AJ,

In cases like that, you're better served by just making the UDF take an array (stringmap) as an argument. Then you can do something like this:

  call mySexoutUDF ar_Map("actorA"::getself, "actorB"::playerRef, ...)

Which MIGHT work, depending on how the UDF call likes (or doesn't) the ar_map evaluation rather than a straight var in that context. If it works, it's "hooray", and I'll put such a 'helper' UDF in sexout itself fairly soon. The UDF itself would just take the one stringmap parameter and then iterate through it making the sexout calls

 

scn mySexoutUDF

array_var arParams

array_var arItem
string_var sType

Begin Function{arParams}
  call fnSexoutActPrep

  foreach item <- arParams
    let sType := TypeOf item["value"]

    if eval "Form" == sType
      call fnSexoutActSetRef item["key"] item["value"]
    elseif eval "Number" == sType
      call fnSexoutActSetFloat item["key"] item["value"]
    endif
  loop

  call fnSexoutActRun
End

This function is basically what fnSexoutActRun itself does. All the fnSexoutActSet* functions just store things in a stringmap like this, then ActRun goes through it in exactly the same way, setting the NX vars and then doing the CIOS.

[astymma]

...

Astymma, I assume you would check on key press (E) and the crosshair ref, and if it's actor and if it can really talk etc.etc. in a quest script with something like 0.01 script delay. I say an OnActivate Event Handler which triggers when you actually activate the ref seems more reliable.

 

Actually, what my testing showed in writing SmallerTalk, was that using OnActivate, and it would need to be a generic OnActivate, without restrictions, is that OnActivate is LESS reliable.The one main reason I moved away from an OnActivate block is the silly behavior in the engine to always force a player to rise from a sitting position to a standing position if they activate anything that has an override of its default activation. I noticed it because I was testing Cass, and I'd sit down next to her at the bar and I kept standing up when I'd initiate conversation. My OnActivate handler was doing it.

 

TBH what you suggested is simply handled by this:

 

SCN WhatWasLastActivated
 
ref refLastActivated
 
Begin GameMode
    If IsControlPressed 5
        set refLastActivated to GetCrosshairRef
    Endif
End; GameMode

 

After all, we don't care what was last activated, since we're checking in a dialog script, it HAS to be the actor we want. Who cares if they activated a chair, a door, their ammo crate and THEN the actor? The refLastActor will simply have the ref of what they last activated. We don't even need to care IF they're an actor, IF they can talk, any of that. When we need the value, we know what it's gonna be... the other person in conversation with the player. I don't see how OnActivate would be more reliable in this situation.

 

But... this doesn't help NX make calls like Pride would need... it would still need a local var declared to set it equal to this quest variable we're constantly updating before the NX call could use the value since NX isn't currently working with quest.questvar syntax. Then again, it sure as hell doesn't hurt to talk these problems out like this one bit. Everyone benefits.

[Guest]

when you wrote smaller talk, there weren't event handlers, maybe that could make the difference

Scn myActivateEventHandler

Ref rActivator
ref rActionRef

Begin Function {rActivator, rActionRef}
…
End

I guess this fires when you click on the actor, no matter if your target is sitting, sleeping or whatever. If you clicked and it took the command, it should fire.

And you would still avoid a Gamemode running on .0x

 

EDIT: and the checks about the actors I was referring, were simply concerning sexout, to avoid to ask for sex to a talking creature.