50 replies to this topic

[SLuckyD]

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 chastisement 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:
FRAPS - for monitoring FPS rate in-game (commercial, free demo available)
Process Explorer - for monitoring GPU memory and usage (freeware)
Notepad++ - for writing scripts (freeware)
Notepad++ Setup and Plugins - 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).

Edited by SLuckyD, 05 May 2012 - 11:20 AM.

[SLuckyD]

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.

[SLuckyD]

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.]

Edited by SLuckyD, 29 April 2012 - 09:03 AM.

[Seigneur Voland]

- 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.

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 ?

[SLuckyD]

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)

[SLuckyD]

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 ProcessExplorer 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...]

Edited by SLuckyD, 29 April 2012 - 11:23 AM.

[RandomNoob]

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.

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

[SLuckyD]

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).

[RandomNoob]

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.

Spoiler

Scriptname Script01 extends ObjectReference
{The main controlling script.}

Event OnUpdate()
    Obj01.RegisterForSingleUpdate(0.000001)
    Obj02.RegisterForSingleUpdate(0.000001)
    ;etc.
    RegisterForSingleUpdate(some reasonable interval)
EndEvent

Spoiler

Scriptname Script02 extends ObjectReference
{The scripts on all the peripheral objects.}

Event OnUpdate()
	;run the translation functions
EndEvent

Edited by RandomNoob, 29 April 2012 - 12:33 PM.

[SLuckyD]

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)

[RandomNoob]

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

Spoiler

Scriptname fg109TestObjScript extends ObjectReference

ObjectReference Property Peripheral01 Auto
ObjectReference Property Peripheral02 Auto
ObjectReference Property Peripheral03 Auto

ObjectReference Property Target00 Auto
ObjectReference Property Target01 Auto
ObjectReference Property Target02 Auto
ObjectReference Property Target03 Auto

Event OnActivate(ObjectReference akActionRef)
	if (akActionRef as Actor).IsSneaking()
		(Peripheral01 as fg109TestObjScript).Target00 = Target01
		Peripheral01.RegisterForSingleUpdate(0.0001)
		(Peripheral02 as fg109TestObjScript).Target00 = Target02
		Peripheral02.RegisterForSingleUpdate(0.0001)
		(Peripheral03 as fg109TestObjScript).Target00 = Target03
		Peripheral03.RegisterForSingleUpdate(0.0001)
		RegisterForSingleUpdate(0.0001)
	else
		TranslateToRef(Target00, 250.0)
		Peripheral01.TranslateToRef(Target01, 250)
		Peripheral02.TranslateToRef(Target02, 250)
		Peripheral03.TranslateToRef(Target03, 250)
	endif
EndEvent

Event OnUpdate()
	TranslateToRef(Target00, 250.0)
EndEvent

This is the resulting video (sorry it's so choppy, but my computer sucks): 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.

Edited by RandomNoob, 29 April 2012 - 02:24 PM.

[Amethyst Deceiver]

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

[SLuckyD]

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.]

Edited by SLuckyD, 29 April 2012 - 10:02 PM.

[spookyfx.com]

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.

i wanted to reiterate here what i posted in the other thread: Papyrus DOES NOT clean up after itself. YOU, the mod (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

Edited by spookyfx.com, 29 April 2012 - 05:24 PM.

[Amethyst Deceiver]

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.

Edited by Amethyst Deceiver, 29 April 2012 - 05:34 PM.

[spookyfx.com]

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

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.

Edited by spookyfx.com, 29 April 2012 - 05:39 PM.

[RandomNoob]

@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.

[SLuckyD]

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]

Edited by SLuckyD, 29 April 2012 - 09:57 PM.

[MERPTeam]

Very interesting thread, thanks!

[RealmEleven]

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

.
So, Amethyst, 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 Super Lucky Dave for the Process Explorer link - that was handy.

[SLuckyD]

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

[RealmEleven]

[...]
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.
[...]

.
Thank you, Super Lucky Dave. I've been waiting for some more information on this issue.

[Seigneur Voland]

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.

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.

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.

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.

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.

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.

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]

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.

Edited by Seigneur Voland, 02 May 2012 - 06:24 AM.

[SLuckyD]

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 <cringes>... 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]

Edited by SLuckyD, 02 May 2012 - 09:52 AM.

[Amethyst Deceiver]

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

[SLuckyD]

