Jump to content


  • Content Count

  • Joined

  • Last visited

About Jebbalon

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

663 profile views
  1. Ahhh... That makes sense now. Ok, so does it have to go in OnInit() or can it also go in OnBeginState() or even OnUpdate() ?
  2. Opened Issue #27626 Adding the filter to OnInit() works too then. One of my scripts for tracking gold, I put them in the OnItemAdded/Removed and that worked too. - I guess there are instances where it would need separate filters for Added vs. Removed. Like gold added to sweetroll vendor and sweetrolls removed. The restriction is to have the filter in the script instance where it is used. Which is all the wiki really explains. Thanks Arthmoor -Jebbalon
  3. This is more of a bug report but also a question about using inventory event filters... I came across a stack dump in my papyrus log this evening (it happens). It contained references to the hearthfire script BYOHHouseBuildingPlayerScript.psc which in this case tracks the number of logs cut at sawmills.Sawn Logs are a weightless non-playable miscellaneous item added to player. The issue I see is that the script is not filtering for only the logs. Therefore EVERY item added to or removed from the player is tracked by that script. In my case the stack dump coincided with being thrown in Falkreath Jail. That included all my items being taken and later returned. That generated many of the inventory events that this script then had to process no doubt leading to the stack dump situation. Here is just 2 stack dump snippets from the log... the first shows the script firing for a Soul Gem being returned to me from the Falkreath evidence chest ( FalkreathEvidenceChest [REFR:000EF437] ). The second shows checking for the number of logs ( BYOHMaterialLog "Sawn Log" [MISC:0300300E] ) Which happens in another script BYOHHouseBuildingScript.psc. It was after Cabbage Soup (000EBA02) was returned to me. The controlling quest is BYOHHouseBuilding [QUST:0300305D] Here is the BYOHHouseBuildingPlayerScript.psc - it is short enough... Adding AddInventoryEventFilter(BYOHMaterialLog) to both OnItemAdded() and OnItemRemoved() would do it. Right? Also, that is the proper way of adding Inventory Event Filters ? correct ? I've seen some scripting that puts the AddInventoryEventFilter() in say the OnInit() event. But I'm not sure that is correct as each could use different filters. Putting the function call into the event makes sense to me, outside the event where it is used doesn't. Anyway, thanks in advance for any insight into this. If it is good thing to add into USSEP I'd be happy to add tracker ticket. -Jebbalon
  4. Well, I'm not sure what is causing crash at Helgen ( see above ) I did remove the edit to that Navmesh from Alt Start - Thing is that the adjacent cells are not also edited. There is landscape changes. So, not sure if the navmesh was finalized or what. Doesn't that do the borders and add adjacent cells to the mod? Anyway, The save that is crashing didn't change. I suspect that something is baked into save. I started a new game using the camping in the woods start. Ran around Helgen just fine, went to Whiterun via Bleak Falls Barrow, killed Mirmulnir, and returned to helgen to check it out. No crashes but the fires were still burning. Left for a day and the fires were out but no bandits. Looked in CKit to find that you have to wait 4 days and visit Whiterun to enable the bandits in Helgen. Did that and ran back there - no crashing! I did run NifOptimizer on lots of my load order that had loose files - not everything. Maybe it caught something, but that save is still crashing. I wish I could figure it out. To me it seems to crash when cell 3, -20 is loading in. That is cell with entrance to Helgen Keep and Western Gate and where the opening scene carts stop. In CKit I viewed from way above helgen with -B-orders turned on. You can see the 5x5 grid that is loaded in fairly well when you do that. 3, -20 is the cell that would be loading when I approached from the north and again from the east. It's not adjacent to the campsite so..... I have no idea what's going on. Anyway, ramble over. Going to start new new game and hope that this doesn't come up again. Thanks
  5. Hey Arthmoor, I'm getting a hard crash outside of Helgen and I've been trying to figure out what is causing it. I'm ~ 75% sure that it is not meshes or textures I've been over my load order multiple times. The ONLY mod that changes any Navmesh in block 0,-1 sub block 0, -3 is Alt Start for the campsite in cell 1, -18 ... I looked at Navmesh edits in all the cells around Helgen in xEdit. [NAVM:000EC740] (in GRUP Cell Temporary Children of ARTHLALCampsite [CELL:000097EF] (in Tamriel "Skyrim" [WRLD:0000003C] at 1,-18)) - record ID for navmesh in question. This is happening after Dragon Rising, so the bandits should be in Helgen - actually they are, I got close enough to Eastern gate to see them. It crashes if I get closer. Around on the North side approaching Helgen gate the crash happens well before getting to the gate. What is bugging me is that I used the Camping in Woods start, I took a left and went to Falkreath first then came back through Helgen to pick up the Alt start book. No crashes until after Bleak Falls, Whiterun, dragon at watchtower and now back to Helgen area where I'm getting the crash. Any ideas?
  6. Link to Issue #25519 I know this has been closed but I noticed something that might be relevant. The MQ303 where their interaction takes place has Farengar in an alias but it is not marked with Allow Dead. USSEP does not edit MQ303, only the script fragment... The QF_MQ303... that USKP changed checks for the alias reference IsDead() But, if he is dead and the alias is not filled then ..... How would that fail ?? As an alias not filled or the IsDead check failing with false meaning alive. ? I looked at my setup and am confident that USSEP is only instance of those scripts. Also, I did the MQ303 quest long after the Mephala quest where Farengar was killed. So filling those aliases happened after he was dead for sure. I could be wrong of course but just wanted to bring it up
  7. It looks steep but it's not too steep to stop them. I think it is more they are running into the rock with current version. I did try in game to just disable the rock but that didn't work. The navmesh would have to be lowered I guess. I also think it is "good enough" - like I said 100% better because they do end up going up the path instead of around entire mountain. With bandits - normal play would not be watching to see them bumping into rocks. I'm probably the only person enjoying watching them run around Yeah, no need to stop the presses on next USSEP. (not that you would for this) Followers would be more the issue and they tend to have work-arounds for getting stuck. Below is my current files for the Patrols addon - requires OBIS SE.esp from Nexus site version 2.5. Separating out just the two patrols that go there would be ... difficult. 1. Load up everything - use the settings book or MCMenu if you have that to enable the patrols. 2. I use ~ TDetect to toggle detection to just follow them around. They also won't spend time fighting everything along the way. 3. Go to Mistwatch keep (Darkwater Crossing side) - Reset the patrols by making change in settings then wait indoors 1 game hour. (you can turn on debug notices to see that) 4. Head out and you should see them jogging up the path from mistwatch. If you look in xEdit/CKit the patrol from Mistwatch up to Riftwatch Tower is #15 and the patrol from Faldar's Tooth to Nilheim is #19 - they cross on that path. Thanks again for looking at this OBIS SE Patrols Addon - for AFK testing.7z
  8. Video starts with patrol 1 trying to go up path. Then Patrol 2 comes down the path fine. Patrol 2 then comes back and gets stuck with 1 I then go up the path out of range and wait an hour - this gets them past rock Then the Patrol 1 comes back down the hill without problem. Hope that helps maybe you can see where to make changes. Thanks again for working on this DayDreamer
  9. Ok - that didn't work. The pretty much stayed at the middle of rock trying to go up. He did several loops back and forth and did move more toward the pink double lines side but never enough to jump up there. The patrol coming down did fine again. They used that area around the pink and did the jump animation. Returning though they were in same situation as other patrol. I have a couple screenshots, but I also made a few videos - give me a bit to edit them together into one shorter video showing everything. I'm thinking it has hard time jumping up. That animation needs to fall across the gap onto the other mesh to work. Going up is hard to get that fall across. Might need to overlap them maybe?
  10. So, I gave it a try and it worked ... well sort of... The patrol coming down the path worked great - they didn't hesitate and it looked really natural as they jumped down that rock. The patrol going up ( see pic below ) got hung up on the NorthEast side of the rock. They were not able to jump up the rock there. They kept trying though and that is 100% better than them going up around the mountain. Also, I did wait for an hour ( wiat menu that is ) and they made it past the rock and on up the path. In your image - the double pink lines at the Top is the area where they are in my pic below. I'm wonder if the jump down can stay there but remove the jump up - I think it is just too steep right there. The other side of rock might be ok but they did not try that side going up the path.
  11. The way you describe it - My guess is that the pathing wasn't working in that area and they moved the rock thinking it was that. Instead it was the rock that probably caused there to be islands in the area that were not connected. Removing the rock didn't do anything but that was what appeared to be blocking the npcs. Anyway... is there any way I can plug in what you uploaded to test it out ?? Or would it be better to wait for release? and Thank you for looking into this issue DayDreamer!
  12. Thanks... I didn't do this for the recent release of OBIS SE v2.5 patrols. Like I said - I just re-routed the patrols to avoid that mountain path. If I do update this again though I'll try out that jump technique.
  13. The terrain is steep in that area but should not pose a problem, the separated navmeshes is more of an issue. 1. Is there an object that can be placed across the gap to link them? Sort of an opposite to the Nav Cut Box. 2. Instead of joining the meshes - what about making them Dropdowns (selecting edges and press 'P' ) ? Might look strange to see NPC jumping there..... but would that work in both directions ? hmm...

Support us on Patreon!

  • Create New...