Fallout New Vegas GECK & Scripting Help 101

[astymma]

MtM and I went over this a lot in PMs and yes' date=' it seems to work reliably to protect yourself from #3. As for references, you should be able to initialize them to zero (same as uninitialized) and if you can't, you can always initialize them to a control reference of some known insignificant reference like a static or marker somewhere unrelated to your task and one which you can check against.

[/quote']

 

Good to know, this. Thanks!

I agree on using local vars sparingly, to be sure. But in the cases I mentioned earlier, having them is much easier than setting your calls in other scripts.

 

Edit: I don't see a ready answer in that other thread on whether or not the same is the case for quest stage result scripts. Can you shed a light on that?

 

It should apply to all script fragments not contained in an actual script object [sCPT]. However, let me reiterate... I do not recommend using locals in any script fragment unless it's the only solution available. Quest variables are far more stable and reliable.

[BruceWayne]

Found this site a while ago. Most of the stuff is directed at beginners, but I think that'd be useful for new modders with little to no scripting/programming background.

 

http://www.cipscis.com/

 

Cipscis is the author of "Cipscis Auto Save Manager" (CASM).

[astymma]

Found this site a while ago. Most of the stuff is directed at beginners' date=' but I think that'd be useful for new modders with little to no scripting/programming background.

 

http://www.cipscis.com/

 

Cipscis is the author of "Cipscis Auto Save Manager" (CASM).

[/quote']

Oh damn, I'd forgotten all about that site, good call Bruce... excellent resource.

[Tasha69]

great resource... helped me a bit, I think... lol

 

I am blonde after all, give me some leeway =P

 

CNC commands, and comparative math (if this than that, unless that, except this..) I can do.

 

It's the syntax for scripting that confuses the hell outta me =P

[Halstrom]

Any Effects on NPC's are likely to be automatically dispelled if the Player leaves the cell, this seems to occur even on Fast Travel, Wait, Sleep as well. So to add scripts to NPC's you are better adding them in Tokens, which I found will continue to run even when the Player isn't in the same cell. So if that script casts effects on the NPC, it may lag the game by continuing to recast the effect as it is removed immediately because the NPC isn't in the Players cell. So you need to put a check checking "GetInSameCell PlayerREF".

 

		if rZActor.GetInSameCell PlayerREF 
			if iCurrNumOva == 1 && rZActor.IsSpellTarget SexoutP2EFertile < 1
				rZActor.CIOS SexoutP2EFertile
			else
				rZActor.Dispel SexoutP2EFertile
			endif
		endif

 

[Halstrom]

I discovered yesterday that if a Clothing effect spell adds any item Misc, or Armor, Scripted or not, to the Actor it works fine for the Player but will cause a BSD like crash if the item is worn by an NPC. Adding an Effect Spell seems ok though.

http://www.loverslab.com/topic/16258-npc-outfit-effect-script-crash/

[DoctaSax]

I mentioned these things before in the old NG thread and possibly one or two others, but this is probably a better place to park it.

The Geck wiki is plain wrong and/or misleading about the "playidle" function being severely limited when it comes to using it on the player:

- you don't have to be in tfc mode; you only have to make sure that you're in the mode the anim's made for (ie 3rd person if it's a 3rd person anim or the kind you only see npc's use). IsPC1stPerson & Tapcontrol can sort that out for you.

- there's no need to be calling it from an activator specifically or to worry about bypassing its default activation; scripts on other objects as well as spell scripts and probably quest scripts will do fine as well - I really recommend spell scripts for maximum control.

- seeing as the above limitations don't apply, there's no need to circumvent them by placing the anims outside the character folder either.

- the 'package solution' suggested in the discussion tab may or may not be needed for 1st person animations (as that's what vanilla uses that method for), but it's not called for in 3rd

 

You are, however, still subject to the usual restraints and peculiarities: certain kf's for instance don't allow themselves to be overridden by a new one, and the behavior of anims is also still determined by whatever you enter into the 'loop' information in the anim widget. That's a trial & error thing, and applies to any method of calling an anim. And of course, adding or copying an anim to/in the anim structure, if needed, may flag certain anims as changed that weren't, making your mod dirty, so you'll have to undo that in FNVEdit.

 

Using playidle is probably not the best solution for a randomized animation system like SexoutNG, but it is, in my opinion, the better one for directly calling specific one-off anims under specific circumstances.

- with pickidle you often have to copy a vanilla anim to place at the top of the structure under new conditions. With playidle you only have to if you want to apply different loop data. This reduces the need to do something that can make your mod dirty (see above).

- whether copying a vanilla anim or adding a new one, with playidle you don't have to place it at the top of the anim structure, reducing the chance of conflicts with pickidle mods where everybody puts everything up top (like the conflict that pose mods have with NG). Playidle calls the anim directly by editorID so it doesn't matter where it's placed. I place them between 'generalidles' and 'loose', which will guarantee that they're never called by the engine by accident, but only when I tell it to.

- if you want one anim to be followed by another, or to stop (same thing: stopping is just overriding an ongoing anim with a neutral stance anim, then stopping your script), you just 'playidle' your new anim instead of having to adjust the conditions it depends on first & then calling pickidle

 

In short, almost anything an NPC can do (cry, laugh, cook, dance, throw up), your PC can do too. For that, playidle's the smart choice most of the time.

I don't mean this as a shameless plug, but modders learn from examples, and I don't recall any mod using this method on the player quite as extensively as Sexout FleshedOut does.

[dewguru]

I saw in the OP where it mentioned disabling the Spell Check for New Vegas. This is because FO:NV's GECK apparently doesn't include a default dictionary so you're constantly being prompted to confirm you spelled things right.

 

Instead of tossing it to the side and then risking breaking immersion or impact when a failed word slips by and appears in a key piece of dialog, you can make do using the one from FallOut 3.

 

These directions were pulled from the Nexus's GECK Power-Up page, and it worked fine for me.

 

1. If you have Fallout 3 GECK installed, simply copy the folder "lex" from your Fallout 3 folder into your New Vegas folder (assuming you didn't install GECKs somewhere else).
2. If you don't, download Fallout 3 GECK (http://download.zenimax.com/fallout/3/geck/Fallout3_GECK.exe), install it to any directory (but not into New Vegas directory) and do what is described above. You need neither Fallout 3 itself, nor update 1.5 for the GECK.

[DoctaSax]

Something else that I don't see mentioned here yet & might catch modders unawares:

a spell script may run one more time after the spell's been dispelled, causing all sorts of stuff to go wrong due to code processing one more time that you may no longer want to run. The best way to deal with this is to use a doonce/stage variable to "close" it, making sure that at the moment it's dispelled, nothing of worth in the script is processed anymore, other than the dispel itself:

 

So instead of:

scn yourspellscptname
Begin ScriptEffectUpdate

; do stuff 
dispel youractoreffectid
End
 

do:

scn yourspellscpt name
int idoonce

begin ScriptEffectUpdate
if idoonce == 0
; do stuff
set idoonce to 1 ; if all you needed it to do is done
else
dispel youractoreffectid
endif
End
 

[Halstrom]

 

Something else that I don't see mentioned here yet & might catch modders unawares:

a spell script may run one more time after the spell's been dispelled, causing all sorts of stuff to go wrong due to code processing one more time that you may no longer want to run. The best way to deal with this is to use a doonce/stage variable to "close" it, making sure that at the moment it's dispelled, nothing of worth in the script is processed anymore, other than the dispel itself:

Ahh yes, I've experienced that with other scripts to so use this, I also like to add a counter in to reduce lag and give time for things to update sometimes so the script only runs completely every 50th time (or 200th, or whatever) as I've experienced scripts running before items have been equipped or something added by the script isn't there yet. There is also an issue with RemoveMe, if you call it twice you can cause a CTD, so you need to block it from running a second time before the script is actually removed.

Set iCount to iCount + 1
if iCount > 49 && iRemoving < 1
   Set iCount to 0

   ; *** Check Script is Ok to run, set to 1, if you just want to pause it set it to 0, if actor is dead or item/script not required then set it to -1, GetDead can false trigger passing through Doors & Fast Travel / Wait / Sleep on NPC's so best put a filter counter on it like below.

   if rZActor.GetDead
       Set iDeadCount to iDeadCount + 1
       if iDeadCount > 9
         Set iOkToRun to -1
       else
         Set iDeadCount to 0
       endif
   endif

   if iOktoRun > 0

   ; *** Do Stuff, if script finished set iOKToRun to -1

endif

if iOkToRun < 0 && iRemoving < 1
   Set iRemoving to 1
   RemoveMe (or Disable or Dispel ThisEffect)
endif

[Nverjos]

Do to discovering that GetLos will CTD on some actors I need to change around a script. GetDetected and IsActorDetected don't work for what I need, they don't work on player as the caller. So I see this GetHeadingAngle but I'm not sure I understand the mechanics behind falloutNV and its degrees.

 

From what I understand the direction being looked at is 0, and direct west and east are -90/90 respectively. So what is directly behind, 180 or -180? Or does it count down, from 180 to the -90(do west) back down to 0...

 

Basically I need a way to detect if the back is turned away from another actor, player.GetHeadingAngle actor > 45 & what? < -45 or > -45, I can't for the life of me figure out how FNV is reading the negative left angle. Does it go 0, to -179 and count down to -90, or 0 to -1 and count to -90?

 

Will NV engine even read that as between 45 and -45 angle? Never used the geck language or made a mod for FO3 or FNV so I'm confused on this mechanic. I've tried virtually everything, and so far I can't get it to work 100%

[DoctaSax]

I use

if (player.GetHeadingAngle DocMitchellRef < -134) || (player.GetHeadingAngle DocMitchellRef > 134)

in my asschecking script to detect whether the doc's somewhere behind the player, ie 45ish degrees to the left and right respectively, like an upside down V

 

so straight ahead from the calling actor is 0, right back is 180/-180, left is -90, right is 90. Don't worry too much about specifying either a 180 or -180. < -179 and > 179 do the trick just as well, give or take a degree.

(which coincidentally is not at all in line with the way the gamebryo engine usually handles trigonometry, but that's a different story)

[Nverjos]

I use

if (player.GetHeadingAngle DocMitchellRef < -134) || (player.GetHeadingAngle DocMitchellRef > 134)

in my asschecking script to detect whether the doc's somewhere behind the player, ie 45ish degrees to the left and right respectively, like an upside down V

 

so straight ahead from the calling actor is 0, right back is 180/-180, left is -90, right is 90. Don't worry too much about specifying either a 180 or -180. < -179 and > 179 do the trick just as well, give or take a degree.

(which coincidentally is not at all in line with the way the gamebryo engine usually handles trigonometry, but that's a different story)

 

Ah thank you. I had tried 135 but wasn't getting it to work, so I began thinking maybe the game read it differently and was trying to figure out the perpheral perspective from a 45 degree angle forward. But looking at what you got, I think I mixed up my carrots >, <. Math was never my strong point in college, I would have kept my 3.8 if not for 4 advanced trig classes that I passed only by kissing ass.

 

Again thank you.

[prideslayer]

I mentioned these things before in the old NG thread and possibly one or two others, but this is probably a better place to park it.

 

...

 

 

Using playidle is probably not the best solution for a randomized animation system like SexoutNG

I disagree here..

 

PlayIdle would be perfect for NG, and I do intend to switch to it at some point, simply because doing so would negate all the camera stupidity with TFC in sexout. The only reason sexout uses pickidle is that I haven't come up with a clean way to use playidle.

 

The only way I can see at present, which is terribly ugly, is to reference every sexout animation by name in a script. By necessity this would be a really ugly script (in fact a set of scripts) due to limits on script size, nesting depth, and the number of branches conditionals can have.

 

All of this because, IIRC, you cannot add idles to a formlist from the geck or from a script -- and even if you could, I don't believe playidle would work with a ref var holding an idle pulled out of the list. I could be wrong about this not working from a script standpoint, I don't remember if I tried.

 

I've wracked my brain for a way to address this via NX and come up empty as well, it seems there's always a hurdle preventing NX alone from doing it -- a change or two to NVSE is probably required as well, be that an IDLE type variable and new list type to hold idles, an NX_Playidle that casts the form ref to an IDLE, or.. whatever.

 

This doesn't mean I've given up on the 'ugly' solution, which would work fine, I just need to think about how to keep the ugliness to a minimum.

[DoctaSax]

Well, the reason I said it's probably not a good idea is exactly the need to specify the editor-IDs for each actor, for each anim, and how that would make for some big-ass scripts. Using numbers + pickidle still seemed the better option for a big system because of that, although I hadn't thought of the possibility the playidle function could be expanded in nvse.
 

How does TFC factor in?

 

[astymma]

TFC comes in since 1st and 3rd person use different skeletons so they use different animation paths. The Sexout animation folder is found only under the 3rd person skeleton base path and not the 1st person base path. So calling PickIdle while in 1st person won't select any anims not found in the 1st person base path. Generally means Sexout has to swap to 3rd and then PickIdle to use the correct anim base path to find the correct idles.

[DoctaSax]

Okay. So you guys wanna provide for a little POV functionality or something?

[Halstrom]

Here's a bit of strange annoying trivia I discovered yesterday by accident, if you use GetIsCreature or GetIsSex on the robot follower EDE it will freeze the script as it seems neither applies to it. I didn't try any other robots, I hope the others work ok, maybe he's special having multiple variations.

[prideslayer]

astymma & doc, That's not a TFC thing, that's just a 1st/3rd person thing.

 

TFC enters in because pickidle will not play an idle on the *player* if the camera is in 3rd person but not in TFC -- playidle will. So I could ditch the delay and tfc toggle, and all the problems that come with me 'blindly' toggling TFC off and on without being able to check what state it's in to begin with.

 

Hal, GetIsCreature should not freeze it... are you sure on that one? If it does for certain, you can always use that NX skeleton function, NX_IsUsingSkeleton It was the first or one of the first to make it in; you give it a skeleton name and a ref and it will tell you if the ref is using that skeleton.

playerRef.NX_IsUsingSkeleton "_male" ; returns 1
playerRef.NX_IsUsingSkeleton "dog" ; returns 0
somedogref.NX_IsUsingSkeleton "_male" ; returns 0
somedogref.NX_IsUsingSkeleton "dog" ; returns 1

Just.. another option. My original intention was to use this to pick animations based entirely on the skeleton and to hell with all this figuring out what kind of creature it is business. Never got around to it, can't remember why, but the function works.

 

edit: no idea what skeleton ede is using... heh.

[astymma]

Well, there's 4 EDE's... all creatures, all using meshes/creatures/eyebot/skeleton.nif

 

I would think NX_IsUsingSkeleton could also determine 1st and 3rd by checking for _1stperson or _male. Heck, you may need to be checking for both to determine a human. That is, assuming _1stperson isn't a special handler that still retains the _male return value.

[Halstrom]

astymma & doc, That's not a TFC thing, that's just a 1st/3rd person thing.

 

TFC enters in because pickidle will not play an idle on the *player* if the camera is in 3rd person but not in TFC -- playidle will. So I could ditch the delay and tfc toggle, and all the problems that come with me 'blindly' toggling TFC off and on without being able to check what state it's in to begin with.

 

Hal, GetIsCreature should not freeze it... are you sure on that one? If it does for certain, you can always use that NX skeleton function, NX_IsUsingSkeleton It was the first or one of the first to make it in; you give it a skeleton name and a ref and it will tell you if the ref is using that skeleton.

edit: no idea what skeleton ede is using... heh.

 

According to some Debug "Mark" type messages, my script below freezed everytime at EDE in the formlist at the GetIsSex, so then I put a GetIsCreature filter in to avoid that check on creatures,  and got the same result, I removed EDE from the formlist being read and it all works fine including Lily, Rex & Cheyenne, all of who are creatures of course, and human NPC's just not EDE.

; *** Add to Current Companion lists if Possible Companions are Teammates
                Set iCnt to ListGetCount SexoutSLActorDataPossibleCompanions
		Label 1
		if iCnt > 0
			Set iCnt to iCnt - 1
			Set rNPC to ListGetNthForm SexoutSLActorDataPossibleCompanions iCnt
			if rNPC.GetIsSex Female
				if rNPC.GetPlayerTeammate
					Set fDistanceToPlayer to rZPlayer.GetDistance rNPC
					AddFormToFormList SexoutSLDataCurrCompanionsFem rNPC
				else
					if NX_IsInList SexoutSLDataCurrCompanionsFem rNPC
						ListRemoveForm SexoutSLDataCurrCompanionsFem rNPC	
					endif
				endif
			elseif rNPC.GetIsSex Male
				if rNPC.GetPlayerTeammate
					Set fDistanceToPlayer to rZPlayer.GetDistance rNPC
					AddFormToFormList SexoutSLDataCurrCompanionsMale rNPC
				else
					if NX_IsInList SexoutSLDataCurrCompanionsMale rNPC
						ListRemoveForm SexoutSLDataCurrCompanionsMale rNPC	
					endif
				endif
			endif
		goto 1
		endif

I imagine EDE wouldn't have any bones unless his antenne twitch

[prideslayer]

I will look deeper into EDE as soon as I am done with current tasks, poke me if I forget, it might be a few days.

 

NX_IsUsingSkeleton might be able to tell the difference between _male and _1stperson, but that isn't the problem. IsPC1stPerson works fine for that, and is what sexout currently uses. The problem is in knowing if tfc (The 'ufo' cam) is currently enabled or not.

 

If it's not -- it must be, to start animations on the player with pickidle.

If it is -- it has to be disabled before the knockdown, or the knockdown doesn't work.

[Halstrom]

I will look deeper into EDE as soon as I am done with current tasks, poke me if I forget, it might be a few days.

 

NX_IsUsingSkeleton might be able to tell the difference between _male and _1stperson, but that isn't the problem. IsPC1stPerson works fine for that, and is what sexout currently uses. The problem is in knowing if tfc (The 'ufo' cam) is currently enabled or not.

 

If it's not -- it must be, to start animations on the player with pickidle.

If it is -- it has to be disabled before the knockdown, or the knockdown doesn't work.

EDE is no problem for me currently I just wanted to throw it out there so people knew or perhaps knew why

[sen4mi]

 

I mentioned these things before in the old NG thread and possibly one or two others, but this is probably a better place to park it.

 

...

 

 

Using playidle is probably not the best solution for a randomized animation system like SexoutNG

I disagree here..

 

PlayIdle would be perfect for NG, and I do intend to switch to it at some point, simply because doing so would negate all the camera stupidity with TFC in sexout. The only reason sexout uses pickidle is that I haven't come up with a clean way to use playidle.

 

The only way I can see at present, which is terribly ugly, is to reference every sexout animation by name in a script. By necessity this would be a really ugly script (in fact a set of scripts) due to limits on script size, nesting depth, and the number of branches conditionals can have.

 

All of this because, IIRC, you cannot add idles to a formlist from the geck or from a script -- and even if you could, I don't believe playidle would work with a ref var holding an idle pulled out of the list. I could be wrong about this not working from a script standpoint, I don't remember if I tried.

 

I've wracked my brain for a way to address this via NX and come up empty as well, it seems there's always a hurdle preventing NX alone from doing it -- a change or two to NVSE is probably required as well, be that an IDLE type variable and new list type to hold idles, an NX_Playidle that casts the form ref to an IDLE, or.. whatever.

 

This doesn't mean I've given up on the 'ugly' solution, which would work fine, I just need to think about how to keep the ugliness to a minimum.

 

 

I think the best way for dealing with this kind of thing involves synthetic scripts.

 

In other words, I would build a table that represents the name -> anim relationships, and then write a short program in python (or whatever) that turns that table into GECK code of some sort. If you run into size limitations, you can alter your code to do things in blocks (which you might implement using quest stages.

 

Now when you need to add new anims all you have to do is update the table. Oh, and re-run your generating code. Oh, and copy and paste the results into place. Oh, and it's tempting to have the script be smart enough (and retain enough state from prior runs) that you only have to copy and paste the changed blocks. Oh, and it's tempting to try and optimize for minimal block changes. Argh! Nothing is ever easy!! (And it's smart to utterly avoid my "tempting" suggestions.)

[jaam]

You may want to check the scripting ability built into FNVEdit now. They should help with repetitive work.