Posts from Data transfer from one map to another between any maps Auto-translated

Basically, I tried to create a campaign with more than 5 missions.
I have to do it through regular maps, but the inability to carry over data is very limiting.
I googled on various sites and found that you used to be able to do print_to directly into a file, but as it turns out, this feature was removed long ago.
I couldn't think of anything better than adding a function to the game code myself.
I hooked where the game calls the regular print to the console and assembled a simple DLL that intercepts them and saves exactly what I need into a file.
To make everything transfer automatically to subsequent missions, I write script functions directly into a LUA file, which can then be loaded in the next map (campaign mission) via a simple doFile().

Example of transferring data from one map to another.
The video shows how the Attack and Defense stats of hero Vittorio are transferred between missions. (thrown together quickly from scrap in 0.00001 nanosec)
Saving to the file occurs when the blue player's hero is killed. (but essentially, this can be written into any trigger, absolutely any)

https://www.youtube.com/watch?v=2icBCpRaBp4


If this idea is developed further, it's theoretically possible to transfer any information to other maps on the fly.
Everything can be downloaded and tried in the attachment. The DLL source is compiled via MINGW GCC, but MS VS might swallow it too.

Pros
1) Obviously, this method allows creating campaigns with more than 5 missions simply by transferring info between maps (or between several campaigns, if needed)
2) You can choose which information to transfer—not like in a regular campaign from the map editor; for example, you can transfer only one specific stat, skill, artifact, or even an army.
3) Transfer info for more than 5 heroes.
4) There are probably others, but I haven't thought of them yet.
Cons
1) Right now it's all hardcoded in the DLL; perhaps someone can suggest a better way to automate and simplify this so that even people unable to compile a DLL can use it.
2) I have to manually write print for almost every stat value, as the text output is what's hooked in the DLL. It doesn't catch something like print("ATAK=",A), only a regular print.
3) ChangeHeroStat specifically adds stats rather than setting values, so currently I have to subtract the original value and then add the new one.
4) There are probably others, but I haven't thought of them yet.

Question:
Does anyone have a method or script on how exactly to set stat values instead of adding them as in ChangeHeroStat?

These are very good findings! I need to sit down and think about the information you provided. Maybe we can find a way to simplify this method to make it more accessible.

I don't know how feasible this is:
1) Create a separate application where, by means of checkboxes, for example, you can specify what information needs to be saved and in which mission/chapter (for example, save the hero's progression and army in chapter 1, and something else in chapter 2). And save the selected settings to a file, for example, in the form of an 'ini' or 'xml' file.
2) Parse the file with the saved settings from the Dll, and substitute the necessary data for transferring into the function that will create the script.

I found where the game calls the regular print function to the console and created a simple DLL that intercepts these calls and saves the output to a file, which is exactly what I needed.

I want to express my sincere appreciation for the excellent work you are doing. Thank you!

Cool stuff

Wow, this is awesome! You can set the stats as delta-default (subtract the initial value from the delta), but I see you already know that. By the way, I want to mention that data (numbers and strings, as well as functions for the parser) can be passed between scenarios using SetGameVar, and teleportation to new missions can be done automatically using WarpToMap.

I saw you mentioned on YouTube, "It would be great if data from the map file (map.xdb), such as the position of objects at the end of the game, could be saved and loaded."
In theory, any information that can be accessed through scripts and outputted using "print" can be remembered, and then set again using scripts. But as I understand it, "SetGameVar" can also do this, right?
And what exactly is meant by the position of objects? Where the hero was standing? In theory, you can find out its coordinates through locations and teleport it using "SetObjectPosition." Or does this not work for heroes? And for other objects, like resources, you can probably also find out if they have been picked up, right? I think I saw "GetObjectsInRegion" in the manual. Of course, it turns out to be a complicated process, but is it theoretically possible?

By the way, do "SetGameVar" and "WarpToMap" also work in campaigns, or only in standard missions?
So, it seems I wasted my time creating my own DLL, since there was already a way to do this.

Regarding setting stats, is "delta-default" the only solution? I thought there should be a more "normal" way. It seems like the developers didn't finish the scripting API, or rather, they broke it for some reason, because I read that in older versions, "ChangeStat" used to set values normally, instead of adding to them. It's strange that after changing this function, the developers didn't add something like "SetStat."

You can find the coordinates of objects on the map, but then you would have to name them all.
Essentially, what I want is a utopian idea of completely transferring map information into a script (for constant movement between locations, like in Stalker).

Unfortunately, SetGameVar transfers data between sequentially launched scenarios, as well as between campaign missions (this is how artifact transfer is organized). But you didn't write the DLL for nothing; I'm sure it has a wider application. Is it possible to save tables? That would be amazing: it's impossible to transfer complex n-dimensional tables using SetGameVar.

Regarding stats, I think that's how it is, unfortunately.