Greslin

Code for F4SE 0.6.20 seems to be here: https://github.com/dagobaking/fo4-autoload/tree/patch-5 Someone just needs to update the version numbers and recompile it, probably.

The Frontier melodrama didn't start with the lizard thing, and it went well beyond it. Setting aside all the crazy things that came out, it basically came down to the Frontier dev team making themselves a giant target (long dev time, hype, a bit of audience antagonism, etc.) and other people taking shots at it. Few mods are ever going to have that combination of high profile, high expectation, weird hidden nonsense, and just flat-out unfortunate turns of events. Writing-wise, the best "should I cut it" story rule I've ever heard is this: if it doesn't reveal character or advance the plot, cut it. Does this dialogue directly move the story? Does it reveal some aspect of the characters that we'll need to know in order to feel immersed in the plot? If not, it serves no purpose other than you getting a kick out of it being there. Cut it. At best, it's a weird random side joke. If it does serve a purpose, keep it and let your audience think whatever they want. It's your mod, not theirs.

Mostly I just wanted to confirm that someone else has seen the same issue. Thanks. I found an alternate method to get the results I need.

Hey, all. I've been beating my head against this for the better part of a week now, and I'm about to give up. What I'm trying to do in my own script is replicate what's happening here in the base Inst307Fight_BeaconQuestRespawn01 script: ObjectReference function GetRespawnMarker() if (myBeaconMarkerRef == None || myOffsetMarkerRef == None) myBeaconMarkerRef = myBeaconMarker.GetRef() myOffsetMarkerRef = myOffsetMarker.GetRef() EndIf int tries = 0 ;Offset the spawn point from the beacon. While (tries < 5) myOffsetMarkerRef.MoveTo(myBeaconMarkerRef, Utility.RandomInt(-32, 32), Utility.RandomInt(-32, 32), 0, True) myOffsetMarkerRef.MoveToNearestNavmeshLocation() ;Check for DirectLoS between the two markers to make sure we haven't offset through a wall or something. if (myOffsetMarkerRef.HasDirectLoS(myBeaconMarkerRef)) return myOffsetMarkerRef endif tries = tries + 1 EndWhile return myBeaconMarkerRef EndFunction Both of those markers are FlagPurple heading markers. I'm specifically focused on the HasDirectLOS() step, determining whether the LOS between two statics is blocked. Best I can tell, almost every other place in the base code that uses HasDirectLOS() checks between the player and the object, or else it's using HasDetectionLOS() instead. Unfortunately HasDetectionLOS() is useless for me here, because what I'm trying to do is programmatically determine whether there is something blocking the LOS of two static objects. That code above would imply to me that this indeed should work. However, every time I've attempted it in my own script, the HasDirectLOS() function call returns a false - even if it's a clear path. I've verified that they're on roughly the same Z plane, that the coordinates aren't screwy, and all that. My concern is that, looking at the Bethesda script up there, it wouldn't break exactly if HasDirectLOS() simply didn't work. It would just default to returning myBeaconMarkerRef. So I'm starting to wonder if HasDirectLOS() doesn't work at all. Does anyone else have experience with this that could spare me more days of frustration, or prevent me from just giving up on this effort completely? Any help is appreciated. Thanks.

Something like Be Exceptional? https://www.nexusmods.com/fallout4/mods/28222

Amen to that one. I've been doing a lot of work lately myself with dynamic spawning. The real challenge is about fixing the real problem, and being willing to deal with the consequences of that. For example - and this is from my own recent experience - boosting super mutant spawning right around DC. There is a big encampment just down the street from DC, but the mutants stay on their block and DCS stays in theirs. That doesn't make any sense for either group. And if you boost mutant spawning, you also increase the chances that those two groups are going to intersect in unpredictable ways. That is made more difficult when you consider how lightly fortified DC really is, in terms of exterior guard manpower. Bethesda's answer to that (and a rational one, given that they needed to actually get the game done on time) is to limit mutant numbers and strength to something DCS can deal with, and then keep their aggro zones fairly away from an overlap. And that works great until you throw more mutants into the mix, or expand their aggro radius, or make them tougher. Then DCS quickly gets overwhelmed. So you think on that a bit, and think, okay. Well clearly we need more DCS, so let's get more DCS out on the street. And maybe they need better guns, or armor, or more HP. And that works great, except there's a raider encampment on the OTHER side of DCS, and you've thrown the balance off there, so now you have to figure out what to do about them. Place more raiders? That's still not really addressing the core problem, because now you have tons of extra spawns for all three groups and you're causing problems for caravans, NPCs Travel, and the like. At this point the easiest answer is to throw it back to the user and say, you knew what you were getting into when you installed this mod. But that still doesn't actually solve the core problem: the completely unrealistic security capabilities of Diamond City, given the enemies they're surrounded by. If Bethesda wasn't protecting them with Code Magic, DC would have been thoroughly overrun a LONG time ago. The solution I finally opted for was a flexible reinforcement mechanic for DCS, where they could call in extra help when they needed it, and then the reinforcements would quietly despawn after the fun was over. That gave them strength as needed but without all of the balance wreckage. It's not just the number of things you touch, but making sure you touch the right things. Playing around with Bethesda game balance is a little like defusing a bomb. The green wire isn't always the right one to pull. :smile:

Meanwhile, your question is a little vague. What are you trying to do?

If you don't already know FO4Edit inside and out, take some time and get a refresher. It'll solve nearly all of your mod problems.

*wave* Well hi there!

