I want to add -save and -load commands

[Aphystic]

So pretty much what the title says, an easy explanation of how to add -save and -load commands into my orpg homemade map. I find the other instructions I've found very hard to understand. Please #Confused.

 

[Death Adder]

afaik the code is a huge number which represents all the stuff you want to "save/load" show as letters (basically like with colour codes), one part of this is the same thing but for the username so you can't just steal other peoples "saves" since they're not actual "saves" but just codes that you could technically enter without ever saving once.

At least that's the general idea of it, I'm by no means an expert.

As for actually implementing it, I'm assuming there's several systems for this in the spell section and supposedly there's even a codeless one. They should probably have instructions so I'd suggest looking around a bit.

Hope I helped, at least a bit.

 

[Zwiebelchen]

My advice is to concentrate on other stuff first, until you have accumulated enough mapping and triggering skill to understand these instructions.

Most Save/Load systems sport a very detailed instruction manual. If you have trouble following those, then you simply need more general triggering experience first.

You don't learn to drive before you learn to walk.

 

[BeeszBuzz]

So pretty much what the title says, an easy explanation of how to add -save and -load commands into my orpg homemade map. I find the other instructions I've found very hard to understand. Please #Confused.

If you're like me, you'll want to finish your project first, make it fun with even the lowest graphics in spells and unit models. In fact, take it through the bunny test, change every model to a bunny and play it through as a bunny. If it is still fun, then it is worth a save/load system

 

[Nestharus]

Uh, so I'm going to actually answer your question because giving a reply that isn't answering your actual question is something I find to be rather annoying : P. My favorite response is "why do you need this?" - . -


A good save/load system is not an actual save/load system. It's more of a collection of templates and tutorials. From these templates and tutorials, you put together your own save/load system. This is why they require a bit of experience. Now certainly, there are bad ones out there that are actual systems, but they aren't going to work as well as a good one : P.

Indeed, a save/load code is nothing but a gigantic number. What you do is you mash all of your values together into a single giant value.

If you think of the number 172, it's 3 digits, right? Well, each digit could very well be its own value.

1, 7, 2

How do we combine those into one number?

1*10 + 7 = 17
17*10 + 2 = 172

Now, it's a little bit more complicated than this, but that's how save/load systems work. You need a special system in order to handle very large numbers. Division is especially painful : ).

Besides just cramming numbers together, save/load systems also deal with encryption, hashing, code uniqueness to a player, versioning, and catalogs. It's all about keeping the codes as small as possible and as secure as possible.

Encryption scrambles the code up so that it's a garbly mess. If you try to read the values out, you will get nothing but junk. Sure, you can still get the values, but something else prevents the code from actually validating.

Hashing is like a unique signature to the code One popular hashing algorithm is MD5, which is used to ensure that files on your computer are not corrupt. The hash is another value that is calculated from your code and then inserted into the code. Once you insert the hash, you perform encryption so that the hash is all mixed up in the code. You have to decrypt the code correctly in order to compute the same hash again when you are doing loading. Furthermore, because it's all scrambled up, if you try to change anything, you will get hashes that aren't equal. Encryption + Hashing is how to protect your code.

One technique I like to use to ensure code uniqueness is to use the player's name and some other stuff as the key when I encrypt the code. This means that if any other players tries to load it, they'll decrypt it wrong and got an invalid code back.

Next we have versioning. Versioning is used when you want different versions of your code. For example, you add 3 new items to the map or some new thing to save. Without a versioning system, you won't be able to read older codes because you'll be trying to read values that aren't there (or vice versa). All you do is add a version value to the code and you're set. I like to do something special to make this version value as small as possible : ). The version value will tell you which loader to use so that you read the code correctly. You will always only have 1 saver because you'll always want to save in the latest format.

The final thing are catalogs. Catalogs are where you put all of your data. They're sorta like databases, but they aren't. Catalogs can have several filters applied on top of them in order to get the smallest data sets possible. Here is an example.

Let's say you have a catalog that holds all of the items in your map. You have level requirements for items. The hero is level 10. When you get items from that catalog for saving, do you really want to get items that are above level 10? You don't. This will reduce the data set, thus reducing the size of your code.

Anyways, that's kind of a run-down of everything you need to know about using save/load. At this point, you'd need to design your catalogs, decide between version'd save/load or non-version'd save/load, and load all of your catalogs with data. You'll also have to figure out whether some values can use lossy compression or not. For example, you might want to save player health. Do you really need the exact value? Maybe +/- 32 health is good enough. It'll save you quite a lot of space.


