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.
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.
Any file ending with .dds is a texture. Any file ending with .m3 is a model. I think models reference textures at a specific file path within the StarCraft II file system. The hard coded texture paths can be swapped out with an arbitrary texture to some extent.
5. How does one find the string for this highlighted action?
UI editor allows one to browse the XML of the UI elements. The string is created based on what various XML elements are named.
6. What does this do?
Sets a global reference named "1testname" to the actor which executes the message. Another message can use this global reference to interact with that actor from another actor. Since the reference is global only 1 actor can be assigned to it at a time, however this is still useful if one only needs a reference to the actor immediately, eg for accompanying actor to connect to it. I think various targeting UI from WoL such as Raynor's Penetrating Rounds used global references. I also recall the heal beams from medic/medivac also using it.
7. Talking Portraits(Lips)
I think one needs to attach the appropriate lip sync file to the voice over that one orders the portrait to play. I am not familiar with how to load lip sync files to a portrait without a voice over, but possible they are animation extension files. Alarak and Zagara likely do not support lip sync (they have no human like mouth) so instead they use generic talking animations similar to how Warcraft III worked.
...owner by 'any' = it's seem to make me the number of active player (and it doesn't give me any error)
Any is not a valid parameter to make a unit with. A unit must be owned and any is not a valid owner.
Parameter ouf bounds in 'sUnitCreate' (Value: 16, min: 0, max: 15) (this is what I don't know how to solve it)
Player 16 is not a valid value for the player. I am guessing it is failing to find a unit so you are getting the owner of null and hence it returns an invalid player number.
Because half the reason a lot of people cannot play HotS in the USA is because of so many people streaming that it is overloading some internet nodes causing them to drop packets. Under current regulations all packets have to be dropped and delayed equally, even if that packet is 1 of several megabytes worth per second used for a 4k HD stream that no one would care is dropped, or is a few kilobytes per second of game command packets that is extremely latency critical and dropping it will cause the player to experience lag due to retransmission. Technically under the new regulations internet companies could offer cheaper low priority bandwidth for streaming companies where latency is unimportant but quantity is while offering game servers more expensive high priority bandwidth where latency is extremely important but quantity is small.
Sounds good and sensible right? Well the problem, and reason why the previous regulation existed to stop this, is human greed. Instead of offering sensible QoS levels at sensible prices targeting different practical applications. They will use QoS to blackmail content providers into having to buy the most expensive "premium" QoS level to even stand a chance of having their packets delivered. Once everyone is subscribing to this premium QoS and the internet starts to behave like it does currently due to too much data and too little infrastructure they will then introduce a new "ultra premium" QoS level that is above "premium" with a larger cost. The black mail cycle will repeat with normal premium customers not being able to reliably deliver content unless they subscribe to the new ultra premium service. During this cycle no one bothers to invest in new infrastructure as you can just charge infinitely more for existing infrastructure by inventing new "extra ultra premium" QoS levels for it to sell.
Mostly when they want to sell you a service and there is a free alternative out there, without net neutrality they can just block all access to it to users using their internet. It also enables them selling limited internet where you can only access certain things, which might not be terrible on individual level (as you chose to pay less) but is a bad thing on a bigger scale.
The average private internet consumer will probably not notice the change at all, even to their internet bill, as there is no real way or point to meter them. It is the content providers who will be paying for the QoS, and that QoS can apply both ways (so they can pay for priority incoming and outgoing traffic). This is why Facebook, Google, etc are all against it since they will be the ones having to pay.
What the average private internet consumer will notice is that the QoS of the sites they visit and services they use will change, for better or worse. In the case of games, if the game company subscribes to a higher end QoS connection then their players might have a better play experience as connections that lagged before start to work with low ping. On the other hand if the game company goes with the cheapest QoS they can find the opposite can happen and where as before players could play with low ping suddenly the game becomes unplayable. This can only be made worse if huge bandwidth intensive content providers such as Netflix or Google use high end QoS to deliver their streaming services as although their streaming performance might improve slightly, it will totally trash peoples ability to play online games unless the companies use the same or better QoS in which case it becomes nothing better than it is now but costing more.
This is why "net neutrality" is important. This is why most sensible countries enforce it.
The main problems mentioned above with StarCraft II is a change in general player habits rather than anything to do with Blizzard.
StarCraft II engine was made during the early days of wide spread truly simultaneous multi threading. It edged on faster dual cores with only 2 heavy threads, as opposed to where computers actually went with slightly slower quad cores, and now going towards hex and oct cores. It was also created just before entering the era of the monster graphic cards so was designed to support some pretty old D3D9 style hardware as opposed to taking full advantage of the cutting edge D3D10 hardware. In fact the game engine was so optimized around this style of graphics it is one of the few game engines that has been known to cause hardware damage to GPUs due to it making them use so much power, although that is really a design flaw with the GPU hardware/driver.
All this means the game has not aged well, in fact it might even be aging worse than Warcraft III. Warcraft III will run extremely well on pretty much any modern computer that has a CPU and a GPU from the last 10 years, even integrated GPUs. StarCraft II on the other hand still needs a pretty decent computer to run well, and even then it can still cause modern GPUs to overheat under some conditions. It also seems that Blizzard has given up modernizing the SC2 engine, since HotS constantly receives performance optimizations and new features that will likely never be ported back to StarCraft II.
A lot of old Warcraft III players did not move to StarCraft II, instead moving on to discrete MOBA games, mobile games or even giving up gaming for social networking. A lot of old Warcraft III developers gave up modding StarCraft II due to early day problems. StarCraft II also did not attract the flood of "trash" content that populated Warcraft III custom game list for years since it has more strict publishing rules and the editor requires a little more intelligence to use. Many of the better Warcraft III creators grew out of this style of content creation entirely and moved on to creating their own independent games. The real nail in the coffin is the false news style dark cloud that constantly covers StarCraft II of all the "arcade issues" that were fixed early on but people still insist that they exist and constantly spam about them everywhere.
That said StarCraft II arcade should not be under estimated. If your map is good it can get access to thousands of players, far more than Warcraft III ever allowed (most players were there to only play DotA Allstars). Additionally if one works with the game engine rather than against it one can create some highly polished content. If enough people published decent new content to the Arcade StarCraft II could still take off, since playing the same old maps does get boring eventually.
StarCraft II also never got the technical expertise that Warcraft III got. There was no generation of people like Vexorian for StarCraft II early on. It took several years before the model format was finally cracked, and even then it was done largely by the Warcraft III technical community. The lack of such expertise is obvious and unfortunately does not help the game's image as there are many wide spread StarCraft II technical documents or tutorials that are just out right wrong. For example the belief that running actions in new thread makes them run in parallel on multi core systems and that synchronization is needed between threads is entirely wrong, as the game uses a similar trigger threading/scheduling model as Warcraft III so only 1 thread can run at any time and all state is consistent between threads so there is no concept such as synchronization.
StarCraft II does not support this as far as I am aware. Heroes of the Storm needed special mechanics added to it so they could efficiently create Li Ming Arcane Orb and other abilities that scale with distance travelled.
Both DrSuperEvil's approaches sound a sensible work around depending on which sort of scaling you want. However they might not be completely accurate in the case of projectile linked damage where a projectile is launched and the launcher moves. If the launcher moves away from the target it might increase the damage, and like wise if it moves towards the target the game might be decreased.
If a projectile is used another approach would be to periodically increment a buff/charge on the projectile unit and deal damage based on the number of such buff/charge. This is the travel time of the projectile which translates into a duration.
Make sure the building footprints are flush square with the placement grid. It is possible there are tiny gaps which are big enough for the path finder to find a route through but too small for any unit to practically fit through.
Units are not always factored in by the path finder since unit on unit collision is more physics based. In such case I recommend placing all player controlled units on a different collision layer so they cannot be used to block the walkers.
Instead of killing the players maze in the case of a blockage, detect when they try to make a blockage (eg placing the final building to make a solid wall) and then cancel that building. This is far more user friendly as it does not heavily punish accidental blocking.
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.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.962722852512156
Any file ending with .dds is a texture. Any file ending with .m3 is a model. I think models reference textures at a specific file path within the StarCraft II file system. The hard coded texture paths can be swapped out with an arbitrary texture to some extent.
UI editor allows one to browse the XML of the UI elements. The string is created based on what various XML elements are named.
Sets a global reference named "1testname" to the actor which executes the message. Another message can use this global reference to interact with that actor from another actor. Since the reference is global only 1 actor can be assigned to it at a time, however this is still useful if one only needs a reference to the actor immediately, eg for accompanying actor to connect to it. I think various targeting UI from WoL such as Raynor's Penetrating Rounds used global references. I also recall the heal beams from medic/medivac also using it.
I think one needs to attach the appropriate lip sync file to the voice over that one orders the portrait to play. I am not familiar with how to load lip sync files to a portrait without a voice over, but possible they are animation extension files. Alarak and Zagara likely do not support lip sync (they have no human like mouth) so instead they use generic talking animations similar to how Warcraft III worked.
0.962236390387445
Any is not a valid parameter to make a unit with. A unit must be owned and any is not a valid owner.
Player 16 is not a valid value for the player. I am guessing it is failing to find a unit so you are getting the owner of null and hence it returns an invalid player number.
0.96440489432703
Because half the reason a lot of people cannot play HotS in the USA is because of so many people streaming that it is overloading some internet nodes causing them to drop packets. Under current regulations all packets have to be dropped and delayed equally, even if that packet is 1 of several megabytes worth per second used for a 4k HD stream that no one would care is dropped, or is a few kilobytes per second of game command packets that is extremely latency critical and dropping it will cause the player to experience lag due to retransmission. Technically under the new regulations internet companies could offer cheaper low priority bandwidth for streaming companies where latency is unimportant but quantity is while offering game servers more expensive high priority bandwidth where latency is extremely important but quantity is small.
Sounds good and sensible right? Well the problem, and reason why the previous regulation existed to stop this, is human greed. Instead of offering sensible QoS levels at sensible prices targeting different practical applications. They will use QoS to blackmail content providers into having to buy the most expensive "premium" QoS level to even stand a chance of having their packets delivered. Once everyone is subscribing to this premium QoS and the internet starts to behave like it does currently due to too much data and too little infrastructure they will then introduce a new "ultra premium" QoS level that is above "premium" with a larger cost. The black mail cycle will repeat with normal premium customers not being able to reliably deliver content unless they subscribe to the new ultra premium service. During this cycle no one bothers to invest in new infrastructure as you can just charge infinitely more for existing infrastructure by inventing new "extra ultra premium" QoS levels for it to sell.
The average private internet consumer will probably not notice the change at all, even to their internet bill, as there is no real way or point to meter them. It is the content providers who will be paying for the QoS, and that QoS can apply both ways (so they can pay for priority incoming and outgoing traffic). This is why Facebook, Google, etc are all against it since they will be the ones having to pay.
What the average private internet consumer will notice is that the QoS of the sites they visit and services they use will change, for better or worse. In the case of games, if the game company subscribes to a higher end QoS connection then their players might have a better play experience as connections that lagged before start to work with low ping. On the other hand if the game company goes with the cheapest QoS they can find the opposite can happen and where as before players could play with low ping suddenly the game becomes unplayable. This can only be made worse if huge bandwidth intensive content providers such as Netflix or Google use high end QoS to deliver their streaming services as although their streaming performance might improve slightly, it will totally trash peoples ability to play online games unless the companies use the same or better QoS in which case it becomes nothing better than it is now but costing more.
This is why "net neutrality" is important. This is why most sensible countries enforce it.
0.963130173062453
The main problems mentioned above with StarCraft II is a change in general player habits rather than anything to do with Blizzard.
StarCraft II engine was made during the early days of wide spread truly simultaneous multi threading. It edged on faster dual cores with only 2 heavy threads, as opposed to where computers actually went with slightly slower quad cores, and now going towards hex and oct cores. It was also created just before entering the era of the monster graphic cards so was designed to support some pretty old D3D9 style hardware as opposed to taking full advantage of the cutting edge D3D10 hardware. In fact the game engine was so optimized around this style of graphics it is one of the few game engines that has been known to cause hardware damage to GPUs due to it making them use so much power, although that is really a design flaw with the GPU hardware/driver.
All this means the game has not aged well, in fact it might even be aging worse than Warcraft III. Warcraft III will run extremely well on pretty much any modern computer that has a CPU and a GPU from the last 10 years, even integrated GPUs. StarCraft II on the other hand still needs a pretty decent computer to run well, and even then it can still cause modern GPUs to overheat under some conditions. It also seems that Blizzard has given up modernizing the SC2 engine, since HotS constantly receives performance optimizations and new features that will likely never be ported back to StarCraft II.
A lot of old Warcraft III players did not move to StarCraft II, instead moving on to discrete MOBA games, mobile games or even giving up gaming for social networking. A lot of old Warcraft III developers gave up modding StarCraft II due to early day problems. StarCraft II also did not attract the flood of "trash" content that populated Warcraft III custom game list for years since it has more strict publishing rules and the editor requires a little more intelligence to use. Many of the better Warcraft III creators grew out of this style of content creation entirely and moved on to creating their own independent games. The real nail in the coffin is the false news style dark cloud that constantly covers StarCraft II of all the "arcade issues" that were fixed early on but people still insist that they exist and constantly spam about them everywhere.
That said StarCraft II arcade should not be under estimated. If your map is good it can get access to thousands of players, far more than Warcraft III ever allowed (most players were there to only play DotA Allstars). Additionally if one works with the game engine rather than against it one can create some highly polished content. If enough people published decent new content to the Arcade StarCraft II could still take off, since playing the same old maps does get boring eventually.
StarCraft II also never got the technical expertise that Warcraft III got. There was no generation of people like Vexorian for StarCraft II early on. It took several years before the model format was finally cracked, and even then it was done largely by the Warcraft III technical community. The lack of such expertise is obvious and unfortunately does not help the game's image as there are many wide spread StarCraft II technical documents or tutorials that are just out right wrong. For example the belief that running actions in new thread makes them run in parallel on multi core systems and that synchronization is needed between threads is entirely wrong, as the game uses a similar trigger threading/scheduling model as Warcraft III so only 1 thread can run at any time and all state is consistent between threads so there is no concept such as synchronization.
0.9623944742901
StarCraft II does not support this as far as I am aware. Heroes of the Storm needed special mechanics added to it so they could efficiently create Li Ming Arcane Orb and other abilities that scale with distance travelled.
Both DrSuperEvil's approaches sound a sensible work around depending on which sort of scaling you want. However they might not be completely accurate in the case of projectile linked damage where a projectile is launched and the launcher moves. If the launcher moves away from the target it might increase the damage, and like wise if it moves towards the target the game might be decreased.
If a projectile is used another approach would be to periodically increment a buff/charge on the projectile unit and deal damage based on the number of such buff/charge. This is the travel time of the projectile which translates into a duration.
0.962680883472963
Make sure the building footprints are flush square with the placement grid. It is possible there are tiny gaps which are big enough for the path finder to find a route through but too small for any unit to practically fit through.
Units are not always factored in by the path finder since unit on unit collision is more physics based. In such case I recommend placing all player controlled units on a different collision layer so they cannot be used to block the walkers.
Instead of killing the players maze in the case of a blockage, detect when they try to make a blockage (eg placing the final building to make a solid wall) and then cancel that building. This is far more user friendly as it does not heavily punish accidental blocking.