Fallout New Vegas GECK & Scripting Help 101

[Guest tomm434]

What do you mean "timer that doesn't decrease too fast or too slow" ? They all work simmilar.

 

If you just need help making a timer, you can check out my guide

http://www.loverslab.com/topic/33209-scripting-in-fallout-new-vegas-for-dummies-part2-variables/

You can place it in quest gamemode block since it will always be running while player is wearing power armor.

 

 

Also you can add a value to timer of player uses additional functions of Power armor. So, more functon he uses, the more quickier will timer end.

And if player powers armor up, you will substract a value from timer. Just simple as that.

[prideslayer]

I have a boilerplate timer I use everywhere I need one. It's dead simple.

 

float fDelay
float elapsed

; .... 

Begin Gamemode
  set elapsed to GetSecondsPassed
  if (fDelay > 0)
    set fDelay to fDelay - elapsed
    return
  endif

 ; ...

 ; set fDelay wherever you need to, whenever you need to.
End

In a script effect update block, use ScriptEffectElapsedSeconds instead of GetSecondsPassed.

[Halstrom]

To account for time lost waiting/sleeping & fast travel I uses this if you want to work in hours and have an increment per hour, this makes calculations for stuff happening at 30min intervals.

 

 

; *** Alter Script run Hours to catch up after Fast Travel / Wait / Sleep
			if fLastUpdateHour <= 0 || fLastUpdateHour > 24
				Set fLastUpdateHour to fCurrHour
				Set fLastUpdateDay to fCurrDay
				DebugPrint "Preg1Fert %n: Reset LastD %2.3f, LastH %2.3f" rZActor fLastUpdateDay fLastUpdateHour
			endif
			Set iDaysPassed to fCurrDay - fLastUpdateDay
			if iDaysPassed > 0
				DebugPrint "Preg1FertF %n: iDaysPassed %4.5f, fHoursPassed %4.5f" rZActor iDaysPassed fHoursPassed
			endif
			if iDaysPassed < 0
				DebugPrint "Preg2Fert %n: FertToken Time Travel Occurance %5.4f" rZActor  iDaysPassed
				Set fLastUpdateDay to fCurrDay
				Set fLastUpdateHour to fCurrHour
			endif
			if iDaysPassed > 7
				DebugPrint "Preg2Fert %n: FertToken Time Travel Occurance %5.4f" rZActor  iDaysPassed
				Set fLastUpdateDay to fCurrDay + 7
				Set fLastUpdateHour to fCurrHour
			endif
			Set iDaysPassed to fCurrDay - fLastUpdateDay
			if fCurrHour > fLastUpdateHour
				Set fHoursPassed to fCurrHour - fLastUpdateHour
			elseif fCurrHour < fLastUpdateHour
				Set fHoursPassed to (fCurrHour + 23.999999) - fLastUpdateHour
;				DebugPrint "Preg1FertF %n: Midnight Passed, Days%2.0f, Curr%2.5f, Last %2.4f" rZActor iDaysPassed fCurrHour fLastUpdateHour
			endif
			Set fHoursPassed to fHoursPassed + (iDaysPassed * 24)
			Label 1
			Set fHourStep to .5

<Do Stuff>

				Set fLastUpdateHour to fCurrHour
				Set fLastUpdateDay to fCurrDay
				Set fHoursPassed to fHoursPassed - fHourStep
			Goto 1
			endif ; *** Catchup Time stuff

 

[ArgusSCCT]

Making the timer is not what I've got a problem with its the whole formula that goes into deciding how much "energy" is subtracted when the player moves or when time passes. 

 

For example here's the formula it uses to determine how much power should be drained and yes it does take into account how much "functionality" the player is using. 

	set fDrain to fDrain + fDelta * timescale * PPADrainMult * fBaseWatts / 3600

