I know I have seen topics similar to this one, but I was wondering... Did anyone ever find an [i]easy[/i] way to accomplish this? I would be using on average... 60 variables. Just put each of them into the code and randomize them, hoping people don't try and cheat it? Discussiveness.

I know I have seen topics similar to this one, but I was wondering... Did anyone ever find an easy way to accomplish this? I would be using on average... 60 variables. Just put each of them into the code and randomize them, hoping people don't try and cheat it?

Discussiveness.

Well, you just enter a value into a death count for which they pick (Maybe 1-4) and then you have triggers that check when they are done to see if it matches one of yours, if not, you either reset or give error or something.

Well, you just enter a value into a death count for which they pick (Maybe 1-4) and then you have triggers that check when they are done to see if it matches one of yours, if not, you either reset or give error or something.

I think I did this in a map once, but i can't remember much about it.

I think I did this in a map once, but i can't remember much about it.

So many intriguing ways to do this... Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations. So you'll have to split up the system into multiple password entries. I'm guessing you were planning this? Giving the player, say, 10 passwords means that each password will deal with 64 possibilities (still assuming each variable has only 2 possible values), a lot more manageable. This also means that you could assign longer strings of letters/numbers for each password, making them less guessable (instead of spitting out a sequence of 60 individual values, which the player could easily start guessing at). Have each of the 64 possibilities correspond to a unique password. For example, a Death Count of 12 for Password A will always correspond to 1243 (or whatever). You could even make this correspondence the same for each of the 10 passwords and drastically reduce the number of triggers. One possibility, one which requires a lot more triggers but makes it a lot less guessable, is to have multiple password "sets". In this idea, in addition to the regular 10 passwords, you give the player an initial "keycode". The player has no idea that this keycode tells the triggers which "set" to use when interpreting the password. Let's say you had 2 sets (enough to throw the player off even more) and passwords A - J. Under Set 1, if the player enters 1111 for Password A, this may mean the player starts off with a zealot, 100 minerals, a forge, a drone, an overlord, and a ghost (for example, and assuming each variable has only 2 possible values). Under Set 2, entering the same password might mean the player starts off with a marine, 200 minerals, a forge, a drone, a dropship, and a ghost. Of course, having just two sets will require twice the number of triggers. An easier way of doing this, which would require fewer triggers, would be to have a trigger that adds a random number to the death count that holds each of the 10 passwords (when generating the passwords); and a corresponding trigger which subtracts the same amount (when the player enters the passwords). Which number gets added/subtracted depends on which "set" is used -- indicated by the initial "keycode", a special code at the beginning of the password given to the player. Again, the other 10 passwords may each contain very specific information, but the player will have no idea that the first password is actually an anti-guessing mechanism. Let's take an example: Password given to player: 1212 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 The player enters this password. The triggers first deal with the first chunk. They read, 1212. Okay. That corresponds to a death count value of 15 (for example). Since it's the first thing we received, we know it's telling us which numbers to subtract. Let's look up possibility 15 (the possibility randomly assigned when the password was generated). Possibility 15 tells us to subtract 9 from each of the passwords' death counts. Okay. First the triggers translate the remaining 10 passwords into the corresponding Possibility Death Counts. Then 9 is subtracted from each, giving the ACTUAL Possibility Death Counts. This is then acted upon (giving the player whatever units or whatever the variables intend). What's great about this method is that having a four-digit "keycode" would give you tons of possibilities for numbers to add/subtract, and unless the player was extremely dedicated, they'd never figure it out. They'd have to memorize entire passwords to take advantage of it. You could even have a meta-keycode, which tells the trigger system which way to interpret the keycode. The more keycodes you have, the more randomization is possible. It's a lot easier to set up triggers for multiple ways to randomize than for multiple ways to interpret. Another very simple way to randomize is to mix up the order of the 10 passwords. Give the player a keycode before the 10 passwords. This keycode remembers how the passwords are mixed up, so when the player enters that keycode, the trigger system will rearrange itself to ask for the passwords in the proper order. You could even have a meta-order keycode. A keycode that randomizes which way to interpret the next keycode. Again, the more meta-information there is, the harder it is to crack. The problem with having so many variables is the length of the passwords. This is especially a problem with telling the player the password they've been assigned, since a Display Text Message will always show the same thing, you can't put multiple messages on one line. If you can arrange the password system so each password it gives out on each line is longer, great, but that requires a lot more triggers. On the other hand, more randomization will require more lines of text, since each separate password element requires its own Display Text Message action. Shorter lines of text, sure, but still more. Also, all my numbers and estimates assume that each variable has only 2 possible values. Triggerwise, bigger amounts of possible values become easier to deal with if you have MORE password elements -- giving the player 60 separate password letters to remember will take a LOT less triggers than giving him, say, 10 separate passwords to remember... but it will also be a lot easier to crack/guess at, and probably piss the player off, making him sit there writing down 60 digits, trying not to lose track of which line he's copying... Alright, I hope all this was clear. If it wasn't, let me know and I'll say it a lot simpler. Just wanted to get the gist of it down.

