Scenario code twice in savegame - Why?

[kurt751]

To playtest changes in my campaign, I usually edit a savegame and add/edit the new code in it. Much quicker than starting from scratch just because of a minor adjustment.
Doing this I noticed most scenario code exists in two copies, of which one is apparently inert (doesn't matter what I change in there).
How comes the scenario code exists in two copies?

[Dugi]

The first copy is how it was when the scenario was starting. The save files contain detailed information about the situation at scenario start, not only the scenario code but also information about units and variables.

The second copy is the actual information, containing the events that haven't fired yet, actual status of units and variables etc. If you are upset about scenario events bloating the scenario files, I can tell you about a trick how to get them out of the scenario start part.

[kurt751]

The first copy is how it was when the scenario was starting. The save files contain detailed information about the situation at scenario start, not only the scenario code but also information about units and variables.

The second copy is the actual information, containing the events that haven't fired yet, actual status of units and variables etc.

Why put the whole code in the second copy, and not just the modified variables (events and unit status)? Events which haven't fired yet can be looked up in the first part of the savegame, no need for a copy, or is there one? (I'm not a developer, by any stretch of imagination...)

If you are upset about scenario events bloating the scenario files, I can tell you about a trick how to get them out of the scenario start part.

Well, it's true I'm a little bothered with 2-3MB big savegames (uncompressed) when the information could had obviously been optimized a little; But then again the "everything but the kitchen sink" approach is quite helpful for editing/tweaking savegames.
Also, events aren't actually the biggest part of the savegame, as far as I understand what I see: The main space hogs seems to be unit descriptions and AI stuff (almost a third of the file for the AI stuff, or what I think is AI stuff (heaps of "[command][move][checkup][result]" thingies)).

I guess I can extract the events (at least some of them) and declare them as campaign macros, isn't it?
I'm indeed tempted to do this for a longish part which appears in each of the 9 scenarios, but I think doing it for the rest will just add complexity and (thus) bugs.

[Dugi]

Why put the whole code in the second copy, and not just the modified variables (events and unit status)?

