Jump to content

Fallout New Vegas GECK & Scripting Help 101


Recommended Posts

This was a classic Geckism I had a week ago, I had 6 similar scripts in SexoutDrugging, all using this same code, 5 worked fine the other caused a CTD that required me to press the power button and restart the computer, couldn't even open task manager.

 

DebugPrint "DrugFadeAdj %4.2f, %4.4f" fCurrDrugCount fDrugFade; *** shows variables as good values 30-150 & 2.02 when I edit out the line below and let it run.

 

Set fCurrDrugCount to fCurrDrugCount - fDrugFade ; **** This line crashes it if not commented out.

 

I also tried with the same crash result

Set fCurrDrugCount to fCurrDrugCount - 1

 

and

Set fCurrDrugCount to fDrugFade

 

and

Set fCurrDrugCount to 1

 

The only other thing I had changed earlier in the script was this line and it turned out to be the real problem

 

Set fDrugFade to 2 * ((201 - SexoutSQVAR.iDrugDuration) / 100)

 

Changed to this and it seems fixed, maybe it didn't like the 201-otherscript.variable

 

Set fTempA to 201 - SexoutSQVAR.iDrugDuration

Set fDrugFade to 2 * (fTempA / 100)

 

Still got me stuffed if that was the issue why this failed

 

Set fCurrDrugCount to 1

 

I changed all the other scripts to the same code anyway just in case, but they were all working fine.

Link to comment

Well, maybe another stupid question: How do I figure out, what kind of creature I have ... for example, when talking to them via SmalerTalk.

Faction doesn't seem to work, because spawning creatures are not added to the specific creatur faction, only the "over all creature" faction.

I want to make something similiar to the "CumBuff"-Effect in Sexout,  to switch specific races to peacefull and back, and get the ability to talk to them, as long as the effect continues. Maybe someon has some advices how to make this.

Link to comment

OH! so many questions ...

 

1.) Any idea how to undress an npc or the pc via script/dialogue-result?

 

The only way I can imagine - as there is no "unequip armor" function, and I don't know which armor the pc/npc wears at the moment I want to do it - is to add a certain armor first, then equip this certain armor, and at least remove this added armor - but maybe there is a smarter solution?

 

2.) The PC shall give an NPC a armor/clothing which is in a certain clothing-formlist (for example "give me some sexy clothing!").

 

How can I do that? I can use the barter menu. But how can I figure out, which item was given? And how can I make the NPC to equip this certain but unknown armor/clothing? Or is this task just to difficult for a noob like me?

Link to comment

OH! so many questions ...

 

1.) Any idea how to undress an npc or the pc via script/dialogue-result?

 

The only way I can imagine - as there is no "unequip armor" function, and I don't know which armor the pc/npc wears at the moment I want to do it - is to add a certain armor first, then equip this certain armor, and at least remove this added armor - but maybe there is a smarter solution?

 

2.) The PC shall give an NPC a armor/clothing which is in a certain clothing-formlist (for example "give me some sexy clothing!").

 

How can I do that? I can use the barter menu. But how can I figure out, which item was given? And how can I make the NPC to equip this certain but unknown armor/clothing? Or is this task just to difficult for a noob like me?

You can check what an Actor is wearing in any slot with a function called something like :

 

 

Set rCurrOutfit to rZActor.GetEquippedObject 2

 

 

Slot 2 is the upperbody, there is a list in the GECK help http://geck.bethsoft.com/index.php?title=GetEquippedObject

 

Make sure rZActor actually equals something first or you can crash the script, you can also cause a crash by trying to remove nothing worn by an actor if they have nothing worn in that slot.

 

So do this to remove outfits.

 

 

Set rZActor to GetContainer ; *** (or GetSelf depending on script type)
if rZActor ; *** this checks the Actor is valid many times on the first scan Set rZActor to GetSelf will actually return null which will cause a crash on the next line as it tries to see what "nothing" is wearing

    Set rCurrOutfit to rZActor.GetEquippedObject 2

    if rCurrOutfit ; *** this checks there is something worn to avoid removing "nothing" and causing ScriptCrash
        rZActor.RemoveItem rCurrOutfit 1 1
    endif
