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.