So many intriguing ways to do this...

Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.

So you'll have to split up the system into multiple password entries. I'm guessing you were planning this? Giving the player, say, 10 passwords means that each password will deal with 64 possibilities (still assuming each variable has only 2 possible values), a lot more manageable. This also means that you could assign longer strings of letters/numbers for each password, making them less guessable (instead of spitting out a sequence of 60 individual values, which the player could easily start guessing at). Have each of the 64 possibilities correspond to a unique password. For example, a Death Count of 12 for Password A will always correspond to 1243 (or whatever). You could even make this correspondence the same for each of the 10 passwords and drastically reduce the number of triggers.

One possibility, one which requires a lot more triggers but makes it a lot less guessable, is to have multiple password "sets". In this idea, in addition to the regular 10 passwords, you give the player an initial "keycode". The player has no idea that this keycode tells the triggers which "set" to use when interpreting the password. Let's say you had 2 sets (enough to throw the player off even more) and passwords A - J. Under Set 1, if the player enters 1111 for Password A, this may mean the player starts off with a zealot, 100 minerals, a forge, a drone, an overlord, and a ghost (for example, and assuming each variable has only 2 possible values). Under Set 2, entering the same password might mean the player starts off with a marine, 200 minerals, a forge, a drone, a dropship, and a ghost. Of course, having just two sets will require twice the number of triggers.

An easier way of doing this, which would require fewer triggers, would be to have a trigger that adds a random number to the death count that holds each of the 10 passwords (when generating the passwords); and a corresponding trigger which subtracts the same amount (when the player enters the passwords). Which number gets added/subtracted depends on which "set" is used -- indicated by the initial "keycode", a special code at the beginning of the password given to the player. Again, the other 10 passwords may each contain very specific information, but the player will have no idea that the first password is actually an anti-guessing mechanism.

Let's take an example:

Password given to player: 1212 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234

The player enters this password. The triggers first deal with the first chunk. They read, 1212. Okay. That corresponds to a death count value of 15 (for example). Since it's the first thing we received, we know it's telling us which numbers to subtract. Let's look up possibility 15 (the possibility randomly assigned when the password was generated). Possibility 15 tells us to subtract 9 from each of the passwords' death counts.

Okay. First the triggers translate the remaining 10 passwords into the corresponding Possibility Death Counts. Then 9 is subtracted from each, giving the ACTUAL Possibility Death Counts. This is then acted upon (giving the player whatever units or whatever the variables intend).

What's great about this method is that having a four-digit "keycode" would give you tons of possibilities for numbers to add/subtract, and unless the player was extremely dedicated, they'd never figure it out. They'd have to memorize entire passwords to take advantage of it. You could even have a meta-keycode, which tells the trigger system which way to interpret the keycode. The more keycodes you have, the more randomization is possible. It's a lot easier to set up triggers for multiple ways to randomize than for multiple ways to interpret.

Another very simple way to randomize is to mix up the order of the 10 passwords. Give the player a keycode before the 10 passwords. This keycode remembers how the passwords are mixed up, so when the player enters that keycode, the trigger system will rearrange itself to ask for the passwords in the proper order.

You could even have a meta-order keycode. A keycode that randomizes which way to interpret the next keycode. Again, the more meta-information there is, the harder it is to crack.

The problem with having so many variables is the length of the passwords. This is especially a problem with telling the player the password they've been assigned, since a Display Text Message will always show the same thing, you can't put multiple messages on one line. If you can arrange the password system so each password it gives out on each line is longer, great, but that requires a lot more triggers. On the other hand, more randomization will require more lines of text, since each separate password element requires its own Display Text Message action. Shorter lines of text, sure, but still more.

