Unofficial Patch Project
  • Content count

  • Joined

  • Last visited


About Sclerocephalus

  • Rank
  • Birthday 12/29/65

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

933 profile views
  1. Are you running any workshop-related mods ? If so, please list them. What you report sounds very much like a threading issue. If I'm right with this assumption, checking the workshopIDs of the affected settlers (this is a property on WorkshopNPCScript that gets initialized by a function on WorkshopParentScript that registers all new actors ) won't help at all since there's very likely nothing wrong wit them. To understand the issue, let's assume that there is a lenghty function on one of the workshop scripts [NB: there are in fact several of those] that is called other scripts every once in a while. This other script is passing an actor in (and expects said function to do something with that actror, e.g. to modify certain parameters on his workshopNPCScript). Let's further assume that the function has to run some checks on the actor's current parameters (i.e. the modifications to apply depend on the current values), so it will likely start with reading out those values and storing them in local variables for quick access. Subsequently, it runs the checks on those local variables. If that function is running long enough, there is a good chance that it will be called again (with a different actor passed in) before it has stopped running Now we have two threads running, one for each acvtor, but they are running on the same script and are using the same local variables. The second thread, when it starts running, writes the data of the scond actor in those variables before it proceeds, so the first thread, if it has not yet finished its job on these values, is now using the parameter set of an entirely unrelated actor without even knowing it. This is what we call a threading issue. If they affect a frequently used function, they can make an ultimate mess within a very short period of time, and there's a high risk to damage the integrity of your game's data beyond repair.
  2. Version 1.0.0

    1 download

    A small mod that makes the remaining shack and the wooden stairs at Hangman's Alley scrappable. Just that and nothing else.
  3. What is that glitch you're talking about ?
  4. Attacker aliases react to OnDeath events, and these events provide the rererence of the killer. If this has been the player, all settlers at the respective workshop will be added to a specific faction that is checked by the dialogue conditions.
  5. @Ethruvisil You appear to be missing a point here: That script does NOT make the bow a Daedric artifact (nor does the patch!). It only makes it that the bow counts for the Daedric artifacts achievement. You could as well attach the script to any weapon in the game, and all it does would be to increment the achievement count when the player obtains that weapon. It does not automatically make any weapon it is running on a Daedric artifact though.
  6. Extract FollowerScript.psc from the UFO4P archive (into the Data/Scripts/Source/User folder) Open that file (e.g. with Notepad) and make the required edits. Save. Open the CK, navigate to the Followers quest and open the scripts tab. Right click on FollowerScript and select 'edit source', then recompile. This creates the required FollowerScript.pex in your Data/Scripts folder. You may keep this a s a loose file to override the versions from both the UFO4P and the EBF BSAs. Better though: repack the EBF BSA with the new pex file.
  7. @InsanePlumber There's another one you could help us with if you have some time left to do it:
  8. It appears to be an accepted fact in the FO4 modding community that the CK may crash very frequently, and this may also be one of the reasons why no one seems to bother finding out why this may be the case. So far, the CK has working fine for me; there were occasional crashes 'out of nowhere' but I couldn't say that it would crash mor often than e.g. the Skyrim CK did. This changed however recently, after installing a custom mesh replacer mod (that came with the notorious loose files). Suddenly, the CK became extremely unstable and crashed frequently when trying to open a cell or actor preview window. Upon investigation of this problem, it turned out rather quickly that the meshes were faulty. Moreover though, this was not an exception with that specific mod, but, very sadly, appears to be a rather common problem with many of the custom arrmor & clothing meshes available for FO4 so far. I have been looking at a fairly large number of them during the last three weeks, and 80% of the meshes distributed with those mods had one of the two errors described in detail below. So far, only the stock armor & clothing replacers that came with the CBBE mod were all fine. This is a sad yield (and IMHO really bad work of the FO4 modders community), considering that this problem is not new: the Skyrim CK would crash on such meshes as well, as also does the SSE game engine. The FO4 and Skyrim game engines are more forgiving: they still run with the faulty meshes (one should expect however that they do still profit in some way if those mesh errors are corrected). (1) The BSSkinIntance of a BSSubIndexTriShape is missing a link to the skeleton root: This guarantees an immediate CTD of the CK whenever it tries to render that mesh in the cell or actor previews. If you have faulty meshes that may be used as outfit parts of an actor, you're usually not even able to bring up the actor window for that actor, since the CK will already crash upon trying to do this. The fix is simple: In Nifskope, expand the BSSubIndexTriShape, then select the BSSkinIntance node. In the details view, check the first line. This displays the skeleton root, and if it contains a 'none' entry, replace this with the number of the root node (this is usually zero). Done. Make sure however to check all BSSubIndexTriShapes. If one is missing the link, chances are very high that others are missing it as well. (2) The root node has an empty extra data array: This is a rare one, but just like the previous error will guarantee an immediate crash of the CK. In NifSkope, select the root node, and in the details view, check 'Num Extra Data List'. If this is not zero, expand the 'Extra Data List' array. If this contains only 'none' entries, set Num Extra Data List to zero, then right click on the array and run 'Update array'. This happens when someone uses an existing vanilla mesh as template for his work and removes extra data such as attachment points he doesn't need. They may be properly deleted, but the extra data array is apparently not automatically updated.
  9. Are you talking about the dead ghouls at Sunshine Tidings ? The dead ghouls are pe-placed dead bodies and they are never cleaned up. You have to disable them if you want to get rid of them. Note that there are two sorts of ghouls when you arrive at Sunshine Tidings for the first time: dead ones and living enemies. The enemies will get cleaned up after you killed them. That's how the game engine works: any actor who starts in the game alive will be cleaned up after he has been killed (this also applies to pre-placed actors), but pre-placed dead bodies will always stay. BTW, none of the gouls at Sunshine Tidings is created by random encounters. Random encounters do NEVER place dead bodies. Encounters with dead enemies (often at camp sites, but also the dead postman and a few others) do technically create living actors and kill them at run-time (there is a special function on one of the RE scripts to do this), so they will all clean up properly. I don't think that mirelurks are ever involved in random encounters (there is a workshop mirelurk attack that may take place on Spectacle Island, and another random encounter with mirelurks at Far Harbor, but this only ever occurs on the island). I will have to look at the RE quests though to be sure. Object encounter triggers do not reset. That is, all object encounter locations are only used once (there are designer notes on the end fragments of all object type RE quests that make it very clear that this has been intended). UFO4P doesn't change this, and therefore, neither the cooldown timers (this is vanilla functionality to add a delay to the reuse of specific triggers) nor the UFO4P rearm timers (a rvariable short timer that has to run out before a trigger that was unintentionally not rearmed gets actually rearmed) apply here because they never run. What has been placed by an object trigger will stay in the game forever (unless picked up by the player), and if those objects disappear eventually, there's something fundamentally wrong with your game. BTW, OnLoacationChange events are tricky: this event fires when you enter or leave workshop mode, which may leadi scripts into 'thinking' that the player left or entered a location when he actually never moved. Depending on what your script is supposed to do, you may need to conceive a workaround to discern those invalid events from valid ones.
  10. Not true either. There also are plenty of base game load screens displayed. Load screen appearance frequency is determined by another global, DLC01LoadScreenRate. This has been set to a whopping 20%, which is far too high, considering that the automatron DLC only adds 6 load screens, compared to around 100 (a rough estimate, I did not count them!) in the base game. Thus, this one might even get fixed.
  11. I have been running the game unmodified for ca. 3 months now, and it is pretty much 1:1. Perecption is deceptive because you see the indivudal DLC encounters more often (there nowhere are more than half a dozen in any encounter category). Chance values of 20-30 are probably more appropriate nonetheless.
  12. xEdit -> Global -> DLC01REPercentChance EDIT: right-click on the global, then select 'copy as override'. Make a new file, give it a meaningful name, then change the value in the override. Done.
  13. (1) RE quests will stop running (clear their aliases and subsequent cleanup of generated actors by the engine) if all actors have unloaded. When you levae the game, all game data is cleared from your PCs memory, but that doesn't mean that the actors have unloaded in the game. If you reload and are still in the same area, they have not unloaded. You must leave the area and only then the cells (plus actors) may unload, and only then the quest stops running and the engine can perform the cleanup. This has been tested extensively and works as intended. (2) Don't confuse respawning (preplaced) enemies with random encounters. A large fraction of enemies in the game is preplaced. They will be cleaned up eventually after they're dead but will respawn upon cell reset. Depending on how you move during a fight, you may drag enemies from adjacent cells into the battle, but not all of the cells may reset at the same time, and on another occasion, you may have less enemies to fight in that area. Thus, that's not a bug either. (3) There are seven encounter types in the game: assault, camp, object, checkpoint, chokepoint, scene and travel. Each encounter type uses its own triggers, i.e. assault type triggers will only start assault encounters, camp type triggers will only start camp encounters, etc. To do so, the trigger sends an encounter specific keyword to the story manager, and this randomly selects a quest from a list (there are separate quest lists for the individual encounter types). Now, the Automatron DLC adds a separate set of lists for each encounter type and lets the story manager decide at a 50/50 chance from which list to select the quest. Since this has been implemented very consistently, there's no doubt that this was intended, and therefore, this is not something we consider a bug. It certainly is bad design though, since the number of quests in the DLC added lists is much smaller than the number of quests in the lists from the base game, hence the chances for specific encounters are much higher for those from the DLC [NB: making a mod to modify this to your liking should take less than a minute: simply reduce the random chance values on the respective story manager nodes]. (4) Culling of in-game placed objects is not normal behaviour, and even if specific references have been set up to be disabled in specific conditions, this should not happen right in front of your eyes. Missing landscape pieces are clearly a rendering problem and have nothing to do with random encounters. Unless you're running some really bad mods, there likely is a problem with your game configuration: either you have touched certain ini settings you should have better left alone or your game settings are too ambitious in regard to what your PC can handle.
  14. The log entry for the Default2StateActivator script fix should be rephrased as the doors that are affected are not badly configured; it's just that a specific configuration is needed to become affected: Fixed issue causing the script to break certain doors that are configured to be activated only once, such as the Castle Volkihar Ruin doors. (Bug #21999) Also note that this fix is not retroactive.
  15. Somehow, we always start with assuming that they know how their stuff works, don't we ? Well, until a couple of days ago, I also still assumed that they know how their package stacks work, but ....