Encryption adds no protection. It just obfuscates the data. Even when data is encrypted, by randomly mutating the data one will load different results.
You want to store a cryptographic hash of the data using a proven secure algorithm which is seeding in a unique non-standard way with reversible operations like bitwise rotation, addition and bitwise exclusive or. The protection comes from the random like nature of the output of cryptographic hashes combined with custom unknown logic, resulting in something that is hard to guess especially for someone without a computer science degree.
When the bank is loaded it re-computes the cryptographic hash of the stored data using the same algorithm and compares it with the stored hash. If there is a disparity the data has been tampered with and the load fails.
A strong cryptographic hash like SHA-256 combined with xoring with a map specific key, the SHA-256 of the user account identifier and some arbitrary but constant rotations will be more than secure enough to stop people modifying the banks directly. It will only be cracked by someone modifying/reading the triggers. It could technically be cracked without by an expert, but orders of magnitude more people will crack it by using the triggers directly so one can ignore those as a threat.
Do not try to invent a cryptographic hash algorithm. Chances are you will do it wrong since there is a reason millions of dollars are spent every year on developing them. The people who create them are extremely mathematically gifted and have years of experience with computer security. Best you can do is take a standard algorithm and modify it slightly using non destructive operators so that it produces non standard output which exponentially increases the complexity of solving the algorithm with respect to the number of transformations you apply. Hence the weakest point of security quickly falls to everyone being able to read the map script itself, so anything more extreme like encrypting the data as well becomes pointless.
As such encrypting the data on top of that is pointless unless you want to obfuscate what you store from the people themselves, which clearly is not the case for achievements when people know they have them.
Component files work well for data and triggers as those are XML so can be merged efficiently. They do not work at all well for terrain and other such files as those are binary files so cannot be merged.
Surely "is_alive" should be a boolean seeing how a unit is either alive or dead and not some other state?
Use a linear search to find right spawn point. For condition on unit death use a unit group to detect if the dying unit is a spawner. One can speed up linear search by making it a list and removing dead spawners from it.
I would suggest making each star its own trigger thread. A local array keeps track of the planets that orbit it. Movement is done using a while loop with a wait at the end of its action block. The loop terminates when the star dies, possibly killing all planets in the process. This means each star gets a dedicated trigger thread so it becomes quite scaleable as far as data management goes.
Did this occur soon after having published an update for the map? I recall an issue around 2015 where map lobbies might not be immediately available after publishing an update for that map. The solution was to wait anywhere from 5 to 120 minutes and then lobby creation could resume. Possibly it has to wait for the last active game of the previous version to end?
If one has a reasonable number of stars existing at a time, eg at most 60 or 160, then that is easy. Otherwise one has to use data tables which are considerably slower than the records used.
I am aware the planets do appear a bit unstable and shaky far away from the sun. The reason for this is likely due to internal fixed point error in the polar offset maths. For short distances they seem stable enough.
The galaxy int type is a standard 32bit two's compliment integer has the following range.
Min Value = -2,147,483,648
Max Value = 2,147,483,647
Since 333,474,250 is less than 2,147,483,647 then using an int should work.
Depending on the sort of mathematical operations one needs, one can easily implement a 64bit two's compliment integer using 2 int values (a low-word and a high-word).
With addition this is fairly straight forward to do. Add the two low-word values together to produce the result of the low-word and determine if an overflow occurred. Overflow occurs with addition when {both inputs are negative} or {1 input is negative, the other input is positive and the result is not negative}. Add the two high-words together and then if overflow had occurred with the low-words add an extra 1 value to the result to produce the high-word. This is fairly simple to compute.
Subtraction is a similar idea and in worst case could be implemented using addition and negation of a number.
Multiplication and division are not so simple. They likely require repeated addition to perform.
A 64bit two's compliment integer has the following range.
Min Value = -2,305,843,009,213,693,952
Max Value = 2,305,843,009,213,693,951
Anything beyond that and you really should consider deflating your numbers.
You could use a Modify Player effect to modify the catalog for the unit but that would affect all instances of that unit.
Last I checked it was much worse to modify data than it was to use buffs due to a resource leak. Each time data is modified it made a duplicate of that data leaving the previous copy in memory, unused. Thanks to efficient algorithms it did not slow the game down but it did mean exiting the game could take several minutes due to some inefficiency with freeing the extra allocated copies. Additionally if several million such modifications were made it is possible some clients may crash due to out of memory errors.
I recommend looking at how Rexar does this for his one trait in Heroes of the Storm. He might use a method compatible with Heroes of the Storm. I suspect it was done with stacking buffs.
Try using the catalog actions to modify the build ability for the specific player. There are also catalog functions to read values if you want the modification to be dynamic, eg 50% as opposed to a constant.
You still might want to check individual sub parts such as the q^2 in case of overflow. In such a case you could clamp them to max value instead of the output of the entire thing becoming garbage.
Would it not be possible to scale down the formula? Currently it uses some pretty large numbers.
For example 440 * population * quantity supplied. So if one was to supply 1,000 people with 1,000 units you are looking at 440,000,000 which is well past the range of the SC2 fixed point. However if one were to define population in thousands of people and supply in thousands of units then one gets 440 * 1 * 1 which is 440, well within the range of the fixed point type. Obviously the constants would need to be changed depending how they were derived. If the constants end up growing then this is counter productive so not a viable solution.
One could try rounding parts of if into integers (range of -2,147,483,648 to 2,147,483,647). However I doubt the game comes with integer square root so one would have to implement one themselves. Wikipedia has a few articles explaining. https://en.wikipedia.org/wiki/Methods_of_computing_square_roots
Otherwise you will need some kind of custom number type with custom maths functions to process the intermediate value.
One might have to write a custom floating point or multi word fixed point library to solve such an equation. Such libraries are often used for micro controllers and other cheap/simple processors where larger or more complex dedicated maths instructions are missing. I suggest using a search engine to look for such code, there appears to be tons on GitHub with heavy reference to Wikipedia which might be adaptable to Galaxy.
What is it for? Maybe there are other solutions that achieve similar results without requiring large intermediate values. For example an iterative algorithm that approximates towards it within reasonable time and complexity.
0.937662337662338
Encryption adds no protection. It just obfuscates the data. Even when data is encrypted, by randomly mutating the data one will load different results.
You want to store a cryptographic hash of the data using a proven secure algorithm which is seeding in a unique non-standard way with reversible operations like bitwise rotation, addition and bitwise exclusive or. The protection comes from the random like nature of the output of cryptographic hashes combined with custom unknown logic, resulting in something that is hard to guess especially for someone without a computer science degree.
When the bank is loaded it re-computes the cryptographic hash of the stored data using the same algorithm and compares it with the stored hash. If there is a disparity the data has been tampered with and the load fails.
A strong cryptographic hash like SHA-256 combined with xoring with a map specific key, the SHA-256 of the user account identifier and some arbitrary but constant rotations will be more than secure enough to stop people modifying the banks directly. It will only be cracked by someone modifying/reading the triggers. It could technically be cracked without by an expert, but orders of magnitude more people will crack it by using the triggers directly so one can ignore those as a threat.
Do not try to invent a cryptographic hash algorithm. Chances are you will do it wrong since there is a reason millions of dollars are spent every year on developing them. The people who create them are extremely mathematically gifted and have years of experience with computer security. Best you can do is take a standard algorithm and modify it slightly using non destructive operators so that it produces non standard output which exponentially increases the complexity of solving the algorithm with respect to the number of transformations you apply. Hence the weakest point of security quickly falls to everyone being able to read the map script itself, so anything more extreme like encrypting the data as well becomes pointless.
As such encrypting the data on top of that is pointless unless you want to obfuscate what you store from the people themselves, which clearly is not the case for achievements when people know they have them.
0
Component files work well for data and triggers as those are XML so can be merged efficiently. They do not work at all well for terrain and other such files as those are binary files so cannot be merged.
0
Surely "is_alive" should be a boolean seeing how a unit is either alive or dead and not some other state?
Use a linear search to find right spawn point. For condition on unit death use a unit group to detect if the dying unit is a spawner. One can speed up linear search by making it a list and removing dead spawners from it.
0
I would suggest making each star its own trigger thread. A local array keeps track of the planets that orbit it. Movement is done using a while loop with a wait at the end of its action block. The loop terminates when the star dies, possibly killing all planets in the process. This means each star gets a dedicated trigger thread so it becomes quite scaleable as far as data management goes.
0
Did this occur soon after having published an update for the map? I recall an issue around 2015 where map lobbies might not be immediately available after publishing an update for that map. The solution was to wait anywhere from 5 to 120 minutes and then lobby creation could resume. Possibly it has to wait for the last active game of the previous version to end?
0
One could have a trigger per star yes. Also if one keeps the data separate then there is no risk of them orbiting other stars.
0
If one has a reasonable number of stars existing at a time, eg at most 60 or 160, then that is easy. Otherwise one has to use data tables which are considerably slower than the records used.
0
I made this back long ago for someone... I guess he probably does not mind having it shared 6 years later, and if he does I will remove it.
Drop Box link may be removed in distant future.
https://www.dropbox.com/s/04s8jkblvlnr7hp/IG Orbit Demo.SC2Map?dl=0
I am aware the planets do appear a bit unstable and shaky far away from the sun. The reason for this is likely due to internal fixed point error in the polar offset maths. For short distances they seem stable enough.
0
The galaxy int type is a standard 32bit two's compliment integer has the following range.
Min Value = -2,147,483,648
Max Value = 2,147,483,647
Since 333,474,250 is less than 2,147,483,647 then using an int should work.
Depending on the sort of mathematical operations one needs, one can easily implement a 64bit two's compliment integer using 2 int values (a low-word and a high-word).
With addition this is fairly straight forward to do. Add the two low-word values together to produce the result of the low-word and determine if an overflow occurred. Overflow occurs with addition when {both inputs are negative} or {1 input is negative, the other input is positive and the result is not negative}. Add the two high-words together and then if overflow had occurred with the low-words add an extra 1 value to the result to produce the high-word. This is fairly simple to compute.
Subtraction is a similar idea and in worst case could be implemented using addition and negation of a number.
Multiplication and division are not so simple. They likely require repeated addition to perform.
A 64bit two's compliment integer has the following range.
Min Value = -2,305,843,009,213,693,952
Max Value = 2,305,843,009,213,693,951
Anything beyond that and you really should consider deflating your numbers.
0
Last I checked it was much worse to modify data than it was to use buffs due to a resource leak. Each time data is modified it made a duplicate of that data leaving the previous copy in memory, unused. Thanks to efficient algorithms it did not slow the game down but it did mean exiting the game could take several minutes due to some inefficiency with freeing the extra allocated copies. Additionally if several million such modifications were made it is possible some clients may crash due to out of memory errors.
I recommend looking at how Rexar does this for his one trait in Heroes of the Storm. He might use a method compatible with Heroes of the Storm. I suspect it was done with stacking buffs.
0
Try using the catalog actions to modify the build ability for the specific player. There are also catalog functions to read values if you want the modification to be dynamic, eg 50% as opposed to a constant.
0.960446719404374
You still might want to check individual sub parts such as the q^2 in case of overflow. In such a case you could clamp them to max value instead of the output of the entire thing becoming garbage.
0.96040987424313
Would it not be possible to scale down the formula? Currently it uses some pretty large numbers.
For example 440 * population * quantity supplied. So if one was to supply 1,000 people with 1,000 units you are looking at 440,000,000 which is well past the range of the SC2 fixed point. However if one were to define population in thousands of people and supply in thousands of units then one gets 440 * 1 * 1 which is 440, well within the range of the fixed point type. Obviously the constants would need to be changed depending how they were derived. If the constants end up growing then this is counter productive so not a viable solution.
One could try rounding parts of if into integers (range of -2,147,483,648 to 2,147,483,647). However I doubt the game comes with integer square root so one would have to implement one themselves. Wikipedia has a few articles explaining. https://en.wikipedia.org/wiki/Methods_of_computing_square_roots
Otherwise you will need some kind of custom number type with custom maths functions to process the intermediate value.
0.96037296037296
One might have to write a custom floating point or multi word fixed point library to solve such an equation. Such libraries are often used for micro controllers and other cheap/simple processors where larger or more complex dedicated maths instructions are missing. I suggest using a search engine to look for such code, there appears to be tons on GitHub with heavy reference to Wikipedia which might be adaptable to Galaxy.
What is it for? Maybe there are other solutions that achieve similar results without requiring large intermediate values. For example an iterative algorithm that approximates towards it within reasonable time and complexity.
0
Periodic events alone will not cause lag. One must either be using far too many of them (inefficient) or something else is the cause.