In this case fDrain is how much it has to subtract, no clue what fDelta is supposed to be or why it was named that way, aside from that it gets modified everywhere in the old script, PPADrainMult is a global variable and fBaseWatts is an accounting of the total watts plus whatever power armor mods the player is using and each adds a unique amount. I had a solution for that though, since it appears that the old mod's script checks if the player has those mods equipped. I however, want to put those values in each mod's own script and add it to fBaseWatts. I know you can modify variables in different scripts but if I add things to fBaseWatts through another script will it work? My other solution would be to make fBaseWatts a global instead and add to it through each different script. 

 

In short the issue is that if I come up with something new it has to be calculated very carefully, the old mod uses a lot of calculation to set up a particular amount of power drain. 

[nyaalich]

Mathematically (or mathemagically if your name is Donald), delta indicates the amount by which something is changed.  Rate of change at a certain moment in time.  That said, can't tell you how it's being used in that script.

 

Of course, there are no parentheses in there anyway so...*shudder.*

 

You don't (and generally shouldn't) need to make it global.  I'm sure there's a quest in there somewhere that's tracking all of this.  The variable basewatts just needs to be in the script for that quest.  Guessing that the ppadrainmult is in fact not a vanilla global.

[Halstrom]

Ahh well, yeah make fBaseWatts a global or NX_Variable, global better than Quest variable usually as there's a big problem with Quest Variables causing index errors in other plugins reading them if any are deleted/renamed or added. NX_Variables are best if you want interact with other esp's or for them to be able to read the Battery charge or send info without being masters, but require PrideSlayers NX_Extender to be installed of course.

 

You can do:

 

rActor.NX_SetEVFl "PowerArmor:fBatteryCharge" 70

 

and any other mod can do

 

Set fBatteryCharge to rActor.NX_GetEVFl "PowerArmor:fBatteryCharge"

 

and know it's at 70%

 

No crashes if either mod isn't installed it just returns zero's or the last saved value (they are saved separately to the the other variables in the game save, so not removed by clean saves)

[nyaalich]

Perhaps I misunderstand his use of "mods."  I was thinking armor mods like how there are weapon mods in NV as opposed to esps.

 

I thought that it was generally frowned upon to add globals?

[ArgusSCCT]

Mathematically (or mathemagically if your name is Donald), delta indicates the amount by which something is changed.  Rate of change at a certain moment in time.  That said, can't tell you how it's being used in that script.

 

Of course, there are no parentheses in there anyway so...*shudder.*

 

You don't (and generally shouldn't) need to make it global.  I'm sure there's a quest in there somewhere that's tracking all of this.  The variable basewatts just needs to be in the script for that quest.  Guessing that the ppadrainmult is in fact not a vanilla global.

 

Yeah, this script in particular is a mess, I'm dividing it into three different things, one for initializing the power armor, another to check for charge and another for speed related multipliers and what not. The old script uses like 30 variables or something? It's just unmanageable, don't know how the previous author managed to work with that and I'm beginning to suspect it was the reason as to why so many people complain that the mod was buggy. 

 

Generally I don't like globals, they've told me they're more trouble than they are worth. So far I've only used one global from the old mod, and it was only because it was one of the few scripts that was understandable, functional and well written. Though if there is a way to get rid of those globals I will use it, Some more experienced programmers I know personally have told me to avoid using that stuff. If it is possible to modify fBaseWatts through another script and adding to the value instead of assigning something else to it I will do that. I'm still not so sure about how modifying variables between scripts work. If I modify it through another script  while the original script is running, does it have the value that the original script gave it? That's my main question.

 

Yeah PPADrainMult is in fact not a vanilla global and by mods I do mean Power Armor mods, not the esps, though I really should find another name for that.

 

 

Ahh well, yeah make fBaseWatts a global or NX_Variable, global better than Quest variable usually as there's a big problem with Quest Variables causing index errors in other plugins reading them if any are deleted/renamed or added. NX_Variables are best if you want interact with other esp's or for them to be able to read the Battery charge or send info without being masters, but require PrideSlayers NX_Extender to be installed of course.

 

You can do:

 

rActor.NX_SetEVFl "PowerArmor:fBatteryCharge" 70

 

and any other mod can do

 

Set fBatteryCharge to rActor.NX_GetEVFl "PowerArmor:fBatteryCharge"

 