Also, all my numbers and estimates assume that each variable has only 2 possible values. Triggerwise, bigger amounts of possible values become easier to deal with if you have MORE password elements -- giving the player 60 separate password letters to remember will take a LOT less triggers than giving him, say, 10 separate passwords to remember... but it will also be a lot easier to crack/guess at, and probably piss the player off, making him sit there writing down 60 digits, trying not to lose track of which line he's copying...

Alright, I hope all this was clear. If it wasn't, let me know and I'll say it a lot simpler. Just wanted to get the gist of it down.

[quote=razorsnail]Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.[/quote]Actually, it's (Number of variables)^(number of possible values). so 60 vars with 2 values would be 3,600 possible values, far les than one quintillion. :P Too bad you can't manually manipulate the numbers without making modding plugins. Then you could do all sorts of encryption and algorithms.

Quote from razorsnail

Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.

Actually, it's (Number of variables)^(number of possible values). so 60 vars with 2 values would be 3,600 possible values, far les than one quintillion.

Too bad you can't manually manipulate the numbers without making modding plugins. Then you could do all sorts of encryption and algorithms.

To keep the chances of a random guess getting something correct, you'll need to have more possible passwords than variable settings. For example. If your variables have a total of 1,000 different possibilities, and you only have 4,000 different possibilities, there is a 25% chance of someone randomly entering numbers and guessing. You should be able to do the math for what you want the percentage chance for them to crack one out. For 60 variables, ungh. If this is for the "Monster Dyne" map, lets say, just say that each of the 60 variables only has "50" (Level str spells etc.) possiblities, 00-99. That's 120 digits you would have to enter. If you use a MC system, it'll be the fastest you can make it. If each has 99, you can use 15 death counters. Death Counters can represent 8 digits, as the max value a dc can have is 2,147,483,647 So DC1 could equal 21,432,001 Condition 1a Check DC1 Check DC2 Check DC3 ... Check DC15 P1 Password Entering Set Action Set P1 Passsword Good Clear P1 Password Entering As far as creating these triggers, if you learn how to program, create a list of all the possiblities, or create a program to create a list of possibliites. Create this list in a format that another program can interpret that list and create the triggers in "Trig edit" for SCMDraft. Here's the problem with mine though, 60 with 50 possiblities equals this number. 8.028 ^88 power of triggers. Albeit a computer program could create this list. The size of that file will be huge, thus making your map huge. I'd also ask Tuxedo Templar if the number of triggers slows down a maps ability to run triggers effectively. Albeit these triggers will only be checked at the beginning of the map... that's a lot of triggers. There may be a way to make Starcraft editor to use an internal encryption for your death counters. Use death counters from the computers, as theres only two players. Multiplication, addition, sraction ubtand division can be used by starcraft, but I don't know the math for creating the encryption. This is where I wish I'd have worked on Warcraft 3 maps, because A LOT of maps use an encryption system... I'd go searching for that if I was to try and build in a system for Staredit... and it'd probably be easily 1% of the triggers of hard codeing... Figureing out the encryption route is probably the best way. Also, DO NOT use display text to show the password. Use "Minerals" and set minerals to value to display the password. If you don't, you'll end up eating up a bunch of your string limit.

To keep the chances of a random guess getting something correct, you'll need to have more possible passwords than variable settings. For example. If your variables have a total of 1,000 different possibilities, and you only have 4,000 different possibilities, there is a 25% chance of someone randomly entering numbers and guessing. You should be able to do the math for what you want the percentage chance for them to crack one out.

For 60 variables, ungh. If this is for the "Monster Dyne" map, lets say, just say that each of the 60 variables only has "50" (Level str spells etc.) possiblities, 00-99. That's 120 digits you would have to enter. If you use a MC system, it'll be the fastest you can make it. If each has 99, you can use 15 death counters.

Death Counters can represent 8 digits, as the max value a dc can have is 2,147,483,647

So DC1 could equal 21,432,001

Condition 1a
Check DC1
Check DC2
Check DC3
...
Check DC15
P1 Password Entering Set
Action
Set P1 Passsword Good
Clear P1 Password Entering

