Page 1 of 1

[Deprotection] I have stumbled upon a problem

Posted: September 29th, 2015, 3:45 pm
by Dissed
Hello, definitely glad to see you guys still here. One of the best communities around.

Though I just can't seem to figure out what I am doing wrong, even followed steps from every tutorial I could find yet nothing seems to work. Could it be just that the map's .j is un-recoverable?
I recovered everything except the .w3i which is impossible unless the map didn't have a single line of jass in it. Would appreciate any help on this matter, thank you for taking the time to read.

Attached the map/file in question, I seem to be having issues with the $ trick.

Edit: Added the .j script since that's the only problem.

Edit2: Re-added map file

Re: [Deprotection] I have stumbled upon a problem

Posted: September 30th, 2015, 6:36 am
by NumberXIII
what are you trying to do??

Re: [Deprotection] I have stumbled upon a problem

Posted: September 30th, 2015, 3:21 pm
by Dissed
Trying to fix the script and be able to save it, newgen or a custom terrain/data file is required to save it.

Re: [Deprotection] I have stumbled upon a problem

Posted: October 5th, 2015, 4:05 pm
by Dissed
Any luck anyone?

Re: [Deprotection] I have stumbled upon a problem

Posted: October 5th, 2015, 4:22 pm
by haxorico
interesting, this is something i haven't encountered before. But I bet it is just a sort of anti-cheats and SHOULD be ignored.

Anyway, the $ sign converts hex-decimal to decimal, so $A = 10 etc..
Now a problem I saw in the code is "$udg_force01", and I checked, it is a force variable, meaning it has no integer (to my knoledge). Also the syntax itself makes no sense

Code: Select all

set rO=rO+1
exitwhen rO>$udg_force01

rO is clearly an integer (it also stats that in the code), so how can you check if an integer is bigger than a force...
It could either be an anti-cheat OR, it counts all the units in that specific force, lets say you have 5 heroes in that force variable, it will be set to 10, and the $ sign could just be a quick convert. It is interesting, but after trying to test, map didn't work. So I guess it is a simple Anti-Cheat.
Can't test as I don't have the map.

Edit: there is also $ on an integer variable that is always either 0 or 1848651824, and as far as I know, there is no "Player(1848651824)" so it has to be 0. and the $ is there for no reason that I can understand

Re: [Deprotection] I have stumbled upon a problem

Posted: October 5th, 2015, 9:50 pm
by Dissed
Yeah there was a bit of confusing stuff in there, thanks for looking at it. I also forgot to re-add the map, my bad.

I used an un-hexing(useful-tools-f69/hex-fixer-v27-lastupdate-14-06-2014-t26236.html) tool and it didn't work apparently so I guess I will have to go through the entire script manually? What do you do with $udg...?

Re: [Deprotection] I have stumbled upon a problem

Posted: October 5th, 2015, 10:45 pm
by haxorico
Dissed wrote:Yeah there was a bit of confusing stuff in there, thanks for looking at it. I also forgot to re-add the map, my bad.

I used an un-hexing(useful-tools-f69/hex-fixer-v27-lastupdate-14-06-2014-t26236.html) tool and it didn't work apparently so I guess I will have to go through the entire script manually? What do you do with $udg...?

My advice? I would just replace them with a number I think is right, depending on the code, and see how and if it affects the map.
Unhex tool wont with this problem as the tool doesn't know how to convert udg_integer2 (example..)