General Geck help (Unequipping armor edition)

[BruceWayne]

Or if you do it like shown above...

 

If you assign a getisid for the GOODBYE-topic you supercede the standard isVoiceType condition. It's the same as for GREETING.

 

I did that, so the NPCs still have their combat or idle chatter, like hellos and such.

[BruceWayne]

At first, I made the exact same mistake...

[BruceWayne]

Sorry, for hijacking your thread again, user, but I need some help with AI-packages and maybe someone knows how to solve it.

 

I'm trying to give my NPC some new daily routines and have made some packages with different things to do. Starting times and durations are set, as are conditions when not to do them.

The problem I'm having now is, that they won't do them at all or only some of them. They don't seem to switch to the next package they have assigned to them and are always running the package, when I first meet them. "Continue when PC is near" is supposed to do that, if I understand it correctly, but unfortunately the NPCs seem to do it, even if that box is not checked. Are there some checkboxes to avoid, so that they automatically choose the next package in line?

 

I can provide more info on the AI-packages, if that's needed.

[DoctaSax]

Ah, packages. A neverending source of joy

I'm assuming that you already know packages on an npc are evaluated top to bottom in the list, so the more generic stuff should be last. Just putting it in there in case.

Other than that, the 'continue if pc is near' flag would've been my first choice to switch off, but you got that covered.

Try switching off other flags like 'must complete'/'must reach location'. Every time I try to use them, they seem to mess things up more than they help.

[BruceWayne]

Ah' date=' packages. A neverending source of joy

I'm assuming that you already know packages on an npc are evaluated top to bottom in the list, so the more generic stuff should be last. Just putting it in there in case.

Other than that, the 'continue if pc is near' flag would've been my first choice to switch off, but you got that covered.

Try switching off other flags like 'must complete'/'must reach location'. Every time I try to use them, they seem to mess things up more than they help.