endif





 

You can also check if the Actor is wearing anything in a formlist with:

 

if rZActor.GetEquipped Formlist

 

There are a heap of Formlists in SCR populated already with stuff like SexoutSLClothAppearFormalSexy or SexoutSLClothBindingsCollar many of them can be populated by the player using Sexout Clothing Evaluation

Link to comment
  • 2 weeks later...

Most of my Scripts look something like this:

Set rZActor to GetContainer
Set iCount to iCount + 1
if rZActor && iCount > 299 && iRemoving < 1
     Set iCount to 0
;*** Do Stuff
    if iScriptFinished
          Set iRemoving to1
          RemoveMe
    endif
endif

The if rZActor just checks rZActor equals something, anything except "NULL" as I've found with some functions you might end up trying to remove or add items to an object or actor called "NULL" and that can cause a script to freeze or crash. You may get away without it 99.9% of the time, maybe on some script types more than others, but I've seen it fail at least a few times. The counter just reduces the frequency that the "Do stuff" happens to every 200th scan or run of the script. Some scripts where I want a fast response I skip it completely or set it to 99. That is 200 script scans not seconds, dependant on the script type that could be be .1 of a second delay or 10 seconds, effect scripts seem to naturally run a slower frequency than object scripts.

 

I wouldn't do that inside an OnAdd or ScriptEffectStart as they only run once (supposedly anyway) you may not reliably get an Actors REF in an OnAdd so I Prefer to use a GameMode or ScriptEffectUpdate myself.

 

The iScriptFinished I might use if the script is done and I don't want it to run again or I detect the actor is dead because scripts keep running on corpses.

On that subject I also may need to check that the token is actually on an Actor too by:

if rZActor.GetIsSex Male || rZActor.GetIsSex Female

This stops scripts running inside crates or when left on the floor or carried by a Creature.

Link to comment
  • 4 weeks later...

I wanted to write down the bad mistake I did, that made me erasing many hours of work with a single click. It was a mixture of more newbie mistakes, but who knows if this could avoid someone else to lose their work. :)

 

First, it mainly comes from the fact I don't use PU (I had negative side effects, after that I refused to use it), so for the ones that use it I'm sure it is easily avoidable.

 

When I debug my little scripts, when it doesn't compile and I don't see the mistake I start placing semicolons on the lines until I find the "bad one". Second thing, I don't put away from a line the semicolon even if it still doesn't compile, since there could be more than one mistake, so I add many semicolons until it starts compiling, then I go backward.

 

Now, there's a thing that allows to create an error that GECK doesn't warn at start. I create a quest.variable (quest.NPC), then I create an npc (but also a topic, etc.) with the same ID (no matter if it will have a different REF). It allows me to do it, I didn't tried it with PU on, but I feel it too would allow this. Now if I'll use that variable on conditions or scripts, I'll be able to do that. But if I'll reopen the script where it was declared, it won't compile anymore since it sees an error on the same name used in another object.

 

Of course PU would address the line, so you can easily find which var shares the same name and change it. Me, I did the mistake to place several ; until I found the wrong variable name (I have many of them, I wasn't opening that script since a while, so meanwhile I did many modifies in the mod before noticing the shared name, at start I couldn't understand where it was coming from).

 

This caused the problem: when finally the script compiled, it automatically erased all the conditions using the variables with semicolons, pointing to a quest.null value. Now I have hundreds conditions to check, in AI and dialogues. The only ones that are not erased are of course those written inside the other scripts.

 

Cherry on the cake: I do daily backups, but of course for Murphy's law today I forgot to do it so I've lost all the work of yesterday, and it was a lot!!!. :-(

Link to comment

Join the club.  I recently re-wrote, using a completely different method, 3 scripts that weren't working right due to this '>' instead of this '<'.  Always keep your eye on those little buggers.

 

> = 8 hours down the drain.

< = Priceless.

 

 

Link to comment

I wanted to write down the bad mistake I did, that made me erasing many hours of work with a single click. It was a mixture of more newbie mistakes, but who knows if this could avoid someone else to lose their work. :)

 

