Jump to content

DayDreamer

Members
  • Content Count

    695
  • Joined

  • Last visited

About DayDreamer

  • Rank
    Clanholder
  • Birthday 06/11/1957

Profile Information

  • Gender
    Male
  • Location
    Michigan

Recent Profile Visitors

1345 profile views
  1. 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?
  2. 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.
  3. 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.)
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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!
  15. 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.

Support us on Patreon!

Patreon
×
×
  • Create New...