Jump to content


  • Content Count

  • Joined

  • Last visited

About DayDreamer

  • Rank
  • Birthday 06/11/1957

Profile Information

  • Gender
  • Location

Recent Profile Visitors

5411 profile views
  1. You should probably also clean the masters. No reason for all 3 DLC.
  2. AFKTrack currently is failing to upload .7z proposed bug fixes.
  3. I've recently rediscovered this problem, and posted a resolution here. This is a CK2 bug. It assigns the sharedinfo a new number, leaving your new reference at the old number. Using SSEEdit, you need to renumber your new reference, then renumber the original back to its proper number. The shared voice files (and lips) match the original number.
  4. As a side note, you can move objects in script properties (level 5) by renumbering them with xEdit. I don't know what happens to the old object in the save file, but the new object will appear in its new position, and its script properties will be refreshed. Usually, this means that the object with the script property will also need to be renumbered, so that its properties will be refreshed with the renumbered reference. When adding script properties, you also must renumber any objects using the script, so that they are refreshed with updated properties. However, dialogue TIF properties seem to be an exception. All their properties seem to be refreshed at time of execution. Perhaps they aren't normally kept in memory? My current technique is to have quests only in TIF properties, with as few as possible hard coded references, using keyed linked references in objects as much as possible. Obviously, the keys themselves appear in scripts, but they are generally vanilla and unchanging.
  5. [Lost with recent DB reload] Cell (-9, 18) in world 'Tamriel' (0000003C) is not in exterior cell data. Cell (-8, 19) in world 'Tamriel' (0000003C) is not in exterior cell data. After fixing some navmesh near Movarth's Lair, this has appeared in my CK2 warnings. What does it mean? These are MovarthsLairExterior04 and MovarthsLairExterior02 respectively. Along with MovarthsLairExterior01, they are in MovarthsLairLocation. MovarthsLairExterior03 is not in any location, probably a bug (but no warning).
  6. Me too, we don't thank folks enough.
  7. SharedInfos are voiced response lines used in more than one place, so that they didn't need to record the same lines over and over. Simple enough concept. However, make sharedinfo on an existing INFO creates a new INFO, then moves the new INFO into the sharedinfo list, and points the old INFO at the new INFO. That means the voice line would need to be re-recorded for the new INFO formid. Fixing requires xEdit. Swap the formids. Find the original INFO. Select change formid, control-C copy the original, change to any low unused number such as xx000888 (anything less than the next object id in the header). Control-click the DNAM response formid. (Write down that new response formid.) Select change formid, control-V paste the original formid. Go back to the unused number, and change it to the new response formid. Load up the CK again, check that it now is voiced. Also, a second CK bug is make sharedinfo doesn't clear the number of response lines. Go back to the now renumbered INFO, and re-select the same named response. That clears the number properly. (Or do it in xEdit, but I'm always worrying that the CK is doing something else we don't know about.)
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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....
  15. 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.

Support us on Patreon!

  • Create New...