[Lynette Wilson]

Hi Guys/Girls,

Can anyone advise on how they develop (mainly scripts) within the CK/SkyRim? For example how you go about testing any changes to scripts etc, because I am seeing strange effects while changing code within scripts and then testing within the game. I pretty much know that this is due to how the game saves state (scripts an all within the save game content) but I don't really understand the whole save game process (apart from this is what killed my own original save games once I got to level 60+).

I understand threads, but I can't seem to get my head around how threads are controlled from a main quest & within the save game? For example I created a main quest so that I could set the 'auto run' property as a way of 'spawning' my script so that I could then register for updates. The way I understood the WIKI and forum posts was this is how to auto start a script without it being attached to an in-game activation event? This worked (feedback welcome if any better way?).

My confusion is that I seem to be getting random results as to how often my script receives the onupdate event, and that I see properties (i.e. the auto ones which I applied from CK) from a previous 'development cycle' ghosting into the current script? Seems they are already 'queued' into the save game but the actual (old) script is not? To clarify, it seemed like the game had to play out the previous quest (But only the properties attached via the CK persisted) the script didn't, before updating and then playing the changes? - the new script seemed to kick in instantly (which makes sense because there is only one compiled version of the script available to the game - which is my current one).

I kinda use my existing save game for development (which I know is wrong, but I have already seen that 'cart journey' 4 times! and I cant be arsed) - which is why I'm looking for pointers into how you guys develop and test within the game?

Feel free to shoot me in the knee with a flaming arrow, for using my existing save game! but they all crash eventually ;o)

[Andrew Perry]

I use the COC console command from the main menu if I need to test things with a clean save.

[Charlotte X]

Thanks, RandoomNoob. Only just re-read your reply and noticed you suggested doing the COC from the main menu. Just tried it and works like a charm... Imagine how much time I have spent, testing my mod and how much time I could have saved just doing that ;o) I normally pick an old save game that has not seen the mod...

Good Tip, Cheers

[Cassie Boyle]

I also use an existing savegame for testing, however I made that savegame before creating the mod (so it has no traces of the mod in it), I never overwrite that save, and I always reload from that save after making any change. Yes, for a quest mod that would mean running through your entire mod from the beginning - but if you can't speed-run your own mod, then just possibly it's too complicated or tough . Anyway, always having a completely clean save to test from could save you a world of grief, even if you only test from your clean savegame now and again.

[Susan]

I normally pick an old save game that has not seen the mod...

And you should continue to do so. COC from the main menu isn't testing the game in a proper state, so you won't see proper results as users will see them.

[TIhIsmc L Griot]

This seems fine, as a testing approach.

Also, the http://www.creationkit.com/Save_File_Notes_(Papyrus) tells how script changes impact players who've saved an earlier version of a mod.

Incidentally, is there a more comprehensive guide to what is conserved, and what is overwritten, in the latter situation?

The wiki talks about scripts, but what about other objects and associated information?

[Richard Thompson]

During the development cycle RandoomNoobs advice on the coc from main menu is perfect (for me as my mod is mostly scripted). I would of course also test against save games during the final testing cycle, but the coc is saving me lots of time and headaches as I was sometimes seeing strange errors where previous versions of my scripts were obviously playing out...

A combination of the two suits me perfectly ;o)

[Gen Daley]

I should clarify - I'm not against the use of COC to get to where you're going more quickly. I'm just against doing so from the main menu since by definition you're not even playing a real game. It's much less prone to error if you stash a freshly mintend save somewhere to be used for this purpose. One that's only been exposed to the vanilla game or an alt-start mod if that makes it slightly less painful to bother.

IMO, Bethesda should have disabled use of the console from the main menu.

[Christine]

@Arthmoor; Advice taken on board and I will create a Vanilla Save (after watching the cart intro again) and copy that save (and rename to Vanilla) to be reloaded each time I want to test.

What about the mod that lets you start at the character generation stage, and then select either Storm or Imperial. before creating the new game? Does this suffer from the same effects?

Could you expand on why the COC from main menu is dangerous for testing script effects only? I find it works great for my needs. I do still see the same items being added twice to my player from a scripted quest! and this now makes me suspect my code rather than save game issues:-

Spoiler