Events that were removed disappear. Events can be also dynamically added and removed. It would be annoying to implement it in a way that events that were there from the start but have been removed were listed somewhere.
[quote="kurt751]I guess I can extract the events (at least some of them) and declare them as campaign macros, isn't it?[/quote]Macros help nothing. They just serve to hide long code. The code remains there, bloats save files and consumes memory.

You can avoid doing it in a different way. You can put all these events inside a unit type. In a prestart event, create the unit and kill it immediately afterwards. All the events will be inside it and the unit with humongous code will never appear in a save file. These events also won't be duplicated in the save file and there wouldn't be many copies of it inside the parsed scenario code in memory. If you need some arguments to these macros, set them as variables. It's convenient to put this variable setting and unit spawning and killing inside a macro (it would not need to be large, then).

[gfgtdf]

In 1.13 we actuall plan to change the code so that the events that are unchanged from the beginning have an id are not stored in every savefile and instead read form the [scenario] file if the sacenrio has require_download=yes (or was it require_scenario=yes ?). Instead the savefiles just stores dummy events like [event] id = <event_id> [/event] so that then the event with that id is then lookedup form the scneairo file. Not sure if we have time to implemet it naytime soon.

[kurt751]

Events that were removed disappear. Events can be also dynamically added and removed. It would be annoying to implement it in a way that events that were there from the start but have been removed were listed somewhere.

I have that nagging feeling that I'm missing something obvious. As I see the way the game works (non-developer, remember!), the scenario lists a number of condition-effect cases, and the game engine checks every now and then to see if one of those conditions is met. IMHO this doesn't require removing or adding stuff; Except maybe for the "first_time_only=yes" events, but for those a simple "active/inactive" flag would be enough, wouldn't it?

In a prestart event, create the unit and kill it immediately afterwards. All the events will be inside it and the unit with humongous code will never appear in a save file.

And where will the game find the necessary event informations if the container unit is gone?

These events also won't be duplicated in the save file and there wouldn't be many copies of it inside the parsed scenario code in memory. If you need some arguments to these macros, set them as variables. It's convenient to put this variable setting and unit spawning and killing inside a macro (it would not need to be large, then).

Well, I didn't understand everything yet, but this sounds like a hack to me. Wouldn't it be more efficient on the long term to just streamline the way the game handles those things, once and for all?
Just wondering.

[Dugi]

Let me explain it once again. These events of yours are identical in all scenarios, so you just put them into a unit_type, a unit that is specially made for that purpose. You create it, which places all the events into the 'current events' part of scenario. Then you kill it and those events remain there. This is some sort of inject-code-into-current-scenario operation. Yes, they are in the save file, but only once. They also appear only twice in memory (once in the unit type, once in current scenario), not once per scenario loaded plus once in current scenario.

Well, I didn't understand everything yet, but this sounds like a hack to me. Wouldn't it be more efficient on the long term to just streamline the way the game handles those things, once and for all?

Yes, but it would require massive changes in the game's deep bowels. It's usually recommended to do all this stuff in lua, WML wasn't designed for it, lua stays entirely out of save files and never keeps more than once instance of it. Also, its execution is like 100 times faster.

[kurt751]

In 1.13 we actuall plan to change the code so that the events that are unchanged from the beginning have an id are not stored in every savefile and instead read form the [scenario] file if the sacenrio has require_download=yes (or was it require_scenario=yes ?). Instead the savefiles just stores dummy events like [event] id = <event_id> [/event] so that then the event with that id is then lookedup form the scneairo file. Not sure if we have time to implemet it naytime soon.

Ah, that sounds more like it!

And for the units, wouldn't it be enough to only store in the savegame what has changed from the base unit type definition?
Initially it would be "max ("healthy") hitpoints", "traits/abilities", "name", "id", and the current status (current hp, remaining moves, remaining attacks). Then pretty soon "xp" would be added, and so on. At the end of a long campaign the list of changed attributes would most likely be quite long, but by leaving out everything that's unchanged from the base unit type you might economize a couple hundred lines easily. Even just leaving out the description texts would save a lot of space!...

[kurt751]

Yes, they are in the save file, but only once.

Okay, got it. That was the part I was missing. Thank you.

Yes, but it would require massive changes in the game's deep bowels. It's usually recommended to do all this stuff in lua, WML wasn't designed for it, lua stays entirely out of save files and never keeps more than once instance of it. Also, its execution is like 100 times faster.

Yes, yes, obviously. I was talking theoretically, since I have no idea how much time it would take in this specific situation.
What is this game written in? I would had guessed some flavor of C, isn't it?

[Dugi]

What is this game written in? I would had guessed some flavor of C, isn't it?

It's written in C++. Lua is used for deeper scripting because it's the standard for game scripting. It was added somewhere in wesnoth 1.7 in order to save players from having massive parts of code written in clunky WML.

[kurt751]

I see.

Thanks again for the "event unit" idea. I'll consider it, but given it's my first campaign and I think I'm already quite ambitious for a newbie (scripted events, custom units, (most likely) custom terrains, and all that), I'm not sure I want to add additional difficulty/work. I'm already happy everything works as intended...
There is also the translation; I could translate it myself to at least a couple languages (I'll do french & german I think), and there is finishing the unit graphics (make some, animate the others), draw title screens (pictures, not maps), so it's not like I'm about to finish anytime soon...
Jeez, I sometimes think I'm crazy to do that all by myself, it's not like I'm retired, having nothing else to do...

[Tad_Carlucci]

I'd suggest ignoring the turn save files whenever possible.

Editing them is such a bad idea on so many levels. But, at the top of the heap is that by doing it you're doubling your workload.

When I'm working on changes, I load the start of the scenario and use debug commands to fast-forward to where I want to look.

For example, if I want to test that the thieves appear on turn 16, I don't step through 15 turns. For initial testing, I simply ':throw turn 16' to see if '[event]name=turn 16' does what it's supposed to do. Or I jump to turn 15 (':turn 15') and play through to turn 16.

That way, I don't need to edit the save file, then, re-test when I'm done because I can never be sure the changes to the save file were the same as the changes to my master.

[Dugi]

I'd suggest ignoring the turn save files whenever possible.
Editing them is such a bad idea on so many levels. But, at the top of the heap is that by doing it you're doubling your workload.

No. This is very counterproductive.

Even if it's something as trivial as having some thieves appear in turn 15, it's often more efficient to edit turn 14 save file to fix the issue there and continue your play than to debug it using debug mode and restart the whole scenario. However, Kurt's case isn't so trivial.

If you're facing a complex problem, the situation rarely arises and restarting the scenario (after reloading the campaign) forces you to wait until that situation arises. If you know to locate the relevant location, all you have to do is to fix the WML in the save file (recompression = 2 seconds, reloading = 1 second, doing the stunt again = 2 seconds, usually faster even than reloading the campaign) and when it's fixed, you move the changes into your scenario code. It can save hours of fruitless drudgery.

Believe me, I am the guy who can write a relatively long campaign with non-trivial scenarios, long dialogues and cutscenes in 3 weeks.

[Tad_Carlucci]

when it's fixed, you move the changes into your scenario code.

There's the point-of-failure. You still need to re-test because you've finally changed the scenario code. Or did you? Maybe you copy-and-pasted an extra line? Or missed one? The only way to be sure is to run all your tests, again. So where's the time savings?

[Dugi]

There's the point-of-failure. You still need to re-test because you've finally changed the scenario code. Or did you? Maybe you copy-and-pasted an extra line? Or missed one? The only way to be sure is to run all your tests, again. So where's the time savings?

There is usually just one error. One change. Nothing to break. If you don't have a tendency to overuse macros, you can copy the whole block from the save file into the scenario and it will be fine.