Maybe I'll have to break my current stance on not fooling with the INI files in Skyrim. Until now, I haven't seen the need for it, as the game runs great as-is (unlike Oblivion which had to be tweaked until practically a new game). But getting into it closer and seeing what's going on, I'm wondering if there aren't some 'magic' setting tweaks, probably shadow-specific, which may help or get rid of the performance hits. Unless anyone knows more about that, I'll look into it in the near future.

About lights.. I know about the 4/view limit, which I didn't preCK (one mod had flickering lights because of that). I haven't gotten far enough into remaking that mod to have placed the cool lighting back in it yet... I'll have to keep this in mind, as I was hoping to use a bunch of shadow-casters; they're soooo much nicer looking. Hopefully some INI tweaks'll help though. My gpu is a gts360, not as good as yours; but it shouldn't be struggling at certain detail levels, as it seemingly does.

[Seigneur Voland]

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]

So, okay. But for what i'm doing it will not result in the same thing. Of course i could use only one update to decrease the variables from their original values to 0, but ... it would completely wreck my mod.

And you were absolutely right about the errors in the log. I simply fixed them all (really the only thing i did since yesterday) and this made the timing not accurate anymore ... it is now FASTER than expected. Which is a good thing on a side, but on another, using mods that have a lot of errors will so delay everything. The log is also full of vanilla errors, some are even cycling. No matter what can be done, this timed script will never behave as i would. Time to re-do it from scratch and completely change the process, i guess.

[SLuckyD]

I didn't mean to run everything from one script; but to change the formulas for whatever you need to.. in order to get the timing to synch. Unless you're moving objects in real-time, there isn't much else that you'd need such a frequent update interval. Now that errors aren't slowing it down, it probably isn't stacking as much (if at all)... so your 0.25 interval runs closer to how it actually should (which is probably too fast). You never said what you're timing, so I dunno if this could be tweaked the way I'm thinking of.

Are you aware that by coc'ing into the game from the Title Screen, you are actually causing most of the Vanilla errors? There are all kinds of properties/etc that aren't initialized if you never trigger certain quests/events/etc. If you load a saveGame, then look at your log, that'd be a better indicator - as presumably you saved it after playing the actual game. I've found saveGames don't seem to affect these types of errors ('none'), but I want to look more at that.

Before you go writing your entire mod, you may want to consider a couple things. Have you tested it while having an fps counter running (like fraps)? If you aren't getting at least 50fps at ALL times (no spikes below 50), then intense scripts will occasional misfire; becoming more frequent the closer you get 30fps. Below 30, intensely timed scripts simply deteriorate into unusability. So it may be your system's performance, rather than other mods' scripting errors causing problems.

It's quite unrealistic to expect everyone to fix their scripts; though that's what this thread is intended to help and educate about. Many people are simply Oblivious (pun intended)... don't know, don't care, and expect everything to work as it did years ago for some completely different game. To design one's mod around everyone else's shortcomings seems a bit extreme in my opinion... it'd be easier to lobby the authors of popular mods to just fix them; you've seen for yourself how easy it is and the impact it has.

Now.. you said the timing of the script is fouled, couldn't you place code in it to limit numbers of firings or speed? In my sailing mod, I recently found that I could do without a lot of code I previously thought necessary to control timing. It's only necessary when a system runs at borderline speed (45fps with spikes down to 30, usually at cell-changes). My point is that if people know your mod/script requires a certain level of system performance, they can take the necessary steps to achieve it. (detail levels, faulty mods, background apps, etc)


Everyone, I found out a couple more things about the CK, scripts, and moving stuff:

- if a ref is enabled then immediately transTo (I dunno about moveto), the transTo does NOT fire immediately (if at all). I had to put a wait between the commands and it works fine. Placing it in another event or function works too. I wonder how many commands, which seem not to work for some, that this can be applied to.

- while using the default Medium detail settings (the button in the launcher), running the CK drops my fps rate by 15... no questions asked (from 45-50 down to 30-35). This is only running the CK, NOT loading any plugins or skyrim.esm or ANYTHING. How can this BE?? I suspect shaders, but I know precious little about GPU hardware and how it's controlled. My biggest peeve is that nothing's in the render window, no textures or anything are loaded... CK isn't doing 'anything', so why does it affect the game so badly?

