Jump to content


Unofficial Patch Project
  • Content count

  • Joined

  • Last visited


About Sclerocephalus

  • Rank
  • Birthday 12/29/1965

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1680 profile views
  1. Birds you see in the scope will always be stuck. That's an engine issue and cannot be fixed. Without using the scope, the birds would be out of sight and have no 3D (culled by the engine), so the scripts running on them would be halted (waiting for the birds to recover 3D) since pretty much anything BirdCritterScript is doing requires 3D to be loaded. Debugging has shown that the scripts running on the birds I observe ithrough a scope consider them to not have any 3D, so the scripts pretty much ignore that a scope is being used - or, to say it the other way around, the code that handles the stuff you see through the scope does not care about animated objects. It only displays animations on actors (technically, birds are activators, not actors) and considers anything else as static. However, not even the actor animations are correctly handled: they often move without displaying the walking/running animations, making them appear as they would be standing on conveyor belts. Needless to say that this cannot be fixed either because that code is running at engine level. Likewise, any other scripted effects that require 3D on a reference will stop working if that object is observed through a scope (e.g. shaders on automatron robots). Workshop mode (another code running at engine level) ignores birds too (presumably to save performance). There are no birds at workshops (workshop mode ignoring them is the likely reason), except for Kingsport Lighthouse which has some gulls on the pier. Soon after you go into workshop mode, they will all freeze - and this cannot be fixed either. Modders who add workshops to non-vanilla workshop locations should make sure that the bird spawners are disabled.
  2. DN011_TriggerNonsense.jpg

    Trigger 1 starts the quest (DN011), trigger 2 waits for one second (to give the quest the time to run its startup), then fills the ref of the intercom in an as yet empty alias. Finally, trigger 3 sets a quest stage that activates the ref in that alias. If you pass the distance between triggers 2 and 3 in less than one second, the whole "ingenious" construction stops working and you get this: https://afktrack.iguanadons.net/index.php?a=issues&i=23757
  3. This was done on purpose. For further information, check the tracker entry: https://afktrack.iguanadons.net/index.php?a=issues&i=22849 Plus, mattresses have steel springs inside, so it should consume steel to construct them. This is consistent with the non-workshop version scrap recipes in the base game.
  4. Issues with random encounters

    Both are supposed to respawn quickly.
  5. Issues with random encounters

    There is no safe way to do it manually. You could call Stop() on those quests, which properly shuts them down and also leads to all actors left by them in the game world to disappear very quickly. It does not solve the problem with the trigger though: to unblock the trigger, you need a script. It also does most likely not solve the problem with the actual encounter quest: once that quest starts running again, it will not shut down on its own. Best wait therefore until all RE quests are eventually fixed. There appears to be a common misconception that we already did that, but that's not true (note that we also didn't claim to have it done already). All random encounters are using a framework of common scripts, RETriggerScript (which runs on all triggers) and REScript (which runs on all RE quests). Depending on the encounter type and the design of specific RE quests, individual quests may be running other "random encounter scripts" in addition (e.g. REAssaultSC_FactionScript, REAssaultQuestScript, REChokepointTriggerScript and others). The basic functionality, which includes evaluation of the stop conditions, the subsequent shut down and rearming of the trigger is only handled by REScript and RETriggerScript though. What we started with was to fix all bugs on these two scripts, and to add the trigger rearming procedure to REScript (while the vanilla quests were designed to do that on their own, they did never succeed in actually doing it because of an improperly used flag on their end fragments) . With these fixes, all RE quests that are properly set up would start working as expected again, and this applied in fact to more than two thrids of the RE quests in the game. Emphasis here is on "properly set up": all quests need to set properties on their REScript to define appropriate shut down conditions, and likewise, all quests must call the Startup() function on REScript from their quest fragments, in order to make REScript register for cleanup events (it never evaluates the stop conditions if this hasn't been done). There were quite a number of quests that did not have any stop conditions defined, and they would never shut down on their own. This was the case with both DLC01RETravelKMK01 and DLC01RETravelKMK02. The 'gassy settler' is an example of a quest that never called Startup() on its REScript. These problems (and many others) are quest specific and need to addressed by quest-specific fixes. This is still a work in progress. DLC01RETravelKMK01 and DLC01RETravelKMK02 were supposedly fixed in UFO4P 2.0.0 but the modifications to the properties on REScript went missing when the mod was packed up for release after the beta phase. Both quests were still not working with UFO4P 2.0.1, but the fix has been redone in UFO4P 2.0.2 and is now working. The gassy settler has been fixed in UFO4P 2.0.2
  6. Discord problems

    Around 10 hours ago, I tried to open the chat room but all I got was the grey screen where Discord tells me that it is going to connect. Shutting down my PC (switching it off) and restarting did not help. EDIT: Nevermind ... Turned out that certain operations (like fetching a source map) were flagged as disallowed after the last NoScript update.
  7. Issues with random encounters

    Yes. Install UFO4P.
  8. 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.
  9. 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.
  10. 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.
  11. [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 ?
  12. (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.
  13. 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.
  14. 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.

Support us on Patreon!