You are here

Testing module without starting from beginning

7 posts / 0 new
Last post
andgalf
Testing module without starting from beginning

I have been thinking about this for a while and I suspect that there's no way around it...

When you test your module and play from the beginning and then maybe there is a bug, something you had forgot as a builder, like forgetting to place a waypoint or something...Is there anyway to save in the game and then correct the bug, and then continue to play with your saved game, without having to start from the beginning again? I've played NWN2 since the day it came out and from what I've heard there is no way around this, because somehow all the settings of all the areas and whatnot is saved in the save slot, so to speak. This is quite annoying I think. Sure, you can set a new start location in the toolset and try things out, that's the way I do it now, but it would really save alot of time if it were possible to start from a saved game after you have changed things... Maybe there is a way to edit the save file/save slot?

Thanks for your time!

  • up
    50%
  • down
    50%
Trinital

For testing purposes - this really comes down to good modular design. There should be nothing stopping you from playing the module starting from any random area - as long as you have the proper variables setup (which can be done very easily with a test trigger or command line)

 

  • up
    50%
  • down
    50%
andgalf

I'm not sure I follow what you mean here. How do you do a test trigger?

And it still doesn't answer my question...I think...or maybe it does...

What I needed to know was if I could continue with a saved game after I've corrected a bug (if I had for instance forgot to place a waypoint somewhere), and that when loading the samegame it doesn't remember the bug, but instead sees what I've corrected. I mean if one places things in the override folder that's no problem, you can remove or add things there, and the savegame adjust itself after that...but not when you do things in an area in the toolset for example. Then all that information is somehow stored in the savegame, so if I play my module for an hour and everything works fine, all of a sudden I see a mistake I made, I save the game, correct the misstake in the toolset, I can't continue with my savegame because in the savegame the misstake still exists. So is there a way around this?

  • up
    50%
  • down
    50%
kevL's

i'll just throw this out there ... it's more complicated than suggested, keeping things in synch between the module, the saved game, and the override files. But yes i've done it as follows:


The .Z file, as it turns out, is apparently a rather straightforward .Zip file. so unzip it. inside you get a "-" file: use Tani's Nwn2Packer to open it.

put your files in. Then use 7-Zip to turn the "-" file back to a .Z file. I simply right-clicked that file, chose 'To .zip' and then renamed the file to what it's supposed to be.

that could be one way to skin the proverbial cat. But it's sorta like using a blowtorch. Yer unlikely to be happy with the results, and the cat doesn't like it.


Instead you should design modules with an OnModuleLoad (or similar) script. It can have a "temporary stuff" section (that needs to be deleted before release). Voila, suddenly there's a way to spawn stuff, set variables, even change handlers for events ... simply by copying, modifying, and re-compiling that script to /Override. Builders may even hook such a script just to hot-patch things *after* release.

  • up
    50%
  • down
    50%
andgalf

Thanks for the replies!

Right now I have some standard script on OnModuleLoad called x2_mod_def_load

If I was good at scripting maybe I would use it to set variables like you said. As of now I'm terrible at scripting so I will try the other method which to me doesn't seem to be that complicated actually...we'll see.

  • up
    50%
  • down
    50%
kevL's

it might not be the steps that are complicated (although mind there are different algorithms that can be used for a .ZIP file*, maybe i got lucky by chosing the default one of the 7-Zip version which i used at the time...). The complicated bit is using a program like TlkEdit2 to figure out the difference between a .Gic and a .Git, etc. And realizing that game-play variables will change in those files when they get saved, but won't be changed when exporting those same files from the toolset .....


so you could end up with a mish-mash of (a) "well i got my waypoint now" and (b) "but why can't i open this door that requires such-and-such a variable before it can open?" This is to say, variables that get set as the plot progresses have to go in the saved files somewhere, and some of them might have been in the file you've just re-modified with the toolset ...

 

 

* note that's "zip" and not "7z"

  • up
    50%
  • down
    50%
andgalf

Ok. I see what you mean now. I will perhaps try it once or twice, but I will be careful when trying it out. Then I will know if it creates more problems than it solves.

  • up
    50%
  • down
    50%