As far as creating these triggers, if you learn how to program, create a list of all the possiblities, or create a program to create a list of possibliites. Create this list in a format that another program can interpret that list and create the triggers in "Trig edit" for SCMDraft. Here's the problem with mine though, 60 with 50 possiblities equals this number. 8.028 ^88 power of triggers. Albeit a computer program could create this list. The size of that file will be huge, thus making your map huge. I'd also ask Tuxedo Templar if the number of triggers slows down a maps ability to run triggers effectively. Albeit these triggers will only be checked at the beginning of the map... that's a lot of triggers.

There may be a way to make Starcraft editor to use an internal encryption for your death counters. Use death counters from the computers, as theres only two players. Multiplication, addition, sraction ubtand division can be used by starcraft, but I don't know the math for creating the encryption. This is where I wish I'd have worked on Warcraft 3 maps, because A LOT of maps use an encryption system... I'd go searching for that if I was to try and build in a system for Staredit... and it'd probably be easily 1% of the triggers of hard codeing... Figureing out the encryption route is probably the best way.

Also, DO NOT use display text to show the password. Use "Minerals" and set minerals to value to display the password. If you don't, you'll end up eating up a bunch of your string limit.

Minerals cannot show all the digits. You could also use gas...

Minerals cannot show all the digits. You could also use gas...

As I go along, I will be figuring out the best combinations I can make and if I can somehow combine variables. A lot of what you said is going through my mind and I have a general idea of how I will go about it. Thanks ^^

As I go along, I will be figuring out the best combinations I can make and if I can somehow combine variables.

A lot of what you said is going through my mind and I have a general idea of how I will go about it. Thanks

I meant like multiple units, "Mineral Type 1" Have it display 4 or 6 (Or however man for each Death Counter) I used. Not the minerals that a player has... that peaks out somewheres way before the 60 variable thing. I still say figure out how the WCIII encryption systems in a map works. I'm hoping it doesn't use any Logs, that'd be a pain to do. The other problem is if it uses exponents, because I don't know if WCIII has a cap of a value... Either way the goal would be a system to be able to encrypt, decrypt any given number setup. I now want to try and create an "encryption/decryption" system just to try it out. Time for wikipedia searching :-/... That looks like it explains how WCIII does it, now to create a math system for SC, since there's no easy way to do it. http://world-editor-tutorials.thehelper.net/cat_usersubmit.php?view=37153

I meant like multiple units, "Mineral Type 1" Have it display 4 or 6 (Or however man for each Death Counter) I used. Not the minerals that a player has... that peaks out somewheres way before the 60 variable thing.

I still say figure out how the WCIII encryption systems in a map works. I'm hoping it doesn't use any Logs, that'd be a pain to do. The other problem is if it uses exponents, because I don't know if WCIII has a cap of a value... Either way the goal would be a system to be able to encrypt, decrypt any given number setup. I now want to try and create an "encryption/decryption" system just to
try it out. Time for wikipedia searching :-/...

That looks like it explains how WCIII does it, now to create a math system for SC, since there's no easy way to do it.

http://world-editor-tutorials.thehelper.net/cat_usersubmit.php?view=37153

You could use modding plugins. :P

You could use modding plugins.

[quote=name:FaRTy1billion][quote=razorsnail]Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.[/quote]Actually, it's (Number of variables)^(number of possible values). so 60 vars with 2 values would be 3,600 possible values, far les than one quintillion. :P[/quote] Haha, oops. I think the best way is to generate a string of passwords, and mix up the order, and add/subtract values to the death counts. Have a few passwords at the beginning that have nothing to do with the variables, but instead determine the way the actual death counts are mixed/modified. Like I said, the more meta-information you have, the easier it is to create an unguessable system. And if you have a STRING of 3- or 4-digit passwords, each password can contain multiple variables and many, many more possible "incorrect" passwords than correct passwords. You can also give them to the player one by one. You could have a beacon or data disc or whatever for each password, arranged in a line, and when the player brings a unit to one of them, it will show him the password. Or whatever. Here's an example: A - 2 B - 14 C - 14 D - 23 E - 1234 F - 2134 G - 1234 H - 1234 I - 1234 J - 1234 E - J are the passwords containing variable information. A is the "global" password, telling the system which interpretation paradigm to use. The global paradigm could do a few things: mix up the order of all the other elements, or tell which system of triggers to use for B, C, and D. B tells the system which order the passwords are in, depending on the interpretation paradigm. C directs the system to the correct trigger which will add or subtract from each death count, depending on the interpretation paradigm. D tells you WHICH death counts to add or subtract from, depending on the interpretation paradigm. You could even have "patterns" -- like a value is assigned to each death count of E-J, and the trigger that C directed you to will determine how much is added/subtracted from each value. You could continue to add layers to this. Extra layers reduce guessability without generating huge numbers of triggers. The more non-variable layers you have, the more incorrect passwords you can have without having to deal with extra triggers/variables. And like I said before, a string of passwords lets you give them to the player one by one in order, and lets the player ask for each again if he didn't get it the first time.

Quote from O)FaRTy1billion[MM]

Quote from razorsnail

Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.

Actually, it's (Number of variables)^(number of possible values). so 60 vars with 2 values would be 3,600 possible values, far les than one quintillion.

Haha, oops.

I think the best way is to generate a string of passwords, and mix up the order, and add/subtract values to the death counts. Have a few passwords at the beginning that have nothing to do with the variables, but instead determine the way the actual death counts are mixed/modified.

Like I said, the more meta-information you have, the easier it is to create an unguessable system. And if you have a STRING of 3- or 4-digit passwords, each password can contain multiple variables and many, many more possible "incorrect" passwords than correct passwords. You can also give them to the player one by one. You could have a beacon or data disc or whatever for each password, arranged in a line, and when the player brings a unit to one of them, it will show him the password. Or whatever.

Here's an example:

A - 2
B - 14
C - 14
D - 23
E - 1234
F - 2134
G - 1234
H - 1234
I - 1234
J - 1234

E - J are the passwords containing variable information.
A is the "global" password, telling the system which interpretation paradigm to use. The global paradigm could do a few things: mix up the order of all the other elements, or tell which system of triggers to use for B, C, and D.
B tells the system which order the passwords are in, depending on the interpretation paradigm.
C directs the system to the correct trigger which will add or subtract from each death count, depending on the interpretation paradigm.
D tells you WHICH death counts to add or subtract from, depending on the interpretation paradigm. You could even have "patterns" -- like a value is assigned to each death count of E-J, and the trigger that C directed you to will determine how much is added/subtracted from each value.

You could continue to add layers to this. Extra layers reduce guessability without generating huge numbers of triggers.

The more non-variable layers you have, the more incorrect passwords you can have without having to deal with extra triggers/variables.

And like I said before, a string of passwords lets you give them to the player one by one in order, and lets the player ask for each again if he didn't get it the first time.

