DataSystem

[Tom Jones]

And I suppose we must all change all our units in all our maps
to "Can't Raise, Does not Decay" just so we can use grim's system ?

Not just so you can use grims systems, but generally it's a better idea to give dummy units that death description. Also a trigger that removes a unit 2-3 seconds after it dies is also a good idea.

 

[TheDamien]

Once again, the units are not being removed when you kill them. In my map, I set the peasants to "Can't Raise, Does not Decay" so that they would be removed after dying. Remember, a decaying unit is still a unit.

I have also now added multiple variables to my test map. You will see that the Handle IDs for each variable are being recycled.

 

[Cohadar]

Once again, the units are not being removed when you kill them. In my map, I set the peasants to "Can't Raise, Does not Decay" so that they would be removed after dying. Remember, a decaying unit is still a unit.

I have also now added multiple variables to my test map. You will see that the Handle IDs for each variable are being recycled.

Stop using false test maps,
when you set units to "Can't Raise, Does not Decay" you fake the map conditions in your favor
it is called "experiment adjustment" and is regarded as fallacy.

Also Decay is not the only reason the counters keep incrementing,
whenever you create some handles that are destroyed
after "page size" handles have been created after them it will
stop garbage collector from reseting the counter.

There is no real way to control this in any real map.

So basically what I am saying is that Grim's system has a nice starting idea,
but it's true realization is impossible because it has unrealistic prerequisites
to function properly.

It is like selling a car that looks like ferrari and works like ferrari
but you have to change it's engine-oil every half hour or it will crash and kill you.

EDIT:

To answer to Tom:
giving dummy units not-Decay is ok, but expecting that to be applied on all units is too much,
also killed units are removed automatically by wc3 88 seconds after they die,
(this can be seen in gameplay constants as you know)
so it is not a real reason for handles not recycling.

EDIT 2:
So lets be precise now and get this thing to the end already.
Lets assume that wc3 "memory page" is 8192 integers long (it can be different I am not sure)
so we create some handles in that page and than destroy them and null them.

But if only ONE handle in that page is still there
(some global variable you are using or any handle that is used for a longer period of time)
the garbage collector will be unable to recycle the rest of 8191 handles because it can
recycle only whole pages.

So it basically takes only 3 variables on wrong places to fuckup Grim's system.

 

[TheDamien]

Stop using false test maps,
when you set units to "Can't Raise, Does not Decay" you fake the map conditions in your favor
it is called "experiment adjustment" and is regarded as fallacy.

Also Decay is not the only reason the counters keep incrementing,
whenever you create some handles that are destroyed
after "page size" handles have been created after them it will
stop garbage collector from reseting the counter.

Sigh.

How exactly do I "fake" the "map conditions" in my favour by ensuring all my handles are removed? Seems to be common sense considering the fact that I'm testing whether unused Handle IDs are recycled.

 

[Cohadar]

I edited my previous post just now, take a look

 

[grim001]

Good map makers have been making maps that stay within a reasonable handle range forever, bad map makers have been leaking forever.

A gamecache backup could be added to prevent it from ever failing (as in CSData), but I think it serves a better purpose as a leak detector.

No one really cares about your made-up nonsense Cohadar. I'm not gonna reply to this thread anymore.

 

[Cohadar]

Like I said it hasn't got anything to do with leaks,
the problem is in some bad assumptions your system has.

I don't make thins up, and I have given enough of proof
in my testmaps, and you will realize I am right as soon as you
find out what garbage collector is and how it works,
use google ffs.

I understand you are pissed off because it is your system,
but it has some flaws none the less.

 

[TheDamien]

I agree with grim. Sorry, but this is getting ridiculous. As far as any reasonable mapmaker should be concerned, Handle IDs are recycled, and that is final.

 

[Cohadar]

I agree with grim. Sorry, but this is getting ridiculous. As far as any reasonable mapmaker should be concerned, Handle IDs are recycled, and that is final.

I agree with you handles are indeed recycled in all leak-free maps,
it is just that it does not have to be the first 3*8192 handles that get
to be recycled first and that is the main problem here.

Stuff like this are really tricky and there is great probability that map with
this system will work in 90% of cases, but there is also that 10%
that happens completely at random and is impossible to debug.

If you ask me it is too unpredictable.

Besides there are better ways to make a Data storage system....

 

[--Thanatos--]

...

I think I'd better just ask; why the hell in my map it raises by hundreds every DebugMsg()?

Now, here's an example of mine:

5573
3446
5574
3440
5575
3434
5576
3428
5577
3422

looks like the 5k are rising and a 3k for the reverse.

Also:
Forgot to read your first post.

Omg using handles with structs

The whole point of structs is that you don't have to use handles any more,
in fact structs were created because people got sick of handles.

There are like 10000000 better ways.

I advise you (and everyone else) to do the following:

read this ffs: http://www.wc3campaigns.net/vexorian...permanual.html

than spend 3 days (or more) making test maps in witch you will
experiment with examples from that page and learning vJASS.

True knowledge only comes with hard work,
that is the price you must pay, but IT WILL BE WORTH IT

Read that "enough" times.

EDIT again: your attachments are all just doing the same mistake I did on my map; Handle IDs raising by stupid value every use. Ok, so, I'm asking a suggestion, what should I do?

 

[Tom Jones]

Care to clarify some more? If your wondering why your ids increases insanely, you probaly have a lot of memory leaks.

 

[SFilip]

> where did you get the idea that all handles are greater than 0x100000 ?
Probably from Vexorian's CSCache which uses a similar method.

