is there a way to figure out what type a handle is?

[Builder Bob]

Let's say I have a function like this:

function DestroyHandle takes handle h returns nothing
	if IsHandleATrigger(h) == true then
		DestroyTrigger(h)
	elseif IsHandleATimer(h) == true then
		DestroyTimer(h)
	endif
endfunction

How can I make the IsHandleATrigger() and IsHandleATimer() functions? Are there any possibilities?

 

[SFilip]

Not possible.
Though...what are you trying to do?

 

[Chocobo]

set anyhandle = null

 

[Rheias]

Note that functions like DestroyTrigger etc. can't take handles and must take only their type, meaning anyway you couldn't do it, as it would syntax you.

 

[Builder Bob]

I see... I suspected as much.

What I am trying to do? Well, nothing that specifically requires this. I just wanted to streamline things, and thought I'd see what my options were.

Now I don't have to bother continuing on that path. Thanks guys.

 

[Jazradel]

You can do this, but it's not worth it.

function Handle2Timer takes handle h returns timer t
return t
endfunction

Would convert it I think. To check what type it is, convert it and see if a native that normally takes that type has a valid return.

 

[0zaru]

that is a bad return bug

maybe like this, but i doubt that will work

function H2T takes handle h returns timer
return h
return CreateTimer()
endfunction

or maybe add a local, i don't know =P

 

[~GaLs~]

>>maybe like this, but i doubt that will work
Why create a handle?

function H2T takes handle h returns timer
    return h
    return null
endfunction

 

[Builder Bob]

Hmmm... That's just the way some of the attachment systems return values. Wonder why I didn't think about that before.

It's very interesting by the way. You say it's not worth it Jazradel. In what way do you mean? I don't know much about the return bug. Does it take more time or something to run the function compared to other functions that doesn't exploit the return bug?

 

[TheDamien]

I would not recommend you abuse the return bug for this purpose.

 

[~GaLs~]

Return Bug

 

[Builder Bob]

I would not recommend you abuse the return bug for this purpose.

I appreciate your concern, but the original post is just an example and is in no way the real way I intend to use this. In fact I don't exactly know how I want to use it yet.

However, I don't want to limit myself by not using every option I have at my disposal. By expanding my knowledge of what's possible, I can find new ways of doing things that I found difficult doing before.

Return Bug

I appreciate this. It shows exactly how you can exploit the return bug, but not what the problems about using it are. Not in words I can understand anyway.

Why the warnings about abusing it at all? I've seen it before. Is it just because it can cause crashes if used wrong, or are there any other reasons?

 

[~GaLs~]

>>Why the warnings about abusing it at all? I've seen it before. Is it just because it can cause crashes if used wrong, or are there any other reasons?
It is the handle stack issue. Damit I cant find any thread about this issue....

Handle stack is... when a handle is recycled, the attached item is still attached to the handle.

Correct me if..

 

[Cohadar]

However, I don't want to limit myself by not using every option I have at my disposal. By expanding my knowledge of what's possible, I can find new ways of doing things that I found difficult doing before.

The only problem is that since wc3 mapping is quite old discipline by now, there is a 99,9% of chance that whatever "options" you came upon have already:
* been tried, found working -> made into a system.
* been tried, found not working -> rejected.

So I would advice you to spend your time looking for what already exists,
because it is 99,9% chance that it will work better than anything you came up yourself.

Btw, H2<something> functions have been discovered to belong in "not working" category.
(except for the H2I of course)

 

[~GaLs~]

www.wc3campaigns.net
www.hiveworkshop.com
www.wc3jass.com

You would need to look into wc3c because most of those "pro" mapper gathers there and most of the problem you facing can be found there.

 

[Cohadar]

if www.wc3campaigns.net link does not work sometimes
you can use http://hilton[dot]gw[dot]oiccam[dot]com

 

[Builder Bob]

(---)
It is the handle stack issue. Damit I cant find any thread about this issue....

Handle stack is... when a handle is recycled, the attached item is still attached to the handle.
(---)

Does this mean that it's only an issue if you attach something to the handle? So it's not the functions themselves that are the problem?

Stop me when I'm wrong.

A handle is basically an integer that is pointing to an object in the game.
When we create a new object, it's assigned a random(or is there a pattern?) integer value, between somethingLow and somethingHigh. Since we only have a limited amount of integer values to assign, the handles need to be recycled. This is the root of the problem.