Here is what I might do... for an encryption system. We're going with the each variable has 50 options. (0-99) Set up a conversion system. 0000 = 1000 1000 = 4000 4000 = 3000 etc. 000 = 100 100 = 400 etc. 00 = 50 etc. 0 = 9 This will leave a 4 digit set of passwords to require 40 triggers to properly convert 4 switches or 1 death counter etc. Realisticly. If you want it to be for the first set of numbers. If you want it in 4 digit sets. So, a player enters 1000. Useing the conversion system, the resultant data will become 3159. How the triggers work. Death Counter to represent What step of conversion you're on. (Conversion) Death Counter to represent What step of 4 digit codes to analyze you're on (Code) Death Counter to represent Code Set 1 - X where X is the number of four digit steps you are on. (CS1 - CSX) Death Counter to represent Converted Codes (CC1 - CCX) Trigger Condition Death Counter Conversion is 1 Death Counter Code is 1 CS1 has at least 3999 deaths CS1 has at most 4001 deaths Action Add 3000 deaths to CC1 Subtract 4000 deaths from CS1 *NOTE: This must be done on any value that is > 0 for an entered digit* Add 1 death to Code Trigger Condition Death Counter Conversion is 1 Death Counter Code is 2 CS1 has at most 99 deaths Action Add 100 deaths to CC1 *Note the missing subtract from CS1 Add 1 death to Code Make sets of triggers for ALL Conversions. On the last step of a conversian (If you want players to only have one chance to get the password correct, add one death to Counter Conversian, if not read on.) No matter what be sure the last step sets counter code to 0. Right now, the total trigger ammount is 40 x X, where X is the number of 4 set triggers. In loveless's case, it's 1200 triggers. This will encrypt it, and if you wanted too you could change up the death conversions for each Counter conversion. Next set of triggers is to process the "Decrypted" data. Here is where we can also put bad password detection in. I'm assumeing you'll use death counters to represent stats, health etc. etc. So, the decryption process should be the spot where you set the players Death Counters to the levels you want them. The Decrypted Number was 3159. We will split this number up for visual purposes only to be 31 and 59. 59 is a bad number... it's > 50. The 31 is good. 31 is health, 51 is MP New Variables P1HP P1MP Old Variables CC1 = 3159 Trigger Example Condition CC1 = at least 100 Action Add 1 to Player 1's HP Subtract 100 from CC1 Preserve Trigger Condition CC1 is greater than 50 Action Set Bad Password There are two things you can do when a bad password comes up. Have them re enter the password, which involves you setting all the variables to 0, and haveing them re enter it... or tell them they're starting a new game... The number of triggers here is 3 x V, where V is the number of variables that a password represents. That puts the total triggers for just the encryption/decryption at 1380 Triggers. I would use the HP/MP Variables as mainly display values. For example. Conditon HP is at 30 Deaths Action Set Resource type 1 to "30" Or Set HP % to 30% on a unit that has exactly 100 Health. Preserve Trigger This means each variable would have 51 values, which is 3060 Triggers. I didn't show a code-entering system... but I think you should be able to figure it out from what I've shown. Also, the probability of randomly guessing a correct password is 1/(2^60) for my system. That's approaching 0. Boo yah. I think thge password entering system could be done in 120 triggers. 4560 Triggers. I could be wrong, but that's what I estimate the whole Password Enter, Decrypt, Display. The last step is showing the password at a save. I'd want it to be so that when they saved they were done with the map until they decided to load. You need to first encrypt all the death counters. Which will be about 1200 triggers. Then Display the password which will be another 120. 5880 Total Triggers. I would definitely would want some sort of trigger duplicator system...

Here is what I might do... for an encryption system. We're going with the each variable has 50 options. (0-99) Set up a conversion system.
0000 = 1000
1000 = 4000
4000 = 3000
etc.
000 = 100
100 = 400
etc.
00 = 50
etc.
0 = 9
This will leave a 4 digit set of passwords to require 40 triggers to properly convert
4 switches or 1 death counter
etc. Realisticly. If you want it to be for the first set of numbers. If you want it in 4 digit sets.

So, a player enters 1000. Useing the conversion system, the resultant data will become 3159. How the triggers work.

Death Counter to represent What step of conversion you're on. (Conversion)
Death Counter to represent What step of 4 digit codes to analyze you're on (Code)
Death Counter to represent Code Set 1 - X where X is the number of four digit steps you are on. (CS1 - CSX)
Death Counter to represent Converted Codes (CC1 - CCX)

Trigger
Condition
Death Counter Conversion is 1
Death Counter Code is 1
CS1 has at least 3999 deaths
CS1 has at most 4001 deaths
Action
Add 3000 deaths to CC1
Subtract 4000 deaths from CS1 *NOTE: This must be done on any value that is > 0 for an entered digit*
Add 1 death to Code

Trigger
Condition
Death Counter Conversion is 1
Death Counter Code is 2
CS1 has at most 99 deaths
Action
Add 100 deaths to CC1
*Note the missing subtract from CS1
Add 1 death to Code


Make sets of triggers for ALL Conversions. On the last step of a conversian (If you want players to only have one chance to get the password correct, add one death to Counter Conversian, if not read on.) No matter what be sure the last step sets counter code to 0. Right now, the total trigger ammount is 40 x X, where X is the number of 4 set triggers. In loveless's case, it's 1200 triggers. This will encrypt it, and if you wanted too you could change up the death conversions for each Counter conversion.

Next set of triggers is to process the "Decrypted" data. Here is where we can also put bad password detection in. I'm assumeing you'll use death counters to represent stats, health etc. etc. So, the decryption process should be the spot where you set the players Death Counters to the levels you want them.

The Decrypted Number was 3159. We will split this number up for visual purposes only to be 31 and 59. 59 is a bad number... it's > 50. The 31 is good. 31 is health, 51 is MP
New Variables
P1HP
P1MP
Old Variables
CC1 = 3159
Trigger Example
Condition
CC1 = at least 100
Action
Add 1 to Player 1's HP
Subtract 100 from CC1
Preserve Trigger

