Discussion So what's your favorite save/load system and why? : )

Nestharus

o-o
Reaction score
84
Do you like Acehart's because it is easy to use and is very GUI friendly?

Do you like Pipedream's because it produces small codes?

Do you like CodeGen because it doesn't use vjass?

Do you like iGen because it is easy to use?

Do you like Encoder because it is the most flexible?


What do you think is most important in a save/load system?

Ease of use?
GUI friendly?
Absolutely smallest codes possible?
Ability to save absolutely anything, even full scale objects?
Security?


Do you think that 24 hours spent implementing a save/load system to produce codes 33% to 84% smaller than an original code is time well spent?

Do you think that spending 12 hours to produce a code that is only 33% smaller (no range) is time better spent?

Do you think just using an easier system to produce a code of a larger size is best as it gives you time to focus on other things?
 

Weep

Godspeed to the sound of the pounding
Reaction score
401
I don't have a favorite; I've never used save/load systems*. ;)

If I were to choose, I would probably prioritize low maintenance and low end-user difficulty. In other words, I want to not have to modify any code if I add new objects (eg. not update a catalog if I make a new item or quest line), and want a code which is reasonably short (a subjective measure).

*I recently used BigInt to shorten some data by converting from 144-digit b13 to b82, since I don't need security, but I'm wondering if there's a way to compress it further, since there is the potential for lots of repetition. I don't need a fancy catalog or scrambling, just compression (deflation?). Have you made such a resource?
 

Nestharus

o-o
Reaction score
84
There are a few ways, but I haven't implemented any of them..

The best type of compression is when you have specific patterns. For example, if you know that there is a 87% chance that the next digit will be a 7 and a 13% chance that it will be a 6, you can drop it and assume that it's a 7 =).

No real way to compress totally random data.. The stuff I did with shifting and the norm catalogs are about the only way to do it for wc3 given the size of codes. You can use huffman, but that would actually end up increasing the code size since the codes are so small : |.


This should prove helpful, but only useful if you can sort the data (maximize repetition)- http://www.oocities.org/hmaxf_urlcr/vbc.htm


http://en.wikipedia.org/wiki/Statistical_Lempel_Ziv
http://en.wikipedia.org/wiki/Lempel–Ziv–Markov_chain_algorithm


Now, once you do a bit of research, you should see why general compression techniques are impossible in wc3.

Try to compress a .txt file with 10 characters in it using winzip. If you add it to a winzip archive, the file will end up getting bigger. Why? Because of all of the extra data needed to store huffman trees.

The more random the data is, the more difficult it is to compress. This is why many experts regard it as impossible to compress random data =P.

edit
Also, simple base conversion doesn't actually shorten the length of data. The data is still the exact same. The stuff Encoder does actually does shorten the length of data (range shifting). Catalogs actually shorten the length of data (more compression). Also you can use links so that useless information doesn't get saved into a code. For example, a max lvl character doesn't need their xp saved =P.
 

Lyerae

I keep popping up on this site from time to time.
Reaction score
105
I would say yours, 'cause I have your messenger info, so I can bitch at you if it doesn't work right. :p
 

Narks

Vastly intelligent whale-like being from the stars
Reaction score
90
-.-"

you know, it's considered impolite to go around announcing your system is the best everywhere (even if it may be)
 

Nestharus

o-o
Reaction score
84
-.-"

you know, it's considered impolite to go around announcing your system is the best everywhere (even if it may be)

where did I say that here? For ease of use and GUI friendly, mine is by far the worst, and Weep considers those 2 things more important, making Pipedream's a better choice for him.
 

muzzel

New Member
Reaction score
1
i like Pipedreams, it creates small codes and still is very fast compared to other systems (with Kode we even reached the op limit im some cases).
 

Romek

Super Moderator
Reaction score
963
I'd make my own save/load systems specifically catered to the maps that need it, so it'd be quite literally unbeatable in all aspects. :p

Also, in that list you provided, all of those 'reasons' are things people actually care about, except the one you gave your system. What exactly is a save/load system that is 'powerful', if it isn't one that specifically produces short codes, is easy to use, or is GUI friendly (or doesn't use vJass for a few users with specific needs)?
 

Nestharus

o-o
Reaction score
84
I guess I meant flexibility to produce minimal save/load codes at the cost of ease of use (remember that I spent 24 hours implementing it into a map to produce the best save/load code possible) =P.

->Do you think that 24 hours spent implementing a save/load system to produce codes 33% to 84% smaller than an original code is time well spent?

lol... yea, those numbers came from direct experience =P


