Joined: February 14th, 2018, 5:35 am Posts: 1787
Title: Just Another S.Mod
What is NewGen?
It's JJ2197's cheatpack remade by nuzamacuxe.
Why did you remade it?
Because the old one wasn't well coded, had potential leaks and some commands weren't working correctly (example: autoh).
But have you changed everything?
No. I tried to not change for example the command names since some people would be confused saying that x command isn't working. But I removed some useless commands like: area, noarea, dead, birth, stand, attack, regmin, regmax, reg, ground, spa, destid.
To check the command list you mustinput a space after list command. Example: -list 1
What changes were made then?
- Don't need to type "-note", "-nomana", "-cdon" to disable those commands anymore. To disable teleport command, for example, you just need to type "-tele" again; - Autohealworks properly and it's MUI now (can handle multiples units); - Code is way better than before; - Supportsarrow activator; - Name activator is visible and easy to change; - It now uses group recycle instead of create and destroy group; - No leaks and lightweight; - Easy to add new commands; - New commands: stats (adds # to all your stats), clear (clear your screen), ploc (pings x y location); - Now you can changeteleport key to A or M; - Compatible with latest Warcraft III version; - Now you can change the operator symboleasily.
Could you show me the code difference?
Sure.
ACTIVATOR: -wc3edit
You do not have the required permissions to view the files attached to this post.
Very nice! Looks much cleaner even with just a quick glance over it. No more dynamic triggers and WaitForString calls. Small efficiency comment: I'd make these commands use elseif rather than "endif/then" like this:
Code:
if command == "debuff" then call UnitRemoveBuffs( jjUnit, true, true ) endif if command == "heal" then call UnitRestoreLife( jjUnit, UnitMaxLife( jjUnit ) ) endif
That way we can save computation on evaluating these ifs
Here's a version of this with nice formatting (tabbed in on code blocks) for reading purposes.
Attachment:
JJCP-New-Formatted.j
And here's a version of this with the names scrambled up and randomized so that it won't collide with any variables/functions (avoids basic anti cheat)
Attachment:
JJCP-New-Scrambled.j
You do not have the required permissions to view the files attached to this post.
Joined: February 14th, 2018, 5:35 am Posts: 1787
Title: Just Another S.Mod
Thanks guys.
owner123 wrote:
Very nice! Looks much cleaner even with just a quick glance over it. No more dynamic triggers and WaitForString calls. Small efficiency comment: I'd make these commands use elseif rather than "endif/then" like this:
...
That way we can save computation on evaluating these ifs
Thanks for suggestion. I got what you mean, but grouping commands (at least when we are talking about Warcraft) in general is useless. xD
Joined: February 24th, 2009, 1:31 pm Posts: 3810 Location: JEW LAND
Good job, great to see updates to old CPs and keeping it alive!
nuzamacuxe wrote:
- It now uses group recycle instead of create and destroy group;
Why not destroy the group after use? From what I read in the code (and I could be wrong as I looked at a notepad on my phone..), the group is now a global variable that keeps on getting the units called upon and then removing the units (as was previously).
Isn't that a "waste of space" - as while the variable isnt being used it is still taking place (also taking space in the heap and not the stack? not sure how jass works but meh).
Just curious as I have NOT been using jass for some time now. Seems like a lot of new optimization have been made
Joined: February 14th, 2018, 5:35 am Posts: 1787
Title: Just Another S.Mod
Thanks, haxorico.
Because it's inefficient.
No, using a global group more than once by emptying it everytime will not cause any leaks nor "waste of space". Since I use pure jass to code, it's just better to use a global group and recycle it. GUI is different though.
Joined: February 24th, 2009, 1:31 pm Posts: 3810 Location: JEW LAND
nuzamacuxe wrote:
Thanks, haxorico.
Because it's inefficient.
No, using a global group more than once by emptying it everytime will not cause any leaks nor "waste of space". Since I use pure jass to code, it's just better to use a global group and recycle it. GUI is different though.
Not talking about leaks, more about general coding. For example, if I have a program with many different functions and loops (as many big projects have). I will not use a single global integer called "i" or "index" that will be set to a starting value (like 0) at the beginning of each loop. As while no loop is using it, it is just some data that is sitting waiting and taking space.
When I need to use some data, I create it and when it is finished, destroy it.
Example for a cheatpack, is aslong as the game is running, even if I am not using the cheat-pack (as I am a user who is unaware), there is data taking space (the group is still being created, an empty group is still taking some space).
Anyway i'm just rambling, just my two cents, need someone like Dekar who will probably have more formal information on the matter (maybe Ken/FatherSpace?).
Very nice! Looks much cleaner even with just a quick glance over it. No more dynamic triggers and WaitForString calls. Small efficiency comment: I'd make these commands use elseif rather than "endif/then" like this:
Code:
if command == "debuff" then call UnitRemoveBuffs( jjUnit, true, true ) endif if command == "heal" then call UnitRestoreLife( jjUnit, UnitMaxLife( jjUnit ) ) endif
That way we can save computation on evaluating these ifs
Well, WC3 has a limit of about 50 elseifs or maybe a bit higher, I have actually run into a limit, when I was rewriting VIP system for NRPG, so I would actually suggest avoid using it, instead it's better to add return in the if statement to exit from the thread upon completion, or just leave it as is. Aka in WC3 elseif is still read as a separate if, and the lower you go the more "paths" it generates.
haxorico wrote:
Not talking about leaks, more about general coding. For example, if I have a program with many different functions and loops (as many big projects have).
That is not really correct, every time a CreateGroup or DestroyGroup is called, WC3 is re-allocating memory, aka trying to free whatever was occupied and shifts it, to the changes. That also includes the shifting of arrays and so on, which is not really ideal. Don't forget JASS only stores pointers, not the "objects" themselves. A Group is simply a dynamic array, that doesn't accept repeating entries, so there is no real point in destroying it, if it is used as a temporary group, which we can see in:
The point is, you don't need to destroy a group that will be used frequently, but you should destroy a group that probably will never be used again, if it is used in something like MUI spells. The same reasoning applies even to C++, you generally want to avoid re-creating variables if they don't really serve any purpose (although C++ has a much better garbage collector than what Warcraft 3 has, but oh well).
And now for the natives, I am using 1.26a offsets, CreateGroup ( GameDll + 0x3D2900 ) and DestroyGroup ( GameDll + 0x3C3FA0 ):
Spoiler for CreateGroup:
Attachment:
CreateGroup.png
Spoiler for DestroyGroup:
Attachment:
DestroyGroup_2.png
Attachment:
DestroyGroup.png
haxorico wrote:
I will not use a single global integer called "i" or "index" that will be set to a starting value (like 0) at the beginning of each loop. As while no loop is using it, it is just some data that is sitting waiting and taking space. When I need to use some data, I create it and when it is finished, destroy it.
You are comparing completely different types of variables, however, yes, with this example it is indeed better to get rid of unused variables, which I have stated above
haxorico wrote:
Example for a cheatpack, is aslong as the game is running, even if I am not using the cheat-pack (as I am a user who is unaware), there is data taking space (the group is still being created, an empty group is still taking some space).
Well, same goes for any of the code, right? User will never be aware of what is happening "under the hood" until he takes a peek.
You do not have the required permissions to view the files attached to this post.
Users browsing this forum: testsubject and 3 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum