Jump to content

Sclerocephalus

Unofficial Patch Project
  • Content Count

    962
  • Joined

  • Last visited

Posts posted by Sclerocephalus


  1. You can't move settlers around with console commands. There's a ton of extra stuff that needs to be done to make this work, and there are dedicated functions on WorkshopParentScript to handle that. If you don't do it properly, the affected NPCs may glitch out in various ways. That's nothing new.


  2. 54 minutes ago, DayDreamer said:

    The problem at the moment is no way to decide whether the vanilla driver is sitting in his carriage seat. ICAIO moves the driver around, and has him sleeping. The long-time US*P solution is checking that he's sitting anywhere, fixing a lot of grief, but there are cases of that not being quite correct (sitting inside, sitting on a bench outside). Still, it's much better than nothing!

    What I'm currently doing in Touring Carriages is after the player selects "Where do you want to go?" checking bSitting. Unfortunately, because that test happens afterward, the player sees only "Never mind."

    I was looking for a definitive early test (such as the aforementioned "link.IsInFurnitureState Sit == 1 AND"; that works in scripting). Apparently, even though documented, it doesn't work properly in conditions. Or I'm doing it wrong.

     

    You probably have to track this for each driver and store the tracking variable. OnActivate() events on the carriages should reliably work to tell you whether the driver is sitting (and in which carriage). OnSit() is not reliable and may even pass a wrong furniture ref (apparently an engine bug, according to the notes on the CK Wiki). OnGetUp(), on the other hand, is reliable,


  3. On 5/7/2020 at 3:19 PM, DayDreamer said:

    Although bSitting is set by the vanilla drivers in their script, available game engine dialogue conditions are not able to easily access it. GetVMScriptVariable only works on a specific reference, so every destination would need to be duplicated for each and every driver. Not practical.

    If I got this right, you're looking for a way to store the driver state. You want it to be easily accessible by condition functions and you also want to protect it from being manipulated by unsuspecting mod authors.

     

    SOLUTION:

    Make a custom faction, count all drivers in, and store the information in the faction rank. Tthis also enables you to use more than two states (in case you need them).

    There are condition functions for both the adherence to a faction and the faction rank.


  4. This had to be expected.

     

    Fast travel markers are pre-placed objects (i.e. placed references that are defined in a master file or a plugin) and therefore cannot be deleted. Only objects created at run time can [NB: to my knowledge, the only exception are pre-placed live actors if they are no longer persistent].. If you "delete" an object (either in workshop mode, by a script or by console commands), it only gets disabled and tagged as "marked for deletion". The game will then delete it when it is safe to do so. For pre-placed objects, this is never the case; for all others, this is the case if the object is no longer persistent (i.e. if there is no script running on it, if it is no longer in a quest alias or referenced by a script property, and if it is no longer linked to another reference). Enable states have no impact on the functionality of fast travel markers; they'll always work, whether enabled or not.

     

    If you place a "new" marker in workshop mode, the game actually moves the existing marker to the new spot (and bakes the new position in your save).

     


  5. That Labyrinthian mesh issue was caused by a bug in the compressed mesh type collision calculations of NifTools which has been corrected in the meantime. If the meshes in question had their collisions built with the latest version of NifTools, there should be no weather issues (and if they have no compressed mesh type collision, it shouldn't matter anyway).

    From my own experiences with faulty meshes, the CK is much less forgiving than the game. Thus, the lack of crash reports does not necessarily support the integrity of the meshes. It just tells us that few (if any) users of that mod are doing work in the CK.

    About three years ago, I posted a note on frequent FO4 armor and clothing mesh errors. Any mesh with one of these errors still works in the game but crashes the CK immediately [NB: if there wasn't that killer reply by Insane Plumber which basically says that you must be a complete idiot if you allow for faulty meshes being a problem in your game, there might have been replies by other people and a discussion could have been started. Unfortunately though, with that post in place, anyone posting a reply related to the topic would have had to admit that he's a complete idiot too, so it's not a big suprise that nobody did. Let's just hope that this guy doesn't earn his living as a teacher.]

    Oldrim behaves in the same way as FO4 in that respect, but SSE appears to be somewhat less forgiving.


  6. Some things to keep in mind:

    • When an actor is placed, the game will try to move it onto the nearest navmesh without saying. If a cell is not loaded, there will be no navmesh either, so placement is expected to be pretty inaccurate.
    • Placing an actor in an unloaded cell via PlaceAtMe won't work if the ref to place the actor at is not peristent. While you can force any ref to be persistent by ticking the respective flag in the CK, having too many peristent refs is not a good idea (they permanently consume memory).
    • Likewise, actors cannot interact with refs in unloaded cells unless they are persistent.
    • Actors that run packages to move from one place to another do still move while they are in unloaded area, but this "movement" is a simulation and no real movement. The game updates them at pretty long time intervals and then moves them some distance forward, so they actually move discontinuously.. Update intervals for actors in loaded cells are much shorter.. Thus, if a package starts running on an actor in an unloaded cell, it has to be expected that there will be some time passing before he actually starts moving (plus, he will not really move until he is on a working navmesh; it's likely therefore that the game will teleport him onto the edge of the loaded area, and only then the package runs normally). It's also worth mentioning that movement through unloaded cells is poorly repeatable. Some years ago, I made a mod for measuring the time needed by an actor to move from one location to another (with a long list of locations covered) in order to find out whether they were repeatable (see https://www.nexusmods.com/skyrim/mods/31241). Unfortunately though, they varied by a very large margin. Of course, reproducibility (which takes hardware and game setup variations on other peoples' PCs into account) is even much worse.
    • Placing an actor may take a considerable real time since the game may need to load his face preset and outfit items. If the actors in question only use vanilla items, this is almost negligible. With mods installed that add more faces (and some mods hold them in very long leveled lists) and/or custom outfit items (with texture resolutions notoriously over the top), the situation can be significantly worse. It's a good idea therefore to spawn actors (even disabled ones) at a far enough distance. Otherwise, they may pop in in plain sight. The more actors are spawned at the same time, the worse this gets. There's a reason why most random encounters start running when the trigger loads, i.e. when the cell with the trigger attaches at the edge of the loaded cell grid.

     

     


  7. Quote

    t's not possible to have objects in perfect visible contact, because a part of the tower, a tiny layer, is probably transparent,

    3D game objects generally consist of two meshes, one for the visuals (i.e. what you see) and an invisible one for the physics (the so-called collision mesh). The mesh for the visuals has pretty high detail.. The collision mesh however has low detail because the performance that needs to be invested in collision detection increases with the number of faces. A good collision mesh preserves the shape of the visuals mesh as accurately as possible despite having a much lower face count. To accomplish this, tiny wrinkles that may exist in the visuals mesh get flattened out in the collision mesh. Also, accuracy may get reduced on purpose in places that are out of reach to colliding objects. The water tower, for example, does actually not need any elaborate collision at the top because that's out of reach to the player, and there are no high-flying actors around. If collision is noticeably inaccurate (the "thin transparent layer" phenomenon you were referring to) in places that can be directly interacted with, this is plain simply a mesh error and by no means a limitation of contemporary computer games. In fact, you can realize "perfect contact" quite easily; that only depends on the skills of the 3D artist.

    Now if you look at the tower mesh in the CK and toggle the collision geometry (by pressing F4 while the render window is active, note that you will have to wait a few seconds for the collsion meshes to be displayed), you'll see that the collision at the tower's base is pretty accurate, and also that the first aid box is the object with the bad collision (note the completely unnecessary details on the edges). That box was also not floating but clipping into the tower base instead, in addition to being placed in a position that blatantly derides real-world physics. That's a crystal clear placed reference issue (see screenshot).

    AuSecours.jpg


  8. Package records, conditions sub-records: there's a "parameter #3" listed by xEdit in each package of condition data (CTDA):

    It appears that this parameter may have different meanings - or may be totally unused - depending on what target the condition has been specified to run. If that target is a quest alias (i.e. the "RunOn"  line will display "QuestAlias"), parameter #3 is always the ID of that alias on the quest that owns the package (I confirmed this myself by playing around with the aliases).


  9. Which ghouls ? The pre-placed DEAD ones or those that you killed (i.e. the bodies of the pre-placed LIVE actors)

    We only handle pre-placed DEAD ones because they are never cleaned up otherwise. Pre-placed LIVE actors are clened up by the engine eventually after they have been killed. Though, in a very fresh game with few actors loaded so far, this may take a while.

    Side note: altering the time scale won't change anything because scripts need real time to process their tasks. This time won't change, so the only thing gained by altering the time scale is a longer game time span for scripts to finish running.


  10. Since we cannot disable refs when there is a risk that this could happen in plain sight of the player, we have to wait until the area unloads. More specifically, until all refs that need to be disabled have unloaded. This process doesn't start running until the player owns the respective workshop. Therefore, it usually takes place the first time the area unloads after the player gained control of the workshop.

    The Sunshine Tidings cleanup missed two ghoul bodies because they are in cells that do not form part of the workshop location, although they're still within the buildable area (Bug #23763). This has been fixed for UFO4P 2.0.4 but that fix was not retroactive (i.e. they won't be disabled unless you start a new game).


  11. I'm currently using NifSkope 2.0 Dev 7.

    Used this to change the user version numbers from Skyrim to FO3 (?), 12/83 -> 11/34., then saved (Note: the file had previously been stripped of the collision, the BSShaderProperty blocks and the BSX flags). Upon trying to reload it, I got this warning:

    [0] Array Properties invalid

    Pos 376: failed to load block number 0 (BSFadeNode) previous block was NiHeader

    Failed to load F:/Skyrim Mod Projects/Nifs for Blender Import/dwermsmcolumnfixed01_raw_01.nif

     

    Loaded the stripped file in old NifSkope, changed the user version numbers there and saved. This file loads fine (i.e. without that error) in both old NifSkope and NifSkope 2.0.


  12. (1) There is no function to toggle persistence from a script. If an object is unexpectedly persistent, this might be because it is still linked to other objects (or other objects being linked to it). Workshop objects that require an actor are linked from that actor (this link is deleted on unload and restored on load). All crops are linked from their damage helpers but this link is permanent; it is not cleared until the crop is deleted.  It also could be that the offending object is in a script property. All crops, for example, keep the reference of their damage helper in a script property and they also have an array on WorkshopObjectScript to keep the references of their furniture markers.

    (2) Deleted objects are not actually removed until their parent cell unloads. Up to that point, they're only "marked for deletion" (that's why scripts should disable them before they delete them, so they are at least invisible until they are actually deleted). Thus, in order to make sure that you don't look at bogus objects, you should allow the workshop to unload and reload before you start inspecting objects. Better though if you allow it to unload and reload twice because the householding functions that start running when a workshop loads do a lot of cleanup stuff that may result in even more objects being removed when it unloads subsequently.


  13. Update:

    I'm pretty much convinced now that this iis not an F4SE issue. You might want to have a look at this ticket which we fixed almost two yeras ago:

    https://afktrack.afkmods.com/index.php?a=issues&i=20640

    In this case, an actor array that should actually have been initialized by the OnLoad() event was mysteriously 'none'. At that time, I had no F4SE running (and it did probably not even exist). I also did not spend any time to investigate why the array was none Just added a sanity check and a line to re-initialize the array if necessary, and that did fix it.


  14. That's an as yet overlooked vanilla bug !

    If you send an actor to another workshop, or if a new settler is created for a workshop, the workshop scripts run the TryToAutoAssignActor() function on him. This function auto assigns the actor to food or safety (depending on whether he's a guard or a normal settler), by setting a property on his WorkshopNPCScript, and then assigns him to all unassigned objects of that type that already exist at that workshop. If there are no unassigned resource objects, it won't do anything, and also clears the porperty on his WorkshopNPCScript again.

    The scripts check for brahmins before they call that function, but they forgot to check for Dogmeat.

    To unassign him, you only have to assign the objects that are currently assigned to him to somebody else.

     

    EDIT: there also may be something else wrong, but not on the scripts: Do you, by chance, have a mod installed that removes the LocTypeWorkshopSettlement from some or all workshop locations ?  Asking this for a reason: around two years ago, I downloaded a mod that removed the enemy level lock on locations (i.e. made it so the level won't get stuck at the level  of your first visit to a location) and then found out that this mod removed that keyword from all workshop locations. Reported this to the mod author but I don't know whether it was ever fixed. Removing that keyword has detrimental effects on the workshops because the workshop scripts check for it and some operations will not run as intended if it's missing. This would in fact explain why TryToAutoAssignActor() runs on Sanctuary while you are at Red Rocket when it actually shouldn't.

Support us on Patreon!

Patreon
×
×
  • Create New...