Fallout2AM

because during a noisy combat a script doesn't always do what it is supposed to do and with the correct timing. However I could introduce that feature as optional, so if something goes wrong I can simply uncheck it, this seems a fair compromise

in a heavily modded environment it wasn't answering properly, especially during fights. I considered a smooth reaction of the player being more important than changing its speed continuously because of external factors interfering with it, and I dropped that idea.

That's the same script I wrote you few days ago :wink: rSelf probably must be implicit. you can do it with a local var, a quest.var, or checking the status of other refs etc. yours the choice

I assume you never experienced these downsides. I didn't mess with fatigue, I introduced a new stat.

when they don't finish the execution, it means they crash at a certain point.

I did a similar concept, but didn't change the speedmult to avoid downsides (have a similar mod on skyrim, it's annoying). It will block you from running when you're tired, and you will become tired soon if you are more encoumbered

There's no separated loader for the editor, you should simply create a shortcut and edit it, adding -editor at the end, like this: "C:\Steam\SteamApps\common\Fallout New Vegas\nvse_loader.exe" -editor

do you hear the classic equip sound, when it happens?

because it's not super easy and requires some line of code. I can think to at least 2 approaches: 1) introduce your own custom crafting system, at least under certain conditions, so that vanilla won't be touched 2) remove in game all the player's items, move them on a temporary container, transfer all the items of that container to the player, open the craftin menu and craft, when you close it you will do the inverse - trasferring the items from the player back to the container, and taking the player's item from the temporary container back to the player.

I assume you want to reverse the effect when you UnEquip, but that syntax is not correct, you should make 2 different blocks. Begin OnEquip ; Do my code End Begin OnUnequip ; Do the contrary End Now take this as it is, I should test it. But I do feel that when you change aggressivity it won't simply stop attacking you, it is possible that it requires some extra StopCombat or something like that.

change every: Let SomeVar := SomeValueto : Set SomeVar to SomeValue

I already do that, but it's not the same than mtidle. If you work with animations you know what I mean.

if fStartingTime exists, then it means I already defined it and I don't mean to define it again. If it doesn't exist, it means this script is running for the very first time and fStartingTime is zero. At that point, define it to GameDaysPassed. It's the same if you use a variable to stage the script, this is just another solution, you can choose whatever solution you want once you get the sense. I don't see why, what do you mean? No, what you wrote will be executed more and more without any effect Maybe you wanted to compare to 1, like this: If DoOnce == 0 Set DoOnce to 1 ; do the code Endif; do the code will be executed only once. I use boolean expressions in my scripts because they're slightly faster than compare to a specific value, but the sense is the same. Exactly. The sense should be "check the difference between the ending time and the starting time, until this difference is 1 day". Oh now I understand what you're doing. It's more or less like when in FO3 you ask to your robot (WASDWorth?) if he has water or if he can say a joke but only once for a day. Well you could still use the Once a day, you just need to put another level in the dialogue - Can I ask you for something? - ONCE A DAY - This subject will be among the other subjects but will appear only once a day. - Sure, go On - Extra step is necessary - Can you tell me a joke? - And now your random sentences. They all will be back to the main level, so you won't have the Can I ask you for something? anymore. - 1 ) Joke 1 - RANDOM - 2 ) Joke 2 - RANDOM - 3 ) Joke 3 - RANDOM

I don't know how it works for creatures, since I always looked at actor's skeleton mainly. But for humans actors, both prefixes, suffixes and headers are hardcoded, I found them all loaded in memory. You should stick with the existing ones and couldn't add new ones, so everything you can do is a replacer. I managed to make a custom localized per gender idle animation, but it was just a lucky smart exception, I couldn't think to any other exceptions like this. When you use a file name which is not contemplated, it will be taken in consideration based by its header, it will replace the "real" animation file with the same header if its file name is more on top (alphabetical order), vice-versa it won't be considered if it's on bottom. If the file misses, or the header is invalid, a valid one will be checked inside some specific subfolders (i.e. \female) However I understood you are working with a creature, so you shouldn't have problems in this, you can do whatever you want since the skeleton can be localized in whatever path you want. The visibility controllers are often used because the same animation handles different weapons.