First, it mainly comes from the fact I don't use PU (I had negative side effects, after that I refused to use it), so for the ones that use it I'm sure it is easily avoidable.

 

When I debug my little scripts, when it doesn't compile and I don't see the mistake I start placing semicolons on the lines until I find the "bad one". Second thing, I don't put away from a line the semicolon even if it still doesn't compile, since there could be more than one mistake, so I add many semicolons until it starts compiling, then I go backward.

 

Now, there's a thing that allows to create an error that GECK doesn't warn at start. I create a quest.variable (quest.NPC), then I create an npc (but also a topic, etc.) with the same ID (no matter if it will have a different REF). It allows me to do it, I didn't tried it with PU on, but I feel it too would allow this. Now if I'll use that variable on conditions or scripts, I'll be able to do that. But if I'll reopen the script where it was declared, it won't compile anymore since it sees an error on the same name used in another object.

 

Of course PU would address the line, so you can easily find which var shares the same name and change it. Me, I did the mistake to place several ; until I found the wrong variable name (I have many of them, I wasn't opening that script since a while, so meanwhile I did many modifies in the mod before noticing the shared name, at start I couldn't understand where it was coming from).

 

This caused the problem: when finally the script compiled, it automatically erased all the conditions using the variables with semicolons, pointing to a quest.null value. Now I have hundreds conditions to check, in AI and dialogues. The only ones that are not erased are of course those written inside the other scripts.

 

Cherry on the cake: I do daily backups, but of course for Murphy's law today I forgot to do it so I've lost all the work of yesterday, and it was a lot!!!. :-(

 

Why exactly would not you use PU ?

Link to comment

 

Why exactly would not you use PU ?

 

It gives me too many warnings, continuosly, about navmeshing, things that it shouldn't concern. Nonsense comes when it doesn't give me navmesh warnings when in game navmesh doesn't work; instead it gives warnings on cells that in game work perfectly, this makes me feel so upset since I have so many issues in game with navmesh breaking my architectural plans...

Anyway, this happened not once but twice, that's why I stopped using it. Figure the scene: click here - clickclickclickclickclick on warnings, click there, clickclickclickclick on warnings etc. One more click and one of these enervating popup boxes finished under the render window and I didn't notice it. What happened was that the End Results compiler wasn't popping my mistakes anymore, compiling everything. I do some typos when I write, it's rare that I write 10-20 lines without a typo. I let you figure the rest... I just say that I had to take back my previous backup.

Anyway life isn't that hard without PU telling me the exact line where I have an issue, since I compile short blocks and I put semicolons when I really can't see the mistake. My issue in the previous post was really a combination of inexperience and stupidity mixed together.

 

Now, if there's a way to tell PU "look my typos on scripts, not everything else! At least until you'll decide to really solve my navmesh problems...", well I'll be very glad to learn how to do it... :)

 

PS Now I could seem prevented on PU, since when I had the above issue. But I just want to add that I used it twice. And twice I found holes in navmesh cells that were working perfectly, and triangles messed up like if navmesh was been "optimized" (optimization...). I wasn't opening or modifying those cells since a long time and I found it after some time, so I can't understand how that happened. Of course I can't say it's PU, I even don't know if it's able to do things like that. But I know its enervating warnings about navmeshes. And I'm prevented, maybe.

 

Out of topic: I gave a try to NVSE even if I was still contrary (need to learn better the basics), after 4 days I realized this and I really wondered how could I live without it until now... NVSE is really the perfect toy! All hail NVSE!

http://www.youtube.com/watch?v=xudHKDLyzTc&feature=youtu.be

Link to comment

Consider an earlier version of PU, A.J. - it won't give you as many warnings and still help you with your scripts. I reverted to 1.6 after the latest started giving me popups about a user-made BSA being loaded, and a few other things - leftover FO3 stuff pointing to textures I don't have etc. 1.7 reactivates more warnings, including the less important ones, but the warnings by 1.6 are still really helpful in order to find & fix script mistakes without too much aggravation.

Link to comment

You do realise that the description on Nexus asked the users to comment on which warning should be kept or not ?

 

A user that knows things well surely should provide a feedback like that. When I'll feel I'll be able to give a feedback, I surely will report things like that. At the moment I just prefer sticking with the consciousness that I started 4 months ago using the GECK and few days ago using NVSE. I have no past experience in modding, or scripts, or whatever, I can not even provide feedbacks by analogy: essentially, my issues with PU could come from the fact I'm still not enough crafty to use it. I hope you didn't misunderstand the tone of my first post, my purpose was to underline a mistake I did because of inexperience and how it caused a lot of errors all around the whole mod (hoping to leave a warn for those like me that just started writing the first scripts) and not doing an action against a software that SURELY deserves a lot of attention since you all use it.

Link to comment

You do realise that the description on Nexus asked the users to comment on which warning should be kept or not ?

Ah, yeah, it's in the readme. But then, I make it a point not to do anything on the nexus other than download. Truth be told, I was used to 1.6, & tried switching to 1.7.3 only recently. The missing textures are from leftover FO3 effect shaders, and there's not much I can do about them being missing other than extracting them from the FO3 BSAs - & then who knows, I might get used them being around for me, and forget others won't have them. If you try to work on a plugin that has the DLCs as masters, it becomes a bit spammy - missing base forms, form overrides that are replaced by duplicates, non-persistent refs that should be persistent...

1.7+ is not wrong in pointing any of that out, but when it's about stuff I won't fix anyway, it gets you into a habit of clicking "yes to all" & then you might click away something that pertains to your plugin. So I just switch out versions depending on what I do - seeing as I'm busy with scripts only atm, and so far it's involved going in & out of the geck and looking up a few things in the DLCs quite a bit, 1.6 is enough for me right now. I just wanted to point out to AJ he could do the same, not criticize PU, far from it. Whether those warnings should be kept or not, is really up to what different modders want to do - I may not have much of use for some of them, but others might. The number of warnings it gives about the DLCs probably explains why Obisidian switched off the warnings system in the first place - couldn't stand the walk of shame, I'll bet ;)