and know it's at 70%

 

No crashes if either mod isn't installed it just returns zero's or the last saved value (they are saved separately to the the other variables in the game save, so not removed by clean saves)

 

 

I would use NX_Extender, but I'm afraid that will cause complaints when I release it, especially if I tell people they have to go to another site to download NX_Extender. And while I don't care for people who complain about x or y, I'm mainly doing this for myself and a friend who got the permissions. I still have to consider the users at least a little bit. 

[Halstrom]

Well the only options to communicate with other plugins are globals and token counting which I also due in my mods, if someone wants to know how pregnant an actor is there are 0-100 unscripted PregPercent tokens that can be counted by a dependant mod in dialogue conditions.

 

And 've looked through quests & Topics, checking use info by Doctor NPC's & Doctor Quests and I'm just further confused, I have a Entry "Can you check if I'm Pregnant?" Preg Testing Topic that currently works fine in the MedicalClinic with Dr Usanagi, but I think I'm going to need someone to hold my hand & just point out to me exactly which quest I should drop it into so all doctors give the "Can you check if I'm Pregnant?" option. Is it GenericAdult or VDoctors, I'm just not getting how this actors dialogue mumbo jumbo is working

[Odessa]

I added dialogue for STDs to all the doctor's in Wear and a Tear.

 

Created quest: SexoutWearSTDDoctorsQuest

 

Added all the topics to it, including zSexoutWearSTDDoctorsASK (Can we talk about STDs?), which is marked as top level.

[Guest]

	set fDrain to fDrain + fDelta * timescale * PPADrainMult * fBaseWatts / 3600

 

My guess Delta is a value tweaked by MCM in a future application. I mean maybe right now there's no MCM function like that, but changing Delta was useful to decide if the armor was consuming too much or too little, maybe by the user itself, via MCM.

[Guest]

Added all the topics to it, including zSexoutWearSTDDoctorsASK (Can we talk about STDs?), which is marked as top level.

 

Just a note about top levels: please be careful to set the conditions (GetIsID / whatever), in the topic or in the quest condition tab. I saw scary things coming out from top levels with unproper conditions, really without any sense!

[prideslayer]

Well the only options to communicate with other plugins are globals and token counting

Ahem.

[Guest tomm434]

 

Well the only options to communicate with other plugins are globals and token counting

Ahem.

 

