Jump to content


  • Content Count

  • Joined

  • Last visited

About DayDreamer

  • Rank
  • Birthday 06/11/1957

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1659 profile views
  1. Excellent, thanks. I didn't know req worked as after. I'll have to keep reminding folks to update their master list. The Description already tells them to sort with LOOT, but using Vortex they don't see the master list update reminder as it runs automatically. (There's a separate UI element.) I'm fairly sure they don't see the LOOT warnings either.
  2. I've done it, although Nexus no longer allows '+' so I've used '-'. And asked for an update to the LOOT master list over on Github. Unfortunately, that updated master list isn't working for some folks. To explain: the current updated master list has only TC-ICAIO "After Immersive Citizens - TC patch.esp" (ICAIO-TC in my notation). That works If and Only If (IFF in mathematical terms) the user installed TC, then installed ICAIO, then installed TC-ICAIO. The LOOT result is the 4-way sandwich TC, ICAIO, ICAIO-TC, TC-ICAIO (wiping out the bad ICAIO-TC changes). So far so good. ICAIO has a conditional installation package check and only installs ICAIO-TC when it detects TC has already been installed. So any other installation order doesn't install and sort correctly. Many users installed ICAIO, then install TC later. TC-ICAIO has been specifically written without ICAIO as a master (to avoid the Permissions prohibition on modification) and is in default group, so LOOT (Vortex?) can sometimes install it before ICAIO. That won't work. Could TC-ICAIO please have 3 after conditions (as I'd attempted to request over on Github)? After TouringCarriages.esp. After ICAIO. And (as currently is) After ICAIO-TC.
  3. CptMcSplody recently explained (elsewhere) how to set ICAIO to default group, so that this sandwich would happen. I'm not sure it matters. I'd been looking at the ICAIO-TC patch conflicts on its own, without checking how ICAIO itself is internally structured. What we are experiencing is similar to graphics Z-fighting. Load order isn't helping, other than incidentally. ICAIO is a set of massive Quests, mainly organized by city. Every actor is an alias in these quests. That's how it runs the superceding packages for "immersion". No matter where it loads, these individual quests spontaneuously run a package on the actor from time to time. The problem is that there are other quests with these same actors and often the same or similar packages. Sometimes a vanilla quest with an actor gets going, but then the ICAIO package executes an override that interrupts the vanilla quest. Sometimes this override is a package from the vanilla quest that has already run. Sometimes the package creates conditions that were never envisioned in the vanilla quest/scene. Simultaneous parallel execution without any semblance of threading or dispatch signalling. The author has turned off his nexus forum page for a couple of years now, and doesn't answer direct messages. His permissions don't allow bug fixes. Although fairly popular, my guess is the best alternative is to flag this as dangerous, as it damages every other quest/scene with the same actors.
  4. IIRC, we added that condition because of Run For Your Lives; actually When Vampires Attack at the time, driver ran and hid in Windhelm City, and trying to take a ride from him caused a reproducible problem. Ensuring he was sitting was enough to fix it, because the only place he sat was on his linked seat. Agreed. Personally, I don't run ICAIO (I've always used Run For Your Lives), so I've no good reproducible tests. It's just user reports. (Many of them.) Thanks for all the assistance. At least I've learned something about failures of the OnSit() event and the "link.IsInFurnitureState Sit" conditional. Maybe they'll work in some future game engine. Reported bugs in tickets 200515-007256 and 200515-07347 respectively. No idea how to access anybody else's tracked bugs.
  5. Interesting. That's a vanilla script: CarriageDriverScript. The Bug note is 2015. Anybody know whether that bug has been formally reported to Bethesda? The bSitting conditional variable is only relied upon in one line of code. Since the vanilla driver only ever sits in one place, this bug may not have occurred in the past. ICAIO claims (on its description) to have been QA'd by Bethesda. Arthmoor's target practice is on the same Bethesda page, so he could tell us how much vetting is actually done.... What should be done for US*P?
  6. Ahem, only some of us are programmers, even senior or distinguished programmers, but have also been very senior managers. Or as a former colleague once phrased it: "I route, therefore you exist." Others are not. But we all understand the process of elimination and Occam's Razor. Please don't be discouraged. Keep in mind that folks generally don't like it implied that they are idiots or didn't understand you. There is a wealth of experience here fixing Bethesda bugs going back at least a decade or more.
  7. Aha, might help to be mentioned in USSEP Fixes, with the usual strikeout in UDBP. I know most folks never read it, but a few of us do....
  8. Not exactly, although your idea is very clever, and I'll look into it for the future. (There already is CarriageSystemFaction and unused JobCarriageFaction.) 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.
  9. Been years since I've been staring at papyrus logs, but recently a new warning has been showing up: [05/09/2020 - 06:09:04AM] warning: Variable ::DLC2NordicArrow_var on script udbp_retroactive212script loaded from save not found within the actual object. This variable will be skipped. [05/09/2020 - 06:09:04AM] warning: Variable ::LItemBanditWeaponArrows_var on script udbp_retroactive212script loaded from save not found within the actual object. This variable will be skipped. Not seeing a change notice in the USSEP history for the most recent release.
  10. I've tested, and it works reliably. The downside is that it requires the driver to re-load and re-sit before it works. So only after leaving a city. Not as user freindly as I'd like. After much hair pullng, tried pairing the existing "subject.GetSitting == 3 AND" with "link.IsInFurnitureState Sit == 1 AND". The driver links to the furniture. You don't know where the driver is sitting, and you don't know who is using the furniture, but the pairing should work. Yet it didn't. Could somebody else test and tell me what I'm doing wrong?
  11. There's another value specified later in the unused StopRiding() myDriver.SetActorValue("variable01", 1); reset "home" to be here. Would folks be willing to add a similar line to CarriageDriverScript OnSit() to parallel bSitting? Known values: 0 = off (unknown), 1 = home (idle), 2 = chatter, 3 = pausing ride
  12. ANSWER: 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. The vanilla alternative that was only partially implemented was using Subject:Variable01. 0 means ready for dialogue, 2 means ready for chatter on ride. US*P already has a bug fix using these values. But there now exists a popular Better Vampires that alters Variable01. There may be others. Modders who didn't read the CK documentation. https://www.creationkit.com/index.php?title=Actor_Value My advice has always been: Perhaps a bit rude, but these are nearly impossible to debug. They don't show up as conficts in xEdit, because they are scripted.
  13. Script. Currently runs at a variable rate. Had moved this from the driver into the horse, so it worked better as the carriage turned corners. Also, driver has its own OnUpdate for Say() chatter. But it tends to miss NPCs that move just in front of the seat between the horse and driver. That's also why I've changed from FindClosestActor() to FindRandomActor(), and shifted the coordinates out in front of the horse somewhat. The closest to the horse is usually the driver, and vice versa. Re-starting the same quest over and over wouldn't work. Could be another quest instead? Can a quest do positioning this fancy?
  14. Many of my critter fixes were included here years ago. Since then, somebody analyzed 3,000+ landing sites, starting with USSEP's existing fixes. Should we port them all to here? (Has permission.) https://www.nexusmods.com/skyrimspecialedition/mods/29434
  15. Just noticed that https://www.nexusmods.com/skyrimspecialedition/mods/21055 Enchantment Reload Fix SE was ported. It was previously recommended for LE, so it could be added to OP here.

Support us on Patreon!

  • Create New...