But it seems that a pretty good sized save/load code, like the one by Pipedream's, with ease of use, like Pipe's is, is most important to most users =), so I'm expecting a lot of people will like Pipedream's the most for being both easy to use and producing pretty good save/load codes =).

Also, from what I've seen, only maps with very special data should have save/load systems built for them. This means that 99% of maps (since I've only seen one like this) would have just as good a code on Encoder w/ less the time (if people are willing to invest). You could also have a code that's just about as good in a fraction of the time using Pipedream's (much more appealing to most ^_^).
 

Nestharus

o-o
Reaction score
84
Building a tree based frame for a save/load object will be much more flexible than building a list based frame =p. However, tree based frames, while being more flexible, take more time to build. Also, this means that you have the power to really build insane catalogs, which then adds way more complexity to the code and makes everything take way longer to do.

A tree based structure is the ultimate flexibility for save/load, but that flexibility leads to the ultimate complexity =P.

So yea, simple catalogs means a lot less time spent on the code. Simple list based structure also means a lot less time spent on the code.


So each save/load system has its pros and cons. I would think that Pipedream's is probably the most time efficient option (pretty good codes and low time to make them) while Encoder is the least efficient (minimal sized codes but ridiculous period of time to make them).

It's like comparing a php website to a c# or java website. Php websites are pretty good and take a lot less time to do and are way cheaper to do. a c# or java website is excellent but take way more time and money to do =|.

Pipedream's would be like the php of save/load, acehart's etc like the ruby on rails of save/load, and encoder like the c#/java of save/load.

It could also be compare to operating systems. Pipedream's would be windows and encoder would be Linux.
 

Romek

Super Moderator
Reaction score
963
> would have just as good a code on Encoder w/ less the time
I'm positive it takes less than 24 full hours to code a specialized system for a map. No need to worry about compatibility and configuration issues, which is the main setback that full systems face. I'd also get maximum optimization in terms of code size (for example storing hero level and 2 booleans in base-40 as a single character, or using the remaining 'space' in a few characters to squeeze in another piece of data).

Not that I believe it took you 24 hours to implement a system. That's actually quite scary considering you built the system and know exactly what to do and how to configure it. Other people would first need to figure all that out before implementing it. :eek:

Edit: Also, security is overrated. Nobody's going to be messing with the save code itself. If anything, they'll just open the map and use it to generate a code that saves exactly what they want (which could even be done as simply as placing a hero in the map, setting its stats, levels and items, and running the map and getting a code through the game itself - completely avoiding JASS code altogether).
 

Bribe

vJass errors are legion
Reaction score
67
Is there a way to detect if the game is being played on battle.net? If so it could detect against a player cheating his way through with greedisgood or whosyourdaddy codes.
 

Nestharus

o-o
Reaction score
84
I'm positive it takes less than 24 full hours to code a specialized system for a map. No need to worry about compatibility and configuration issues, which is the main setback that full systems face. I'd also get maximum optimization in terms of code size (for example storing hero level and 2 booleans in base-40 as a single character, or using the remaining 'space' in a few characters to squeeze in another piece of data).

Not that I believe it took you 24 hours to implement a system. That's actually quite scary considering you built the system and know exactly what to do and how to configure it. Other people would first need to figure all that out before implementing it.

The time I spent on the actual Encoder object, the save/load portion, was very little. In fact, it might have only been 10 minutes at most, and that was me looking into new algorithms I hadn't previously thought of.

The time spent on the catalogs, which has nothing to do with a save/load system (if you look inside of the implementation, you will see that the implementation, not the save/load system, uses the catalogs) was almost 24 hours.

I coded the initial simplified version, 23 characters long (simplified meaning simple catalogs) in maybe 45 minutes, and again most of the time spent doing that was looking through the GUI to collect all of the data from the map. The actual Encoder object took maybe 5 minutes to build.

The advanced version took longer because I investigated 2 new algorithms that I previously hadn't thought about, which involves linking things to things while those things exist-

item.link(1,itemCount,item,0)

This will link an item to an item for all eternity so long as an item is written to the DataBuffer
item -> item -> item -> item -> item -> item -> item

Notice that the range is 1 to itemCount, meaning the range filter takes all existing item ids. The minute a 0 is plugged in, the link stops. In this way, incomplete inventories can actually be saved in smaller spaces. For example, if only 1 item was present in the inventory, only 2 slots needed to be saved. If 6 items were present, all 6 slots were saved. The variation on the above link for saving inventories linked 6 different item ranges together-
item1 -> item2 -> item3 -> item4 -> item5 -> item6