Uhm, let me link you kind of the gold standard of save/load. It includes all of the tutorials + catalog types you can use. From here, you can decide which catalogs you need + how many and then organize all of your data into them. It includes several other nice little helper things too, like saving abilities and inventories. Of course, for each specific thing you save, you're going to have to figure out what method will work best for your particular map.

https://github.com/nestharus/JASS/blob/master/jass/Systems/SaveLoad/Save and Load With Snippets.w3x

This is an interactive tutorial that teaches you a lot about save/load. You just run this map in Warcraft 3. Each lesson is very short. There are practice problems, labs, and so on =). This is the tutorial that a lot of people in the Warcraft 3 community use when they want to learn how save/load works. This is why a lot more people understand save/load pretty well now as compared to before =D. This will also help you really understand the pros/cons of each save/load resource when you are trying to decide which one to use. For simpler maps, a resource like Acehart's is perfectly reasonable =).

https://github.com/nestharus/JASS/b...teractive Saving and Loading Tutorial (1).w3m

 

[Daffa]

http://www.hiveworkshop.com/forums/...0-2-a-177395/?prev=search=CodeGen&d=list&r=20

 

[Dr Super Good]

one part of this is the same thing but for the username so you can't just steal other peoples "saves" since they're not actual "saves" but just codes that you could technically enter without ever saving once.

You never save the user name as part of the code. Instead you use the case insensitive user name as part of a key. The user name key can be part of the hash or be used to modify the encryption key. The result is that you deal with two problems at once, both protecting the code from modification and name locking it.

One technique I like to use to ensure code uniqueness is to use the player's name and some other stuff as the key when I encrypt the code. This means that if any other players tries to load it, they'll decrypt it wrong and got an invalid code back.

The other approach is to use it as part of the hash. You can even do both although modifying the encryption key is probably the better of the two (unique codes between players) and is good enough by itself.

How do we combine those into one number?

1*10 + 7 = 17
17*10 + 2 = 172

Now, it's a little bit more complicated than this, but that's how save/load systems work. You need a special system in order to handle very large numbers. Division is especially painful : ).

This is how to produce optimum codes at the cost of extra runtime overhead doing the highly complicated long multiplication and divisions required.

Logically it is far simpler to use powers of two for the size of numbers. A vector of bits can deal with this and inserting elements into it becomes highly efficient and a matter of bitwise shifts and masking. This may or may not be more efficient in WC3 due to the lack of native bitwise operators for the integer type however in StarCraft II it will likely be orders of magnitude faster. The resulting bit vector is perfect to feed into standard hashing and encryption algorithms.

Next we have versioning. Versioning is used when you want different versions of your code. For example, you add 3 new items to the map or some new thing to save. Without a versioning system, you won't be able to read older codes because you'll be trying to read values that aren't there (or vice versa). All you do is add a version value to the code and you're set. I like to do something special to make this version value as small as possible : ). The version value will tell you which loader to use so that you read the code correctly. You will always only have 1 saver because you'll always want to save in the latest format.

A hacky approach is to use the same load function with conditional statements to change the values loaded. In theory this degrades load performance as the number of versions increase however this should not really matter.

 

[Zwiebelchen]

You never save the user name as part of the code. Instead you use the case insensitive user name as part of a key. The user name key can be part of the hash or be used to modify the encryption key. The result is that you deal with two problems at once, both protecting the code from modification and name locking it.


The other approach is to use it as part of the hash. You can even do both although modifying the encryption key is probably the better of the two (unique codes between players) and is good enough by itself.


This is how to produce optimum codes at the cost of extra runtime overhead doing the highly complicated long multiplication and divisions required.

Logically it is far simpler to use powers of two for the size of numbers. A vector of bits can deal with this and inserting elements into it becomes highly efficient and a matter of bitwise shifts and masking. This may or may not be more efficient in WC3 due to the lack of native bitwise operators for the integer type however in StarCraft II it will likely be orders of magnitude faster. The resulting bit vector is perfect to feed into standard hashing and encryption algorithms.


A hacky approach is to use the same load function with conditional statements to change the values loaded. In theory this degrades load performance as the number of versions increase however this should not really matter.

All this would be super helpful information if this was The Lab. But this thread was made by a user who probably uses GUI and is probably a beginner to coding in general.