I'm guessing it's a mod that lets Nate/Nora join the Pen-15 club.

You know, you could just ask for the game for Christmas.

I'll answer #2 for you. I got this tip off fadingsignal, the technique he used with True Storms and that I later used with Insult To Injury. There are about a dozen or so occlusion space markers, generally placed within the "fake" interiors such as the ruined houses in Sanctuary. You have to create a formlist of those markers, and then do a recurring check to see if the player is near one. This is the function I'm using in my ITI mod: bool Function IsPlayerNearSoundMarker() Actor PlayerRef = Game.GetPlayer() SoundMarkerArray = PlayerRef.FindAllReferencesOfType(ITI_FList_RainSoundMarkers as Form, 512.0) If (SoundMarkerArray.length) doMessage("Player in pseudo-interior space") return True Else return False EndIf EndFunction You can find that list of markers in the ESPs for either my mod or True Storms. It's not 100% foolproof, but for the most part that function will usually return true if the player is somewhere that would kick off the rain acoustic muffle. Again, can't take credit for it. Thank fadingsignal.

If that doesn't sort it, try renaming the ESPs without parentheses. Common delimiter characters like that can sometimes throw file name checking off in software that isn't looking for it. I don't know if NMM is or not, but that'd be my next thing to check.

What he said. Assuming you didn't attempt to add the new records directly into the ESM (that would be bad), the best way I know of to revert it in the ESP is to delete the records using FO4Edit. Then do a "Clean Masters". FO4Edit will rebuild the ESP's master records to include only the ones directly needed by the ESP.

More to the point, it allowed me to finally fix the Ashes bug in More Realistic Cats. God, that little critter's been a pain in my neck for a long while.

The first thing that crossed my mind here was, he's using an outdated F4SE. F4SE has undergone a lot of changes in the last year, and every new FO4 update has required a new F4SE release. So before you get any farther into the weeds, go make absolutely sure that your FO4 build is at 1.10.64 and your F4SE is the 0.6.5 runtime. If there's a mismatch there you're likely to have problems. Then check to make absolutely sure that any .dll plugin-based mods (Data/F4SE/Plugins) that you're using with F4SE are updated for 0.6.5, and that you're using the most recent versions. They need to be compiled for that specific version, or else they won't work. So double check and make sure it's all up to date. If you're absolutely, positively, super duper sure that this isn't the problem, and you're still instacrashing when you load f4se_loader.exe, then you're getting closer to having to do a full reinstall due to some weird esoteric issue. But my guess is you have something outdated in the mix.

Are you using NMM?

Okay, I had to go revisit Merge Plugins Standalone for myself. It's been a while, and I wanted to get you something other than lame guesswork. That "Plugin Selection" window is MP's way of saying, "This is what your plugins.txt file says about your current load order." The red files are the masters that the other checked plugins depend on, so you're going to want to check those. But you can't AFAIK rearrange the load order from this screen. Right click and uncheck all, then select the plugins you'd like to merge. Then check the plugins/masters that are now in red, and get things to where the OK button unlocks. MP will then start scanning through your plugins. The window after that is the one where you're actually doing the merge building. The window above is basically the same as the plugin selection popup that appears when you first open FO4Edit. If the load order problem persists, go take a look at it in NMM and see if the screwy load order is happening there. If so, you can fix it from NMM. If I'm still not grasping your problem, PM me your plugins.txt or post it here. Don't try to fix it in MP. We'll see what the root problem is.

I really, really, really wouldn't attempt merging the ESMs. Too many other mods depend on those assets and some expect to find them under their original filenames. I don't think I would touch Armorsmith, either.

THANK YOU. I don't know that I ever would have noticed that little dropdown. Dogmeat is visible again!

Okay, I'm at the end of my rope here. This should be working. I'm hoping one of the old hands around has figured their way around this particular odd CK problem: 1. Load CK. 2. Load Fallout4.esm and start work on a new plugin. 3. Create a duplicate of the DogmeatRace race record. New record is called DogmeatRaceCOPY0000. 4. Bring up the Dogmeat actor record and change its race to DogmeatRaceCOPY0000. 5. Dogmeat's skin texture vanishes and DM is now invisible. What the hell? One owner of the race, one owner of the skin, identical records. Why am I not getting a texture here?

Brought to you by Google: https://stuyk.com/fallout-4-creating-a-new-settlement-location/ Something like that?

I don't really think we need mod police, running QA on each mod and ensuring that everyone's dependencies work properly. That's the player's job. A LOT of mods are just abandonware. Someone wrote it up, maybe polished it, maybe left it broken, and then lost interest. When you see a two-year-old mod with dependencies, it's a good bet that at least one of them are broken, because we're not required (thankfully) to coordinate that stuff with each other. That's why FO4 modder needs to learn FO4Edit and learn how to do their own detective work. Even so, what you're talking about isn't what this thread's about.

In my experience, GrepWin is a lot faster, has a much more useful interface, has better regex support, and has easy right-click context menu integration. In general, I also find GW a lot more useful in that it's a separate utility that doesn't require me to break my current N++ workflow. Not knocking Notepad++, I'm a major fan and it's my dedicated dev editor. Use it every day. And its file search works, but it doesn't really hold a candle IMHO.

If all you want is a normal-looking Piper again, I'm a big fan of Bombshell Piper. As far as what's going on with LooksMenu, no idea there. Maybe try Face Ripper? (Seriously, your Piper looks like the before image on an episode of Intervention. "I DON'T HAVE A PROBLEM MOM!")