Can you name more of them please? (not sarcasm, I'm really interested since quest variables are out of the case).

 

 

 

By the way, how do mods can correspond through globals? Do I use complier overrider?

[prideslayer]

 

 

Well the only options to communicate with other plugins are globals and token counting

Ahem.

 

Can you name more of them please? (not sarcasm, I'm really interested since quest variables are out of the case).

 

1. NX vars.

2. Buildref'd UDFs.

 

By the way, how do mods can correspond through globals? Do I use complier overrider?

I wouldn't use globals. The script won't compile in the GECK if the mod supplying the global isn't loaded, and if compiled with it loaded, will probably crash at runtime if it's not loaded at that point.

[Guest tomm434]

of course! Thanks.

[prideslayer]

You can combine them as well to solve the kind of problem Odessa was talking about a while back, WRT quest vars. This requires support of the mod though so it won't solve that exact problem. If you want to not cause that problem in your own mods though..

 

1. Create a UDF that takes the name of a quest var as a string parameter and returns the value of the quest var.

2. Create an NX var that holds a ref to your UDF, so other mods don't have to buildref.

 

So other mods that want to get at your quest vars without having your mod as a master or using buildref can do something like:

ref remoteUDF
float someQuestFloatVar

let remoteUDF := playerREF.NX_GetEVFo "mymod:questvargetter"
if (remoteUDF)
  let someQuestFloatVar := call remoteUDF "nameOfQuestVar"
endif

Of course more error checking and such would be good, but that is a general idea.

[Guest tomm434]

That makes my head spin but I get the idea.

 

You know, I was looking for a way for people to export variables for my mod whle they update Sexout and then import them backl.(my mod depends on Sexout and it has some important story variables to be stored - you remember that in my log I always set variable to 1 to play the scene?). Export is easy(con_scof + showquestvars) but import is tricky.

 

And NX might be the way out but that's too much work. I think I'll have to do it for each variable separately right?

[prideslayer]

I don't really understand what you want to do, give me a rundown of the actions a player would take?

 

1. save game (saving NX vars in the process)

2. quit

3. update mod.

4. load game.

 

That will work fine with NX vars.

 

If they clean save in there anywhere to 'clear' out your mod, then NX will clear as well. On load it checks the modlist against what's in the save in order to account for changes in the load order (since it's saving formIDs and refs and has to change them to match), so if it encounters IDs for a mod that is no longer there, they are discarded during the load.

[prideslayer]

Ah let me clarify that last bit.

 

NX vars are only cleared if they are refs/formIDs of a missing mod, or if they exist ON a ref from a missing mod. If you set a bunch of NX vars on the player, they will not be discarded, unless they're refs that point to things in a missing mod, since the player ref is still available.

 

You can set a bunch of NX floats on the player in any mod, do a completely clean save, and they will still be there. This is actually something I want to address at some point, and is the historical reason why the NX vars are generally prefixed with the name of the owning mod. My intention was to record the NX var origin and clean out any owned by a missing mod, but I never got around to figuring out how to determine which mod was calling the NX functions.

[Guest tomm434]

prideslayer, to update sexout, I have to switch it off thus switching off every mod that depends on Sexout(including TTWQuestOverhaul). So, quest variables will reset.

People need to do a clean save on Sexout when they update it, yes?(instruction says that)

 

 

I wanted to add export and import button in MCM. With placing NX variables on player, I can avoid that but that's a lot of work and I'll have to make update script which will transform all quest variable into player NX variables for people who don't start new game. Hell no. (but it would be right thing to do, I know.)

 

 

 

 

 

[prideslayer]

prideslayer, to update sexout, I have to switch it off thus switching off every mod that depends on Sexout(including TTWQuestOverhaul). So, quest variables will reset.

People need to do a clean save on Sexout when they update it, yes?(instruction says that)

What instructions say that? You don't need to do a clean save for sexout. I never do. It has an update script that runs whenever the version changes. Usually there's nothing for it to do. When there is, it does it.

[Guest tomm434]

really? I thought I read it somewhere. Ok, less to worry about then.(Although I just realise that are nice ini functions that allow you to save ini setting  -  just type "ini" at gribblesh site). That's pretty easy and would be funny to play but I see no practical point in that.

[Xilandro]

Seems like this is the most active FO scripting thread in the world, so I will live here =D

And I need some help =\

Trying to rotate player's X angle.

Extremely simple code that will run only for one frame

    if IsKeyPressed 208 != DownArrow
        set DownArrow to IsKeyPressed 208
        if DownArrow
            player.rotate x 1
        else
        endif
    endif

If player's X angle is > 0 - script will work just fine. But if X angle is < 0... player's X will immediately go to 360 degrees, visually everything will be fine though, until I move the mouse. If i will move it - X angle will drop to 90.

 

[ArgusSCCT]

 

	set fDrain to fDrain + fDelta * timescale * PPADrainMult * fBaseWatts / 3600

 

My guess Delta is a value tweaked by MCM in a future application. I mean maybe right now there's no MCM function like that, but changing Delta was useful to decide if the armor was consuming too much or too little, maybe by the user itself, via MCM.

 

 

I don't know what it does to be honest, been trying to figure it out for a while now and I can't. The mod doesn't have an MCM, I don't know if it was ever going to and I wouldn't be surprised if it was just abandoned because it became unmanageable by that point. I could post the script with fDelta, but believe me it has fDelta all over the place and that's why I can't figure out what it does, plus they weren't big on abstraction, I'm pretty sure this script attempts to do most of the essential parts of the mod on its own instead of separating them into different scripts. The name "fDelta"  doesn't help either. 

 

Out of curiosity what's this UDF thing everyone keeps referring to? Is it something that NX uses?