Jump to content


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

1372 profile views
  1. Only the scripted objects (mainly beds, crops, settlers, turrets) demand papyrus resources. But I agree that this is likely not a problem with your workshops, considering the stats you provided. Best guess therefore is that there is a mod conflict, presumably with scripted mods. It may also be worth checking whether one of the mods you're running makes significant changes to the conditions for creating new settlers.
  2. What do you mean exactly with 'ground out a high level character' and 'not doing much of the storyline' ? Because settlements will grow slowly over time. Your workshops will stop recruiting if there are five or more settlers without jobs assigned, so you have to concentrate heavily on workshops at least. Even then however, it may take a long while until the population limit is reached. Building limit uncappers and settlement border removers do not harm your game in any way. They do however enable you to ruin your game yourself, by building too many scripted objects. it's those that eventually lead to the issue where settlers apparently become unassignable [NB: I'm explicitly referencing to this as an issue: this is not a bug, but a limitation imposed by game design. Papyrus is simply too slow to handle too large a number of objects within a sufficiently short period of time]. Of course, if you disable the uncappers, all of the stuff you built won't go away, so it won't make a difference whether those mods are enabled once the issue has hit you. EDIT: For clarification: the settler assignment issue is an entirely separate issue that is not related to the previously discussed problems with sending settlers around. To make all your workshops available in the selection menu, you really only have to increase the value of that game setting.
  3. I assume that you are running a mod that uncaps the population limit (presumably by modifying WorkshopScript), but does not increase the value of the game setting iWorkshopSettlerPopulationMax at the same time. Or, if not, your settlements are at or close to their population limits. The settler limit at a given workshop does not depend on that setting (it only depends on the calculation formula coded on WorkshopScript). However, the code that displays the destination workshops to select from when you send settlers around DOES check that game setting, and if the population at a given workshop is beyond the limit, that destination will be grayed out (i.e. not a selectable option). Also note that this latter code cannot be modified because it is implemented at engine level (so we have no access); that is, it can only be controlled indirectly, via the aformentioned game setting. I should add here that the limit imposed by the game setting may be too low even without population limit uncappers, since the maximum number of settlers that may be created at a given workshop if you make use of all charisma boosting equipment available in the base game (plus charisma boosting chems) can go beyond that value.
  4. [WIPz] TES5Edit

    Question: How is the 'Check Circular Leveled Lists' option supposed to be used ? I'm asking because I have been using this quite regularly but always found it somewhat suspect that there was never any message displayed in the 'messages' window. So I made a 'use all' flag leveled list with three items in it, two arbitrarily chosen armors and a reference to itself (evaluating this would theoretically return an infinite number of items). Then I ran the checker, but it did not find it. Thus, I am wondering now whether the procedure does actually work at all. Or does it only check for two or more leveled lists cross-referencing itself ? Or am I just plain stupid and overlooking something obvious ?
  5. (1) Updating the refs to have the proper property values set is your responsibility as the mod's author. (2) A running script will not accept any new values set in the properties window. E.g. if you have script that permanently runs on a start game enabled quest, the only chance to make it to accept new property values is to write another script that overwrites the values at run time. Not so if the script is not permanently running though. Trap scripts will not run if the trap is not in the loaded area.
  6. If you add or remove properties from the script on the base object, the references using that script will NOT UPDATE AUTOMATICALLY. You must update them manually for each affected reference, by navigating to that reference in the CK, select the script, then click on 'properties' - and only then, a message will pop up notifying you that the script properties have been updated. Once this is done, you're fine. Modifications that are restricted to the code however do not require this procedure, as the scripts on the references will update to the new code automatically (well, unless they were loaded when the last save was made before you did upgrade; in that case, they may need to reload until the changes take effect). This is particulalry annoying, of course, if you modify both the code and the script properties. In that case, if you have not manually updated all affected references, they will run the new code but will continue to use the properties they got from the old script - which will most likely result in the scripts running on them to stop working.
  7. Well, the resources from linked workshops are never considered in the actual stats. Which makes sense because there is no practicable way to take care of them: Calculating them irequires a lengthy code that will not finish running within a fraction of a second, but takes a few seconds at least. Moreover, the linked resources are constantly changing since every workshop runs an update every game day where concumption is calculated and removed from the existing resources, and new resources are produced. With the maximum number of workshops player owned, this means that the values are changing every 2-3 minutes real time. Which in turn means that you cannot safely store the data in variables somewhere and print them on the screen if the Stats tab is clicked on the pip-boy. Instead, they would have to be recalculated every single time. Not even the function that transfers resources from linked workshops does evaluate the resource counts before it starts running: it simply loops through the workshops and tries to find surplus resources that it can transfer to the workshop with the shortage. And if it finishes running, it may or may not have succeeded in doing the job.
  8. CompanionActorScript errors with Ada are completely 'normal' and expected. Each companion has its own set of global variables to store certain affinity data, which CompanionActorScript is processing on a regular basis. For unknown reasons however, a set of variables for Ada is completely missing from the game. They are not only not initialized on Ada's script, they do not even exist! Assuming that it was intended to omit certain behaviours for Ada, creating bogus globals for her is probably not the best solution. Plastering the script with sanity checks (this would require many!) is not practicable either. I'm not sure yet how this is best fixed. The assaultron stuff cannot be fixed. There were some issues in the script that could be fixed, but these errors cannot. They are thrown because the script keeps on running when the engine has already cleaned up the magic effect it was attached to [NB: Note that this happens with all magic effect scripts, and they throw similar errors]. The engine is pretty aggressive in cleaning up magic effects as soon as they finish, but papyrus always lags a bit in noticing this.
  9. Updated these to 2.0.2 as well:
  10. Bethesda.net update

    2.0.2 is currently a beta version.
  11. UFO4P 2.0.2 beta - Errors logs

    The stuff from the companion scripts suggests that you are running a follower mod that conflicts with some of the UFO4P edits. Apart from those, pretty much everything on your log has been showing up there since the game's release. We haven't had the time yet to take care of all of them [Have you ever looked at a papyrus log before you installed the current beta ?]. Some of them cannot be fixed, so you have to live with them , e.g. "Failed to send event FillRed for unspecified reasons" - if you have an idea what those reasons are, we could have a look. Apparently though, not even the game knows). Assigning None to a non-object variable ... from SpotlightTriggerScript: it's just a warning (not an error) and the scripts work as intended. I have no idea where those remaining warnings come from (there were more of them before the recent script edits). AttractionObjectScript: cannot enable() ... That's simply bad game design and has been an issue since Skyrim: they try to run enable/disable via script commands on enable-parented references. That never works.
  12. It makes no difference whether you talk about the pip-boy stats or the workshop resource data. They are the same. The pip-boy just displays them, and if these values are wrong, it'is actually the workshop data being wrong. Getting close to a workshop is not sufficient for the auto-correction procedures to start running. You must be in the workshop location, and the workbench must have loaded. This may be the case if you get close enough but it is not necessarily always the case in that situation. Might be worth mentioning here that the code that displays the data on the pip-boy runs at engine level. In addition to printing the data, it may add warning signs to individual stats. If these warnings are wrong for whatever reason (e.g. without the stats being actually wrong), you'll have to live with them as we cannot fix that. I found a practicable fix for #20316 meanwhile, but even with that one fixed, I cannot promise that the issue is finally gone. It's even possible that there's an error in those parts of the workshop code that run at engine level, and this cannot be fixed anyway.
  13. Not possible. Either there is a shortage at the workshop and the related resource values will display in red, or there isn't and they will display in green. If the pip-boy reports a shortage but the resource values are displayed in green, the pip-boy values are wrong. This is the 'settlement stats bug' (i.e. the pip-boy reports wrong values for the workshop resources - at times, they are displayed as zero, but they may in fact have any erroneous value). The wrong values are corrected by the workshop scripts themselves, but this is not possible if the affected workshop location is not loaded (recalculating the resource values is done by counting the workshop objects and adding up their contributions to the individual resource types; if the location is not loaded, no objects would be found and everything would become zero). Therefore, you have to travel to the location (so that the cells are loaded), and once you arrive, a householding function will start running in the background. It is that function that does the corrections (among other stuff). Going into workshop mode is not necessary for this to happen [NB: workshop mode does always display the correct values, so the code apparently does a resource recalculation as soon as it starts running. Note that workshop mode is a largely separate module that runs at engine level; thus, how it works and what it exactly does is unknown to us. Modifying it is not possible either.] Main reason for this bug were threading issues, but all of them have been resolved a long time ago (the last remaining fixes went live with UFO4P 2.0.0). There are still occasional reports on workshop stats issues though, and I know from my own game that there is at least one remaining bug (there's no way to be sure that it is only one issue). While running tests and packing up stuff for the current beta, I identified a potential culprit: https://afktrack.iguanadons.net/index.php?a=issues&i=23016 Right now though, I have no idea how to fix it because I see no way to tell whether the player left a workshop location (the vanilla OnLocationChanged event is bugged and records bogus leave events if the player opens an in-game menu that are impossible to discern from valid leave events).
  14. That should be 'Array index out of range error'. Plus, the fix for #20799 should be flagged NR.
  15. Extreme long loading times - all of a sudden...

    Is anyone of you using texture or mesh replacers ? They don't necessarily require a plugin (so you're technically running the game without mods), but if they don't, they ususally come as loose files. If so, it might be worth checking the Nexus pages (or wherever you downloaded them from) for similar complaints about long loading times. Specific textures that are compressed in an inappropriate format are known to cause overly long loading times, and certain faulty meshes are known to cause that too.

Support us on Patreon!