That's a common issue I had many times in the past, I know how to reproduce it but I never managed to find a solution different by RELOAD THE PREVIOUS SAVE, which is bad :smile: So basically you changed vanilla's water height to another value and then back to the normal value? or your worldspace is not mojave but a new worldspace?

In the script you'll define the starting time and then you'll refresh the ending time. When their difference is one day, you're ready to go. If you want a timer which is detached by any other event except the time, you make a script and attach it to a quest with a low delay I didn't test it, but this more or less should explain the concept: Scn MyTimer float fStartingTime float fEndingTime Begin GameMode if fStartingTime else Let fStartingTime := GameDaysPassed endif if fEndingTime - fStartingTime < 1 Let fEndingTime := GameDaysPassed else ; one day's passed endif endInstead if you want to check that only on a trigger, you could store the variables on a script attached to a quest, along with all the other variables you need to track down in your mod, you don't flag Start Game Enabled, then you change the values using the script of the activator. Something like this: -The quest script Scn MyQuestVars ... float fStartingTime float fEndingTime ... -The activator's script: scn MyActivator int bDoOnce Begin OnTriggerEnter Player If bDoOnce if MyQuestVars.fEndingTime - MyQuestVars.fStartingTime < 1 Let MyQuestVars.fEndingTime := GameDaysPassed else ; one day's passed endif else Let bDoOnce := 1 Let MyQuestVars.fStartingTime := GameDaysPassed endifThe only exception is the player's waiting 24 hours inside the trigger zone, if you think it's a risk you should add a MenuMode block.

What about a single script for every door, something like this: Begin OnActivate Let rMyRef := GetSelf Let rMyActor := GetAR if GetStage MyQuest > some_value GetSelf.Activate rMyActor endif EndEDIT: thinking about it, it's probable that GetSelf must remain implicit, omitted. I would need a GECK to test.

It shouldn't be the case, too. Usually you find yourself in Goodspring and nothing more.

Can I know how you solved it?

Everyone should use the animgroups in the folder of their skeletons, so _male is only for human actors. However you can convert them.

If you don't use FNVEdit or GECK, Lutana has a search function for console like in Skyrim

If you want to make a fast 10 minutes test, make a copy of your esp and then change its header to esm with FNVEdit, then try it in game your new esm. I have reasons to believe the npc won't behave in that way anymore and will patrol correctly.

A script like that causing CTD or freezes is very rare. Very. I only wanted to share few small suggestions if I can, my personal approach, because it seems your mod is starting to be big and full of things. If you're modding not vanilla, and you got issues, go back in vanilla or you could have non objective results that lead you to mistakes; you'll have plenty of time in the future to try compatibilities along with other mods, but only once you know your mod works fine in vanilla, so go back vanilla for now. And even if it seems obvious to say, I prefer to repeat it - this doesn't mean you must untick the ESPs in the LO, this means you must erase everything and make a brand fresh install. Then, it's philosophies... but... I never rely on NVAC when I mod. But patchign at 4 Gb is essential for me. Then, once you're modding vanilla and you have weird issues, take a look at what FNVEdit and PU think about your mod, eventually if you have few scripts take a minute to recompile them all one by one. Ignoring issues "because they're small trifles and they're absolutely not connected to the current weird issue I'm having" is not really the kind of approach that usually helps me to solve weird problems, because due to their weird nature of course if I assume that they are not related I'm just lieing to myself: they're weird just because I still have not understood the cause, right? :lol: Last, even if I'm more obvious than before but it's ok and I prefer repeating myself more and more... never duplicate objects or npcs when there's a script attached, and take a big breath and careful look at everything you do when you create a primitive, either a trigger zone or a bound etc.

mmmh... Why that last "Activate"? didn't you want to make them explode? (A couple of things, which are more for your curiosity: the b in front of the Occupied variable should be an i, you are admitting at least 3 values so it's not a boolean-it's just to make things easier when you need to read a script you wrote the month before and you're not remembering parts; the Return in that spot is unuseful - in bigger scripts, using too many Returns could lead me to not see issues when something doesn't work as intended, so I personally tend to not use them if they are not necessary)

If you are attaching the script to the chair, you could get who's activating it, which is the reference you need. At that point you don't need to check anything else, even forgetting the IsCurrentFurnitureRef.