PAPVAFS11

That is correct. The M key unfortunately has no effect.

This shows up whenever I have Toggle Sky enabled. It's a horizontal pink plane attached to the camera that's only visible when looking up or down. It goes away when it's disabled. Anyone know what's up with this? I would also appreciate help with getting rid of these weird outlines on everything, if anyone knows. They go away when the camera's moving.

I seem to recall that there was a way to have AND conditions and OR conditions function together in things like spells and dialogue. So that, in one case, you could have an actor need to be Mr. X for a spell to work, and that he would need to have either his Y or Z value at 30. Could anyone help me remember how this was done?

I was able to find it myself, but I appreciate the tip. I've already got it running, and it seems to be working fine. I think SPID is easier for me to wrap my brain around, but I appreciate the advice all the same. This will help me with a music flavor system I've been thinking about, though, so this is something I'll surely need to remember later.

I have multiple mechanics included in my mod that are meant to affect all human actors, the player included. At present, the existing mechanics are implemented directly into the HumanRace form. This is acceptable for my mod as it's not intended to be compatible with anything else, but I know this is bad practice, and I'd like to find a more flexible solution. With respects to my previously-posted thread, I do not intend to have fast-looping timers on all human actors, and will have substantial checks to minimize unnecessary processing.

I have several applications for looping short timers. I'm at a loss for how I would change them to be reactive instead of proactive, as several of them monitor for actor value changes, like STR, END, and AGI. For example, I have a speed penalty handler to clamp SpeedMult penalties. I'm also using this as a workaround for SpeedMult penalties on NPCs, as I couldn't get spell-driven SpeedMult changes to work on them. This interacts with both armor enchantments and conditional spells that add to or subtract from the speed penalty AV. Another script I wrote handles encumbrance, and that relies directly on SPECIAL values in the encumbrance calculation itself. I don't currently know of any events that trigger on AV changes or spell applications, so I wouldn't know how to break from timers. My playtesting showed me that delays greater than a second were also very clunky for the player, so I tried to keep it short. At the very least, I do have conditional checks inside the timers (IsDead(), GetValue() != fLastValue, etc.) to be sure they actually need to do something, or if they should stop where they are. NPC timers are also usually around 3.0-5.0 seconds. If there's any way I can improve these, I'm all ears. I can post the full scripts if need be.

Event OnTimer(Int iTimer) if iTimer == 1 DoRepeatingTimerStuff() if akOurActor == Game.GetPlayer() || akActor.HasKeyword(ImportantActorNeedsFastTimer) StartTimer(0.1,1) else StartTimer(Utility.RandomFloat(0.5,1.0),1) endif endif EndEvent The intent of this is for repeating timers assigned to many objects to not all tick at once, and to give some headroom for them to finish what they're doing before the timer ticks again. I ask this question as I don't know how expensive RandomFloat() is. That also leads into this example: Event OnSomethingHappened(Actor akHappener) if akHappener != Game.GetPlayer() Utility.Wait(Utility.RandomFloat(0.1,0.5)) endif DoEventStuff() EndEvent Again, in the case that OnSomethingHappened() is called by many simultaneous sources, the Wait() is called with a RandomFloat() to nudge them into happening at different times. Do these work as I want them to? I don't have anything I need them for, but I'd like to work them into habit if they're useful.

I did some digging, and I found the cause. It turned out that this was an incompatibility interaction between Survival Options and my personal mod. The root cause was me editing the HC_Manager quest and script, which broke Survival Options' own edits. That ended up turning the survival cell reset multipliers to zero. Whoopsie. I've decided to shelf Survival Options, since it turns out I'm already getting the features I wanted out of it from Unlimited Survival Mode.

I was unfortunately able to reproduce the issue after a standard new game. If it is of any importance, I will note that the timescale adjustment is part of one of my mods. I can't say for certain whether this would have any effect on cell respawns, but I'm not sure I've touched anything else relating to them.

