Different levels of testing used by different team-members at different times for different reasons. If you're doing nothing but building scenery all day, cluttering interiors or shaping and filling landscapes, why wouldn't you use COC from main menu? Similarly if you're doing the modelling or texturing, and just want to jump straight into a test cell where you have placed (or can spawn) items. It'd greatly speed up productivity, and the quests, scripts and other gubbins wouldn't matter a jot.

That doesn't mean to say that quest designers often or ever do it. It's a tool for some staff, not necessarily a habit for all.

Well said, again, different testing scenarios use different tools.

And why wouldn't you simply use any old random save for the same purpose since it ought to be fairly quick to load either way. The state of any scripts and quests on such a save would be irrelevant if all you're checking for are floating rocks, so why not simply have a default save that everyone on the dev team is supposed to use? Eliminates variables in the procedure that way.

In all honesty, coc command is there for some reason, save is something that is for the user, not for developers, developers are coding the engine, testing stuff, etc.

I can understand that game testers never use the coc, so they mimic the user experience, but developers? I bet they only use saves if they need to do some debugging or something.

loading 2 load screens per test wastes a considerable amount of time, especially when you are jumping in to test your cell 100+ times per session as i find myself frequently doing.

there is nothing wrong with main menu COC for testing and debugging cell layout, lighting and armor/weapons in-game. it really only falls short in testing scripts/quests

if you understand the difference between a main menu COC and loading a clean save, there is no reason to avoid using either one entirely. they both have big advantages depending on the test scenario.

Amen.

Well, unfortunately I'm getting a (or THE) dialog bug. Starting with a 100% vanilla save made by pre 1.7 game version, I have to save and reload to get my dialog to fire. I'm off to test it with a new game with 1.7 from the start. BRB.

Agreed. As another example: a bug that showed up only when games have not been saved would be more easily spotted with a coc.

Well said!

I still don't think people actually get the differences though.

for those wondering, the difference is very simple:

COC test - shortcut that bypasses ALL initialization (i.e. quest data is not set up). obviously very handy for jumping straight into your test cell to look at your clutter, layout, lighting etc. obviously not good to test scripts and quests etc. due to the lack of integrity for quest data

clean save - loading a save made right after escaping helgen with no history of mods installed. obviously very handy for testing just about any situation. downside is loading 2 load screens just to test a new cell (one to fire up the game, one to coc into the cell). since player initialization and quest advancement has absolutely no bearing on PASSIVE clutter placement/layout in a cell (which makes up for a bulk of the work), loading a save is a waste of time. you only really need to load a clean save when testing ACTIVE items/quest/activators/scripts etc.

Perfectly said, let me just add that for scripts coc is also better (not talking about quests).

But in the end, when everything is said and done its good to use the clean save method too.

for further clarification, the true definition of a clean save is as follows:

start new game with absolutely no esm/esp enabled except skyrim.esm and update.esm (not even a mod you are currently working on). run through helgen until Unbound is completed. make a save. you will reload THIS save game every single time you test your mod. it is safe to enable and activate your esp/esm mods that you know work together. note though, although the save file is clean, loading mods creates a non-clean environment, so factor that in when testing (you should always test sterile and non-sterile environments).

making a new save with your test mod enabled will contaminate the save file (both active and passive data is contaminated)... although, making mistakes from dirty save games and understanding those mistakes will really teach you a lot about the limitations of editing an already published mod (in which case you must test with dirty saves as well).

Thats one of the things I'm afraid, after release the best practice is not touch it again, right?

no one's perfect, so there will surely be errors in your already released mod somewhere, that someone will eventually dig up.

most of the time, fixing bugs is straight forward. fixing script errors and quest data is the trickiest. it can sometimes become very difficult to retrofit fixes into an already released mod.


IMO the best practice is to test as many scenarios as possible. always have a sterile testing environment as well as controlled dirty environments (with different combinations of mods active as well as potentially conficting ones etc). you should also stress test as much as possible (test for scenarios that you think would intentionally break the mod).

That might be ideal, but I would not say "best practise". How would you update your mod?

It's definately possible to update a mod and scripts without problems. In one of my mods, I wrote a function to check if they were close to a carriage (ie if a carriage was loaded) and warn them the activation/upgrade was not safe). In another mod, I have it so the user can easily stop the OnUpdate function (though they don't actually realize when they tell their animal to "Go Home", that's what's happening). But I've actually been able to make two script udpates to the mod and haven't had to resort to that. And not a single problem. (Until after I post this, I'm sure.)

Edit:

BTW, I would say "Best Pactise" is to have a way to make sure all your scripts stop. Not only does this provide a clean unisntall, but also give you a forward upgrde route.

Good news then guys, because I have to be honest, I would like to continue updating or fixing it but I'm afraid of causing further problems.

I myself am worried about updating my mod with scripts in. In testing I've found if I change the script of a quest that's already active in a save then the scripts won't be updated for that user.

So far I haven't found a way round that

I have experienced that too, that's why I make sure my mods have a way to (gracefully) stop the scripts. As long as the scripts are not running, I've never had a problem updating my mod. Surprisingly though, I didn't have to do that for my latest mod (BFF Animals). I've made two updates since I initially released it. Neither update required stopping the script and not a single person has complained. I was very thorough in my testing too - verifying the full upgrade path and verifying the scripts were working correctly in game without a single Papyrus error. (I don't know why the differences as this has not been the case with ScenicCarriages, there I have to stop the scripts to upgrade.)

now that dawnguard is officially released on steam, do you think there will be a CK update as well?

if not, i'm wondering if that whole armor record debacle from CK 1.6.91 was just a botched version. i am putting off releasing my armor mod update because of this

There will need to be a CK update. Folks are reporting the CK crashes when Dawnguard is loaded. Plus there's whatever Dawnguard actually changes in record support that the CK currently doesn't know about, which I'm sure includes the armor debacle from 1.6.91.

Also, really, still arguing about testing methods? I'm sorry I bothered to bring that up at this point.

I was hoping that the CK would have been updated with the release of Dawnguard, but it crashes when trying to load it. I even reinstalled the CK and it is the same version.

I hope something happens soon. The only reason I downloaded Dawnguard was to get it in the CK. Well for now...anyway. I will play later.

When did they release Dawnguard for PC, anyway? Earlier today it wasn't there, and then all of a sudden some time past 5:00 PM it was there on Steam. Anyway, the CK needs to have an update of some kind.

It doesn't crash if you install the STRINGS files from the /strings folder in the BSA into the Data/strings directory. I have not merged the other folders from the BSA with my installation, so I'm still getting a few errors on load.

Just by unpacking the Strings from the BSA will not let you see any of the new architecture. You need to open SkyrimEditor.ini and add the Dawngaurd.bsa manually.

Scroll down until you find the [Archive] section and then add Dawnguard.bsa to the line that reads
SResourceArchiveList2=Skyrim - Shaders.bsa, Update.bsa

Add Dawnguard.bsa so that it reads -
SResourceArchiveList2=Skyrim - Shaders.bsa, Update.bsa, Dawnguard.bsa

If you do this first, there is no need to unpack the Strings from the bsa file.

[Edit]
You will still get a lot of errors because the CK is not fully ready for some of the new content, but it will let you use the new objects in your mod.

It seems like the errors are just generic Bethesda-esque errors, nothing due to an unreleased CK update.

The only thing we don't have are the PSC files.