18 réponses à ce sujet

[ColorsFade]

I'm running into a problem testing my module in a play-through. I find a bug, I want to fix it. I go into the toolkit and save the change (like adjusting a conversation or fixing a script). I compile, save, exit the toolkit. Then I go back to my save game and start again. None of my fixes work. 

Why is that? Can save games not be fixed? 

This is making it so that every time I encounter a game-breaking bug, I have to start over from the beginning of the campaign. How the hell do you test a campaign this way? I mean, it's fine for the first 30 minutes of gameplay. But what if you got a bug into the 30th hour of play? Who wants to start over from there? 

I have to be missing something... Because this CANNOT be the way the devs tested the OC. 

[Tchos]

All module resources are saved in the save game. Campaign resources are not. If you have all of your scripts and dialogues in your campaign folder, your fixes should work.

If they're in the module folder, you can just put the fixed copies in your campaign folder or in your override folder.

[andysks]

The folders override each other. Module-Campaign-Override-Hak. I think this is the order, forgive me if I'm wrong. If I have a dialogue in a module with a bug, I put the correction in the campaign, as Tchos said.
I use campaign folder for convos of the main quest, since I might need them later. I also use it for scripts that are useful more than one time. But generally I use the module folder, at least in the beginning, so that I have space for overriding the problems.

However, I also encountered some problems related to this. Sometimes it seemed that once a module is loaded, I couldn't change some things in it. Areas already visited for example.

When PJ was testing for me, he encountered a problem on a convo. Until then, I thought that when a convo fires, no changes were possible. But he said to me that, he opened it in the toolset, and tweaked it a bit and then it worked, for he put it in the campaign folder . Epiphany !

[Tchos]

andysks wrote...
Sometimes it seemed that once a module is loaded, I couldn't change some things in it. Areas already visited for example.

You can actually change areas already visited in many ways if you do it
by script, and not by opening up the area in the toolset.

[andysks]

How do you mean? I just need to state here that my areas rarely have an OnClientEnter event, since I am not a so experienced scripter. Only when I need something really special I use it (spawn companions for example). Therefore all my stuff are placed and not spawned. Maybe one day I'll learn how. In any case, I think this could be a reason for it.

[andysks]

I do the same, but sometimes you need to see the flow and realize something didn't work out too well. I mainly test cutscenes the moment I create them, also new scripts and so on.
Use the script thing, for example there is a local variable on an NPC node called "something". The variable tells it to fire only when it is 0, but then it is set to one, and something went wrong.
I open the console and type rs ga_local_int("something",0,oPC), and the node will fire again after the convo is fixed, no matter where I saved in the playthrough?

[ColorsFade]

Iveforgotmypassword wrote...

I test modules in bits as I make them, all you have to do is keep changing the start area/waypoint, then by using a save I can jump the whole party from where I left them at the end of the previous module to any part of the new one. If vital stuff's happened I stick in an npc with a conversation at the new start point then delete him/her later.

I test modules in bit as well, with a script so I don't have to keep movig the starting waypoint (thus my test script just jumps me to the appropriate module and area, with a known waypoint, or a test waypoint I laid down). I have a pretty elaborate test script so all I have to type is rs x_plot(number) and it will do all the necessary work (journal settings, adding group members, equipping them appropriately for the level, etc). 

Problem is, stuff changes over time, especially in this prologue as I was learning the toolset and figuring out the "best way" to do something. Some older stuff that had already been tested and worked was now broken. Some of it was minor, but if it is a major thing then that's a problem. 

I'll have to figure out if I wanted to move stuff to the campaign folder or not... I have some conversations and scripts there. But others, that were specific to a module, got left in the module. For "fixing" purposes it seems to make more sense to put those in the campaign folder I guess. 

Thanks guys. 

[ColorsFade]

andysks wrote...

I do the same, but sometimes you need to see the flow and realize something didn't work out too well. I mainly test cutscenes the moment I create them, also new scripts and so on.
Use the script thing, for example there is a local variable on an NPC node called "something". The variable tells it to fire only when it is 0, but then it is set to one, and something went wrong.
I open the console and type rs ga_local_int("something",0,oPC), and the node will fire again after the convo is fixed, no matter where I saved in the playthrough?

I test every cut-scene the moment I create it (and it usualy takes me several passes to get it just right). Same with an area encounter. I'll test the crap out of it to make sure it isn't too difficult. 

But I wanted to do a complete playthrough of the prologue to get the "flow" and see if it felt right (and to use a stopwatch and time it to see how many hours of gameplay it is). 

I found a few broken things. One encounter was way too hard. I must have lucked through it the first few times I tested it, because in actual gameplay I couldn't beat it. About the 8th time I failed I decided it needed to be reworked. 

Most of the other issues were with cut-scenes failing. One node failed due to a wrong integer setting in a gc_journal_entry check. Another conversation failed altogether because the library I wrote that the script calls had changed since it was first written. 

One thing I'm figuring out is, once something is tested and finished, I should really leave it alone. As a programmer, I tend to want to optimize stuff once I find a "better way" to do something. But in this engine, the way it's designed, once it's working I should just leave it alone... and if I do change something, it all needs to be re-tested. 

Still, it's working. I'm a little over an hour and 15 minutes into the prologue and there's a lot left to go, so content-wise it's where I was hoping it would be. And it flows well. The pacing seems good. We'll see how many more bugs there are along the way....

[Tchos]

andysks wrote...
How do you mean? I just need to state here that my areas rarely have an OnClientEnter event, since I am not a so experienced scripter. Only when I need something really special I use it (spawn companions for example). Therefore all my stuff are placed and not spawned. Maybe one day I'll learn how. In any case, I think this could be a reason for it.

