BlackPete Posted October 31, 2013 Share Posted October 31, 2013 EDIT: GOT IT! While looking at your screenshot, I got an idea and now I know what's happening: It's the High Res texture pack! When I turn it off, the problem is immediately gone, but when it is active, the scripts slow down incredibly. Surprisingly, my fps drop was not even that significant, but It almost seems as if the rendering engine tries to keep up a minimum framerate at the cost of the papyrus engine and who knows what else - and that's not good, because it appears to affect all scripts! To check this, I turned the HR pack on on my install for playing, with several mods active, and now I get plenty of "none" errors from mods that never threw errors before: It seems strange that the HR pack would be causing it, but then again I don't understand anything about the scripts you guys have been editing. By the way, I was using the HR pack with v. 1.3.3c and this and other weapon racks were working just fine. Some other examples are the one at Shor's Watchtower and the one outside Alvor's house, which are now broken like they were in the vanilla game (when I was playing on the Xbox 360). Link to comment Share on other sites More sharing options...
taleden Posted October 31, 2013 Share Posted October 31, 2013 It makes perfect sense to me that the engine would prefer to keep framerates from dropping too low, and will starve the scripting engine if necessary to do that. As for why it's become a problem now, I remember seeing a lot of arbitrary Wait()s in some recent versions of the scripts, with comments like "in testing this has always happened within 0.2s" (or whatever interval). Those may need to be more forgiving, since I don't think we can expect any specific level of performance from the script engine. But we probably don't want to just raise them to 5s either, if that would overly delay things even when there's no other slowdown. I'll see if I can find where those waits are and rig up an alternative that won't break if the scripting engine slows down. Link to comment Share on other sites More sharing options...
taleden Posted October 31, 2013 Share Posted October 31, 2013 Even with Daydreamer's code active DayDreamer, are your performance-tweaked scripts available for download somewhere? Is it your "WeaponRack 4.3d" on this site or is there something newer? Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 So I guess this was not fixed before 2.0.0 was released? I just tried it again with the final release: grabbed a pre-placed iron sword off a rack (while having another one in inventory), tried to put it back on the rack, was told "This weapon cannot be placed on a rack" and then could never place an iron sword again. Sclero mentioned something about an "exception list" to the "exclusion list" but it doesn't seem to be working, or maybe it was just forgotten in packaging the final release. I asked Arthmoor in a conversation to include this, and he replied: "I'll handle the formlist stuff, but as I just posted in the thread I hope nobody has been left with the impression that the beta is holding for the rest of the work you guys are doing. It's just those meshes we're waiting on right now." Earlier today, I was testing racks with two iron greatswords in inventory, and it worked. Just checked it in TES5Edit and the list contains all iron and steel weapons, hunting bow and long bow. I was just able to reproduce this on the 2.0.0 release, but my memory was off a little: it wasn't the angle that was wrong this time, it was the offset. As in, when first placing a sword on a plaque, it was lined up straight and centered. Then I picked it up, dropped it, grabbed it by the handle and swung it around a bit, dropped it to lean on a wall and picked it up again. When I put it on a rack after that, it was off-center, so the tip of the blade was near the middle of the rack and the handle was hanging off the side. There has been a note about a very similar issue on a discussion page on the CK Wiki. Maybe worth reading. I'll try to find it and post a link. It appears from your description that the translation values on the weapons own NiNode, which are usually discarded when it is moved to a placement node have been retained for some reason. That would perfectly explain the offset. I will have a look into this (although it is not likely that it can be prevented from occurring). Otherwise though, the placement you describe can still be perfectly handled. On the new single-weapon plaque, the trigger is a fairly well-sized box in the center In case you missed the new meshes: I have attached them to a post earlier this day. The new triggers react very fast. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 DayDreamer, are your performance-tweaked scripts available for download somewhere? Is it your "WeaponRack 4.3d" on this site or is there something newer? Yes, I was referring to 4.3d. Otherwise, don't worry - I've never been using the HR pack, and without it, I never could reproduce the issue anyway. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 It seems strange that the HR pack would be causing it, but then again I don't understand anything about the scripts you guys have been editing. By the way, I was using the HR pack with v. 1.3.3c and this and other weapon racks were working just fine. Some other examples are the one at Shor's Watchtower and the one outside Alvor's house, which are now broken like they were in the vanilla game (when I was playing on the Xbox 360). What has been corrected in 1.3.3c were script logic errors. What's happening now with the HR pack active is that the scripts (all scripts!) get choked by the rendering engine. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 It makes perfect sense to me that the engine would prefer to keep framerates from dropping too low, and will starve the scripting engine if necessary to do that. As for why it's become a problem now, I remember seeing a lot of arbitrary Wait()s in some recent versions of the scripts, with comments like "in testing this has always happened within 0.2s" (or whatever interval). Those may need to be more forgiving, since I don't think we can expect any specific level of performance from the script engine. But we probably don't want to just raise them to 5s either, if that would overly delay things even when there's no other slowdown. I'll see if I can find where those waits are and rig up an alternative that won't break if the scripting engine slows down. OK. As for the waits that originate from my scripts, I have always been testing them for the lower limit, and there should be no problem to prolong the intervals. Link to comment Share on other sites More sharing options...
BlackPete Posted October 31, 2013 Share Posted October 31, 2013 What has been corrected in 1.3.3c were script logic errors. What's happening now with the HR pack active is that the scripts (all scripts!) get choked by the rendering engine. That doesn't sound good. Anyhow, I'll leave you guys to your work with those, hopefully there is a solution to the problem. Thanks for the clarification though. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 That doesn't sound good. Anyhow, I'll leave you guys to your work with those, hopefully there is a solution to the problem. Thanks for the clarification though. Well, as you may have learned from the experiences with my machine: I barely got an fps drop! But there was no way to get the scripts to work (without the HR pack, they are performing just fine). DayDreamer got his version on his machine running, though, so there will be a solution, but certainly not for everyone. Link to comment Share on other sites More sharing options...
taleden Posted October 31, 2013 Share Posted October 31, 2013 I asked Arthmoor in a conversation to include this, and he replied: "I'll handle the formlist stuff, but as I just posted in the thread I hope nobody has been left with the impression that the beta is holding for the rest of the work you guys are doing. It's just those meshes we're waiting on right now." Earlier today, I was testing racks with two iron greatswords in inventory, and it worked. This is not related to allowing scripted items to be placed, this is in fact a bug in the code that is meant to prevent scripted items from being placed. I'll test it again but so far, if I have a non-persistent Iron Sword in inventory (but not equipped), and I take a pre-placed Iron Sword off a rack (I'm using the one above the bed in Honeyside), and then equip it and try to place it again, it tells me I can't. It then adds the Iron Sword to the exclusion list so in the future it doesn't even unequip it before telling me I can't place it. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 This is not related to allowing scripted items to be placed, this is in fact a bug in the code that is meant to prevent scripted items from being placed. I'll test it again but so far, if I have a non-persistent Iron Sword in inventory (but not equipped), and I take a pre-placed Iron Sword off a rack (I'm using the one above the bed in Honeyside), and then equip it and try to place it again, it tells me I can't. It then adds the Iron Sword to the exclusion list so in the future it doesn't even unequip it before telling me I can't place it. I understand this, but it shouldn't. The code is very clear: If (USKPWeaponRackExceptionList.HasForm (PlayerItem) == False) USKPWeaponRackExclusionList.AddForm (PlayerItem) Debug.TraceUser ("WeaponRackLog", Self + ": Player item added to exclusion list.") Else Debug.TraceUser ("WeaponRackLog", Self + ": Player item is on exception list.") EndIf I'd really like to know why this is happening. On the logs, I can see that it sorts the right items out. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 I understand this, but it shouldn't. The code is very clear: If (USKPWeaponRackExceptionList.HasForm (PlayerItem) == False) USKPWeaponRackExclusionList.AddForm (PlayerItem) Debug.TraceUser ("WeaponRackLog", Self + ": Player item added to exclusion list.") Else Debug.TraceUser ("WeaponRackLog", Self + ": Player item is on exception list.") EndIf I'd really like to know why this is happening. On the logs, I can see that it sorts the right items out. EDIT: The iron sword is definitely in the exception list. Link to comment Share on other sites More sharing options...
Elgar Posted October 31, 2013 Share Posted October 31, 2013 GOT IT! While looking at your screenshot, I got an idea and now I know what's happening: It's the High Res texture pack! When I turn it off, the problem is immediately gone, but when it is active, the scripts slow down incredibly. Surprisingly, my fps drop was not even that significant, but It almost seems as if the rendering engine tries to keep up a minimum framerate at the cost of the papyrus engine and who knows what else - and that's not good, because it appears to affect all scripts! I wonder how many people have the same issue because they think their system goes along well with high-res textures, although it actually doesn't and it's only their impression that the game is running fluently while everything else goes fubar in the background. Even with Daydreamer's code active, which is faster than mine, there is no way for me to get the racks to work - well, not a great tragedy because I'm usually not using the HR pack on my slow machine for good reasons. And by the way, I'm cured of high-res textures for a good while now. Wow!... That's a big discovery. If this is true, no wonder why some people have strange and non-reproducible bugs because a lot of people use the hi-res DLC even if their rig is far below the minimum requirement. Which leads me to this question : what is your graphics card, Sclerocephalus? Does it have the minimum 1GB VRAM requirement ? EDIT : Sorry for appearing suddenly in this thread without introducing myself. I have been following this topic with great interest since the last few weeks and I admire your perseverance! I have myself a university degree in programming but I can't really help you because it was twenty-years ago and the languages were not really the same... (Ever heard of COBOL ? ) Anyway, I hope you guys will manage to tame this weapon rack beast. ^^ Link to comment Share on other sites More sharing options...
taleden Posted October 31, 2013 Share Posted October 31, 2013 EDIT: The iron sword is definitely in the exception list. You're right, it does not add the Iron Sword to the exclusion list, because it is in the exception list. I was confused on that point. However, it does not consult the exception list when deciding if the player's placed item is allowed to be placed. So if I have an Iron Sword, and I grab a pre-placed Iron Sword, then equip it and try to place it again, it will print the message and let the sword drop on the floor every time. This is due to your test container receiving the persistent copy, but then when it sends that copy back to the player, DropObject() drops the other copy instead. We discussed it a few pages back. Can anyone else reproduce this? Here's what I'm doing: 'coc riftenmistveilkeep' from the menu (usually not advised for testing I know, but in this case, quest initialization shouldn't matter for the rack scripts) 'setstage a7b33 10' to get honeyside 'player.additem f 10000' for some cash buy the bedroom upgrade make sure you have an iron sword in inventory, but don't equip it yet go in and take the iron sword off the rack over the bed equip an iron sword try to place it again watch it fall on the floor pick it up, equip it, try to place it again goto step 9 Link to comment Share on other sites More sharing options...
Vardis Posted October 31, 2013 Share Posted October 31, 2013 Hmm, that seems like an infinite loop there. You really should have a counter to break out of that. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 You're right, it does not add the Iron Sword to the exclusion list, because it is in the exception list. I was confused on that point. However, it does not consult the exception list when deciding if the player's placed item is allowed to be placed. So if I have an Iron Sword, and I grab a pre-placed Iron Sword, then equip it and try to place it again, it will print the message and let the sword drop on the floor every time. This is due to your test container receiving the persistent copy, but then when it sends that copy back to the player, DropObject() drops the other copy instead. We discussed it a few pages back. Can anyone else reproduce this? Here's what I'm doing: 'coc riftenmistveilkeep' from the menu (usually not advised for testing I know, but in this case, quest initialization shouldn't matter for the rack scripts) 'setstage a7b33 10' to get honeyside 'player.additem f 10000' for some cash buy the bedroom upgrade make sure you have an iron sword in inventory, but don't equip it yet go in and take the iron sword off the rack over the bed equip an iron sword try to place it again watch it fall on the floor pick it up, equip it, try to place it again goto step 9 OK, now it's clear. So let's implement the moving container then! By the way: I will be in the forum again for a short while in about 2-3 hours and then off for a day, because I have been working on the meshes almost non-stop for two days. If you see anything unusual with them, please let me know later. Otherwise, you'll have to wait (sorry). There will be a few tests to report which (1) should save many superfluous function calls, (2) concern a minor logics bug (mine, not yours, and also not crucial) and (3) an approach to make the scripts even faster (should have thought about that more intensively earlier instead of letting me chase by others; well, DayDreamer will have to decide whether it's worth considering). I'll post the scripts I'm using then - still without your item handling function, since I'm still trying to optimize the initialization procedure and also want to clean up the aftermath of the mesh replacement before I take the next step. At the moment though, there is not much about thinking (too tired ...) Link to comment Share on other sites More sharing options...
Sclerocephalus Posted October 31, 2013 Author Share Posted October 31, 2013 Wow!... That's a big discovery. If this is true, no wonder why some people have strange and non-reproducible bugs because a lot of people use the hi-res DLC even if their rig is far below the minimum requirement. Which leads me to this question : what is your graphics card, Sclerocephalus? Does it have the minimum 1GB VRAM requirement ? EDIT : Sorry for appearing suddenly in this thread without introducing myself. I have been following this topic with great interest since the last few weeks and I admire your perseverance! I have myself a university degree in programming but I can't really help you because it was twenty-years ago and the languages were not really the same... (Ever heard of COBOL ? ) Anyway, I hope you guys will manage to tame this weapon rack beast. ^^ I'm no programmer myself - and I have heard of COBOL (I also did scientific programming in FORTRAN, BASIC, Assembler, etc. - pretty much everything that was in use about thirty years ago). My graphics card has actually 2GB VRAM, but it is four years ago that my machine was high-end, so that I'm usually not running the HR pack. I only activated it for that test. Link to comment Share on other sites More sharing options...
Vardis Posted October 31, 2013 Share Posted October 31, 2013 I use the hi-res DLC and also get the weapons dropping from outside racks. I've got a GTX 660 running the game at 2560x1600, ultra settings except for shadows (high), and the game runs smoothly as far as I can tell. I guess I'll fire up a new game without that and see if the issue goes away, although I'd prefer the scripts be a bit more flexible if it's just a timing issue. Link to comment Share on other sites More sharing options...
DayDreamer Posted October 31, 2013 Share Posted October 31, 2013 There are too many posts to consolidate. I'll take them a few at a time. That's because of how WeaponRackActivateScript and the script I am referring to work. My script does only reset properties on the activator script; in the Honeyside case, it would specifically check for each rack whether the base object of PlayersDroppedWeapon is an x-marker and, if true, reset PlayersDroppedWeapon to "none" and PlacedItemInit to "false". Running this from anywhere when UHFP loads has no effect unless the offending link has been removed (but the chances for this to happen are bad within a running game). Otherwise, the activators will check their link when they run their initialization procedure on next load/cell attach, will find the x-markers and get stuck again. I may have mentioned previously that there are problems with your scripts. I'll not repeat them here. My scripts all have an Else clause. If the rack type is unrecognized. If the keywords are missing or unrecognized. Also, a version that I was running internally last week but never got around to releasing clears the starting item pointers on detach. That will be in my final. I just wanted to test it some more. [...]Forgot to add this: the names of the rack objects are somewhat confusing, but all activators have an "activator" (in capitals) in their name. Everything else are triggers. Yes, I was tired, they were all triggers. The point remains the same. The variables are not all setup correctly. I'm working on it. It turned out to be more work than I'd expected, because I'd expected that everything was mostly working properly.... Link to comment Share on other sites More sharing options...
Arthmoor Posted October 31, 2013 Share Posted October 31, 2013 EDIT: GOT IT! While looking at your screenshot, I got an idea and now I know what's happening: It's the High Res texture pack! Nope, it's not While I do get numerous [None] errors from the Wet & Cold mod, I'm fairly convinced just about everyone else does too and that it has nothing to do with this problem. I am running the hi-res texture pack and have had absolutely no trouble with weapons falling from the racks with 2.0. Not even the dummies. This is even with a pretty substantial load order: Active Mod Files: 00 Skyrim.esm 01 Update.esm 02 Unofficial Skyrim Patch.esp [Version 2.0.0] 03 Dawnguard.esm 04 Unofficial Dawnguard Patch.esp [Version 2.0.0] 05 HearthFires.esm 06 Unofficial Hearthfire Patch.esp [Version 2.0.0] 07 Dragonborn.esm 08 Unofficial Dragonborn Patch.esp [Version 2.0.0] 09 Falskaar.esm 0A SkyUI.esp 0B HighResTexturePack01.esp 0C HighResTexturePack02.esp 0D HighResTexturePack03.esp 0E Unofficial High Resolution Patch.esp [Version 1.1.3a] 0F Skyrim Content Restoration Project.esp [Version 1.0] 10 StaticMeshImprovementMod-FurnitureChestSnowFix.esp 11 StaticMeshImprovementMod-DragonbornTernFix.esp 12 Chesko_LoreBasedLoadingScreens.esp 13 chesko_levelup.esp 14 colored constellations.esp 15 thatsice.esp 16 better embers.esp 17 SkyFalls Plus SkyMills - All DLC and Falskaar.esp 18 EnhancedLightsandFX.esp 19 ELFX - Exteriors.esp 1A ELFX - Dawnguard.esp 1B ELFX - Dragonborn.esp 1C Unique BOOZE Bottles.esp 1D Better Dynamic Snow.esp 1E Cliffracers.esp 1F Footprints.esp 20 Footprints - Ash.esp 21 SoS - The Dungeons.esp [Version 1.23] 22 SoS - The Wilds.esp [Version 1.13] 23 Book Covers Skyrim.esp 24 Book Covers Dawnguard.esp 25 Book Covers Hearthfire.esp 26 Book Covers Dragonborn.esp 27 WetandCold.esp 28 WetandCold - Ashes.esp 29 Tamriel Compendium.esp [Version 1.1] 2A Legionettes.esp 2B Dragon Claw Stands.esp 2C Dwemer Spectres.esp 2D AronsMechaDragons.esp 2E Prometheus_BeastSkeletons.esp 2F Appropriately Attired Jarls Redux.esp 30 FA Guard Helmet.esp 31 SkaalKidAetaCoat.esp 32 Lively Followers.esp 33 Bring Out Your Dead.esp [Version 1.2.1] 34 Run For Your Lives.esp [Version 1.2.3] 35 When Vampires Attack.esp [Version 1.1] 36 Breaking and Entering.esp 37 Flexible Smithing (Stripped).esp 38 Ars Metallica.esp [Version 1.2.1] 39 Ars Metallica - Dawnguard.esp [Version 1.2.1] 3A Ars Metallica - Hearthfire.esp [Version 1.2.1] 3B Ars Metallica - Dragonborn.esp [Version 1.2.1] 3C Freedom of Speech -- Dawnguard.esp 3D Gildergreen Regrown.esp [Version 1.2.5] 3E The Paarthurnax Dilemma.esp [Version 1.2.5] 3F houseofhorrorsalternateending.esp 40 Wyrmstooth.esp [Version 1.9] 41 IslandFastTravel.esp 42 underwater_treasure.esp 43 chesko_step418_sn.esp 44 Oblivion Gates v3 - Skyrim + Dawnguard DLC.esp 45 HoldBorderBanners.esp 46 Point The Way.esp [Version 1.0.2] 47 Practice Dummies.esp 48 tos_amber_guard.esp 49 tos_laintardale_hf.esp 4A tos_oakwood_hf.esp 4B tos_granitehall.esp 4C HoldStables.esp 4D SkyrimSewers.esp [Version 4.11] 4E Oblivion Gates in Cities.esp [Version 1.0] 4F ImpeREAL Empire - Unique Cities - Falkreath.esp 50 Helgen Reborn.esp [Version 105] 51 HRFixes.esp 52 EMCompViljaSkyrim.esp 53 EMViljaInSolstheimAddOn.esp 54 Alternate Start - Live Another Life.esp [Version 2.3.3b] 55 RealisticWaterTwo.esp 56 RealisticWaterTwo - Legendary.esp 57 RealisticWaterTwo - Falskaar.esp 58 RealisticWaterTwo - Wyrmstooth.esp 59 RealisticWaterTwo - Waves - Falskaar.esp 5A RealisticWaterTwo - Waves - Wyrmstooth.esp 5B Serana Joins The Party.esp 5C Stuff Needs Fixing.esp 5D FalskaarWeaponRacks.esp 5E Bashed Patch.esp So while frame rates likely do impact things, because hey, Gamebryo, why not tie everything to the clock, the hi-res pack can't really be the sole cause to all this considering the additional load on the system I've got along with it. For example, Footprints is a pretty script heavy mod but displays no errors in the Papyrus log at all despite that. EDIT: Re: The Honeyside thing. Nexus user reports: YAY i can use Honeyside's weapon plaques now!As always, kudos to the team. So are we absolutely sure that we need to worry about running a fixer script at all? This user's getting the same result I got - break the links and the racks "just work" without having to do anything. Link to comment Share on other sites More sharing options...
DayDreamer Posted October 31, 2013 Share Posted October 31, 2013 You guys are probably well aware of this and have probably worked it out already, but some non-player owned weapon racks have started not holding weapons again since v. 2.0.0. One example of this is at the Whitewatch Tower (screenshot), where the weapons were staying on the rack (as they should) with v. 1.3.3c. Yes, I was aware of this! I sped up the scripts immensely. However, Arthmoor decided not to include my faster scripts. I did post them for testing here and on the official forum for USKP. Yes, have heard this from various people. The initialization routine of the racks is too slow (it can be improved), but I would really like to understand what's causing it with some people while others are not affected, because I still cannot reproduce it in my game. Daydreamer has been working on this particular issue, as he's one of the persons who are affected, and by now, has the performance of the scripts greatly improved (he also made a few other remarkable additions, by the way), while I am still a bit clueless as to where that comes from. Whereas I told him repeatedly that it was script congestion. If I ride into Riverwood on a carriage, the weapons often (but not always) drop. Sometimes half of them drop. Even walking into Riverwood. Whereas fast travel to Riverwood is fine. My tests at the time (indeed for all my 2.0.0 beta tests) were using Wet and Cold and Touring Carriages, because folks told me that W&C was very script intensive. And it is!!! It seems strange that the HR pack would be causing it, but then again I don't understand anything about the scripts you guys have been editing. By the way, I was using the HR pack with v. 1.3.3c and this and other weapon racks were working just fine. Some other examples are the one at Shor's Watchtower and the one outside Alvor's house, which are now broken like they were in the vanilla game (when I was playing on the Xbox 360). I run with the HR pack and SMIM. It is not HR related AFAICT. As I have written, it's the RegisterForSingleUpdate(0.0) bottleneck, and the fact that Sclerocephalus doesn't yet understand how to do multi-thread interlocks. I've had traces with 2 threads running the setup at the same time -- from the OnCellAttach and the OnLoad. It happened about half the time. It makes perfect sense to me that the engine would prefer to keep framerates from dropping too low, and will starve the scripting engine if necessary to do that. As for why it's become a problem now, I remember seeing a lot of arbitrary Wait()s in some recent versions of the scripts, with comments like "in testing this has always happened within 0.2s" (or whatever interval). Those may need to be more forgiving, since I don't think we can expect any specific level of performance from the script engine. But we probably don't want to just raise them to 5s either, if that would overly delay things even when there's no other slowdown. I'll see if I can find where those waits are and rig up an alternative that won't break if the scripting engine slows down. I already told Sclero that the 3D loop needed to be at least 10 iterations. He grudgingly increased from 3 to 5 in his final version. Vanilla is 10. Mine is 10. It could even be 20. In almost all cases, it iterates exactly once! But when you need it, you need it!!! Also, he has a bug in his code that executes the 3D test twice. And fencepost errors that execute the 3D tests an extra pair of times for each of those tests. And a lot more bugs that I'd fixed last week.... DayDreamer, are your performance-tweaked scripts available for download somewhere? Is it your "WeaponRack 4.3d" on this site or is there something newer? I'm working on it. I was trying to integrate your new code. I'll stop and just leave it as is for a later revision. Link to comment Share on other sites More sharing options...
DayDreamer Posted October 31, 2013 Share Posted October 31, 2013 EDIT : Sorry for appearing suddenly in this thread without introducing myself. I have been following this topic with great interest since the last few weeks and I admire your perseverance! I have myself a university degree in programming but I can't really help you because it was twenty-years ago and the languages were not really the same... (Ever heard of COBOL ? ) Anyway, I hope you guys will manage to tame this weapon rack beast. ^^ Hey, I remember COBOL. I learned it over a weekend to help a sweetheart who had to take it for her business degree. She ended up being a COBOL programmer for Whirlpool. I didn't use it again for 4 years, and then wrote a debugger for analyzing stack dumps for our networking front end product -- the only COBOL program I've ever written. Not easy to to bit twiddling. We could use more analysts of any flavor around here. So welcome! I'm no programmer myself - and I have heard of COBOL (I also did scientific programming in FORTRAN, BASIC, Assembler, etc. - pretty much everything that was in use about thirty years ago). My graphics card has actually 2GB VRAM, but it is four years ago that my machine was high-end, so that I'm usually not running the HR pack. I only activated it for that test. I'm up to about 30 languages over the years. About half of them assembler. But don't really remember most of them, you just flow into the next one with the skills you've picked up over the years. I'm only running a GTX 570 with 1.2GB, and it handles HiRes Ultra just fine -- the only visual hiccups I see are usually papyrus vomiting. I use the hi-res DLC and also get the weapons dropping from outside racks. I've got a GTX 660 running the game at 2560x1600, ultra settings except for shadows (high), and the game runs smoothly as far as I can tell. I guess I'll fire up a new game without that and see if the issue goes away, although I'd prefer the scripts be a bit more flexible if it's just a timing issue. Just wait a day. I'll throw another test release together. Nope, it's not While I do get numerous [None] errors from the Wet & Cold mod, I'm fairly convinced just about everyone else does too and that it has nothing to do with this problem. So are we absolutely sure that we need to worry about running a fixer script at all? This user's getting the same result I got - break the links and the racks "just work" without having to do anything. I've tested without the fixer script now, and my code just rejects the XMarkers in the first place. You could speed it up some more by putting XMarkers and XMarkerHeadings in the exclusion list.... Link to comment Share on other sites More sharing options...
Vardis Posted October 31, 2013 Share Posted October 31, 2013 I turned off hi-res, and for the first time, wasn't getting weapons dropping from exterior racks. So while it's obviously not directly because of the hi-res stuff, it certainly looks related to expectations on how fast things are being loaded. as some of you had guessed. Link to comment Share on other sites More sharing options...
DayDreamer Posted October 31, 2013 Share Posted October 31, 2013 I turned off hi-res, and for the first time, wasn't getting weapons dropping from exterior racks. So while it's obviously not directly because of the hi-res stuff, it certainly looks related to expectations on how fast things are being loaded. as some of you had guessed.Try this with HiRes. Works for me. But this was barely tested walking into Warmaidens and walking Whiterun to Riverwood -- a lot less testing than I'd normally release. This is a beta, but it should be useful for regular saves. (I hope.) Note, this doesn't have all my speed improvements, and the logging will slow things down some. It was quickly thrown together from Talenden's weapons test v3, Sclerocephalus' meshes v3.5, with my hasty merge. But it should be good for immediate testing. Please try Talenden's weapons test by placing previously un-rackable weapons like Dwarven Battleaxe, or Ebony Blade, or Silver swords, or Volendrung, or Wuuthrad! (There's a list in the USKPWRPlayerAliasScript.) Please drop any whiffy logs here on this list. WeaponRack-4-4d.7z Link to comment Share on other sites More sharing options...
BlackPete Posted November 1, 2013 Share Posted November 1, 2013 Nope, it's not I am running the hi-res texture pack and have had absolutely no trouble with weapons falling from the racks with 2.0. Not even the dummies. This is even with a pretty substantial load order: Active Mod Files: So while frame rates likely do impact things, because hey, Gamebryo, why not tie everything to the clock, the hi-res pack can't really be the sole cause to all this considering the additional load on the system I've got along with it. For example, Footprints is a pretty script heavy mod but displays no errors in the Papyrus log at all despite that. So it isn't the HR pack after all? That's good I suppose, but if it has to do with how fast your system runs the game (from what I think I'm understanding), that's not good either. I have a medium to high end computer that runs the game at a high fps rate in most areas, so I have no idea why it would be a result of my system not being able to handle all of the scripts quickly enough. Re: The Honeyside thing. Nexus user reports: So are we absolutely sure that we need to worry about running a fixer script at all? This user's getting the same result I got - break the links and the racks "just work" without having to do anything. Like I mentioned several days ago, for me, the Honeyside weapon racks/displays in the basement weren't working with v. 1.3.3c and they still don't work with v. 2.0.0 (which apparently is known issue). Sclerocephalus thought that the fix in 2.0.0 was not retroactive, but I have to say I'm thoroughly confused at this point, mostly because I don't understand the scripting process being done with these racks. Despite several people trying to explain it to me, I don't think I ever will understand it, because I don't really have a good mind for programming. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now