Fallout New Vegas GECK & Scripting Help 101

[Odessa]

Nope. It seems to work like that, I assume if you pass a float to a function that expects an int, it converts it, so floor.

 

You could use NX_GetRandom to be sure.

 

I can't see myself using the vanilla compiler very often now.

[jaam]

Flooring and ceiling are done automatically every time the value is used. Internally, all numeric are floats, except references (those are integer overwriting a float).

[prideslayer]

Internally, all numeric are floats, except references (those are integer overwriting a float).

This is why I never use shorts in any of the scripts I write. Pointless, and might give an incorrect impression if you're expecting it to roll over or something.

[Odessa]

This causes a CTD, always:

 

                        DebugPrint "Ammo"
                        rPay.AddItem (Call tsolGetRandFLForm SexoutSolNovacJohnAmmoFL), (NX_GetRandom 4, 10)
                        DebugPrint "Ammo added"

 

From scof I know it is that line.

 

If I add an interim variable, like:

 

                        DebugPrint "Ammo"
                        let rItem := Call tsolGetRandFLForm SexoutSolNovacJohnAmmoFL
                        rPay.AddItem rItem, (NX_GetRandom 4, 10)
                        DebugPrint "Ammo added"

 

Then it works fine. I haven't tested other contexts, but is this because UDFs can't by nature be used within '1-liners' like this, although the NVSE compiler allows it?

[prideslayer]

It's because the built in functions can't evaluate on the right hand side. "rItem" is a simple variable, while "call ...." is an expression. For expressions, you need to do eval. This *should* work, or some variation, but I'm still learning the ropes myself

 

rPay.AddItem (eval Call tsolGetRandFLForm SexoutSolNovacJohnAmmoFL), (NX_GetRandom 4, 10)

I constantly stick the eval in the wrong spot(s) and occasionally get frustrated and just use a var also. The compiler override might address it as well.

[prideslayer]

Oh you'd need an eval for the NX_.... also. I think.

[Odessa]

I tried adding 'eval', but it crashes in the same place.

 

According to this documentation, eval is only for use within 'if' statements for expressions that evaluate to a boolean. In this case, my function returns a form (an ammo type from a formlist).

 

Also, to use function calls within function calls, you only need to use the compiler override (and suspend your disbelief at NVSE4 ), which is working reliably for me with regular functions. I'm wondering if UDFs can't be used like this due to their implementation.

[DoctaSax]

Hm, yeah, I kinda sidestepped the issue in the syntax tutorial by presenting eval as something that affects the if-line. It's good enough for most of us nincompoops, but people with a programming background may expect to be able to get more of it, and in some cases you may and in some not. Eval does expect the expression it evals to be boolean, so if you treat it as something that affects the entire if-line, at least that's always going to be the case.

 

Getting vanilla/pre-4 functions to accept UDF calls and array elements as parameters is really more CO-territory though. Eval is mostly about getting them to be accepted in regular comparison and math syntax. Jaam also added some functionality to mix eval & non-eval stuff using { } but I never investigated the ifs and buts properly.

 

Also note that there's more of a likelihood to run into the maximum line size limit for if-conditions now that you can construct big monstrosities with udf calls, array element lookups &  strings. That also exists in vanilla, but you have far less chance of running into it.

 

I spent most of yesterday pouring over all remaining obse threads on the beth forums for more guidance on more advanced usage - how to thoroughly predict what combination of CO/evalornoeval/parentheses you'll need for a given situation, but in the end there's little I can say other than try stuff out; what compiles and works in-game works, the rest doesn't. There's a lot of power in the new stuff, but it requires responsible use.

[prideslayer]

Ah that makes sense Doc.

 

The examples were all related to conditional testing, but I jumped the gun and assumed eval should 'just work' anywhere. Oops!

[Halstrom]

Hmm I did multiquote here but it didn't work even after updating Java, though the quote command works fine, I still can't get any basic LL post editor stuff to work but anyway

 

I noticed really screwy crashes & script lockups trying to evaluate variables inside functions, so I just try to make a habit now of pulling them into a temporary variable the line before use.

 

If doing something that evaluates creatures and races you might want the GetIsCreature check first as I discovered you can crash a script by trying GetIsSex on some creatures like EDE so I suspect the same could happen on GetIsRace

[nyaalich]

My head is fuzzy.  Unfortunately, I haven't been drinking.

I'm having the worst time with Base Effects and Spells.

What I'm trying to do:  Equip non-damaging flower weapon -> CHA +1

Current Setup:  To bypass the damage requirement for weapon effects (ench and scripts too, yes?), I have a token added at the beginning of the game that checks if the weapon is a flower.  If so, call spell.  If not, dispel.

Do I have to write a script for this or bind it to an effect?  There's an Increase Charisma effect as an option for spells.  There's also one for Base Effects.

 

At this point, I just want to use modav to increase/decrease on equip/unequip, but this is a persistently aggravating knowledge gap.

 

Any help straightening me out once and for all would be greatly appreciated. 

[DoctaSax]

I'd advise against manipulating actor values with ModAV, simply because you may forget to re-set to the original value, or if you store it, the unaltered value may have changed due to other aspects of the game anyway.

 

