DataSystem

[--Thanatos--]

library DataSystem

function DataSystem_H2I takes handle h returns integer
    return h
    return 0
endfunction

//! textmacro DataSystem_Declare takes NAME, TYPE

globals
    public $TYPE$ array $NAME$1
    public $TYPE$ array $NAME$2
    public $TYPE$ array $NAME$3
endglobals

function Set$NAME$ takes handle h, $TYPE$ v returns nothing
    local integer i=DataSystem_H2I(h)-0x100000
    if (i<8191) then
        set $NAME$1<i>=v
    elseif (i&lt;16382) then
        set $NAME$2[i-8191]=v
    elseif (i&lt;24573) then
        set $NAME$3[i-16382]=v
    endif
endfunction

function Get$NAME$ takes handle h returns $TYPE$
    local integer i=DataSystem_H2I(h)-0x100000
    if (i&lt;8191) then
        return $NAME$1<i>
    elseif (i&lt;16382) then
        return $NAME$2[i-8191]
    endif
    return $NAME$3[i-16832]
endfunction
//! endtextmacro

//! runtextmacro DataSystem_Declare(&quot;Data&quot;,&quot;integer&quot;)
endlibrary

</i></i>

By Grim.

I use this for my map, but it reaches it's limit a lot of times. Any better way?

 

[Cohadar]

Omg using handles with structs :nuts:

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/jasshelpermanual.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.

 

[grim001]

ignore cohadar, he is dumb.

what you need to do is stop leaking enormous numbers of handles in your map...
you can think of this as a warning system that you're leaking severely.

if you want to take the lame way out, you could add more backup arrays to it, but 3 is seriously more than enough in the first place.

 

[Cohadar]

Correct me if I am wrong but this "system" is used to
extend the natural array limit of 8192 integers
and store untyped data in this new big array.

Disregarding the fact that untyped data is ALWAYS a bad idea,
could you explain to me why are you using handle as an array index?
and where did you get the idea that all handles have values grater than 0x100000 ?

 

[Steel]

I don't really see a practical use for this. Grim as you said, if you are overloading this, trying to create more space is the least of your worries.

 

[grim001]

it's clear you have no idea what this does... it's a textmacro that allows you to generate functions that will attach any type to a handle with "SetWhatever(handle, type)" and "GetWhatever(handle, type)"

its primary purpose is to attach integers (structs) to handles, especially structs relating to systems as you can make the function name reflect what kind of struct you are getting from the handle. if you just want to attach integer to timer I have a better system for that, but attaching to timers is rarely necessary.

as for the rest of your guesses, they make no sense, so I'll ignore them.

 

[substance]

By Grim.

I use this for my map, but it reaches it's limit a lot of times. Any better way?

Either you using this uncorrectly or you have an absurd amount of handle leaks probably due to a fast periodic timer.

 

[Cohadar]

First it would be nice of you to post the original page of this system
so I don't have to guess whet it does...

Second where did you get the idea that all handles are greater than 0x100000 ?

And third why would anyone want to attach a struct to a custom handle.

The only handles that make any sense of struct attachments
are units and items, and for those I use custom data
for placing structs.
And for timers you can use global timer array
and parallel array for timer data.

Ok maybe this system has some grater purpose that I failed to grasp,
like I said, post original page so we can read....

 

[substance]

It's been disccussed a few times here, but more recently in this thread.

 

[grim001]

Second where did you get the idea that all handles are greater than 0x100000 ?

Because they are.

And third why would anyone want to attach a struct to a custom handle.

There's no such thing as a "custom handle," I don't know what you're talking about.

The only handles that make any sense of struct attachments are units and items, and for those I use custom data
for placing structs.

Guess you've never made dynamic triggers before. And there's only 1 custom data on a unit. What happens if you import a new system that also wants to use custom data?

And for timers you can use global timer array
and parallel array for timer data.

Global timer array? You suggest looping through 100 timers to see which one it matches when a timer expires? Sounds slow.
What you SHOULD have said is that you can use a global struct/integer array and loop through them on each iteration.
That doesn't work if the expiration time varies.

like I said, post original page so we can read....

I didn't even release this system, people are just using it, and I have no doubt some people are using it incorrectly...

 

[--Thanatos--]

So what the hell.

I spam my spells which create a number of units trailing the target with a Timer of 0.04. The units' fading use this.. So how the hell.

In my map, I use BJDebugMsg(I2S(i)) to display the current i, but they seemed to raise by 300 every time I use SetData().

But well, if I did any mistakes, I probably doesn't understand this system that far. >_>

 

[Cohadar]

Because they are.

Really smart answer, and if I asked what makes you think that
handles have values lesser than ( 0x100000 + 8192*3)
you would answer the same?

Those are some really bad assumptions about handles unless you have
a proof than all handles are in range (1048576 .. 1073152) ?

There's no such thing as a "custom handle," I don't know what you're talking about.

custom handle is a handle with no type, JASS calls it simply a handle
also referred to as a "void pointer" in some languages

Guess you've never made dynamic triggers before. And there's only 1 custom data on a unit.

