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.

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.

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

http://www.gamesas.com/user/764276-sluckyd/, 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.

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

FRAPS gives me 60 FPS nearly all the time, excepted at some known places (Markarth, top of Whiterun). And as said, i only use my mod.


I am not coc'ing at all, but using an old save with 150 hours of play. The save log is so full of Companions & Bards Quests errors which are cycling, ha ha. Plus some rising at Fast-Travel, etc.


Making a survival mod, the variables timed are the needs. Of course i could shave me this headache by simply doing GameHour checks to decrease the variables. This, would be always accurate, whatever may be the speed of the script. But i would like to make a system based on real-time second. I tried to limit the numbers of firings or speed with ( GetCurrentRealTime - Var1 >= 1 ) as check, but the result is, even with RFSU(0.01), far too long than expected.

Seriously, this is boooooooring as hell. I miss GameMode with fQuestDelayTime set to 0.01 ; it was not 100% accurate, but still very reliable for such kind of timing.

I have yet to read the full thread, but just in case this hasn't been mentioned yet. Read it, it hasn't been mentioned.

There is one potential issue with how probably most us compile our scripts, that is with ScriptCompile.bat. But it doesn't use the -op switch, which would enable optimizations, also there is not mention of it in the CK wiki.

Initially I though, the VM implements all optimizations but it doesn't look like it. I tested with a custom script, and using the -op switch the compiled script had actually some differences (and not only in the header). So using the switch changes the generated code.

Also, thanks for the effort and great idea!

What kind of optimizations? Does it, say, improves iteration speed? Or does it improve stability?

Well, since even smartphones these days come with at least 2GB microSD card, I think I'll pass file size optimization

The property bug is very enlighting, glad I read this thread. I'll have to watch out for this in the future.

I'm not sure, but I think the optimization only removes white-space and comments; how else can a script BE optimized non-humanly? Tha'd be SOME feat of software engineering if it DID (as true language/compilers/etc probably are). I don't use the commandline or Notepad++'s thing... I open the CK (without loading anything), then compile that way. I think the optim is done with CK compilation, as my compiled scripts have NO comments embedded in them anywhere... unless it's superbly encrypted, but why bother? Aslo, I agree with the size of script files not EVER being an issue.. even with a 1000 lines of code it'd be under 50k I bet. As long as it isn't 50mb I'm happy.. heheh.

About the cyclic errors: I do get plenty of Vanilla errors when playing the game normally; but not NEARLY the amount as when coc'ing into the game (or areas that are quest/trigger sensitive).

Re: The properties thing. When you remove a property from your script and recompile it, it's sufficient to simply open the properties dialogue button on whatever that script is attached to and click "ok". The only exception being if you removed the script's last property. THEN you have to detach the script and reattach it.

I've been doing things this way the whole time and it always gets rid of the pesky property errors in the logs.

One does not need to detach, exit, close the CK, load the CK, reattach, and reassign all the properties.

You already did Sheogorath's quest, didn't you?

If so, the USKP solves this particular bug. It's because the vanilla script never unregisters itself for updating. We simply told it to unregister itself and the problem goes away. Freeing up cycles in the process, which has to be good.

There's tons of these unfortunately. One of the biggest offenders is those random dust particle scripts. It seems those are continuing to run despite the player not being in the cell they belong to. They spew forth errors about trying to play a sound with no 3D loaded. Sadly, due to how Papyrus embeds this crap into the save, you can't fix it by modifying the script. Your save will [censored] about it not matching the stacks and simply ignore the changes. So in many cases the vanilla game has flooded the stacks with a bunch of crap that you simply can't get rid of.

It's like Morrowind all over again

Damn, and I even remember (now) that I read SmkViper's post.

White-space and comments aren't saved with a http://uesp.net/wiki/Tes5Mod:Compiled_Script_File_Format, regardless of the switches used.

I tested some time back if the compiler would inline function calls - to papyrus functions that just dispatch to native ones, like GetAV invokes GetActorValue - but it doesn't even do that.

Another thing along the lines of inlining would be to remove constants (autoreadonly hidden properties) with their actual value. They are useful to maintain readability but to a computer they are just waste.

The PEX format already has a string-table suggesting that strings are interned, that's an optimization right there.
And the above two things, aren't that hard to implement.

Well maybe they use JIT?