This way, the end always terminates (6 items take up 6 slots, not 7).

The other new approach I took was level and xp. I realized that not all levels needed their xp values saved. More specifically, the highest level in the map doesn't need xp as it is always at 100% xp.

Now certainly you can code all of this in a specialized system, but you will end up getting the exact same output as Encoder in the best circumstances of entirely random data.

In the case where data is not random but has patterns to it, then a save/load system tailored to it would beat out Encoder. Have you ever seen a map like that? I know I haven't.


So with this presentation, I showed that the complexity in save/load lies with the catalogs, not with the save/load process itself. The save/load process with Encoder is actually very simple, hence why I coded the encoder object so quickly.

The process of building an entire save/load system from scratch can only ever top Encoder when the data has patterns to it.

So it is actually faster to use Encoder for the absolute best save/load codes possible for an arbitrary set of data. It is only slightly slower to use than a system like Pipedream's (5 mins of code vs a few seconds of code).

The complexity lies in the catalogs. If you were to take the tree based structure to its full advantage by saving things like remaining item charges, hero specific items, and hero specific abilities, you can be sure that the catalogs are going to be extremely complicated as compared to a simple array with Pipedream's. In this way, Encoder only takes a little bit longer than Pipedream's to set up when dealing with the same data. It's when you get to very complex codes, like the one I did for Pearl East Kingdom, that Encoder can take a much longer time to set up as compared to Pipedream's.

I actually got some data comparing the save/load systems for a semi-complex code.

Map info-
100 items
255 max stat
1000000 max gold
100 biggest possible item charge
100 heroes

Save/Load code characters- 72 (a-z, A-Z, 0-9) alpha numeric

Code-
6 items w/ item charge, gold, 7 stats, 1 hero

Code Estimates With 0 Security

Acehart/CodeGen- 42
Pipedream- 27
Encoder- 15-27

Code:
ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZ

Pipedream
ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZ

Encoder
(keep in mind that the code will rarely be at either edge, but will rather normally stay somewhere in the middle)
(this means that this range could be regarded as most probably 23-24 characters long)
ZZZZZ-ZZZZZ-ZZZZZ (no items)
to
ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ (6 items no charge)
to
ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZ

So for arbitrary data, if you want something that's simple and produces pretty good save/load codes, you should use Pipedream's. If you want something that produces the best possible save/load codes but can lead to a lot of complexities, you should use Encoder. If you are totally crazy, you should use Acehart's, CodeGen, iGen, etc ; P. Pipedream's is also very GUI friendly, just like the others.



I am not trying to say that Encoder is the one and only. I'm not trying to say that all of the other systems suck. I am just presenting data and giving the pros and cons to each. Pipedream has the same pros of Acehart's and iGen and more, so that's why I say that those systems are crazy to use. The only pro that CodeGen has over all of the others is that it doesn't need vJASS, but considering that vJASS can now be used on macs, I don't really see that as a pro (unless a person is afraid of installing JassNewGen Pack or something : P).



The discussion was more about what types of save/load systems people preferred. I'm guessing most people prefer Pipedream's because it's low maintenance, easy to use, is GUI friendly, and provides pretty good codes. Pipedream's is a pretty darn good choice, but it can't save complex codes because it is so simple =). When people ask about what save/load system they should use, I tend to recommend Encoder or Pipedream's.


So we go back to what your favorite save/load system is and why. My initial thoughts when posting this is that most people would say Pipedream's, but I figured it'd be a fun discussion =). I still think that most people will say Pipedream's =P.
 

NeuroToxin

New Member
Reaction score
46
@Romek

> Also, security is overrated. Nobody's going to be messing with the save code itself. If anything, they'll just open the map and use it to generate a code that saves exactly what they want (which could even be done as simply as placing a hero in the map, setting its stats, levels and items, and running the map and getting a code through the game itself - completely avoiding JASS code altogether).

This is negative partially. There are hackers out there who will make a save/load code generator.

http://forum.wc3edit.net/deprotecti...-0-0-code-generator-t11263.html?hilit=codegen
Like this place, they do that. (I googled it, no worries)

Therefore, security, if your map will become popular like TBR, is a little needed, but not completely, Either change your code generator by 1-2 letters each time you update it, (Which should be like once a monthish) or just have the code be literally completely random.

@This topic AceHarts does work. I mean, it saves everything needed, its easily edited, it's perfect for noobs.
Frankly, I'm too lazy to learn to use another, Therefore I like that one. It just saves everything, so it's good for me.
 
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Staff online

      Members online

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top