This thread is dedicated to the discovery, discussion, and education about system-stress and scripting errors, and their impact on Skyrim's performance, stability, and mod-ability. I will update this first post to reflect any new discoveries made; kinda like the 'Bug Report' threads... but not for bugs. Much of the advice below is already contained in the Wiki or scattered throughout the forums; but this thread should help correlate and disseminate it effectively.

This topic is poignant, not only for Modders, but USERS of mods. Users with low/medium-end computer systems may experience strange behavior caused by a mod, which Users with high-end systems will never see. Rather than blame the mod's author for it failing to work as-advertised, though sometimes such chastisemant is deserved, it may behoove some people to first check their FPS rate in-game. As you'll read below, SEVERAL things can affect FPS... some caused by system stress, others caused by modding mistakes or simple ignorance; due hopefully to the new-ness of most of the Papyrus scripting language.

Even if your script compiles correctly, and there seems to be no problems in game, your script may STILL contain devastating errors which destroy scripting performance for OTHER mods - and potentially other aspects of the Skyrim experience. To test for errors in scripting, enable Papyrus logging in the Skyrim.INI file, located in your Documents/MyGames/Skyrim/ folder. The recorded logs are located in the same folder as that INI, under a sub-folder called Logs/. Add or change the following lines to enable logging & debug tracing:

[Papyrus]
bEnableLogging=1
bEnableTrace=1
bLoadDebugInformation=1

Helpful Apps:
http://www.fraps.com/ - for monitoring FPS rate in-game (commercial, free demo available)
http://technet.microsoft.com/en-us/sysinternals/bb896653 - for monitoring GPU memory and usage (freeware)
http://notepad-plus-plus.org/ - for writing scripts (freeware)
http://www.creationkit.com/Notepad%2B%2B_Setup - for automatic formatting applied to Papyrus, such as color-coded commands and collapsible trees (link to the CK Wiki page)



PERPETUAL OR CYCLIC SCRIPTING ERRORS

- If using multiple mods which contain such errors in their scripting, general performance will suffer
- Some mods' scripting may be broken by excessive errors in scripts that aren't even active.
- Resolving these errors have been shown to give at least a 5fps boost on low-medium end systems.
- These errors have simple, easy fixes so there is no excuse for authors not to implement them.
- Seemingly benign, these errors are potentially LETHAL to the Skyrim experience, sometimes even causing CTD or corrupting saveGame data.
- Some of these types of errors STILL exist in Vanilla Skyrim; though may not trigger until a certain area, quest, etc is active.

*****
'None' cannot be assigned to a variable or property, then called by certain commands.
This causes an error every time the script calling the command fires. If the script enters a loop containing the faulty line(s), the errors stack up extremely rapidly and may eventually cause CTD.

Examples of this type of error:
- warning: Assigning None to a non-object variable named
- error: Cannot call GetStage() on a None object, aborting function call
- error: Cannot add a None spell to the actor
- error: Unable to call RegisterForSingleUpdate - no native object bound to the script object, or object is of incorrect type
- error: No Spell or Shout passed to HasSpell

TO FIX: When using a variable or property in a command, test to see if it was never assigned a reference (set to 'None'). For example, this can be done using an if-endif loop, such as "if blahblahRef != None" (then run your command).

- Alternatively, you may force the property to be filled with something you KNOW will always be there (such as Player).


*****
Properties in compiled scripts can't be deleted, unless the now-empty properties are manually removed from anything the script is attached to.
This causes perpetual errors, which occur at regular intervals throughout Player's entire gaming session.

Examples of this type of error:
- warning: Property MannequinArmorWeaponsMESSAGE on script MannequinActivatorSCRIPT attached to (00102906) cannot be initialized because the script no longer contains that property
- warning: Property Pose01 on script MannequinActivatorSCRIPT attached to (00102906) cannot be initialized because the script no longer contains that property