Link to comment

I just put up with the extra clicking, it's only 3x "Yes to all" for me, I consider it a small price to pay for the times something extra pops up, this has happened many times with simple script errors that don't show up in FNVEdit, that caused CTD's or just rendered scripts non-functional. and when it does I need to fix it. I see a lot of errors in many other mods in FNVEdit that could be easily solved by the mod owners if they had done a simple FNVEdit "Check for Errors" before uploading their mod.

Wow just realised I appear to be using GeckPU 1.4, didn't realise there had been updates :)

Link to comment

Since I still have PU even if I don't use it, I give you a more detailed statement.

I just opened it now with two of the cells I'm modifying in these days: 25 popups in total. Now if I look at them I see: 4 navmesh errors, 7 missing vanilla textures, 2 missing textures from me (at least it was asking for 2 textures while nifskope has no paths in it on the BSShader, probably is some residual I carried from Blender), more missing vanilla textures, a mtforward that can't be loop, some tri, some egt, missing node / vanilla skinned / parent / etc.etc.... these are warnings about vanilla content I used in my cells. If you load FalloutNV.esm without any esp, you can see almost the same kind of errors when loading for example Hoestler home cell or Steel Mill, these are quite on top. Still Mill for example has errors about raiders and missing normal maps on their teeth, same error in my esp in a location with raiders. This happens too often to me, not only on load, that's why after a while one of those popups ended behind the render window. Anyway I'll follow Doctasax suggestion about trying 1.6 after I'll finish this mod, since I see he had missing textures errors and 1.6 helped in that.

Link to comment

I'm making a sexoutified companion for my TTW playthrough, and I have created a couple of perks that are awarded to the player after he/she has completed a certain amount of sex acts with said companion. And currently I'm keeping track of the sex acts in a quest script, but I was wondering if I later on add more of these, if it'll be unnecessarily taxing to the game? Should I instead keep track by placing a check to every result script of every dialogue option that leads to sex?

 

So instead of having this as a quest script (simplified, I have bunch of other stuff in there aswell):

scn MyQuestScript

int iCounter

begin GameMode

if iCounter >= 40

    playerREF.addperk MyPerk01

endif

end

Should I just add

if iCounter >= 40

    playerREF.addperk MyPerk01

endif