- changing or adding a script to a reference (in the renderWindow) without doing ANYTHING else in the CK session will NOT allow you to save the ESP. The little * next to the plugin name doesn't show, and pressing save does nothing... which is yet another thing that simply shouldn't be. If you press save, shouldn't an app save no matter what? Why does the CK require something to change? ...simply moving something then hitting the 'back' button suffices to trigger 'save-ability'.

[RealmEleven]

Super Lucky Dave, the CK does occupy a lot of space when it is loaded and this is probably the reason it responds with surprising readiness. So, by running the CK in the background, I can set the game up for a reasonably good stress test if I get a few other processes running as well (maybe a high priority virus scan and/or a disk defragmentation). Of course, Windows Media Player can put a lot of stress on the system when you least expect it and I am yet to see any demonstrable capability for this program to be set up not to do anything without asking first. So watch out for some of these. There's also an SR process that arcs up every 10 minutes of idle if the default setting is not corrected. This process scans your disc and places markers for the purpose of system recovery - not such a bad idea, in theory, but it takes a long time and and is resource intensive and, again, none of these scheduled tasks are sensitive to whether you are in full screen mode. For those who think that anything on x86/x64 systems is new; that's yesterday's technology, tomorrow; maybe. SR (System Recovery?) is one you'll have to look up in the Task Scheduler (and no-doubt the name has been changed - but I think you get the picture). My SR process is set to fire on 30 minutes of idle and stop when I come out of idle. But, I'm not done with these little things yet. So far, getting SR under control has made yet another significant improvement to performance. My power supply, which isn't handling the Winter too well and is to be replaced next Monday, seems to be hanging on noticeably better without the CK and SR duking it out for supremacy.
.
Having said this, I tend to think that getting one's mod to "play nicely" with other mods is vital because it's always the other mods which set the stage for your mod - by covering all the other bases that it wouldn't be humanly possible for one author to cover - or which have to vary from one user to another due to different user needs. Either way, if my mod stuffs up other mods, then there is no point uploading it - and that is why this property bug in Papyrus has got me nervous. I think a lot of modders are aware of this - at least those of us who play the game and use other mods as well. That's the key in business, as well - you have to be part of the market you are servicing or you'll never have the faintest chance of understanding the requirements of the market. I think it is something like this which gives modders more success meeting the needs of their markets than a lot of much better funded enterprises. But that's just my opinon.

[SLuckyD]

I just added some stuff to the OP; regarding fragments, scripting baseObjects, and a little update to the deleted property thing.

About the CK: it doesn't take much by itself... it's when you start loading mods (or even just Skyrim.esm), and even more when you start loading cells into the renderWindow. I'm talking about simply starting the CK and LEAVING IT... -15fps when in Medium detail settings. So I looked at it a little closer... when the mouse cursor is OUTSIDE the renderWindow, FRAPS shows the fps to be a solid 16 (in the renderWinow). As soon as the mouse enter the rendWin, the fps skyrockets to 120+... until the mouse either stops moving or leaves the window again.

This leads me to believe that the processes polling the mouse and the rendering are flawed and should be revised for optimal system performance. I guess they assume people wouldn't be playing while the CK is open (which I do unless my sysRam is over half-full); so they probably programmed it to be resource-intense for response time during development. Is it too difficult to STOP those processes if no plugin has been loaded, or if no cells are in the renderWindow, etc etc?

Why would I want the CK not to load a plugin? I use it to easily compile scripts (I couldn't get the command-line thing to work in Notepad++.. so I just do this). Even with no plugins loaded, the CK will still eventually crash after compiling about a dozen times or so (it's seemingly random). Here's the error it gives when that happens; I assume it's garbage cleanup, as I said before... I just think it's funny that CK blames a faulty Windows module (ntdll.dll).

Assert File: C:\_Skyrim\Code\TESV\BSCore\MemoryContextTracker.cpp Line:151
[options to abort/retry/ignore... all crash]


[EDIT: When I first install Window$, I basically gut it... turn off everything like Defender, SysRecovery, indexing drives other than C, firewall, etc etc. So it isn't Windows causing drama, though I understand how that would happen (hence the reason I gut it). I've been doing this (hacking operating systems), since DOS 2.0 back in the 80s... so I'm fairly familiar with it all (ie: I'm not some noob who just ignorantly fools around willy-nilly).]

Edited by SLuckyD, 05 May 2012 - 11:35 AM.