Jump to content

Sclerocephalus

Unofficial Patch Project
  • Content count

    880
  • Joined

  • Last visited

2 Followers

About Sclerocephalus

  • Rank
    Guide
  • Birthday 12/29/1965

Contact Methods

  • Website URL
    http://www.mindat.org/user-600.html#2_0_0_0_0__

Profile Information

  • Gender
    Male
  • Location
    Saartal

Recent Profile Visitors

1574 profile views
  1. Issues with random encounters

    Both are supposed to respawn quickly.
  2. 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
  3. 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.
  4. Issues with random encounters

    Yes. Install UFO4P.
  5. 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.
  6. 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.
  7. 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.
  8. [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 ?
  9. (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.
  10. 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.
  11. 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.
  12. 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.
  13. Updated these to 2.0.2 as well:
  14. Bethesda.net update

    2.0.2 is currently a beta version.
  15. 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.

Support us on Patreon!

×