Stop insulting me only because I question the use of your system asshole.

What happens if you import a new system that also wants to use custom data?

I add that data to already existing struct for units/items.

Global timer array? You suggest looping through 100 timers to see which one it matches when a timer expires? Sounds slow.
What you SHOULD have said is that you can use a global struct/integer array and loop through them on each iteration.
That doesn't work if the expiration time varies.

for loop of 100 iterations on 1GHz computer
lasts (100/2^20) = 95 nanoseconds

I didn't even release this system, people are just using it, and I have no doubt some people are using it incorrectly...

I suggest you double check the numbers you are using in your system.

 

[grim001]

It's not even worth the time to talk to you, go figure out things on your own instead of expecting me to educate you.

But well, if I did any mistakes, I probably doesn't understand this system that far. >_>

The mistake has nothing to do with where you use the engine, it has to do with your entire map leaking handles.

 

[Cohadar]

So what the hell.

I spam my spells which create a number of units trailing the target with a Timer of 0.04. The units' fading use this.. So how the hell.

In my map, I use BJDebugMsg(I2S(i)) to display the current i, but they seemed to raise by 300 every time I use SetData().

But well, if I did any mistakes, I probably doesn't understand this system that far. >_>

Actually you made no mistakes Thanatos,
It is true that handle numbers start from 0x100000
The only problem here is that handles never go backwards.

Whenever you create a unit it gets a new handle number 0x100001
when you create new item on the map it gets a next number 0x100002
when you pick some units in group, that group gets a next number 0x100003

whenever you do something in your map that needs a handle it gets a next number.

It does not matter if you destroy that group or unit properly
even if you null them, game will never use old handlers again
until it runs out of memory completely and starts counting from the beginning.

Therefore it does not matter if you put

public $TYPE$ array $NAME$1
public $TYPE$ array $NAME$2
public $TYPE$ array $NAME$3
...
public $TYPE$ array $NAME$500

no matter how absurdly lot of memory you use to store handles
it will eventually break the limit.

So it is not your leak problem, it is grim's brain problem.

And to prove that I am not just bullshitting here, here is a testmap.

 

[TheDamien]

Actually you made no mistakes Thanatos,
It is true that handle numbers start from 0x100000
The only problem here is that handles never go backwards.

Whenever you create a unit it gets a new handle number 0x100001
when you create new item on the map it gets a next number 0x100002
when you pick some units in group, that group gets a next number 0x100003

whenever you do something in your map that needs a handle it gets a next number.

This is false, I am afraid.

When a handle is removed properly, its ID is taken by the next handle to be created.

I have attached a map that demonstrates this.

Edit: (I suspect what is happening in Than's map is that local variables are not being nulled.)

Another Edit: I have just looked at Cohadar's test map. Handle IDs are increasing because units are being killed instead of removed. Eventually, though, the count will drop right down as corpses decay and the units are finally removed.

 

[Cohadar]

This is false, I am afraid.

When a handle is removed properly, its ID is taken by the next handle to be created.

I have attached a map that demonstrates this.

Edit: (I suspect what is happening in Than's map is that local variables are not being nulled.)

Nope, your test map is a bad example.
The reason handle is recycling in your map is because
it has only one variable and nothing else.

This never happens in real maps because they usually don't destroy data right after it is created, that's why I have 2 kinds of creation in my test map
one for units and one for groups.

Test more seriously before you come to conclusions.

 

[TheDamien]

Nope, your test map is a bad example.
The reason handle is recycling in your map is because
it has only one variable and nothing else.

This never happens in real maps because they usually don't destroy data right after it is created, that's why I have 2 kinds of creation in my test map
one for units and one for groups.

Test more seriously before you come to conclusions.

In this case your condescension is misplaced.

You are not removing the units in your test map, you are merely killing them. Edit your map to remove units instead of killing them, or set the peasants to "Can't Raise, Does not Decay", and you will see no incrementing Handle Id's.

 

[grim001]

Why is it that people who are totally wrong are the most sure they're correct?

 

[Cohadar]

This is false, I am afraid.

When a handle is removed properly, its ID is taken by the next handle to be created.

I have attached a map that demonstrates this.

Actually your map is a bad test example.
It has only one trigger and only one creation of unit.
In real maps there are much more activity
that is why I added 2 creation sequences in my trigger
(one for units, one for groups)

The reason handles are recycled in your map is
simply because you have only one creation and immediate destruction
so the handles stay within same "memory page" and "garbage collector"
is able to recycle memory on that instant.

That never happens in real maps.

Another Edit: I have just looked at Cohadar's test map. Handle IDs are increasing because units are being killed instead of removed. Eventually, though, the count will drop right down as corpses decay and the units are finally removed.

Actually count will never drop down in my test map,
or any real map for that matter.

And out of pure amusement I modified my map to use
unit removal from your map and it is still the same.

 

[Cohadar]

In this case your condescension is misplaced.

You are not removing the units in your test map, you are merely killing them. Edit your map to remove units instead of killing them, or set the peasants to "Can't Raise, Does not Decay", and you will see no incrementing Handle Id's.

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 ?