In fact CSCache has a simple solution for your problem:

    function SetCSData takes handle h, integer v returns nothing
     local integer i=CS_H2I(h)-0x100000
        if (i>=8191) then
            call StoreInteger(cs_cache,"csdata",I2S(i),v)
        else
            set cs_array3<i>=v
        endif
    endfunction

    function GetCSData takes handle h returns integer
     local integer i=CS_H2I(h)-0x100000
        if (i&gt;=8191) then
            //can&#039;t use Get without Set
            return GetStoredInteger(cs_cache,&quot;csdata&quot;,I2S(i))
        endif
     return cs_array3<i>
    endfunction</i></i>

As you can see if the number of handles is too high then gamecache is used. But as said in the comments above this code: "...if you have more than 8191 handles your map is too slow already anyways."

As for handle ids increasing and all...consider the following code:

function Trig_Initialization_Actions takes nothing returns nothing
	local integer i = 0
	local group g
	loop
		set g = CreateGroup()
		call BJDebugMsg(I2S(H2I(g)))
		call DestroyGroup(g)
		set i = i + 1
		exitwhen i == 10
	endloop
	set g = null
endfunction

In an empty map this caused 10 different numbers to appear, each being higher than the one before it by 1.
However there is was leak here as you can see...

Now consider the following:

function myfunc takes nothing returns nothing
	local group g = CreateGroup()
	call BJDebugMsg(I2S(H2I(g)-0x100000))
	call DestroyGroup(g)
	set g = null
endfunction

This function returned one of two numbers (one being higher than another again by 1), but always the same two (103 and 104 for example).
After removing that set g = null the function always returned a number higher than the one before.

Conclusions:
-the ways of the WC3 engine are still unknown and can't be predicted
-nulling seems to be very important here
-leaks and whether you destroyed them or not do not seem to be so important on the other hand
-a system based on H2I(somehandle)-0x100000 is not safe unless there is a backup storage

 

[Rheias]

Sorry for asking this but... What's 0x100000? I understand it is a certain integer, but how big is it?

 

[SFilip]

0x is a prefix for hexadecimal numbers.
100000 is a hexadecimal equivalent to 1048576. This is the id of the first handle created in a map.

 

[substance]

So basically what I am saying is that Grim's system has a nice starting idea,
but it's true realization is impossible because it has unrealistic prerequisites
to function properly.

Well, I've been using it in my map for about 2 months now and the longest a game has lasted was 48 minutes and I've never had any problems.

So if by 'unrealistic prerequisites' you mean nulling and destroying leaks, then yes, you're right.

 

[Cohadar]

I was literally pissed enough to do this even if I don't need it.

http://www.thehelper.net/forums/showthread.php?p=505008#post505008

EDIT:

 As you can see if the number of handles is too high then gamecache is used. But as said in the comments above this code: "...if you have more than 8191 handles your map is too slow already anyways."

Who will add gamecache into grim's system?

 

[grim001]

the purpose of this system is not DATA STORAGE, it's ENCAPSULATION. if you just want to attach integers to handles go ahead and use I2H + gamecache native and it'll be just as fast or faster.

the reason it was keeping things in arrays was to maintain a reference to handles (when used for that), but with the ubiquity of structs nowdays, that functionality is redundant. that's why I didn't really release it in the first place.

nowdays it would work better if it were just a textmacro to generate wrapper functions for attaching/getting an int to/from a handle using gamecache.

but as for the way it was presented in this thread, it does what it's supposed to do with no problems whatsoever assuming you don't have absurd numbers of leaks. SFilip, such a tiny test isn't adequate, a better test is to observe how handle IDs fluxuate over the full course of a leakless map... they will never get anywhere close to this limit. but arguing over a mostly-obsolete function that I don't even use is pretty dumb.

as for Cohadar's system, any convoluted system that exists solely for the purpose of attaching ints is pretty pointless since it's not going to beat using gamecache natives by any significant margin. the only other concern besides speed is encapsulation, which isn't satisfied by this system, you will still get conflicts between different systems which want to utilize it.

 

[Cohadar]

the reason it was keeping things in arrays was to maintain a reference to handles (when used for that), but with the ubiquity of structs nowdays, that functionality is redundant. that's why I didn't really release it in the first place.

I could not agree more, like I said in the beginning structs made gameceche totally obsolete.

And like I said even I don't need my own system because I have one based on
custom value that is working just fine.

All I was trying to prove here is what SFilip condensed in one line

-a system based on H2I(somehandle)-0x100000 is not safe unless there is a backup storage

PS: my system is faster than gamecache
of course that is because it has much less functionalities
but when it comes to storing integers in handles it is unbeatable.

 

[grim001]

I won't believe it unless you have benchmarks, because gamecache natives are fast.

and the only thing you're "safe" from is being notified that you have enormous leaks

 

[Cohadar]

Actually you can see it for yourself

    if (Structs[i] == 0) then
        set Structs[i] = s
        set Handles[i] = h
        set Counter = Counter + 1
        return
    else

in 99,9% of cases get/set methods never get pass that else statement
so my function are basically some operations and an if statement in a function call, it doesn't get much faster than that.

And CS_Cashe is using string for storing data if I remember it correctly
witch means he has to do similar hashing routine like my system
just on strings while I do it with integers,
so it does not really matter if it uses native functions
they are approximately the same.

Of course like I said CS_Cashe can do much more things
while I can store only integers.

I also have leak detection system of my own,
a simple debug function that displays handle values
it is simple as that.
And I think I have proven myself as someone who knows how to avoid leaks.

So after all this nonsense we can finally conclude that
I am not dumb, and that I was actually correct in my first post.

Stay away from CS_Cashe and use structs as much as possible.
or better said: Live long and prosper.