• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Picking Unit Group isnt working... :/

Status
Not open for further replies.
Level 3
Joined
Mar 30, 2013
Messages
22
Hey guys!

Since i am to retarded to use quicksort, i pick my units "by hand" as follows:

  • Order
    • Event
    • Conditions
    • Actions
      • Set TempGrp = (Units in (Playable map area) matching ((Agility of (Matching unit) (including bonuses)) Equals 10))
      • Unit Group - Pick every unit in TempGrp and do (Actions)
        • Loop - Actions
          • Unit Group - Add (Picked unit) to IniGruppen[10]
      • Custom script: call DestroyGroup (udg_TempGrp)
      • Set TempGrp = (Units in (Playable map area) matching ((Agility of (Matching unit) (including)) Equals 9))
      • Unit Group - Pick every unit in TempGrp and do (Actions)
        • Loop - Actions
          • Unit Group - Add (Picked unit) to IniGruppen[9]
      • Custom script: call DestroyGroup (udg_TempGrp)
But somehow it is NOT working. If i put 3 Units with Agility 9 on the map, and let the Game print out the number of Units in "Inigruppen9", it says 0... any help?
 
Level 4
Joined
Jan 27, 2010
Messages
133
If you don't initialize the groups in the variable editor, this will work and be leak free.

  • Set IniGruppen[10] = (Units in (Playable map area) matching ((Agility of (Matching unit) (including bonuses)) Equals 10))
  • Set IniGruppen[9] = (Units in (Playable map area) matching ((Agility of (Matching unit) (including bonuses)) Equals 9))
(If you are using 8,7,6,5 etc, you should perhaps make it a for-loop for code flexibility)
 
Level 3
Joined
Mar 30, 2013
Messages
22
Woooow, thanks guys, that was fast and it helped me so much!

but...

If you don't initialize the groups in the variable editor, this will work and be leak free.

  • Set IniGruppen[10] = (Units in (Playable map area) matching ((Agility of (Matching unit) (including bonuses)) Equals 10))
  • Set IniGruppen[9] = (Units in (Playable map area) matching ((Agility of (Matching unit) (including bonuses)) Equals 9))
(If you are using 8,7,6,5 etc, you should perhaps make it a for-loop for code flexibility)

How can that be leak free? I think it isnt, cuz u dont remove....?
 
Level 4
Joined
Jan 27, 2010
Messages
133
A memory leak is when you lose all pointers(variables) to stuff you create. For instance, Pick all Units will always create a group.

Leak, no variable pointing to first created group.
  • Set variable1 = Pick all Units blah
  • Set variable1 = Pick all Units blah
Not leak:
  • Set variable1 = Pick all Units blah
  • Set variable2 = Pick all Units blah
Not leak:
  • Set variable1 = Pick all Units blah
  • Custom script: call DestroyGroup(udg_variable1)
  • Set variable1 = Pick all Units blah
 
Level 4
Joined
Jan 27, 2010
Messages
133
It doesn't leak. If you don't null a local variable, it will make max handles rise. But it won't leak an object.

If you don't null a global variable, nothing happens (UNLESS, if you are careless and try to use it after it was destroyed). As soon as you reassign the global variable, the system automatically releases the handle id. Nulling is not necessary, and especially not in this case.

See attached map. I'm using JASS because GUI - Pick all Units... always leak a pointer.
 

Attachments

  • leakproof.w3x
    15.5 KB · Views: 37
Last edited:
It doesn't leak. If you don't null a local variable, it will make max handles rise. But it won't leak an object.

If you don't null a global variable, nothing happens (UNLESS, if you are careless and try to use it after it was destroyed). As soon as you reassign the global variable, the system automatically releases the handle id. Nulling is not necessary, and especially not in this case.

See attached map. I'm using JASS because GUI - Pick all Units... always leak a pointer.

im going off of what maker said about how it leaks.
 
Level 4
Joined
Jan 27, 2010
Messages
133
im going off of what maker said about how it leaks.

