Unofficial Patch Project
  • Content count

  • Joined

  • Last visited


About Sclerocephalus

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

538 profile views
  1. I remember Gary Lineker. When told that it might take a decade until all contracts are final, he said: ... but that's unfair, considering that most of the people who voted for the exit are already dead by then.
  2. That's what I did with the remaining API problems on WorkshopParentScript. Many of them date back to to late spring/early summer last year, to very early UFO4P versions when I didn't realize that API compatibility would become that much of an issue in FO4. It never was an issue in Skyrim! The public versions of all functions I had to add on WorkshopParentScript were modified to use the vanilla prototype (so all external scripts are calling public functions now even if they might have been calliing private versions before) while the private versions were modified as needed (they now have a '_private' appended to their names) and are only called from within WorkshopParentScript itself. Those changes went live with UFO4P 2.0 (so there ahould be far less compatibility problems now; if I didn't overlook something on that script, there actually shouldn't be any left at all). Now to the current issue: The underlying issue (i.e. the one that actually required the current modification) was a call of the locked DailyUpdate function (on WorkshopScript) from a locked thread on WorkshopParentScript. The call would always come from the ResetHappiness function; that function is always the last task to be carried out by whichever thread that is calling it. Also, the call of the DailyUpdate function was the first action of the vanilla ResetHappiness function, and it did not call any other functions on external scripts. I therefore solved the issue by splitting the ResetHappiness function in two parts: the first part (which is using the vanilla prototype) starts a short timer on WorkshopScript. This ends the thread on WorkshopParentScript. When the timer event fires on WorkshopScript, it calls the DailyUpdate function with bResetHappiness = true. This bool tells the function to call the remainder of the ResetHappiness function (i.e. the second part which contains the actual code of the vanilla ResetHappiness function) before it finishes running. Now, since the last part is running on a separate thread anyway, it actually doesn't matter which instance of the DailyUpdate function calls ResetHappiness on WorkshopParentScript - as long as it is an instance of the same WorkshopScript and as long as there is no delay. Therefore, I solved the current issue as follows: The DailyUpdate function has been reverted to the vanilla prototype bResetHappiness has been added as a script variable to WorkshopScript. Default value is 'false' When the timer event catches the call from WorkshopParentScript, it sets bResetHappiness to 'true' and calls the DailyUpdate function. Now, there's no guarantee that this function call will be the instance that calls back WorkshopParentScript (because there may be another thread waiting in the lock): that's the flaw I was referring to. However, it won't matter here which instance is making the call (as explained above). Once DailyUpdate has called WorkshopPArentScript, it resets bReseHappiness to 'false'.
  3. In this case, the current solution is the only one that has no flaws, because I have to tell the affected thread itself that it is safe for it to call back a non-public function on WorkshopParentScript. I can offer a workaround with a minor flaw, but there is a good chance that this flaw won't matter. This is currently being tested.
  4. Which leads me to the question why you aren't simply using the UFO4P scripts as the basis for your mods because you will be running into exactly the same problem (and then have to reinvent the wheel). Unless you do not lock the DailyUpdate function, of course, but I don't see any good reason for not doing this. This would explain however why there a still people complaining oaccasionally that the pip-boy stats fix doesn't work for them although they have UFO4P installed.
  5. This is much farther reaching than I had in mind: As already mentioned, the ResetHappiness function could be called from unlocked threads in the vanilla version of WorkshopParentScript, but some threads that were calling it were already locked (in the UFO4P 2.0.1 version, it is only called from locked threads). In the vanilla version of WorkshopScript, the DailyUpdate function was not locked, so there was no issue when ResetHappiness called DailyUpdate. In pretty much every UFO4P version however, the DailyUpdate function is locked. [NB: There may be no obvious reason to lock sole functions that are running on spearate instances of WorkshopScript - but the issue was not created on WorkshopScript; it was created on WorkshopParentScript when any number of DailyUpdates on separate workshops were calling sensitive functions at the same time.] Unlocking the DailyUpdate function is not an option for us, as this would mess up the workshop stats [and not only the stats, it's actually the data on which the workshop scripts are oprating] at pretty much all times. Means that I must find another way to circumvent potential dead locks when ResetHappiness calls DailyUpdate.
  6. This is a tough one because the ResetHappiness function (on WorkshopParentScript) could be called from unlocked threads in the vanilla version of the scripts (as a result, the happiness at any of your settlements could suddenly drop to the start value). As a concequence of locking this (to prevent aforementioned issues from happening), the DailyUpdate function had to be modified to prevent it from hanging in a dead lock when called by ResetHappiness itself. The current solution is actually a workaround to the workaround already. I'll see what i can do. EDIT: Have added it to the tracker:
  7. From the album Bug Reports

    Settlers won't move past the red line although the whole structure is within the vanilla settlement boundaries.
  8. Hopefully, 'new tech' won't mean 'modding impossible'.
  9. This is starting to get ridiculuous. It leaves me with the impression that Beth fumbled the Oldrim stuff together in a hurry and released the SE without appropriate testing (sadly, that's not new though). It really wouldn't surprise me if it turned out that they have no idea either about what's going wrong here.
  10. Version 1.20 is live now, with tons of new meshes: Made numerous corrections to the existimg meshes to bring the mod to v1.0: Modified many walkway meshes to eliminate clipping issues (most of them on the lower level walkways) Redid the vertex colours on all basement dividers (they never were intended to be that dark) Lowered the door bars on all doorway versions of the basement divider meshes to eliminate a narrow gap that remained when doors were placed in the doorways. Improved the collision on most of the interior stairs meshes. Fixed several minor UV issues on various meshes. Added numerous new meshes, so we are at v1.20 now: Added full mesh sets for houses wth 2, 3 and 7 units length (so you can now select from any length between 2 and 8) Added 10 new exterior front meshes, featuring full size stone chimneys (two variants) and large porches with full stone foundations (similar to the vanilla blacksmith mesh) Added new walkway meshes to be used with the new chimneys (the existing ones would clip) Added walkway parts and a new walkway stairs variant to be used in combination with the new large porches Added interior front and end meshes with large fireplaces (to be used in combination with the new exterior chimney meshes) Added full roof versions of the side wing balconies Added new meshes for the basement rooms below the new porches. As a result of doing this, the basement wall of all interior front and end segments meshes had to be split (as there would have to be too many mesh variants to be made otherwise to account for the door options at the basement level). There are now two sets of basement wall front and end meshes (one for the front/end segments with the new chimneys, one for all others) with a multitude of door options to chose from. Added spiral staircases Finally, the demo has been removed from the download. This will be published on a later date as a separate playable mod (with additional content selected from the tons of stuff I made during the last three years).
  11. From the album Sclero's Farmhouse Kit

    Another detail. Main problem was to conceive a cedible support. This consists now of a system of interlocking posts and bars. The two meshes that make the model are orgies of separate tiny and tiniest parts.
  12. From the album Sclero's Farmhouse Kit

    View from above.
  13. From the album Sclero's Farmhouse Kit

    Now available: spiral stairs.
  14. Scroll down. There is a section that deals with the flags in the NiAlphaProperty.
  15. If there are several transparent layers on top of each other (this is the case here, both the inner and the outer layer have an alpha property), there may be rendering issues that require some fiddling with the alpha flags. Just google for 'NiAlphaProperty' and ' flags'. People also report frequently that the model appears to be fine in Nifskope but fails to render properly in the game. Information on those flags can be found here: