Jump to content

DayDreamer

Members
  • Content Count

    699
  • Joined

  • Last visited

Everything posted by DayDreamer

  1. Oh well, I wish that I'd known all that before spending $1,000+ on the Valve Index. (Skyrim VR was half price on Steam, so saved a little something there.) Not a Reddit consumer. Nor a PlayStation of any vintage; one of the reasons that I'd initially ignored it as not aware Skyrim was out for PC VR. Searched for topics here and at Bethesda.net, didn't see any negative details. The VR topics are quite enthusiastic. Now that I've got the Index, I've also learned that my GTX 1080 isn't powerful enough to handle full graphics, whereas on my 4K OLED it is quite lovely. So Skyrim VR looks like the original before the High Resolution DLC. Even RTX 2080ti supposedly isn't enough. Rather disappointing as yet. Definitely not worth playing without US*P.
  2. It's been out over a year, which was about how long it took for SKSE64 to be finished. SKSE VR has been out for awhile, and also SkyUI VR. What do we need to get USVRP/USSEP working? Creation Kit 2 can be made to work (according to forum posts), but the scripts don't match. Do we have a good direct contact at Bethesda? The reason that I'm asking is dozens of folks have asked for Touring Carriages VR. So I've recently purchased a Valve Index. OTOH, Steam Charts says that only hundreds of folks are running VR (280 at this moment), relative to the tens of thousands still running LE (7109) and SE (13788).
  3. I'm disappointed that you don't run TC. After all, it was cut content! Real Carriages was one of the first things posted on the Steamworks site, and Bethesda clearly encouraged us to complete it. You gave good advice back in the day, and we used to coordinate, even agreeing that LOOT should load CRF after TC so that changes to the same places worked well together. But the point of all the navmesh tutorial that I've done is to explain how important the border triangles match their vanilla jumps, so that plugins will work nicely together. "Somebody else's problem" handwaving won't fix it. Each is independent. In the TC case, I'm not modifying the adjacent navmesh, so the problem is occurring with bad jumps to/from plain vanilla. But any plugin that installs in any adjacent cell will also have problems. It's just the nature of the beast.
  4. Product version 1.5.80.0 As I've amply documented, the error is in your navmeshes (plural) at the border with POITundra22 and its adjacent cells on that corner. TC does not alter POITundra22 navmesh. You should not need to run TC to see the NPC problems. As to your other comments, most of the other documented errors in that area are in the non-preferred navmesh, so they probably don't affect any NPCs who don't travel in the non-preferred triangles. They are still egregious errors in the border triangle jump (port) tables, readily visible in xEdit. As to my proposed replacements: I do not break anything in Frost River, intentionally or otherwise. I've observed no problems with guards. Moreover, guards do not cross the boundary into POITundra22, which is the problematic boundary. There is no reason what-so-ever for you to narrow the roadway preferred navmesh, nor to make so many narrow slices. The game engine simply doesn't handle that well.
  5. The example shows a specific border crossing error in CRF 3.1.4, and documents others. Is the tutorial insufficiently clear? I'm surprised that you are unable to reproduce. One vanilla follower who isn't working is Faendal (the only one I've tested). If I learn how to make a short 30 second game video (seems to be a new Win10 feature), would that help?
  6. When I have a bit of time, I'll add an explainer for the road, too. After all, the road was the original source of detecting problems. It does not work properly. On the one building that I'd touched, the original navmesh was under the building. I've 'z' raised it to the roof. The roof is next to the ground at the back, so this makes it possible for NPCs to run up the roof. I'd thought it rather clever. But the main reason for cleverness is to prevent the loss of triangles and vertices, so that border triangles aren't renumbered. That is needed, although there are less clever ways to accomplish the same thing. What other building? I'm sad that you are not willing to take my well-documented patch. I'll make it available for TC+CRF users instead.
  7. Wow, how soon we forget. Dozens of posts in multiple forae, finding unfinished stuff and creating proposed patches, and of course bugs and their fixes. I've always viewed this as a community effort. Of course, Touring Carriages would be cutting room floor as well, but Khulmann and Solar had shown parts of the way, and by then I'd made it work already. I'm surprised that your followers have no issues. I'd spent considerable time over a week period figuring out the problems. Then a very long, tiring, 15 hour day fixing some of them and repeatedly testing to ensure it worked better. Since you especially do not see any bad border links, I've done another tutorial for just one of them at: https://www.afkmods.com/index.php?/topic/5229-navmesh-repair/&do=findComment&comment=175537 Also, listed the others in the Frost River area at: https://www.afkmods.com/index.php?/topic/5229-navmesh-repair/&do=findComment&comment=175540 For the record, my scripts tell me there are 212 renumbered border triangles in the whole CRF. Obviously, some of them are necessary. I've fixed those that are crucial to only two cells as they affected Touring Carriages. Much more needs to be done. I'm using the most recent CRF 3.1.4. Please manually check my changes with xEdit for your own satisfaction. Note how many triangles are now at their original vertices. Installation should be an easy drag and drop of each navmesh line into CRF. (I've tested that, too.)
  8. One down, many more to go. Just in the Frost River area: I've not done them all, but some of them are crucial. My limited fixes thus far are found in: https://afktrack.afkmods.com/index.php?a=issues&i=27173
  9. Having left the find (control-f) dialogue box open, we simply again Go To triangle 273: Select triangle ('t') the old Triangle 15, and delete ('delete') it. As above, our new triangle 389 will be renumbered to 15. For clarity, I've cycled the view ('w') to navmesh only. First select the older top vertex, then control-select our newer bottom vertex: Join them ('q'), and Finalize (control-F1): We can see that it is now connecting Triangle 273 properly to the adjacent vanilla cell Triangle 237.
  10. To repair, we make a brand new triangle (389) overlay, with the same first two vertices in the same order (24, 40), and the third near the remaining original vertex. In vertex mode ('v'), select 24 by dragging a bounding box around that vertex, then 40 by control-dragging around that vertex, then control-right-click to make the triangle: Now, we need to find (control-f) the desired triangle: This takes us to: Remember the 3 vertices and their order (131, 141, 95), then delete ('delete') it. You'll see in a later picture that triangle 389 we made above will now be numbered 273. Select the same 3 vertices in the same order, and add ('a') another new triangle (389) in the same place. So far, so good.
  11. Another year, another example. The current Cutting Room Floor has rather a large number of bad border triangles. Here's a quick refresher tutorial about how to repair just one of many issues. If you walk along the main road near Trilf's House, your follower will either run around through the middle of the village (eastbound) or become stuck at the corner of the building (westbound). Touring Carriages will not pass the building in either direction. First, we need to see what vanilla expects. There is a long narrow border slice, Nav 000E8B41 Triangle 237. With CRF loaded, Edge 2 cannot find its adjacent reference: Turn off adjacent cells ('n'), and look at what is actually there in CRF. Nav 000E8B61 Triangle 15 has no Edge 0, due to a failure to Finalize or some other CK error. Let's use xEdit to see what's wrong. This shows that vanilla expects Triangle 273, not Triangle 15. So in one direction, our intrepid follower/horse is trying to jump to a distant triangle 273 somewhere in the middle of the IronTreeMill cell. While in the other direction, s/he has no idea where to go from triangle 15. Just as we've observed.
  12. 64 GB, and it's not using it. Interesting link. My guess is there's a lot of 32-bit cruft, and not much in the way of error checking. My technique for keeping triangles intact (new triangle carefully selecting vertices in the same order, deleting the old triangle, then 'Q' joining) probably uses more memory than the usual. Multiply by 400+ (and a lot of hours) for this effort, likely stressing the memory. But I didn't mean to hijack this topic. Do we have a CK bugs topic here? There was an extensive one on the old bethsoft site.
  13. I've been hearing about instabilty of the latest (1.5.73.0) over on the Nexus. I've had it generate bad bsas, and probably bad esps. The old one used to crash after compiling 19 files, but haven't done much compiling with the latest version, so unsure whether that's been fixed. On navmeshing, the first Undo works okay, and subsequent ones get slower and slower. Mostly it crashed on Save, once destroying the saved esp file. Finalize caused a crash (once); then had no problems on redo. Find Cover caused a 18 triangle island to merge the main 420+ triangles into itself, even though I'd never made any changes to it and there were no obvious links; then also had no problems on redo. So these are likely transient memory management issues. Had upwards of 20 crashes yesterday, only doing navmeshing. In this case, there were 3 main problems with CRF that I've found: Lack of Finalize. Iron Tree Mill and Frost River Smith both had missing border links. When I Finalized the SmithCELL, a small 3 triangle island split off in adjacent FarmSE, so that was not Finalized properly either. [Another CK error.] Border triangle renumbering. POITundra22 was trying to leap into the vanilla triangle, but that was no longer on the border. This was amazingly hard to find, as they are very difficult to see, long, skinny, triangles on both sides of the border. An easy fix, as I've detailed on the navmesh repair topic. The main road was narrowed, and renavmeshed with a lot of skinny slices. The vanilla worked better, and a few simple improvements make it work much better. As you know, I've been using CRF since early days, and contributed to it. I like it, think it important, and it's long been essential to my load order. I'm just not playing often anymore, so not noticing the changes as quickly as before. https://afktrack.afkmods.com/index.php?a=issues&i=27173
  14. Just to note that I've gotten it to work, after 15 hours of trial and error. Now need to do the interior non-border paths that I'd skipped, and I'll post it soon. Most of the error was by the CK. The current version crashes every hour or so. Most often as I'm trying to save, sometimes corrupting the save file. Losing my work twice after nearly completing it, on the 3rd pass copied the saved file after saving. And sure enough, had to go back several times. The SE game engine seems better in so many ways. After a few thousand hours on the oldrim CK and testing, I'd never expected that the newer CK would be worse.... We need an open source community CK.
  15. That's why my test was with a follower. Directly tests the game engine pathfinding. That's revealed fixes to a dozen or so places where the navmesh doesn't work properly, even though it looks perfectly valid. The usual problem, and the likely problem in this case, is the game engine doesn't like long skinny triangles that have to be crossed lengthwise. For example, where the terrain artist built the road at a corner of a cell, gradually crossing the side of the cell into the next cell. Another problematic shape is larger triangles in the midst of many skinny ones. The NPC behaviour is often to stop and "look around" (spinning or casting back and forth). The best triangle shape seems to be equilateral, with travel perpendicular to the sides. But the automated navmeshing usually makes a lot of skinny triangles radiating out from a central point. The path marker solution that I've used in various places (such as the main road leading West from Whiterun near the burned out farmhouse) is putting the marker just off the preferred road mesh adjacent to the road. Marker locations are chosen by observing NPCs. Those locations look perfectly valid, but NPCs swerve off the side of the road. Sometimes, they swerve off different sides depending on the travel direction. No idea why, but just have to use what works no matter how inelegant. One of the problems fixing this spot is that the CRF navmesh changes are extensive, and there's no visual before and after comparison utility. xEdit has some nice navmesh data comparison features (not on by default) that are okay for small changes, but this looks like nearly everything changed. The only way forward (that I can think of) is to take a snapshot of the current CRF navmesh, then start over changing the fewest possible vanilla triangles to reach the desired result, testing and re-testing.
  16. Mentioning in passing that the light post on the road near the Nightgate Inn also is too close to the road. But the wagon just grazes it. In general, sticking posts under the armpits of the 'T' is problemmatic. Followers (and horses) run into them, because navmesh isn't that specific. They cut the corners, often following the edges of the preferred navmesh.
  17. The Frost River updates caused some problems with Touring Carriages. The signpost (in the lavendar) near the road junction rock pile is inside the preferred road mesh, and the wagon kept hanging on it. Kuhlmann (Real Carriages) had moved the rock pile farther away from the road. I've moved it back now to provide visual stimulus for why I've added path markers sweeping around it. But the wagon still hits the post, although it doesn't hang anymore. (I'll try to have my next version out soon to avoid complaints.) Better would be to move the signpost "above" the top of the T intersection, outside of the preferred roadway. That's what vanilla does in most places (Whiterun, Windhelm, etc). In general, that's the best place. I'd had to stop using Point The Way years ago because of so many posts too close to the road. The horse near the wagon is often (but not always) in the road. There should be a horse seat marker, and a horse sitting package, so that he doesn't wander. But the biggest problem is that once again the carriage won't pass Trilf's House (either direction). Years ago, I'd given you a fixed navmesh; but you've changed so many things since that it doesn't apply anymore (for one thing, there are more buildings with doors). I've looked really hard at it over several days, and nothing is obviously wrong. The cell border triangles match there on the road (although not in other places). An easy test is to run backwards past the house in 3rd person, and see what your follower does. My follower often gets stuck near the corner of the building, but sometimes near the rocks on the other side of the road instead. Usually, the follower will run all the way around through the middle of town. (That's what the horse does going East, but just hangs trying over and over going West.) I've got some test files. Where would be the best place to discuss?
  18. My guess is I'd simply never hit the circumstances for the new "wild" horse behaviors, as they didn't kick in until the wilderness spawn increased with my level. After futzing with several methods of fudging things, none of which were foolproof, I've settled on making the horse Foolhardy. (Vanilla is Cautious.) That seems to work most of the time, even with a leveled Forsworn standing near the road in my tests. It's always been a problem that even a skeever standing directly in the road can bring the horse to a stop. But that's a long-standing game engine navmesh processing issue, not a new predator/prey issue. Sometimes an occupied tiny navmesh slice will block everything, when there's no path around it. The game engine will often "jump" the NPC over the sticking place to catch up with the player. That cannot happen for the horse, as the player is by definition in the cart behind the horse. I've decided not to use the Prisoner Faction. That makes just about everything a friend. But the vanilla design seems to deliberately prevent creatures and bandits from attacking the horse and driver, but allow wizards and others. I've even found a place where wizards won't attack the first time you pass, then attack the second time, forcing you to get out and fight. And of course you have to stop and fight dragons. I'm trying to stick as closely as possible to the vanilla design intent. Thanks for all the advice!
  19. Yeah, but there are Spectre variants that have no software fix. A few months ago, I watched a demo where they could run OpenSSH between two processors, it was so fast and effective. There are even BTB exploits that can bypass the new compiler directives that mitigate the other exploits (just saw a presentation on Tuesday). SPOILER makes the attacks even faster, and can run in driveby Javascript. Still, we are all thankful to Gibson and his many utilities over the years. I still regularly use his password generators.
  20. That's from last year, and I've never seen this new behavior until now (running without any CC). I'd started a runthough on Nov 11, and have tested many/most of the carriage routes along the way, often several times at different levels. (I'm now at Level 28 after a couple of hundred hours, but strict role playing goes slowly.) Still, hopefully related somehow. Does anybody know who at Bethesda might be able to help?
  21. Thanks. Knowing nothing about animation, is there somewhere that I could learn about decoding and understanding the changes? Also, the unexpected behavior is to run off the road, leaving the preferred navmesh, dodging behind a signpost, and eventually stopping in any place where the navmesh has a dark blue cover edge "hiding place". (I've tested/watched this many dozens of times now.) This seems more like a prey/predator behaviour. Is that in the animation? Or is there somewhere else I need to understand, too?
  22. Something new: 1.5.80 sometimes affects carriage horses somehow. Places (canyons?) where something takes over the horse's actions to make it run. If already running, then turns around to run back the way it came.... Boy oh boy was that tricky to debug. Fortunately, I already have a pathing technique to slow down the carriage, originally for towns, and am adding path markers around the problems. Is there some newish CC that involves horses?
  23. Tips has been implemented in the same fashion as many other programs. Easy to turn off. Easy to stop seeing in the current session, and then have them in the next session. Besides, with all the changes, it gives me something to read while running the new auto-clean. That we all had to do this past week with the latest surprise Bethesda releases. But I'm not that happy with the old clean being removed. I liked having the intermediate steps for my own work to check that it was doing what I wanted.... Still getting used to 4.x. Have stopped obsessively downloading every new version. Using whatever is on nexus, hoping for stability.
  24. On PC, I've only seen her miss the first one. And that is somewhat random, depending on where you cast your test spell. Couldn't find anything to fix in CK. Assuming a game engine issue.
  25. I've got Oblivion and Morrowind because they were bundled with Skyrim by the time that I'd purchased it (early 2012). Not yet played either of them. But LOOT state of the art is so far beyond what we'd had in earlier Skyrim days, I'd appreciate LOOT becoming the ecosystem standard, just as xEdit has become.

Support us on Patreon!

Patreon
×
×
  • Create New...