If you are referring to his post in Things that Leak, you might notice that people after him conclude that it's not really a leak when you're dealing with globals.

But please provide me with his test map, so I can deduce if my tests were flawed. I must admit I did run quite a lot of tests before producing the final test map.
 
Level 4
Joined
Jan 27, 2010
Messages
133
Holy S##t.

Wow.

Then I was wrong, and I can confirm your results. I'll post the results of your test-code in Things that leak.

PS. I did the nulling after every Remove. Is it sufficient to do it in end of function?
 
@Maker
Does this leaks too ?
  • Actions
    • Set u = Blood Mage 0000 <gen>
    • Set u = Paladin 0002 <gen>
    • Set u = Archmage 0003 <gen>
Or do you need to null each variable before assign it to new reference ?
Don't care about it. We are talking about a leak that is so goddamn minor, that BILLIONS of global reassignments are needed for only a few megabytes of memory.
Whenever you create/remove a special effect or unit, WC3 leaks a lot more memory. And you can't do anything about that, so you shouldn't care about it.
 
Level 7
Joined
Jan 22, 2013
Messages
293
Don't care about it. We are talking about a leak that is so goddamn minor, that BILLIONS of global reassignments are needed for only a few megabytes of memory.
Whenever you create/remove a special effect or unit, WC3 leaks a lot more memory. And you can't do anything about that, so you shouldn't care about it.

If you are a high quality mapper that isn't lazy, you will ensure all of your work is top of the line. If you have a problem with people not being lazy well then that is just a bad influence.
 
If you are a high quality mapper that isn't lazy, you will ensure all of your work is top of the line. If you have a problem with people not being lazy well then that is just a bad influence.
Lol, reading that from the guy that made a topic complaining why there are not enough people posting GUI problems he could assist fixing for rep...
Tell me, who of us is encouraging people to be lazy?

Seriously, some of the best coders on HIVE agreed with me about this that fixing the globals leak (we actually don't even know wether it's a real leak or just some overhead caused by having one more line of code) is not worth the additional line of code.

Also, it's a matter of style what you would consider "top of the line".
For me, "top of the line" is having practical, short, readable, fast and bugfree code. Nulling globals offends this in multiple ways.
First, it's unpractical. Second, it makes the code longer. Third, it makes the code harder to read, as it implies a global is not used again later on. Fourth, it's an additional memory operation, which makes the code slower.
Well, it doesn't offend the fifth point, at least. Also, structs in vJASS contain and compile to globals. By applying your logic, we should not use structs anymore.

Don't give me that shit about "if you are a high quality coder". I have been around hive for YEARS now and write several hundreds of lines of vJASS every single day for my project.
I rewrote entire systems with thousands of lines of code just for some minor speed increase so I don't give a jack shit what you would call a "high quality coder".
What I give a shit about, though, is people making stuff unneccessary complicated for less experienced users for the sake of a difference that they will never ever notice. It's not like WC3 suddenly starts to lag or the FPS to drop just because of 1 additional megabyte of RAM allocated per hour.
 
Level 7
Joined
Jan 22, 2013
Messages
293
Lol, reading that from the guy that made a topic complaining why there are not enough people posting GUI problems he could assist fixing for rep...
Tell me, who of us is encouraging people to be lazy?

Seriously, some of the best coders on HIVE agreed with me about this that fixing the globals leak (we actually don't even know wether it's a real leak or just some overhead caused by having one more line of code) is not worth the additional line of code.

Also, it's a matter of style what you would consider "top of the line".
For me, "top of the line" is having practical, short, readable, fast and bugfree code. Nulling globals offends this in multiple ways.
First, it's unpractical. Second, it makes the code longer. Third, it makes the code harder to read, as it implies a global is not used again later on. Fourth, it's an additional memory operation, which makes the code slower.
Well, it doesn't offend the fifth point, at least. Also, structs in vJASS contain and compile to globals. By applying your logic, we should not use structs anymore.