if (GetPlayer().GetItemCount(MintyDebuggingRing) < 1)	LogDebug("Adding Ring")	GetPlayer().addItem(MintyDebuggingRing)   Wait(1.0)endif

Even, with RandoomNoobs COC from main menu, sometimes I have two rings in my inventory!? at game start?

Is this why most scripts start off in Init() with player = Game.GetPlayer(); ?

[Catherine N]

If you're talking about an alt-start mod, no, that's fine, unless it's literally doing that without having first placed you in the game somewhere. The engine expects a certain number of things to be "just so" before you start fiddling. One of which is that MQ101 has fired off, which will not happen if you're consoling from the main menu.

When you COC from the main menu, you're bypassing everything the game is expecting to check for. Quests expecting the player may not fill their aliases. Scripts referencing the player can behave irrationally. I've seen scattered reports of CTDs doing it as well. The main menu was not designed to be circumvented, so there's no telling what else may not be set properly by doing this.

Given how buggy the game is, is it really worth the headache to test entirely by COC and then just assume it works through normal play? How many of your users do you expect will scrap their games of hundreds of hours because your mod won't function except in a pristine game state?

I get that walking to your destination each time svcks, you can always drop a map marker on the spot you want to be in, or immediately outside of it if you're dealing with an interior. You don't have to leave that marker in either, just delete it when you're done.

Scripts that do player = Game.GetPlayer() are usually doing so out of convenience because they'll be referencing the same thing several times and it's shorter to be able to type "player" instead of the whole thing each time. Although copy/paste makes that largely irrelevant.

[Brandi Norton]

That code does look risky - Additem is a latent function, meaning that other threads get a chance to do their thing and possibly re-enter your code while the itemcount is still one. There's an example on the http://www.creationkit.com/Threading_Notes_(Papyrus) that protects an additem call with states.

[Damian Parsons]

I agree with everything Arthmoor says about how using COC from main menu is not a good idea. However, I don't make quest mods or anything. I only use it to test my scripts, which are not dependent on anything from the vanilla game (other than by using vanilla objects).

As for why you get two rings, you have that code inside the OnInit of your quest script. The OnInit event in a quest script fires twice whenever the quest is (re)started.

I'd have thought that by having the if condition with GetItemCount, you would avoid adding a ring during the second OnInit but I guess not. Using states would probably not help here either, because the reset would return the script to its default state.

I'd just use a RegisterForSingleUpdate(1) and put the code inside the OnUpdate. (Using RegisterForUpdate would create two update threads.)

[Sista Sila]

However, I don't make quest mods or anything. I only use it to test my scripts, which are not dependent on anything from the vanilla game (other than by using vanilla objects).

Which by itself is enough of a change in behavior to cause potential problems. They may be vanilla objects but YOU aren't a validated player interacting with them if you bypassed the main menu.

[butterfly]

@Arthmoor; I am not disputing your argument!,

But if we do not Save the Game, while testing via the COC from main menu? How is this effecting the actual game? Surely, we are just testing scripted defects, that we are testing out in the game Engine?

I'm really confused, as the save game bloat is being blamed on scripters! and I kinda, think the scripts are to be blamed (My save game crashed before I even installed a MOd, or started making one!).,

but I don't know enough to stop my own scripts from failing! and I certainly do NOT want my own scripts to corrupt a save game!

[CYCO JO-NATE]

That code does look risky - Additem is a latent function, meaning that other threads get a chance to do their thing and possibly re-enter your code while the itemcount is still one. There's an example on the http://www.creationkit.com/Threading_Notes_(Papyrus) that protects an additem call with states.

I tried states, for another reason ;o) I will look again mate, thanks for that. Much appreciated.

[Jonny]

If you have a save set aside that hasn't seen mods yet, it isn't an issue to load that with your mod added to the mix. There seems to be some slight misunderstanding here that adding a mod to an existing game destroys it. That isn't the case for most mods. Only the ones that are poorly made and tested. OR the ones that were built before the CK cam out.

So long as your uncontaminated save never loads your mod, you should be fine. Assuming you haven't done other mod work that has modified vanilla scripts, but those would leak into testing no matter what.

It does no good to blame the scripters btw. We weren't at fault for designing a script engine that permanently attaches scripts to the save. We can only work with what we're given and adopt best practices while testing things to get it all working as smoothly as possible.