Jump to content

DayDreamer

Members
  • Content Count

    699
  • Joined

  • Last visited

About DayDreamer

  • Rank
    Clanholder
  • Birthday 06/11/1957

Profile Information

  • Gender
    Male
  • Location
    Michigan

Recent Profile Visitors

1366 profile views
  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.

Support us on Patreon!

Patreon
×
×
  • Create New...