Don't give me that shit about "if you are a high quality coder". I have been around hive for YEARS now and write several hundreds of lines of vJASS every single day for my project.
I rewrote entire systems with thousands of lines of code just for some minor speed increase so I don't give a jack shit what you would call a "high quality coder".
What I give a shit about, though, is people making stuff unneccessary complicated for less experienced users for the sake of a difference that they will never ever notice. It's not like WC3 suddenly starts to lag or the FPS to drop just because of 1 additional megabyte of RAM allocated per hour.

Doesn't matter how long you have been here or how much you have coded. The fact is "That ignored aspect is still there after you done your work"

I clearly Offended you which was not my intention, however my point was, it shouldn't matter how small it is, it should be exterminated.

Encouraging people to ask for help isn't being lazy, it helps them learn new things after seeing if they have made any mistakes, which improves them to be become better mappers rather then lazy.
 
Doesn't matter how long you have been here or how much you have coded.
It does. There's no aspect in life where experience is a bad thing. I don't consider myself being a professional programmer, but I can say without hesitation that I got at least over ten years of programming experience.
Then, being an engineer, I need to apply common sense at work every day. And this common sense tells me, that things that are too minor to actually make any practical difference in whatever field of life, are not worth the effort.

The fact is "That ignored aspect is still there after you done your work"
True. Still, the ignored aspect, that this other ignored aspect is of absolutely no practical significance, is also still there.

I clearly Offended you which was not my intention, however my point was, it shouldn't matter how small it is, it should be exterminated.
This is pseudo-reasoning. Do you switch off the light and the television if you leave the room just to get a beer from the fridge? Neither do I. Still, you could save a lot of energy if you do that.
And this example actually does make a difference, statistics say.

Applying this model to the case of nulling globals before reassigning, the comparison should more be like: "Do you switch off the light for the fraction of a second when a lightning outside the building illuminates your living room?"
You can clearly tell this is absurd, but this is what we are facing here.

Creating just ONE SINGLE special effect and removing it already creates a leak multiple (I'd say at least a hundred) times larger than this. And you can not do anything about it.
Things like this make a difference for applications that need to run several days without restarting. This is not the case for WC3 maps. I've never seen a game lasting longer than some hours.
Encouraging people to ask for help isn't being lazy, it helps them learn new things after seeing if they have made any mistakes, which improves them to be become better mappers rather then lazy.
Depends on the approach of the helping.
Rather then "I fix the problem for you", one should go the way of "these are the problems and those are the tools to fix them. Try it on your own and then post if you succeeded!". But that's just my personal oppinion.
 
Level 7
Joined
Jan 22, 2013
Messages
293
It does. There's no aspect in life where experience is a bad thing. I don't consider myself being a professional programmer, but I can say without hesitation that I got at least over ten years of programming experience.
Then, being an engineer, I need to apply common sense at work every day. And this common sense tells me, that things that are too minor to actually make any practical difference in whatever field of life, are not worth the effort.


True. Still, the ignored aspect, that this other ignored aspect is of absolutely no practical significance, is also still there.


This is pseudo-reasoning. Do you switch off the light and the television if you leave the room just to get a beer from the fridge? Neither do I. Still, you could save a lot of energy if you do that.
And this example actually does make a difference, statistics say.

Applying this model to the case of nulling globals before reassigning, the comparison should more be like: "Do you switch off the light for the fraction of a second when a lightning outside the building illuminates your living room?"
You can clearly tell this is absurd, but this is what we are facing here.

Creating just ONE SINGLE special effect and removing it already creates a leak multiple (I'd say at least a hundred) times larger than this. And you can not do anything about it.
Things like this make a difference for applications that need to run several days without restarting. This is not the case for WC3 maps. I've never seen a game lasting longer than some hours.

Depends on the approach of the helping.
Rather then "I fix the problem for you", one should go the way of "these are the problems and those are the tools to fix them. Try it on your own and then post if you succeeded!". But that's just my personal oppinion.

Well, I must say, you just showed me how narrow minded I am on that, I appreciate that. +Rep

Very nice, I just don't recall saying experience was a bad thing.
 
Status
Not open for further replies.
Top