Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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:

  1. '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)
  2. 'setstage a7b33 10' to get honeyside
  3. 'player.additem f 10000' for some cash
  4. buy the bedroom upgrade
  5. make sure you have an iron sword in inventory, but don't equip it yet
  6. go in and take the iron sword off the rack over the bed
  7. equip an iron sword
  8. try to place it again
  9. watch it fall on the floor
  10. pick it up, equip it, try to place it again
  11. goto step 9
Link to comment
Share on other sites

 

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:

  1. '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)
  2. 'setstage a7b33 10' to get honeyside
  3. 'player.additem f 10000' for some cash
  4. buy the bedroom upgrade
  5. make sure you have an iron sword in inventory, but don't equip it yet
  6. go in and take the iron sword off the rack over the bed
  7. equip an iron sword
  8. try to place it again
  9. watch it fall on the floor
  10. pick it up, equip it, try to place it again
  11. 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

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

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

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

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 :P

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

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

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 :P

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

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

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

Nope, it's not :P

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...