To all the dialogue result scripts? I'm not sure how significant the impact is.

 

And another, similar question; I have a couple of timers that are a part of a quest script, and currently I have an if statement to determine if the script has served its purpose. But is this enough, or should I instead use this on a token and an object script instead so that it'll be removed alltogether after the script has served it's purpose and needs to be terminated?

 

Example:

 

 

 

scn MyTimerScript

int iControl
float fTimeStart
float fTimePassed ; gametime passed in hours

begin GameMode
 
if (iControl == 0) && (FollowerQuest.FollowerHired == 1) && (FolloweREF.GetInSameCell playerREF == 1)

    if fTimeStart == 0
        set fTimeStart to GameDaysPassed
    endif
    
    set fTimePassed to (GameDaysPassed - fTimeStart) * 24
    
    if (fTimePassed >= 7) && (player.IsInCombat == 0)        ; after 7 hours, start dialogue if not in combat
        FollowerREF.StartConversation playerREF, Topic01
        set iControl to 1        
    endif    
        
endif        
end

 

 

 

Is the above enough to ensure it's not unnecessarily taxing the game?

 

Link to comment

@Brocules: As DoctaSax says, simple quest scripts running at default delay shouldn't cause any problems. You should use 'stopquest' when it is finished, and you could use start/stop via dialogue to have only run when they are hired to really optimise it.

 

Be aware that while 'GameMode' blocks in quest scripts run once every (default) 5 seconds, they always run once every frame (eg: 30+ times a second) if put into object scripts, as do effect script updates. I suspect a lot of stuttering is caused by this in certain vanilla game locations.

 

Conversation scripts can be erratic; they work, sometimes work, never work or freeze the game. I believe Astymma posted some insight into this somewhere. Personally I try to minimise using them and always play test them a lot.

Link to comment

And hey guys, make sure you run your mods through FNVEdit's "Check for Errors" function before uploading, some errors maybe aren't an issue and can't be fixed, but I'm seeing a lot of NULL references in new peoples mods and that makes it harder for me to work out if the errors are related to any SCR changes & deletions.

 

It's saved me many times finding things I'd accidently broken in my own mods when working on them, usually just before I'm  going to upload it :)

I make a habit to check every update I do now before uploading.

Link to comment

And hey guys, make sure you run your mods through FNVEdit's "Check for Errors" function before uploading, some errors maybe aren't an issue and can't be fixed, but I'm seeing a lot of NULL references in new peoples mods and that makes it harder for me to work out if the errors are related to any SCR changes & deletions.

 

It's saved me many times finding things I'd accidently broken in my own mods when working on them, usually just before I'm  going to upload it :)

I make a habit to check every update I do now before uploading.

 

I followed your suggestion and took a look. I corrected the few null references I found, but there's a thing that remains:

 

[00:02]     " " [DIAL:00152CCA] -> Record marked as deleted but contains: Name, Priority,

[00:03]   Above errors were found in :GRUP Top "DIAL"

Error: record DIAL contains unexpected (or out of order) subrecord INFC 43464E49

Error: record DIAL contains unexpected (or out of order) subrecord INFC 43464E49

 

Googling the INFC thing, I arrived in a Skyrim article first, and an AWOP article later, but both were unrelated. AWOP thing was relating to a vanilla missing mesh but I have it on my game.

Googling the DIAL thing, I arrived to a Loverslab article about SexOut (http://www.loverslab.com/topic/4510-sexout-record-conflict-00152cca-dial/), where I read "The GECK assigns records more or less randomly" that leads me to think googling those codes shouldn't be useful then.

 

I'm wondering if it is important or if it one of those you wrote "some errors maybe aren't an issue and can't be fixed". I checked the dialogs, I found one of the first lines is in green and the record is that one. What I don't understand is that it has two columns (falloutnv and my mod), and in my column is marked for delete. I suppose I erased a dialogue from vanilla, does it make sense? its fields are totally empty (while if I open a random dialogue line, I see fields are filled). Could it be that it was already an empty topic from vanilla (so maybe a mistake), and when I saw it on GECK I erased it because I was thinking it was a mistake of mine? Oh god did I do some damage maybe?

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use