My experience and knowledge of actual programming is limited to what I did in the 80s with basic, Pascal, and assembler... and even that was limited. But I've been a consultant for over 20 years, so I like to believe I comprehend big-picture things fairly quickly. But interning JITs is above my head... so I'm outta that part of the discussion.

It just seems there are few things which could be substituted in... if a LOT of things could be sub'd in, then the language would presumably be simpler (written with the 'optimization' already in place). I realize optimization may be more than just crunching 5 lines of code down to 2 or 3 (or whatever); but I'm not adventurous enough to experiment with that kind of stuff... especially given all the issues and bugs we have to deal with already. Command line switches and what-have-you... sounds like asking for trouble..

Arthmoor: That's VERY interesting about sounds and the no3D error. We've been discussing that in another thread, but I hadn't heard of something with no 3D showing that error. I actually have success doing things with 'invisi' objects in non-attached cells (such as mapMarkers and collision boxes). But by knowing SOUNDS are affected by this as well seems to indicate that some objects may have a certain flag or placeholder... unless you're talking about a sound attached to a static (which has 3D). But if there is some kind of flag or piece of data, we can potentially work-around this; or someone could write an app to do it.

But other offenders are critter spawns... I found a bunch of em off the coast near Solitude. I don't remember if I did the Sheogorath quest or not, I don't actually play through the game too often. But I don't use the USKP.. so all those Vanilla errors are still floating around. It gives me reassurance that my mistakes aren't so bad, seeing as Ma Beth's people have made the same ones! Unfortunately it also bolsters my opinion that Papyrus (and the current game-engine in general) should have been developed further before release... stupid deadlines and media-oriented hype.

While I just remove then reattach a script as a quick and effective fix, I'm fairly certain that simply recompiling a script with properties removed will still have those properties; and they cannot be removed manually, only reassigned - it that what you meant by 'ok'? Reassigning nothing? I'll have to check this again to be sure.

Also, I posted in another thread about finding that deleted/changed properties in a mod's script are saved in the saveGame data; but when you fix those errors in the mod (using whatever method, mine being the above 'remove-reattach method'), it is potentially removed from the saveGame data. You just load Skyrim with the fixed mod/script with the old saveGame (which will give you errors for that game session), then save a new one. Exiting Skyrim then loading the new saveGame has the errors all gone.... though the data is potentially still in the actual saveGame (only not referenced). I want to look more into this, but saveGame bloat is better than cyclic/perpetual errors in my opinion... unless it causes other issues I'm not aware of.

The one from the USKP I'm talking about is those dust generators. The ones with the fxDustDropRandomSCRIPT attached to them. I modified that script because the OnLoad() event it calls for triggers even when you're nowhere near a cell with one of those in it. Swapped it for OnCellAttached(). The only problem is, the save continues to use OnLoad(). You can't undo this one. Obviously it can't be clean saved either because it's from a vanilla object.

That script tries to play a sound event, which can't play if the 3D isn't loaded. These are visible activators and so they will have 3D to show if you're there.

As far as compiling out unneeded properties, I've found it sufficient to simply go to the object the script was attached to, click the properties button, then simply click OK from the properties menu. That clears out the ones it doesn't have. The only exception being if you removed the last property and there's nothing on that menu. The OK button won't be accessible then and you'll have to detach and reattach the script.

Ahhh.. that makes sense if the sound is assigned to something visible.

About changing a Vanilla script though... with my Vanilla Mannequin Script fix, I had the same problem (not being able to get rid of the errors). I just added back the deleted properties to fix them. But an alternative is to place it in an ESP... something I wanted to avoid to keep the Fix as simple as possible. I assume the USKP has an ESP, so if you find whatever that troublesome script is attached to... you can get rid of the error, presumably using the method you just described.

Why is it firing an onLoad when you aren't there though? Is the script assigned to something in other areas, then coded to call something from that non-attached cell? Or is that the big mystery....

Not in this case, the script complains about the suspended stack in the updated script not matching what the save game has stored. The game insists on reverting to the one in the save.

I don't know why it's firing an OnLoad() when I'm not in the area. That didn't make sense to me either but it's probably because the script has a poor loop structure that causes it to process endlessly once it's been loaded.