Condition
CC1 is greater than 50
Action
Set Bad Password

There are two things you can do when a bad password comes up. Have them re enter the password, which involves you setting all the variables to 0, and haveing them re enter it... or tell them they're starting a new game... The number of triggers here is 3 x V, where V is the number of variables that a password represents.

That puts the total triggers for just the encryption/decryption at 1380 Triggers. I would use the HP/MP Variables as mainly display values. For example.

Conditon
HP is at 30 Deaths
Action
Set Resource type 1 to "30"
Or
Set HP % to 30% on a unit that has exactly 100 Health.
Preserve Trigger

This means each variable would have 51 values, which is 3060 Triggers.

I didn't show a code-entering system... but I think you should be able to figure it out from what I've shown. Also, the probability of randomly guessing a correct password is 1/(2^60) for my system. That's approaching 0. Boo yah. I think thge password entering system could be done in 120 triggers. 4560 Triggers. I could be wrong, but that's what I estimate the whole Password Enter, Decrypt, Display.

The last step is showing the password at a save. I'd want it to be so that when they saved they were done with the map until they decided to load. You need to first encrypt all the death counters. Which will be about 1200 triggers. Then Display the password which will be another 120. 5880 Total Triggers. I would definitely would want some sort of trigger duplicator system...

I have this enabled on my CTF map I am currently working on. Although I have to input the player 'accounts' myself and redestribute the map but people can log in via beacon system or if they don't have an account then they can log in as a guest and use the point system to gain access to more classes... Only problem with this in my situation is always having to add accounts for players that want one...

I have this enabled on my CTF map I am currently working on. Although I have to input the player 'accounts' myself and redestribute the map but people can log in via beacon system or if they don't have an account then they can log in as a guest and use the point system to gain access to more classes... Only problem with this in my situation is always having to add accounts for players that want one...

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping :><:.

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping .

[quote=name:Daedalus]Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping :><:.[/quote] If they are going to spend that much time trying to figure out a password... By all means, you deserve it.

Quote from Daedalus

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping .

If they are going to spend that much time trying to figure out a password... By all means, you deserve it.

[quote=name:LoveLess][quote=name:Daedalus]Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping :><:.[/quote] If they are going to spend that much time trying to figure out a password... By all means, you deserve it.[/quote] Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.

Quote from LoveLess

Quote from Daedalus

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping .

If they are going to spend that much time trying to figure out a password... By all means, you deserve it.

Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.

Yeah, but does the map maker care if you want to ruin the game for yourself? :P

Yeah, but does the map maker care if you want to ruin the game for yourself?

[quote=name:Daedalus][quote=name:LoveLess][quote=name:Daedalus]Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping :><:.[/quote] If they are going to spend that much time trying to figure out a password... By all means, you deserve it.[/quote] Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.[/quote] Yes, the average time of a mass attack or defense, not the average time of an epic LoveLess map.

Quote from Daedalus

Quote from LoveLess

Quote from Daedalus

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping .

If they are going to spend that much time trying to figure out a password... By all means, you deserve it.

Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.

Yes, the average time of a mass attack or defense, not the average time of an epic LoveLess map.

[quote=name:lil-Inferno][quote=name:Daedalus][quote=name:LoveLess][quote=name:Daedalus]Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping :><:.[/quote] If they are going to spend that much time trying to figure out a password... By all means, you deserve it.[/quote] Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.[/quote] Yes, the average time of a mass attack or defense, not the average time of an epic LoveLess map.[/quote] ... Lulz.

Quote from lil-Inferno

Quote from Daedalus

Quote from LoveLess

Quote from Daedalus

Bytheway, before you all go and work your heads off on a secure passcode system, please take note that anyone could just use OSMAP to open the map, look for a good/the best passcode and cheat. It will probably take some digging in the codes but I bet most people could crack it. Don't you just love open source mapping .

If they are going to spend that much time trying to figure out a password... By all means, you deserve it.

Meh, if anyone makes a map with a passcode save system I bet I can get a good code within 30 minutes, that's the time of an average b.net game.

Yes, the average time of a mass attack or defense, not the average time of an epic LoveLess map.

... Lulz.