For regular actor effects and clothing object scripts, the MO is find or create an AV-modifying base effect that is flagged as "recover" (ie will revert its changes when it's removed), then attach that to your main spell - setting the value & time. Flag the base as "detrimental" for a debuff, don't for a buff.

 

I think an object effect on a weapon however affects the person who's hit with it, not the person carrying it. So I'd say create a regular spell, cast and dispel that on/from the actor carrying it in the weapon's object script.

 

[nyaalich]

The weapon's script is working in the OnEquip and OnUnEquip blocks.

 

So...I assume that one of my flags is wrong?  (Covered =  No settings changed in those fields.)

 

 

 

 

 

[DoctaSax]

Get rid of some of those flags - 'no duration', 'use attribute', 'no hit effect' are unneeded or detrimental. You also don't need to specify actorval in the actor effect, and will need to set some type of duration (nothing wrong with saying 100 days if you're gonna dispel from script anyway).

PC start effect should also be unnecessary - that's TES stuff.

[Guest tomm434]

I'm creating yet another companion mod and want to implement reputation system. Is it okay to store variables in NPC's script? Something I should know of?

 

nyaalich, why don't you set bottom condition to AND instead of OR? Even if it's NOT necessary, nothing bad should happen

 

But something happened in my case. I was doing quest conditions for dialogues and set

GetVoiceType GenericMutantVoice ==1 OR
GetVoiceType GenericMutantVoiceDC ==1 OR

and for some reason dialogues appeared for everyone.
So I changed

GetVoiceType GenericMutantVoiceDC ==1 OR
to
GetVoiceType GenericMutantVoiceDC ==1 AND
And everything worked fine.

 

[nyaalich]

Doc:  You get an A for being Awesome.     Works now! 

[nyaalich]

@tomm:  And and Or conditions in the GECK fuck with my head.  Parentheses I get.  I have to look up how in the hell it evaluates them whenever I have to stack them in a GECK window.

 

I thought that the bottom condition's And/Or was generally ignored, but then that goes back to me having to look it up.  : P

 

If you're creating new companions, there shouldn't be anything wrong with it.  There was some weirdness/constraint with FO:3 where you couldn't or it was unreliable or something due to how an NPC script executes.  In NV, it runs just like an object script.  Salt grains, though.  I haven't fully implemented a companion in NV yet.

[Guest tomm434]

@tomm:  And and Or conditions in the GECK fuck with my head.  Parentheses I get.  I have to look up how in the hell it evaluates them whenever I have to stack them in a GECK window.

 

I thought that the bottom condition's And/Or was generally ignored, but then that goes back to me having to look it up.  : P

 

If you're creating new companions, there shouldn't be anything wrong with it.  There was some weirdness/constraint with FO:3 where you couldn't or it was unreliable or something due to how an NPC script executes.  In NV, it runs just like an object script.  Salt grains, though.  I haven't fully implemented a companion in NV yet.

 

Nice, thanks.

 

To be sure, I always set bottom ones to "AND" and sleep at ease. And yes, sometimes they mess up my brain too.

[DoctaSax]

@tomm:  And and Or conditions in the GECK fuck with my head.  Parentheses I get.  I have to look up how in the hell it evaluates them whenever I have to stack them in a GECK window.

 

I thought that the bottom condition's And/Or was generally ignored, but then that goes back to me having to look it up.  : P

 

I always translate an "A or B or C" to

A or

B or

C and

 

whether it'd work with an 'or' at C or not; it just makes more sense to me to have at least one "and". And because the and/or relationship works from top to bottom, C is the candidate there.

[nyaalich]

New version of the Geck Power-Up released today.  Preserves ONAM records in ESM(s?).

[prideslayer]

- You can now save scripts without compiling them (useful if you want to save your script and finish it later).

The absolute horrors this is going to introduce, I'm almost certain.

[Guest]

Quoting an old message of Dialogue Conditions I asked here in 101 (I saved on my computer), here's the answer I obtained, if it helps:

 

"... If that leads to many conditions for the same line, all is obviously well if they're all ANDs. If there are a couple of ORs, I put them on top - both AND & OR are the relation between the condition it's attached to & the condition underneath, so if you go:
- condition1 OR
- condition2 OR
- condition3 AND
- condition4 AND (final)

that works out fine for me, if I want "always 4" AND "one of the first 3", ORs taking precedence over ANDs. But if you're looking at something that goes like:

- condition1 OR
- condition2 AND
- condition3 AND
- condition4 OR
- condition5 OR
- condition6 AND

then you'd better be sure about what you're doing. CheckMeOut has some of that, for hundreds of lines, and I'll never do any of that again if I can avoid it by just making 2 separate lines - which would've been more impractical in that case. You can't use parentheses like you can in a script line with || and &&, so because OR > AND, you need to work all that out carefully to something that follows geck rules (or > and, no parentheses, from top to bottom)
Let's say you want conditions like:
A OR (B AND C), then you need A OR B AND A OR C AND -- the geck condition version of (A OR B ) AND (A OR C)
(A AND B ) OR (A AND C), then you need A AND B OR C AND -- the geck condition version of A AND (B OR C)"

[Guest tomm434]

Does anybody know why I can't use let command with NPC variables?

let aaaNPCref.Reputation +=1 doesn't comply
but
set aaaNPCref.Reputation to aaaNPCref.Reputation +1
complies.

[Guest]

let local_variable_reputation := aaanpcref.reputation

let local_variable_reputation += 1

 

I usually solve it in this way for quest vars. Or use Compiler Override. I think. I never use it so I'm not completely sure

[Guest tomm434]

oh no. I'd better use standart "set to" command.

 

What  is Complier Override? Some program that bypasses GECK PU checks?