Yea, I've seen the stack errors you're talking about... I think they were usually because something goes missing. But as I said, if the code calling the missing thing is removed (MUST be in an ESP if Vanilla, as well as the script itself), then you save a new saveGame with the changes running; that new saveGame should be 'cleansed' the next time Skyrim is loaded (possibly if same-session loading, but I doubt it). It's harder to do with certain Vanilla things though, because some of that stuff is SOOOO convoluted. Hopefully it'll get straightened out eventually... even if it means starting the entire game from 'beheading day'.. while running the latest USKP/etc.

dtp - dump texture palette
oms - output memory stats (what tex & models are loaded, but mem-stats always shows 0)
?outalloc - also is broke/always is 0
?omsfw - also output mem (just stats?)
dpu - dump papyrus update registrations (that paticular moment is dumped to log after skyrim is exited)
dps - dump papyrus stacks info ("")
tmc - toggle view mode for debugging (DOESN'T WORK)
tni - toggle view mode for navmesh (DOESN'T WORK)
pcb - purge cell buffers (dump loaded cells not currently attached)
tdt - toggle debug text (DOESN'T WORK)
tanim - toggle ALL actor animations (freezes them; if turned back on will finish the frozen anim, then ....?)

Here's some console commands I stumbled across that are pertinent to this thread and testing for various things. I haven't found anything that lists actual memory USAGE, only what's loaded in memory (not how much it takes up). That DOES help a lot; and you'll be surprised at what you'll see when looking at models.... it seems some races' geometry is ALWAYS loaded (even the decapitation stuff), very strange.

I listed a couple extras in case I was using them incorrectly - maybe someone else knows how to get them to work? Also some stuff may be useful in testing for NavMesh Bug induction... like the pcb (maybe the Bug can be triggered by console without fast-trav-return..).

http://www.uesp.net/wiki/Skyrim:Console

ahhhh... a lot has been added since I looked there. That page still doesn't contain the important ones I listed regarding Papyrus and tex/mesh dump though.

I'd also like one to show what quests are still running. Poking around with the USKP, we run into quests that are still active that shouldn't be. Hogging up alias memory and stuff.

sq - list all quests' status (on/off & stage)
sqal - set quest alias logging

I dunno if sqal works or not... I haven't tested it yet. But sq works fine, just be warned that it returns EVERY quest's status and stage to the console. I think you can then save that to a file for easier viewing... but I don't know how. I found a link to a site that has the same listing as I was talking about though... I dunno if it was THE site I got it from, but here's the link to ONE of em. It has ALL the events, console commands, and script commands.

http://mod.gib.me/skyrim/functions.html

= Here's some of my notes on console commands I HAVE tried and they didn't work (or I don't know how to use them properly):
?outalloc - also is broke/always is 0
?omsfw - also output mem (just stats?)
tmc - toggle view mode for debugging (DOESN'T WORK)
tni - toggle view mode for navmesh (DOESN'T WORK)
tdt - toggle debug text (DOESN'T WORK)
tt - toggle trees (DOESN'T WORK)
stdof - set target DOF (DOESN'T WORK, 'removed' notice in-game)
ttl #radius #magnitude - toggle test light (DOESN'T WORK)
tlik - toggle Look IK system (DOESN'T WORK)
tao - toggle audio debug overlay (DOESN'T WORK)
tco - toggle context overlay (DOESN'T WORK)
tcg - toggle collision geometry (DOESN'T WORK)
tplog - toggle papyrus log overlay (DOESN'T WORK)
prints - prints current state of scenes to 'Quest Inf' file (DOESN'T WORK, can't find file)
colmesh - toggle collision info (DOESN'T WORK)
frsx - force RSX crash (DOESN'T WORK on scripts, dunno how to test)


= These work as indicated
tb - toggle cell border lines
dtp - dump texture palette
oms - output memory stats (what tex & models are loaded, but stats always shows 0)
tanim - toggle ALL actor animations (freezes them; if turned back on will finish the frozen anim, then ....?)
tmove - toggle all actor movement
setFog #1 #2 - #1 is start of fog, #2 is end, everything beyond is same fog (but still visible)
eg: 100 1000 is close fog, 10000 100000 would be very hazy day
- does NOT help fps much at all
setClipDist # - 100000 medium distant, 5000 very close (does NOT help fps that much, if at all)

Unfortunately the output from SQ is too large to see everything. It did help reveal the fact that a few things are left open that shouldn't have been at the stage of the game I checked with, but I couldn't get a look at the whole thing because the console output is limited.