TO FIX:
- IF YOUR MOD USES AN ESP/ESM, you must Remove the script from the baseObject or ref (whatever it's attached to). You then Add it back and re-fill the properties. If the script is NOT removed and added back, the deleted property will always remain.

- IF CHANGING A VANILLA SCRIPT ONLY, place the deleted properties back in the script, even if you don't use them. This is only referring to the property declaration, not using that property elsewhere in the script (which I would recommend stay deleted). Otherwise, you'd have to create an ESP which removes then adds back the new script (as above).


*****
Changing properties in fragments may not be saved or compiled, even though CK shows they are (until restarted).
- This is seemingly caused by a bug which causes different quest stages (or steps within those stages) to use the SAME 'sub'-fragment within the script.
- If you open the fragment's source, you will see one or more sub-fragments missing; while in the CK one or more steps/stages will be pointing to the same sub-fragment.
- The CK will compile and save the plugin; but when the 'damaged' property is referenced in-game, the results will reflect whatever the other sub-fragment's code is.
- If you try to change the damaged sub-fragment to what it SHOULD be, the compiler shows errors and reverts back (or won't let you leave the editor without cancelling the changes).

Examples of this type of error:
- (during compiling) failed validation

TO FIX: In the Advanced tab (inside the quest fragment editor), press the "Regenerate" button; reinstate the code you want (which was changed), then recompile and save.


*****
Removing a script from an individual reference (in the renderWindow) will not work if the script was attached to its baseObject.
- Instead of disappearing when you click the 'Remove' button, a red minus sign appears and 'Remove' becomes 'Undelete'.
- The script remains attached and fully functional; and is never deleted... even after exiting then restarting the CK.
- If you remove the script from the baseObject, ALL references in-game which use it will have their scripts removed.

TO FIX: You could create a 'clone' of the baseObject in question, which has the script removed. This way, only the references you place won't have the script, while all the originals will still be as they were.

- If the baseObject is something you already made custom (not changing something Vanilla, but adding another or cloning one); then you may safely remove the script from the baseObject... given that you want ALL the placed references to it to be scriptless.




SYSTEM STRESS

- Less than 30fps will always cause visible lag/flickering, and will cause problems with script-timing.
- Between 30-45fps: occasional problems will occur - usually as Player enters a new area... which heavily taxes system resources in whichever way.
- Generally speaking, 45fps or higher will cause less problems (if any at all)
- Above 60fps should operate trouble-free... given all the enabled mods and scripts were created without bugs.

*****
System Memory (RAM)
If this is max'd out at ANY TIME while playing Skyrim, you will experience problems.

TO HELP:
- Exit any programs running outside of Skyrim, especially memory intensive programs like Photoshop, 3DSMax, the CK itself (on low-end systems)


*****
Detail Level Settings (in the Skyrim Launcher, Options)
Trying to push your system's graphics past what it can handle affects MORE than just graphics; it also affects script-timing, and possibly other aspects of Skyrim. These settings generally cause a bottleneck of FPS by over-taxing the GPU, not the video memory; though hi-res replacers may provoke the latter on lesser systems.

TO HELP:
- Simply press one of the Default Buttons to the next lowest level that what you've been using (Low, Medium, High, Ultra), until your FPS rate is acceptable.
- Reduce or remove individual settings until Skyrim runs at a steady 45fps. The following are especially stressful on lower-end systems:
Shadow Detail - even when FPS is running steady at 45, an Ultra setting can induce problems.
AntiAliasing - 8x sampling may cause problems, even at 40fps.
(any combination which compounds one of these; eg- 8xAA with FXAA or ultra Shadow Detail with a high Blur Radius Detail.)
- Settings which are generally safe to leave high: Anisotropic Filtering, Light Fade (unless combined with Shadow Detail or other stress-catalyst)
- Advanced Users may opt to adjust individual settings in the INI files.
- Reducing the sliders which control "View Distance" GREATLY reduce system-stress, especially on the GPU and its memory. Grass and Items will generally give the biggest boost, while sacrificing as little noticable quality as possible.
- Remove some hi-res texture replacers.


*****


Feel free to post your personal findings and opinions; as well as any anecdotes, solutions, or questions regarding this topic. Pertinent information will be added to this first post (should this thread garner enough interest and usefulness).

I wrote the above, in the hopes that mod authors who create their own scripts will pay heed. Why should I care about other people's mods? One good reason, besides being the communal thing to do, is because their errors are effecting my Gokstad Sailing Ship mod. They also may be exacerbating certain Vanilla bugs, such as the NavMesh Bug or the Wandering Actor Bug (mannequins)... who knows what else?

My mod pushes Papyrus' timing and firing rate to its limits, and requires a fairly high minimum of 'script-time' all to itself. Some users complained that it wasn't working for them, though on a system comparable to mine. After various methods of troubleshooting, we were able to discern the above information and apply it. My ship now sails smoothly for those it didn't before... though sometimes at the expense of in-game visual quality. [Thanks for helping, sknight17!]

So if you're a modder... and you have the occasional User who complains about some seemingly random behavior, and swears up & down that it's YOUR mod causing it; perhaps the above may apply in their circumstances. It certainly is refreshing to find out that one's mod really ISN'T to blame for whatever drama abounds.

On request, I'll post the actual notes I took while experimenting with this (using my Gokstad mod), in case anyone would like to see the specifics as to how I drew the above conclusions; and which individual settings cause exactly which repercussions. Don't worry, it'll be in a "spoiler" thingy so-as not to have a wall of text for those who become dazed at such a sight.

Anyways... I hope this helps you solve mysterious problems you may be having, or just help boost your gaming experience to a slightly higher level (by running as smooth as possible). It already HAS helped some, myself included... so I'm already fulfilled.

Thanks to Amethyst Deceiver for pointing out an alternative to 'adding back a deleted line' (to prevent perpetual property errors). My Vanilla Mannequin Script Fix doesn't use an ESP, so that solution hadn't occurred to me when first posting the above. I already knew this to be the case, from my other mods; but didn't think to apply it in the above documentation.

Basically, the CK embeds data in an ESP which points to any filled properties (and variables?) in a script you've attached to something. If you delete one of those properties from the script, then compile it, the ESP still has that embedded data and will force the game-engine to perpetually search for the deleted properties (for reasons beyond my understanding). You MUST remove the filled property from ALL objects/refs you attached the script to... or you will get the above perpetual errors.

You'll have to individually experiment with this; but I believe since it shouldn't slow down performance, adding the deleted line back into the script may be an easier solution than removing filled properties manually.... in cases such as if one has 5k refs with the script attached. If several refs have it attached, but the script is assigned to their base object (not each indiv ref), it would still be wiser to remove the filled property from the object in my opinion.

[EDIT: To prove to yourself I'm not exaggerating about the ramifications of this... delete the three properties which point to poses in the Vanilla mannequinActivatorSCRIPT and compile it. Since the poses are disabled in Vanilla, these properties are worthless and serve NO function... so theoretically may be deleted.

Without any mods or other scripts installed/enabled: run the game and, from the Title Screen, "coc" to some exterior which is nowhere near any cities or houses. Now just stand there for one minute, then exit the game. Check your Papyrus log and be appalled... then imagine a dozen or more mods which this occurs in.]

Ha, very interesting. I have a serious question about that, because the core of my mod is a Quest Script with variables made to decrease every second (real time) and to reach 0 after one in-game hour.

This script was really huge and full of heavy checks like crawls through gigantic FormLists (+700), and with RFSU(1) the variables were reaching 0 after more than 2 game hours. So i had to move all but the variables in another Quest script, and now with RegisterForSingleUpdate(0.25) these variables are decreasing correctly, getting to 0 EXACTLY after one hour passed in the game.

But i was wondering what could happen on another system/PC. So, for a low-end computer already plumbed with HD Texs, the decrease would be longer ? And what would happen on a beast of PC ?

While I'm not familiar with FormLists in the slightest, I've heard that doing checks to large ones takes noticably extra time to perform... especially if done repetitively and fast. Your first script sounded like it was set to run on a 'self-guided tour', as in it would keep firing no matter what. Once the firings of the script start overlapping each other (because the previous firing hasn't finished checking those lists or whatever yet), they will keep stacking until either the game crashes or your system catches up. In your case, it seemed to take an extra hour to do so.

This stacking effect is what destroys my sailing script - when too many errors from 3rd party mods are tying up the Papyrus threads too long. My script's firing gets 'bumped off' slightly, then this quickly compounds (as my script fires every 0.01sec)... causing the ship to "crash" (though not CTD proper). By removing the presence of errors, we've shown that overall FPS can be increased, and my ship can sail smoothly. This may be the case with YOUR mod/script... check your Papyrus log to see if other mods you run may be interfering with the timing. Also, note that overall FPS affects script timing too... so if you prefer to run a highly detailed game, that may affect it as well.

As you found out, shortening the lists would work (but detract from functionality in your mod). Another thing to test would be to have some kind of mechanism checking for a previous firing still not finshed yet... such as using States. You'd have your regSingle's in both States, but the 'idle' State would firing the code to check the lists, while the 'working' State would just keep shootin' blanks.. heheheh.

A third possibility would be to try increasing your regSingle's timing, such as from 0.25 to 0.5 (since your in-game time seemed to be double what it should have been). I don't know if a half second is fast enough to do what you want it to do, though... but if you don't need such precision, I believe that'd be the easiest way to circumvent the bottleneck... by widening the bottle. [I think you mentioned that your script should fire once per second, but it's set to fire 4 times a second... I dunno if that was just a typing mistake or whatever; but if you only need 1/sec, then change 0.25 to 1.0... that should DEFINITELY help]


About systems' power: anecdotally, high-end systems (ones which can achieve at least a SOLID 60fps without blinking) never experience problems. I assume because those systems are fast enough to handle the extra trash... further helping to prove my theory that Papyrus itself REALLY IS FAST, but is slowed by OTHER things (or certain functions within it.. like huge formLists). My system is lower-medium end, so I can't test this. (i5 2.27, 4gig RAM, 1gig dedi vidRAM)

About hi-res texture packs: I don't use any, so I can't say for SURE; but texture size doesn't seem to play that big a role in FPS... believe it or not.

Using Processixplorer to monitor GPU usage and memory, my Skyrim never uses more than HALF of my 1gig of dedi vidRAM... even when on 'high'. This is disconcerting, as the vidMem seems to TOP OUT at 500mb.... which means Skyrim is 'paging' textures in and out when it should be simply adding them to what's already there; filling out the other half of my memory.

I tested this by entering several cities, walking through them, then going to other cities and doing the same thing. The vidMEM isn't flushed during fast-trav... but I tried by simply walking forever too. Never went above 500mb. Is this why they removed the ability to see vidMem usage from the console in-game? (to hide the fact that vidMem is NOT efficiently used, at least in SOME cases.. like mine)

I'd appreciate it if someone who DOES use extensive tex-packs could monitor their vidMem while in-game... and performing several cell-changes to keep loading more tex into memory. (ProcExplorer is freeware, linked above) If not, I guess I can spend however long it takes to download like 3gig of stuff I don't use.... but it isn't gunna be any time soon heheheh.

[EDIT: it was the OVERALL DETAIL LEVEL that affected FPS and performance.. not my vidRAM. Shadows and AA smacked it the hardest, while switching from low to high texture detail made absolutely no difference. Also the LOD distances are a HUGE factor... even at low detail, 20million objects will still take a bit to load...]

I thought one of the reasons for using RegisterForSingleUpdate was precisely to prevent stuff like this from happening.

If your onUpdate has commands which take longer to finish than the regSingle allows for, the script fires again... stacking the next iteration onto the end of the one it's still performing. In MY case, translateTo... if the ref hasn't gotten to where it's going in the command, the onUpdate is fired again but stacked. In the other case, the lengthy formList searching may be what's taking so long.

I actually exploit this to get my script running smoothly (while moving 12 refs simultaneously in real-time)... but as I said - it's sensitive to disruption because of the intensity and tiny increment of time. What I do.. and this is basically my secret to smooth sailing.. in the onUpdate I have a counter which ticks once when fired. I have an onTranslationComplete assigned to the ref which the script is attached to, which ticks that counter back down by one. THEN.. inside the onUpdate, the code which calls my movement functions are inside an if-endif loop which limits the number of stacked firings. Of course there's more to it, but that's the premise/theory behind my working script. This technique probably won't be applicable to FormLists.. but as I said, I'm not familiar with their use (yet).

It FORCES over-firing, yet limits how many it can get ahead of itself to prevent excessive stacking (such as the extra hour wait explained above). This was the ONLY way I could get multiple objects to move in synchronicity... and I tried many many ways. So since you guys are interested in helping to save Skyrim from krappy scripting (by reading this thread), I've just rewarded you with the secret to smooth sail/flight; which people have been working on for months (took me about 20hrs of actual work).

Actually, I already had smooth sailing and flight weeks ago, I just didn't make any mods from it because of the collision detection problems and the difficulty of using it without custom hotkeys.

From what you're saying, you use the RegisterForSingleUpdate for timing purposes as well, which explains what you meant. I only use it to keep the script running, so I only call it at the end of an OnUpdate event instead of the beginning.

EDIT: Reading your post again, I see what you mean by smooth sailing. That's amazing how you figured out a way to move multiple pieces simultaneously. I guess the Translate functions must involve a lot of behind the scenes math which causes the script to slow down.

EDIT2: Since you're already attaching a script to every object you're moving with the ship, why not have the OnUpdate events inside that script instead? Then you wouldn't need to deal with stacking OnUpdate events in a single script.

I use the regSingle to overload the system, since 0.01 is pretty fast. I call it at the end of the onUpdate; which is preempted by an if-endif (inside the up event) which stops the script from running forever. Since the overload is controlled, lower-end systems can still use the mod, since the 0.01 doesn't fire my ENTIRE code each time. The problems arise when either stacking is delayed (by errors in other scripts), or an as-yet unnamed mechanism regarding FPS.... hence this thread; for education AND further discussion/discovery.

But the translateTo isn't any more intense than other functions I would assume; it's the fact that I only want my boat to go at a certain speed. That's why I said there's actually more to it than the basic theory. Several variables need to be tweaked to optimize it; if any are out of line, the timing falls apart. Examples: one for distance traveled per translateTo, one for how fast the translateTo actually MOVES the boat, another for the rotation speed, then there's a multiplier for the distance... to vary the speed by controls, etc etc.

In my case, it's the speed the object moves at in the translateTo... obviously 300gu would take a normal-speed object longer than 1/100th of a sec to move like 14ft heheheh. Sometimes the rotation speed as well, since it's still considered part of the translation... so if it's at the right spot, but rotates too slow to catch up to the new heading - it collapses. I wound up using a different technique to limit how fast the ship can turn, so that the rotate speed is always constant and in-line with the movement speed.

One VERY important aspect of this; I only attach my sailing script to ONE object (an activator). The properties in the script are assigned to the other objects, which currently are persistent in Tamriel worldSpace. I eventually want to convert to an alias-driven system, but I have zero familiarity with that right now. This would allow me to have a 'disposable ship'... such as one that spawns as an enemy that attacks you somehow, or purchasing a 2nd one (and damage should you wreck). It would also help me get around my problem with moving refs which are inside a cell that isn't attached (no parent cell).

I considered having a master script controlling 'subscripts' through globals and what-not, but thankfully I got it working without all that potentially dramatic testing. It's possible it may help performance, but that would require re-writing most of the script... nearly starting from scratch. So I hope you don't blame me for not wanting to jump into testing that, but I AM curious about the result.I have several things I still want to try (some are VERY avant garde, and actually non-script related)

OK, I just did a little test by attaching this script to a ship, lever, barrel, and bench:


This is the resulting video (sorry it's so choppy, but my computer svcks): http://youtu.be/oNI3ircU5l4

I don't know why, but the bench disappears whenever I quit to main menu and then COC back to the cell. Anyway, if you take a look at the lever, you can see that there's a noticeable difference.

The targets are non-scripted duplicates of the ship and peripherals that are placed directly ahead of the scripted versions for testing purposes.

i wanted to reiterate here what i posted in the other thread:

Papyrus DOES NOT clean up after itself. YOU, the mod author, have to manually clean all of your properties by hand. each and every single freaking one of them.

if you are no longer using a property in your script, or if you have deleted an ObjectReference (especially) from your game world, you need to manually clean that up in the script, or else it will continuously fire an error in the papyrus log... forever. deleting the property from the code itself does not cut it. you have to go into properties and clear the value, then delete it. if at any point you forgot to do this, you need to re-add the same property (note the value is still "cached" once you re-add it), and then clear it, then delete it.

all properties are stored in a subrecord (i'm assuming the VMAD subrecord) and they do not delete themselves, they just sit there forever and continuously fire error messages. you would never know until you check it out in the logs. i figured this out the hard way.

this is an incredibly annoying bug

I see what you mean about the lever seeming to travel slower. Is it only a single translation? I'm not yet familiar with calling functions or commands outside a single script, so I'm not sure what should play out there.

It looks like it's a single translation, which is ALWAYS smooth (unless you go below 30fps). If this is the case, the most likely reason one thing moves slower than the other is because they probably don't share the same point of origin. If they travel to the same ref, but come from different points, they WILL travel at different speeds - but should wind up at the same time.

The 'speed' in the translateTo is how fast to go over the given distance... so a speed of 250 over 100gu would be a LOT slower than the same speed of something doing 250 over 1000gu. In other words, the number assigned to 'speed' is relative and directly proportional to the distance being translated across. That's why tweaking it certain ways collapses my script... I actually had to upload a hotfix because I made a last-minute bump to the top-speed (from 300 to 350gu). This caused OCCASIONAL crashing, even on higher-end systems, which I didn't detect when I briefly tested before ul'ing. So to get the boat to move faster, I have to set the distance traveled further, which ALSO has ramifications.

I can't effectively record video of my ship mod, because my system can't handle running FRAPS (in capture mode) yet still maintain 45+ fps. I do have a brief video of what happens when I TRY though... which is exactly what happens when fps is otherwise affected in-game (or the excessive script errors). All the objects besides Player seem to stop short then resumes movement to instantly catch up, at about 2-3 times per second. The faster the boat moves, the further Player keeps moving forward without it.. during those hesistations; making it even more noticable. Eventually the script stops because my ground/collision-detector is tripped by the erratic movements.

But the only time I've seen one thing slower than another is when distance or speed is different between them; which I also experimented with, as it seemed Player was the one causing the 'studder-ship' effect. I had limited success with it, but it was unstable and the speed had to be constant.. it couldn't go fast or slow or reverse as Players want a ship to.

By controlling other objects' scripts via a master script (through global variables): I was going to try having the 'move function' placed inside the onUpdate event of the moving items, triggered inside it's own onActivate. The master would then simply "otherRef.activate()" to begin each item's 'engine'. The master would then go into real-time 'control polling' and calculate distant, speed, heading, etc accordingly - set to a relatively slow 0.033 regSingle loop. Those calculations would be stored in the aforementioned globals... and the moving items would be remotely shut off by the same globals.

What I foresee this doing is allowing each moving ref to have it's own set of movement firings; reducing the overall stress on the setup. Supposedly, many Papyrus threads can be running at once; so my theory is to speed it up by delegating the intense parts to simultaneously running scripts. I guess this would kinda be like 'script multi-tasking'. The problem I foresee, if any, would be if they really do synch or not. Now you can see why I didn't switch to or test this type of setup before the release... coulda possibly delayed it weeks.

I also lost interest in this potential work-around, because I discovered that 12 moving items behaved exactly the same as 2 or 3. In other words, it's not necessarily how fast the script runs, or how many lines of code it has to go through (though extremes obviously will matter). It's getting the translateTo's to fire WHEN THEY SHOULD... something that multi-task-scripting may not help unless talking about dozens of items. In fact it may make matters worse for tying up that many more threads.

[EDIT: I struck-through my error above... I was mistakenly thinking of a variable in the script before porting it over from Oblivion. That variable was the 'speed' but in Skyrim's script it became the distance traveled per translateTo. THE 'SPEED' IN TRANSLATETO IS CONSTANT NO MATTER WHAT DISTANCE.]

Martin Septim on a stick! THAT is anyoing. How did you discover that clearing the prop first was the way to fix this?

Is there anyway to look at and or edit this VMAD subrecord? I would be willing to bet a HECK of a lot of mods have LOTs of that i them now, with no way at all to remember the prop in order to add them BACK in just to delete them as you are instructing. So some other way will need to be found as well, some way to clean the VMAD subrecord?

Would merging the esp into another one clean it out?

What about breaking up scripts into functions that are in other scripts? Will this make the script manager run the script faster or will it make no differences?
I have had to make 2 separate scripts sometimes out of one and that made them run faster (not badly delayed), but I would this work with functions as well?

Combat scripts are extremely sensitive to this lag issue as a scripted kill may trigger 1/2 second after the weapon hits, that seems like it would be nothing but players seem to feel otherwise.

you might be able to look at the VMAD record in tessnip for any object that has a script attached to it, but it's basically just a hex dump.

actualy, sometimes, clearing the property before deleting doesn't always clean it up.

the surefire way of cleaning the rogue property is to delete the script from the object, then reattach and reassign properties. (removing the script will guarantee the VMAD record, and all cached properties, to delete themselves)
i just spent about 10 hours going through debugging and cleaning all this crap from my files.

it starts to become a REAL pain when you have scripts attached to a base object and your reference inherits some properties and adds overrides others. then you have to go in and remove the script from both the reference and base, and reassign properties all over again.

possibly one of the most annoying bugs to date


i've now made it standard practice to remove the script once i finished with it when it is working, then reassign my properties and test in-game. this launders out the dirty property entries as you go, so that you dont get stuck with cleanup duty in one massive sitting.

99% of all my scripts are magic effects in abilities that get removed from the actor perodicly in game.
I wonder if I am thus bypassing this issue because of how the game handles the spells?

Also, do you know if this is faster:


force = 1 + (Mass * Me.GetBaseActorValue("Stamina") * (AStrength / MEStrength) * PreStamina * aadpBlockStaminaMul.getvalue())
Me.DamageAV("Stamina", Force)

than this:


force = Mass * Me.GetBaseActorValue("Stamina") * (AStrength / MEStrength) * PreStamina * aadpBlockStaminaMul.getvalue()

if force > 1
Me.DamageAV("Stamina", Force)
endif

@SLuckyD

I actually think that the speed variable for the translate functions is not dependent on distance to travel, but just how fast the object should move. For example, an object translating a distance of 1000 units at 250 speed would finish translation in 4 seconds, and a distance of 2000 at 250 speed would take 8 seconds. I would quote the wiki, except that I'm the one who posted all those notes for the translate functions.

As for the test I did, I only called the TranslateToRef function for each object once. Each object's target is a clone of itself placed exactly 10,000 units in the positive Y axis from itself. So each object is moving at the exact same speed, in the exact same direction.

My game also gets extremely choppy when trying to record stuff. The gap between the ship and the lever is not quite as large when I'm not recording, but it's still noticeable.

I'm really interested in how you managed to get your ship to detect collision.

Your "script multi-tasking" is exactly what I was trying to show in the test I did. With my test, I was attempting to show that the translate functions do take a noticeable amount of time to process (maybe 1/20 of a second?) and by using multiple scripts, I could get the objects to start moving at relatively the same time, which cannot be done if you call TranslateToRef in succession for each object from the same script.

Of course, this only worked well because the script for each of them is simple, just a single call to the TranslateToRef function. If it was more complicated, with some scripts needing to call different functions and therefore not finishing their job at the same time, then the timing would be a nightmare.

P.S. I feel like we're hi-jacking the thread with our discussion, so I'll shut up now.

This is exactly why I created this thread... to talk about these kinds of issues. Since the premise behind scripted movement of multiple objects may be applied to other aspects of the game, I think it's pertinent enough.

But you're correct.. the speed IS a constant. I was mistakenly thinking of the variable I used in Oblivion which was my 'speed' variable... when I ported the scripting into Papyrus, that variable became the distance traveled per translation. I guess I confused myself there for a sec.. heheheh. Sorry! (I should probably go back and edit that out so noone believes it, huh?)

Hopefully I redeemed myself by spilling my guts about my script... if not, here's some more. You guys are gunna figure it out eventually anyway... why be greedy? I'm still not gunna show you the actual code just yet, I want to work on it more first; but it really is a masterpiece that once optimized, I'm not sure I'll be able to top it anytime soon. (although my future plans involve chariot racing... another thing I already modded in Obliv, just need to port over)

As far as my collision detection... heheheh - it's an invisible chicken. Seriously... look in the ESP. As you probably know, refs that are translatedTo will go right through any static, land, actor, or anything while translating.. correct? BUT, during my sailing-script adventure, I discovered that ACTORS in the middle of a translateTo will still respond to LAND... they will 'ride' up it, continuing on the same trajectory as the translateTo sent it. So what I did was test for the chicken's zPos... when it hits land, it'll pop up, triggering my anchor function.

It'll also detect statics, but only if they are BELOW it; as they can't be INSIDE the static when the translateTo is finished or the collision won't resume (the actor may still 'walk' through it). THIS is why my script fails when the timing collapses; because the chicken is being erratically moved and probably winds up inside a static or something... tries to pop up out of it and triggers the anchor. The chicken will pop through a static, while the Player won't becaauussse... I move it way faster, so between movement functions, it has an instant of freedom in which it can be affected by the environment (though it's an invulnerable ghost). This stoppage-freedom is prevented in Player and other objects by my exploitation of the stacking.. to keep everything else in constant motion. If the stacking doesn't happen as it should (falls behind because excess stress on the system or scripting errors... the title of this thread.. heheh), the script collapses and the ships studders uncontrollably until it triggers the anchor.

I plan to test a trigger-box system, which would hopefully detect ALL objects in the way. I may need to use this in conjunction with my invisi-chicken, as I dunno if trigger-boxes would detect land or not. But I can hear you through the internet asking, "Why a chicken?" Because it's the simplest, lowest-poly actor I could think of... to reduce resource stress to a minimum. It doesn't even have any bones in the NIF. The only drawback is that every now and again you hear a clucking on board the ship. (I thought I took out the voice/sounds/etc, but I'll have to recheck that..)

NOW.. regarding the multi-script-tasking... if there is ALWAYS noticeable lag between two objects being told to translateTo consecutively (which I'm not sure I believe, but..), I think I know a way around it. Instead of using a master script to fire the peripheral scripts, the master script would still poll, calculate, and set the data into globals... but the scripts would be activated from a quest - which triggers by using conditionals. Since whatever conditional is triggered ONCE, and all the refs detect and react to that at the same time (theoretically); I believe this is as close as you'll ever get to simultaneous firing using Papyrus.

This is how I hope to implement a different system of controls for the ship.... using a quest which is triggered by conditionals looking for directional keypresses (WASD). The peripherals would still be activated by the master script, and the calculations will still be done in the master. The master's onUpdate would test for the 'directional globals', then adjust the calculations accordingly. I think I can do this in Vanilla Skyrim, but I may wind up needing to use SKSE for this kind of thing... which I'm trying to avoid (at least for several months until its been tested more thoroughly). This is something I plan to work on in the next day or two (or whenever I get time); as well as trying to tweak the script further to allow lower end computers to use it.

[EDIT: type-o]

Very interesting thread, thanks!

.
So, http://www.gamesas.com/user/766649-amethyst-deceiver/, when I delete the property line from the script and then save and compile, am I to take it that the property is still there in the plug-in even though it is not showing in the properties window of the reference editor's script tab?
.
As a rule, I avoid using properties and prefer GetNthLinkedRef(n) instead - but I have a lot of autoclosing doors which recently had a sound property removed because the play-sound code doesn't work as documented. So I am wondering whether this is a problem constrained to properties of scripts attached to a base object or whether it includes scripts attached to reference forms as well...?
.
If this is still a problem, would deleting all the affected doors and replacing them (and reattaching the script) do the trick?
.
And, thank you http://www.gamesas.com/user/764276-sluckyd/ for the http://technet.microsoft.com/en-us/sysinternals/bb896653 link - that was handy.

These missing property errors DO occur on refs with a 'faulty' script attached to it. While I STILL advise further checking your Papyrus logs after making ANY changes to scripts, I just tested for your question. It seems the 'deleted-property bug' may not be as frequently recurring as I had previously thought... they happen after fast-travels but NOT every one; though they ALWAYS occur when first loading/starting the game. Very strange... I still need to do more testing to see how frequent and if saveGame data makes a difference.

But to fix it, I've taken to removing the entire script from the base (or the ref), exit the base/ref, save the ESP, then reattaching the script & auto-filling again... then saving the ESP again of course. It's easier than having to go through and remember which properties you deleted, potentially skipping over them while scanning. It seems one can never be too safe in and around the CK... heheheh.

I found several of these types of errors during testing, all around the game-world... but I never documented them. There are WAY to many to list here, but I've started a TXT file containing all the Vanilla errors I find during my testing; by going to different areas, and retesting some. Some of these occur because I coc into the game from above, and questlines aren't triggered; so certain things WON'T be assigned whatever. Here's an example of one:

- on fast-travel to Solitude (there are actually four errors,same one each time)
(0009F82B)].dunBluePalaceArenaSCRIPT.OnUpdate() - "dunBluePalaceArenaSCRIPT.psc" Line 77
[05/01/2012 - 09:53:14AM] warning: Assigning None to a non-object variable named

.
Thank you, http://www.gamesas.com/user/764276-sluckyd/. I've been waiting for some more information on this issue.

I believe it; i've enabled the 2 HD packs from Beth' and the timing of my "core script" is still correct. But then i've enabled FRAPS instead, and the timing was delayed of several in-game minutes. This is not good.

I only have my mod, but so i've checked the log (for the first time) and you're right, there are many errors, the ones you are talking about in OP. Errors about Ref == None etc, also errors about Scripts used as Properties in others scripts. Well i will fix that ASAP and see if it changes something.

This is more or less what i've already done by using a second Quest script for the heavy stuff, instead of States. As said, it helped a lot and increased the speed.

Sorry, you did not get me there, maybe i was not clear at all. I'm using (0.25) because with this value for RFSU my variables are correctly decreasing to 0 in one game hour. If i increase this value, to (0.5) or even to (1) and so have less updates, the variables are reaching 0 after more than one game hour. This is the problem.

About vidMemory: since my Skyrim rig is lower-medium end, I've never tried ultra settings, as even high settings are unacceptably laggy for me. But I tried ultra to see how bad it would be, and to see more about the memory usage.... it topped out at 750mb (of my 1gig dedi). I run no tex packs, and with the game turned completely up to max on everything - it still only uses 3/4 of my vidMem. The textures being completely loaded simply can't be true because the tex.bsa is over 1.3gig. I know ALL the tex doesn't load at the same time, but my system NEVER goes above 750mb, no matter how many cell changes/etc take place.... so there IS swapping going on (no matter how seemingly minimal some may think that to be).

VidMemory seems greater affected by shadows... more detail and distance, combined with radial blur, puts a sizable dent in vidMem. While I'm not too familiar with how GPU hardware interacts with game-engines, that sounds suspicious as I thought shadows are usually drawn real-time and aren't really a function of memory but the gpu speed/shaders/etc. Am I mistaken?

But unless I have the game turned everything down the lowest, and I go to a relatively 'blank' area in the world; my GPU still is close to max'ing out. So, personally, I'm convinced that vidRAM could be better managed and that the GPU is overly taxed, even in the simplest of situations. Shadows just pegs that GPU graph to the ROOF. (in-game shadows aren't that great anyway... even on high/ultra/whatever)

[and yea.. Process Explorer is awesome. I used to use it incessantly back in WinME days ... but I think Vista didn't take too kindly to it, so I stopped using it and soon forgot. Now Win7 is here (which is the first time I'm actually happy with a microsoft product). Doing a google for monitoring vidRam didn't turn up much, but ProcExplo was up there... and I was like "oh yeeeeeaaaaaah!" BTW: They've added GPU monitoring since the WinME days.. heheh.]

Voland: Regarding the change in timing to the regSingle... I meant to increase the increment in order to decrease the system stress caused by the script. Of course you would have to compensate for the longer increment elsewhere in your formulas... I shoulda mentioned that. Example: If you want to count down from 100 over one hour, and currently do it at a rate of x performed 1,440,000 times (60min/hr, 60sec/min, 4quarters/sec * 100)... then doing it at a rate of 2x performed 720,000 times (0.5 and not 0.25) should result in the same thing, but using half the load in the process. (even more so, the larger that regSingle increment gets... the max depending on how frequent you NEED it to update)

[EDIT: type-o]

even though they say never have more than 4 shadow lights visible at a time, i make it a rule to never have more than 1. and i script the hell out of them to show/hide wherever possible. having even 2 shadow lights on at the same time seems to kill my fps faster than anything else. i use a GTX580 with 1.5gb vram and i still get up to 10 fps drops when multiple shadow lights are enabled in a densely cluttered interior