[/quote']

 

Yeah, it seems so easy, whip up a package, throw it in and have them do like you told them to.

 

Actually I thought it doesn't really matter in which order I load them. I'm going to try to put them in chronological order to see if it helps.

I'm using "Must reach location" and "must complete" on my travel packages that I assign per script. I assumed that's what it has to be to make them actually reach their target, without running some other package interference.

 

But on those others I have, like sleep, sandbox, patrol they seem to do nothing.

[BruceWayne]

My guess would be:

if yourcondition
 if isPCSleeping 
 ShowMessage yourmessage  
 endif
endif

You most likely have to run this in a menumode 1012 block. Otherwise it would likely do nothing, as the player is never outside of that menu when sleeping/waiting.

[srayesmanll]

You could check during MenuMode 1012 (the sleep/wait menu). While the menus open, GameMode is suspended, and you can check whether the pc is actually sleeping, or just IsWaiting. If neither, then the player hasn't selected yet. Something like:

 

Begin MenuMode 1012

if (IsPCSleeping == 1)

;Do X

elseif (playerref.IsWating == 1)

;Do Y

else

;Do nothing

endif

End

 

Other than that, I really can't see how it can be used.

[DoctaSax]

I'm using "Must reach location" and "must complete" on my travel packages that I assign per script. I assumed that's what it has to be to make them actually reach their target' date=' without running some other package interference.

 

But on those others I have, like sleep, sandbox, patrol they [i']seem [/i]to do nothing.

 

I've had a few instances where there'd be normal to turn on but were better left turned off. Can't remember much of the details, but that's probably because it didn't make sense in the first place.

 

---

user: If your main script isn't fast enough to catch it, you can try using it to add a token to you, whose object script *should* do the IsPCSleeping every frame in MenuMode, then remove itself when back in gamemode. Casting a spell that checks it in the ScriptEffectUpdate block might work too.

An alternative would be temporarily setting the fquestdelaytime a lot lower.

[srayesmanll]

Ok' date=' what sort of script would I put that in? As I said a quest script wouldn't work I don't think.

[/quote']

 

I think it would. In the soRapist main Quest script, I have the GameMode block for the main part of soRapist. Then at the bottom of that script I have the of MenuMode blocks (actually several) to set a quest variables when either the companion wheel or standard conversation opens. When the menu is closed, GameMode start running again, so I check for the variable set, and do what it needs to (in this case, scan for companions since the companion wheel and standard dialogs are normally the only place to add/remove companions). Take a look in soRapist and you'll see what I did.

[DoctaSax]

Well, even if it doesn't catch it all the time: random is good

Using the game's innate wobbliness to emulate a GetRandomPercent is in fact 'nicely done', if you think of it.

[BruceWayne]

Quick heads up on the packages:

 

It seems that I've trolled myself. It took me way too long to figure this out...

 

 

[BruceWayne]

getitemcount yourformlist > 0

 

If the target reference has any item in that list this evaluates to true.

[DoctaSax]

I'll try the quest script i guess. It's not a vital message so if it doesn't play every time they sleep it'll be all right.

 

Did you test this method, user? I'm thinking of adding some things to MM 1012 in a regular-interval quest as well, so it'd be nice to know I don't need to get fancy with it

[DoctaSax]

Thanks! In my book, if it ain't four hours minimum, it ain't sleep, so that should do fine.

 

Instead of rand you could go "set iSleepNumber to 1 + GetRandomPercent * 4 / 100", btw. Maybe that does work in MM.

[brocules]

I'll sneak a help request here aswell; I've added dialogue to several NPCs across the wasteland, and I want all the top level topics I've added to share one timer for when they can appear again, after the player has selected them once. Currently I'm casting an actor effect on the player in the result script and then checking if the player has it active on the top level topics.

 

Everything else is fine but the duration of the actor effect ingame seems way off. I set a duration for the effect from the dropdown menu to 1 hour, which is displayed as a value of 3600 in actor effects item list. But its nothing close to 1 hour ingame, so if anyone can shed light what the deal is with the duration and its correlation to actual ingame time, I'd appreciate it.

 

Or if theres a better way to implement a timer like this, my knowledge of GECK is still very basic.

[BruceWayne]

I had a similar problem and found this solution:

 

I'm handing out a token instead of a spell. The dialogue topic becomes unavailable, if the NPC has the the token in it's inventory. This can of course work the other way around. Condition for dialogue is GetItemCount tokenname > 0.

 

The token itself has a script running on itself that removes the token, whenever 24 hours are passed.

[brocules]

I had a similar problem and found this solution:

 

I'm handing out a token instead of a spell. The dialogue topic becomes unavailable' date=' if the NPC has the the token in it's inventory. This can of course work the other way around. Condition for dialogue is GetItemCount tokenname > 0.

 

The token itself has a script running on itself that removes the token, whenever 24 hours are passed.

[/quote']

 

Tried to make it work with a token but I it works even less than my actor effect thingie, I'm doing something horribly wrong...

 

Here's what I have as the token script:

 

 

 

scn sexoutSuppliesTimerScript

float timer

begin GameMode

   if timer < 43200
       set timer to timer + GetSecondsPassed
   else
       removeitem sexoutSuppliesTimerToken 1
   endif

end

 

 

 

The script is attached to the sexoutSuppliesToken, and it gets added to the npc's inventory but it doesnt get removed after the 12 hours it's supposed to. It's so simple yet I can't get it to work, I've looked around some of the other token scripts from other sexout mods and I just can't see what I'm doing wrong.

[DoctaSax]

You don't seem to say who/what to delete the token from. Well, indirectly you say the token should be removed from its own inventory, because the implied reference of an object script on a token is the token.

Either go player.removeitem etc, or use RemoveMe.

[jaam]

Most likely, you are too far from the container for the script to run.

 

Personaly, I use a Formlist and a quest script.

Quest scripts always run, though slower the others scripts. And formlist persist properly if you use AddFormToFomrList.

[BruceWayne]

Tried to make it work with a token but I it works even less than my actor effect thingie' date=' I'm doing something horribly wrong...

 

Here's what I have as the token script:

 

*snip*

 

The script is attached to the sexoutSuppliesToken, and it gets added to the npc's inventory but it doesnt get removed after the 12 hours it's supposed to. It's so simple yet I can't get it to work, I've looked around some of the other token scripts from other sexout mods and I just can't see what I'm doing wrong.

[/quote']

 

Try this one for the token:

scn TokenScript

ref refOwner
float fTimeStart
float fTimePassed ; in hours

begin onAdd
set refOwner to getContainer
if refOwner.getItemCount SOASex24CDToken > 1
	refOwner.removeItem SOASex24CDToken 1 1
endif

set fTimeStart to GameDaysPassed
end

begin GameMode
if fTimeStart == 0
	set fTimeStart to GameDaysPassed
endif
set fTimePassed to (GameDaysPassed - fTimeStart) * 24
if fTimePassed > 24
	RemoveMe
endif	
end

 

The OnAdd block sets the reference and ensures that only one token per inventory exists.

 

The Gamemode block contains countdown and removal.

[brocules]

Try this one for the token:

 

*Code*

 

The OnAdd block sets the reference and ensures that only one token per inventory exists.

 

The Gamemode block contains countdown and removal.

 

This seems to be working, much appreciated.

[DoctaSax]

How would I go about unequipping any outfit (anything that takes up the upperbody slot) the player might equip except for any on a formlist?

 

Shame there's no formlist parameter on the unequip function, like with RemoveAllTypedItems.

 

Try this:

 

ref rClothingItem

set rClothingItem to characterRefID.GetEquippedObject 2
if rClothingItem.IsInList FormlistID != 1
characterRefID.unequipitem rClothingItem 0 0/1 (1 if you want to hide the message)
endif [/Code]

 

Can't declare that ref variable in a result script though, as astymma would have me remind you.

If that doesn't work, there's something about the IsInList function that doesn't work properly with inventory refs but let's cross that bridge when we get to it.

[DoctaSax]

Nope. Didn't work. Basically I stuck the nude bodies in the form list' date=' put on a legion recruit armor and it never unequipped it.

 

Like you thought it might.

[/quote']

 

Eh, great.

I shoulda gone & checked NG's undressing of course...

 

ref rClothingItem

set rClothingItem to characterRefID.GetEquippedObject 2 ; check UB-slot gear
if  -1 == ListGetFormIndex FormListID rClothingItem ; 
characterRefID.unequipitem rClothingItem 0 0/1 ;(1 if you want to hide the message)
endif [/Code]

 

*should* do the trick if done in a spell or object script.

[Halstrom]

Nope. Didn't work. Basically I stuck the nude bodies in the form list' date=' put on a legion recruit armor and it never unequipped it.

 

Like you thought it might.

[/quote']

 

Eh, great.

I shoulda gone & checked NG's undressing of course...

 

ref rClothingItem

set rClothingItem to characterRefID.GetEquippedObject 2 ; check UB-slot gear
if  -1 == ListGetFormIndex FormListID rClothingItem ; 
characterRefID.unequipitem rClothingItem 0 0/1 ;(1 if you want to hide the message)
endif [/Code]

 

*should* do the trick if done in a spell or object script.

 

Just watch for a crash if the character is naked, I think in this case it should be ok, but I found if I did any functions using a null rClothiingItem like GetHealth, it would lock the script up.

[DoctaSax]

Fair point, Hal. Stuff like this always has a coupla catches that you easily forget if it's been a while

 

User, you should add a small check:

set rClothingItem to characterRefID.GetEquippedObject 2 ; check UB-slot gear
if rClothingItem
if  -1 == ListGetFormIndex FormListID rClothingItem ;
characterRefID.unequipitem rClothingItem 0 0/1 ;(1 if you want to hide the message)
endif
endif [/Code]