However. There shouldn't be any problem if we convert let's say a unit to handle (for some unknown reason), unless we store that handle over time. So let's say we want to store it over time.

The problem occurs if the unit dies, and is replaced with another. If we now convert the handle back to unit, we will get the wrong unit.

This can be worked around by a death event to set the handle to 0, and I'm sure other problems can be worked around as well.

Please correct me where I'm wrong.

The only problem is that since wc3 mapping is quite old discipline by now, there is a 99,9% of chance that whatever "options" you came upon have already:
* been tried, found working -> made into a system.
* been tried, found not working -> rejected.

(---)

I know. That's how it is in most well established disciplines. What I am saying is not that want to make any new discoveries that haven't been made by others. I am merely trying to learn why one way is chosen over another.

That's why I come here asking for help. To make what for some is common knowledge, my knowledge. I find that by asking the question "why" (something I think is far too little asked), I get a deeper understanding which in turn helps me come up with good ways of doing things much easier.

I hear what you say about looking for other people's systems, but I don't believe in blindly using other people's work simply because it works. I need to at the very least understand it, and modify it to better fit my needs if I can.

>>So I would advice you to spend your time looking for what already exists,
because it is 99,9% chance that it will work better than anything you came up yourself.

No code is perfect for every task. Everything have strengths and weaknesses, so relying on other's code completely is just limiting yourself.

 

[SFilip]

> or is there a pattern?
There always is. Computers don't know about random.

When you create an object, the game assigns a handle id for it, this is somewhat similar to an array index. The first handle id is 0x100000. If that one is already in use by another object you previously created and haven't destroyed then it tries 0x100001, if that one isn't free 0x100002 and so on until it finds one that is unused. The list of all handles is what we know as the handle stack.
Well, it probably (and hopefully) has a more efficient system than just checking every handle in the stack, but you get the idea - first unused ID.

> we will get the wrong unit.
Not necessarily a unit - it can be any handle.

However there is a much bigger problem with using return bugs, at least ones that convert integer to handle. It was proven that this typecast somewhat "confuses" the game - the way it sees it is "WTH, handle popped out of nowhere?!". This can cause handle stack corruption which in turn can make your map end up producing handles with same IDs which, at the very least, completely messes up every H2I attachment system.
H2I is safe though.

 

[Builder Bob]

> or is there a pattern?
There always is. Computers don't know about random.

When you create an object, the game assigns a handle id for it, this is somewhat similar to an array index. The first handle id is 0x100000. If that one is already in use by another object you previously created and haven't destroyed then it tries 0x100001, if that one isn't free 0x100002 and so on until it finds one that is unused. The list of all handles is what we know as the handle stack.
Well, it probably (and hopefully) has a more efficient system than just checking every handle in the stack, but you get the idea - first unused ID.

> we will get the wrong unit.
Not necessarily a unit - it can be any handle.

However there is a much bigger problem with using return bugs, at least ones that convert integer to handle. It was proven that this typecast somewhat "confuses" the game - the way it sees it is "WTH, handle popped out of nowhere?!". This can cause handle stack corruption which in turn can make your map end up producing handles with same IDs which, at the very least, completely messes up every H2I attachment system.
H2I is safe though.

Ahh! Now I'm starting to get a better picture! This explains why the old attachment systems aren't recommended anymore, and why attaching structs is safe, while handles are not. I agree that it's not possible to work around that problem.

Thanks a lot! Definitely +rep

Thanks to everyone who helped get me to understand as well

 

[Cohadar]

The reason things fuckup is because most people don't know that..

A handle is basically an integer that is pointing to an object in the game.

... is actually a false sentence.

handle is an integer pointing to a struct in Jass virtual machine:

struct Handle
    void* pointerToInGameObject
    integer referenceCounter 
endstruct

When ever you copy a variable it increases referenceCounter,
when you null a variable it decreases referenceCounter

when referenceCounter reaches zero Handle is automatically recycled.

The problem with gamecache and I2H is that converting a handle to integer will decrease referenceCounter and if you don't keep a reference in some global array the next time you try to retrieve that handle by using I2H you will be pointing to recycled handle instead of the original one == possible game crash

That is why array systems pwn gamecache, and that is why no pro mapper uses I2H any more.