Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
The system saves a hero with with its stats and xp + gold, lumber. Its realy basic so every one can proberly understand it !
The problem with it is it dont work on BNET...
It works on singel player to 100%
I dont see why it dont work on BNET
I think it is like this ''BNET dont allow ''Game Caches''.
If some one can help me get this work. this way to save stuff for RPG will be so mutch easyer, couse you dont need a CODE !!! it saves on your user name
Many people came up with this idea before, but the reason so many complicated save/load systems exist is simple: Game Caches don't work in multiplayer.
At least: they don't store any data. In multiplayer, Game Caches are used to sync data rather than store it.
So you won't get it to work unless Blizzard decides to suddenly make Game Caches accessible for multiplayer as well (which could potentially ruin many systems that rely on game caches for syncing).
basically, in SP, game caches accepts data and saves them afterwards, but in MP games, it only accepts data but forgets them after the game finishes/closes...
that idea is not really epic, people (including me) have been using it for SP maps, blizzard used it for campaign transition, and Nestharus is already developing an MP save-load system that utilizes game caches for synching (I'm not sure if others have tried it before)
@ Adiktuz, since you are experienced in WC3 stuff,
I would like to know what is the meaning of data sync (ofc, not the dictionary meaning ) because I keep reading this word all over the site without really knowing its meaning.
AFAIK, it's the same as the normal data synching, you basically ensure that the data of each player is the same as the others, and fill out missing data too... and using GC for this makes things much easier as you can just save and save the data and load them without needing variables and such... you can even create multi-dimensional arrays using GC via concatenation of keys...
that's what I understood, not really sure though... you better off asking Nestharus or apoc... especially if you want to know about the I/O save-system that Nes is making...
and IDK about their speed, but caches are supposed to be the fastest (at least that's what I was thought at a very simple subject I had)...
syncing takes values local to a player and sends it to other players in the game so that they all have the value.
considet an integer i that is set to 5 for player 0 only via GetLocalPlayer. Using a gamecache, you store the value for that local player only, you sync using sync cache native, then you do a player select event to wait for the data in the cache to reach the other players in the game.
Preloader allows you to write files. When you have a certain wc3 registry value set to true, it can also read those files via running jass code inside of them; SetPlayerName.
The problem is that the data in the file is all local, so it needs to be sync'd. Those are the ideas of file i/o and data syncing for wc3
The cache is slow as it writes to the harddrive temporarily and uses hasing on strings + their hashed values. A hashtable is stored in RAM and deals directly with integers, making it much faster.
that is still something like what I explained [basically making the data the same for all players]... Nes' post just enlightened me about how they plan to achieve that...
that is still something like what I explained [basically making the data the same for all players]... Nes' post just enlightened me about how they plan to achieve that...
How could they describe it in even more detail?
It's perfectly elaborated and understandable.
Maybe you should get more knowledge about the things he is talking about,
not about how to archive the functionality itself.
How could they describe it in even more detail?
It's perfectly elaborated and understandable.
Maybe you should get more knowledge about the things he is talking about,
not about how to archive the functionality itself.
Sorry Anachron, but my understanding to this point of sync/desync is really vague.
[data that is local to a player] ? what kind of data I am really confused especially with what Neth said about having an integer i = 5, is that a local data or what ?
[data that is local to a player] ? what kind of data I am really confused especially with what Neth said about having an integer i = 5, is that a local data or what ?
local integer i = 0
if GetLocalPlayer() == Player(0) then // Only do things for Red's (Player 1 in GUI) game
set i = 5
endif
call BJDebugMsg( I2S(i) ) // This will show the value of i to all players (it will be 0 for everyone except for red).
JASS has a function called "GetLocalPlayer()", which enables the coder to do stuff for a single player only (only his computer).
If handled incorrectly, it can desync the game.
Example: you create a unit using the GetLocalPlayer-function. The game now has 2 versions: one where the unit exists (only for the local player) and one where it does not exist. This creates a desync and the game will split into 2 completely separate ones, the local player will now be in the game where the unit exists while all other players continue playing in the one where it does not exist.
To avoid things like that, we often set a variable locally and then do stuff with it (instead of doing it for the local player directly).
Now for Save/Load-systems, it is possible to write/read a file without the player having to do anything.
As you might imagine, this is an awesome discovery as it allows the game to save and load your hero(es) without ever needing a code (for Windows at least, I don't know if it works for Macs).
The problem here is the same as before: the data in these files are only for the local player, not for everyone else playing the game with you. If you would just let the game do its job, then there would be multiple versions of the game ( -> desync). We need to share this data with all other players so everyone has the same set of data and there is no conflict between the games.
I must admit though that I do not know how the game caches are able to sync this data.
Therefore, some of my information might be incorrect (I do apologize if that is the case).
No, I mean saving/loading with a command like "-save" and "-load".
True, the "-save" command may (and probably will) still be utilized, though it does not have to be (auto-save in certain area's or after certain events).
In nearly all ORGP's, you have to load your hero(es) with a code such as:
"-load AHXY-1234-HY&3-AHK8"
If you can write/read a local file, then this could potentially become unnecessary (read the second paragraph of my previous post).
This is what Reaver (the OP) wanted to achieve: a codeless save/load-system.
How can I do that, I though the game read the only files in the map file like the J file (an whatever variables it contains in the script) as well as the other files that you find when you open the map with an MPQ editor.
And those files that the save/load system can read/write contain all the data needed to save/load the game without having to save the game from the menu? WOW, if that is the case then that is very cool and handy indeed.
How can I do that, I though the game read the only files in the map file like the J file (an whatever variables it contains in the script) as well as the other files that you find when you open the map with an MPQ editor.
With a few tricks, you can create files on the players' hard drive which can also be read. I really don't know how the details of it work out, but Nestharus already mentioned this:
Preloader allows you to write files. When you have a certain wc3 registry value set to true, it can also read those files via running jass code inside of them; SetPlayerName.
Since Nes is the one who's been busy developing that system, he's the one holding all the information you seek. Here is the demo-system if you're interested, though it is not completed and shouldn't currently be used.
There is a native called PreloadGenEnd that takes a string argument. When this is called, it creates a file on the player's harddrive called the string argument. For example, PreloadGenEnd("hi.txt") creates hi.txt in the wc3 directory.
The Preload command is used to load this file up. It also takes a string argument. If you were to do Preload("I'm saying hi") and then do the PreloadGenEnd above, it would create a text fie with I'm saying hi in it.
You can't read these files directly, but you can run them. These files run both console commands (start -> run -> cmd) and JASS commands. What this means is that, in a way, you can store data into them and retrieve that data. How do you do this? Write SetPlayerName commands into them with the string data =).
For example, if you wanted to save 1234
call Preload("call SetPlayerName(player, 1234)")
The first line is always Preloader or something and the last line is always endfunction. Appending another function to the file (in this case AAA) makes the execution of the file faster for some reason.
Anyways, once the player names are set via preloading the JASS code in the file, you can just use GetPlayerName to get the data for each line : ). This limits 1 file to 15 lines though, but this is fine. You can have like an array of files ; P. The old File I/O thing I did had a file with a counter in it. It would create filenames like FILENAME_COUNTER. It'd first get that counter and then go over all of the files (FILENAME_1, FILENAME_2, etc, etc) and get the 15 lines (max 120 chars each line) out of each file.
For this save/load, you need 2 things
1. A Data Sync System (a very good one is up, just gotta debug it so that it's in working order)
2. A File I/O System (gotta write this still, the one up is crap and does crappy syncing + file i/o)
An encryption system using AES is recommended so that players don't tamper with the data. An MD5 checksum is also recommended.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
) because I keep reading this word all over the site without really knowing its meaning.