I can explain more fully later and elsewhere (it's a big topic), but it's possible even without having an On Client Enter script (though it would be more convenient that way).  It's a bit off-topic here.  I will say, however, that for any area script slots that are empty, you should put fake names into them, for future contingencies.  It won't hurt to have scripts in there that don't exist.

[andysks]

Colors : Have you installed the module testing kit, or MTT? It allows for some really good testing, including an insta kill or resurrect. So, for example on the super hard encounter, you try to do it "legally", but when you see it can't be passed you hit insta kill and note down to nerf it. It is really good, helped me a lot.

Tchos: Should I expect a pm about these stuff ?

[Tchos]

No, I'll make a public thread for it, and perhaps others can also elaborate on some of their approaches.

[ColorsFade]

andysks wrote...

Colors : Have you installed the module testing kit, or MTT? It allows for some really good testing, including an insta kill or resurrect. So, for example on the super hard encounter, you try to do it "legally", but when you see it can't be passed you hit insta kill and note down to nerf it. It is really good, helped me a lot.

Yeah, I haven't got around to installing that yet. I had briefly looked at it. 

If I would have been 30 hours into gameplay when I hit this encounter, I would have just wrote a script in the campaign folder and executed it with the console to kill the buggers. And then, like you said, nerf it later. 

I find I have to nerf my encounters a lot. Which is okay; I'd rather put too many critters in there and have to nerf it rather than not have enough. It's easy to delete spawn points... 

I'm actually pretty happy with my current test framework. I'm just not pleased with my own personal dilligence in testing. There were some things I should have gone back and tested again when I knew changes I was making may retroactively affect certain things. I just got impatient. I got tired of building and wanted to play the thing

Moving all the conversations and scripts to campaign seems like the solution that will work best for me. Because 99% of the time, what I'm finding is that the broken stuff is almost always a conversation or a script. And I know when stuff is going to happen, so I'm really good about saving right before an event. But when the changes didn't stick after reloading the save, I was kinda stumped. Now I understand... module level stuff is saved with the save game. So I'll rework my file strategy. 

@Tchos: feel free to derail the thread. It's a pertinent conversation actually. 

@Andy: Tchos script mechanism is actually pretty simple to understand. It basically works like this: 


Short answer: You put scripts in all the script spots for an area, even if you are NOT going to use them. These just need to have an empty main() method. That's it. So, for every area, you have custom scripts that do nothing. Custom OnClientEnter, custom OnAreaHeartbeat, etc. If you have an area named ForestRuins, you have cient_enter_forest_ruins, client_enter_hb, etc. These scripts just do nothing. They have a blank main() method. 

The key is - you have put them in the area as soon as you created it, so you can use them down the road if you need to, to dynamically add content to an area without having to open the toolset and place stuff. This means you can affect an area that could normally not be changed due to it being saved with the save game. 

Let's say you have an area you want to affect a change in, but you don't want to open the toolset to make a change. You want to do it dynamically through a script. Let's say for the sake of simplicity you want to add a creature to an area at a very specific spot, because you want to introduce a conversation, or something. 

Now, if you already have an existing OnClientEnter script for the area that does some spawning, it's easy: you can add the change in that script, and when the player zones in, the code spawns the new creature (provided it's a Campaign script, or in override). 

But let's say you dont' use an OnClientEnter script for an area. What Tchos is saying is that you should still create a BLANK OnClientEnter script for the area. So let's say you have an area called ForestRuins. It has no OnClientEnter script when you start building it. That's fine - make an OnClientEnter script anyway and just leave it with a blank main() function. 

Now, someday down the road you want to add that creature to that area. People are already playing your mod and have save games, and you want to add that creature. Well, you were smart and provided a blank client_enter_forest_ruins script for that area. So now you go into that script and instead of it being a blank main() method, you add the code to create the creature. You can pick a waypoint, or a specific location with x/y/z coordinates, and you spawn the creature. In this way, a save game can be affected. 

It's how Tchos intends to add content after release, but it could be a lifesaver in other ways (he's had issues with his toolset not allowing him to open his main area; this allows him to keep adding content). 

It's a very dynamic, script-based way to add stuff to an existing area. It just takes a little thinking ahead is all, to ensure you put blank scripts in those spots. (Well, they're not blank; they just have empty main() methods)

[andysks]

I got it . Thanks for the info. I also had a problem with an area not opening, at least not after a dozen tries. I can see how this method could be useful. And just try MTT, you won't regret it .

Also, I know how it feels. I even sent a version to two people for testing, even though I knew bugs were plenty. I guess sometimes we need to see and hear actual progress, playing the thing, instead of just placing placeables that look nice, and checking the area as complete on the excel sheet .

[Tchos]

Actually, I'm not even saying to make scripts with blank main functions. The script doesn't have to actually exist, and you can create one with that name only later, and only if you need it. The game will just ignore missing scripts and move on.

[kevL]

Tchos wrote...

Actually, I'm not even saying to make scripts with blank main functions. The script doesn't have to actually exist, and you can create one with that name only later, and only if you need it. The game will just ignore missing scripts and move on.

doesn't that get problematic, when you click on a field with the name of a script that doesn't exist?

sometimes they disappear and i'm like, "oh ***"

Modifié par kevL, 02 décembre 2013 - 06:04 .

[Tchos]

That only happens if you click on the list box to browse the list of scripts, when the script in the slot doesn't actually exist. If you're not sure that it exists or not, and you're doing it because you want to see what the script does, you could instead just open it from the script palette or some other way (and if it's not there, then you know it's a dummy script).

Also, I keep a list of all scripts I have assigned to my areas, whether they exist or not.

Modifié par Tchos, 02 décembre 2013 - 06:11 .