I'm having a problem where cells are respawning way too fast. This is a reset inside half an hour, with a slower timescale than usual. Here's my usual testing routine: Hardcore mode, timescale at 5. coc ConcordUndergroundExt from main menu. Give myself an AK, do SPECIAL/character name setup, kill the raiders around Preston. Move north, clear out the raider camp near the mole rat pack. Move through the woods to Red Rocket, fight mole rats as necessary, dump unnecessary inventory items at Red Rocket. Move north through Sanctuary to the cliff across the river. Scale cliff, clear raider camp under transmission tower. Move south to Abernathy Farm, passing by campsite random encounter location. Finish loop by returning to Concord.By the time I get back to Concord, the raiders have respawned. Doing additional loops also shows that the other camps have respawned, and random encounter locations have reset. I would post a mod list, but none of the mods I have are published anywhere, and most of it is original work. Does anyone know what could be causing this?

Does anyone know where the player's unspent perk points are stored, if anywhere? That'd be the first place to start looking.

I am interested in learning about InstanceData. I'd like to be able to create my own alternate ammo system for my personal project. Is this offer still good?

Unfortunately, that solution is indeed impractical for my purposes. I want the player to be able to swap between headlamps, gun lamps, and power armor lamps on the fly. I was hoping someone might've figured out an F4SE solution, since I figure that's the only way to cut into engine-level problems like this. I guess I'll just have to make due with basic circles.

Last I tested, that doesn't work. The problem I'm referring to is that the game drops gobo textures after the first one is loaded. So, for example, if you switch on your PIP-Boy light, its gobo will load fine. If you put on power armor and switch on the headlamp, the gobo will fail to load, which also tints the entire flashlight slightly pink (since it's technically overlaying a "missing" texture). The reverse is also true. Near as I'm aware, this applies to any gobo texture used, at least on flashlights.

I'd like to be able to add detail to my flashlights instead of just settling for a simple circle.

Ideally with a condition. At least as far as GetVelocity Z in the console tells me, walking up a hill doesn't increase the player's speed on the Z axis.

IsTalking was what I was looking for. It works best, since sprint breathing is technically the player talking. The cut-off is kind of harsh, and I'm not sure how to script it better, but it's better than overlap. Thanks for the pointer.

I'm incorporating gas masks into my mod, and I want to make the player play appropriate breathing noises while they're equipped. I already have the framework for it, and I've been able to add conditional sprint sounds successfully. What I don't know how to do is how to smoothly implement a constant breathing sound. I figure it'd be easy to just slap on a script that plays a looping sound, but I don't want it to overlap with spoken dialogue, if I can help it. I'd also like to be sure that the breathing noise doesn't get in the way of dialogue, either. Does anyone have any ideas on how I could do this?

I was so used to using GetHealthPercentage in conditions that I didn't even realize that existed. Thanks for the tip.

This is just what I needed, thank you. Now if only I could get the flashlight state for NPCs...

I feel like I've seen people ask this before, but I wasn't sure how to phrase the search terms. I'm trying to make a spell that makes the player regenerate AP faster as long as they avoid completely exhausting their AP. If the player hits 0 AP, the bonus is supposed to go away until they fully regenerate their AP. My problem is that I have no idea how to get the player's actual maximum AP. I can get their base value, but I don't know how to get that after modifications, like hardcore penalties, AP bonuses, and so on. Is there a reliable way to get this value?

Might be a bit hacky and not very NPC-friendly, but wouldn't it be possible to just make a fake "door", that's really an activator, that sends the player to a single cell? Inside would be a matched "door" that gets pointed to its partner once its partner is built. You could prevent any weird quantum entanglement exploits by limiting its construction to a unique resource the player only ever finds once. If you wanted more, you could copy all that as need be. Cell, "doors", and resource.

I want to have creatures behave differently when the player has their light on, but I haven't found a good way to detect the PIP-Boy light state, and my searches in the past have been discouraging. Has this changed since I last looked?

If this offer is still good, I'd like the vanilla feral ghoul models skinned to the standard human skeleton. No modifications needed save for what it takes to make them fit. It'd be perfection if I could get the basic sack hood swapped to use the feral ghoul skeleton, too.

I've found most of a solution through the use of visual effect objects linked to scripted magic effects and enchantments, but it's imperfect. There's a noticeable jitter in the attached object when moving the camera around. I'll need to investigate more before I can say anything with confidence. Edit: Scratch that. View models for weapons and other items render in front of the object. I don't think this method will work for the intended purpose.