Snippet Typecasting

[vercas]

You can generally use a Table instead of a HashTable.

This just removes a HashTable from the map!

 

[Troll-Brain]

Nowadays typecasting is out of date, we have struct and such now, imho this library is only useful to repair broken old maps which used gamecache and return bug. (for lazy ass and not speed freaks)

So this "problem" is totally irrelevant, since these kind of maps didn't use an hashtable for the following really decent reason : it didn't existed yet

I mean don't use this library in new maps, or anyway if you care that much you can edit it for yourself.
Or kingkingyyk3 could "requires optional Table" *shrugs*

 

[kingkingyyk3]

//  ====================================
//   Functions provided :
//  ====================================
//  Agent2Widget(agent) -> widget
//  Agent2Group(agent) -> group
//  Agent2Trigger(agent) -> trigger
//  Agent2Timer(agent) -> timer
//  Agent2Location(agent) -> location
//  Agent2Effect(agent) -> effect
//  Agent2Unit(agent) -> unit
//  Agent2Item(agent) -> item
//  Widget2Unit(widget) -> unit
//  Widget2Destructable(widget) -> destructable
//  Widget2Item(widget) -> item

Table is not open for saving handles.

 

[Troll-Brain]

With an HandleTable and one global variable per handle type, like "widget", "location" and so one, it should work.
But that's not the most important thing.

Honestly kinkingyyk3, do you think about any other valid purpose other than fixing old maps which use the return bug and no hashtables ?

Anyway, we are talking about one hashtable only for a such generic code, so if you hurt the limit of 256 hashtable you are probably doing something wrong.

 

[kingkingyyk3]

With an HandleTable and one global variable per handle type, like "widget", "location" and so one, it should work.

If you are sure on this, please post a demo.

Honestly kinkingyyk3, do you think about any other valid purpose other than fixing old maps which use the return bug and no hashtables ?

It is useful for converting. Just like getting dead items from item death event.

Anyway, we are talking about one hashtable only for a such generic code, so if you hurt the limit of 256 hashtable you are probably doing something wrong.

I don't think you can hit the limit.
If you hit it, you are doing something wrong.

 

[Troll-Brain]

If you are sure on this, please post a demo.

No i am not sure, just a theory, and i can't test it (i mean i can't use vJass, well i could do it in jass but meh ...)

EDIT :
Ok it can be done but with some fancy stuff, including a struct, arrays, and so one, i forgotten that Table returns an integer not an handle, so nevermind.

But remember me, are we still allowed to do that ?

set agentOrHandleVariable = unitVariable

It is useful for converting. Just like getting dead items from item death event.

I said "honestly".
If you are talking about the widget death event if you don't know what sort of widget die when the event fire, then you will probably have other bigger problems.
And without typecasting, you still can know which type of widget is dying, simply because the other event responses will return null, at least this way is not an exploit of a bug.

 

[kingkingyyk3]

And without typecasting, you still can know which type of widget is dying, simply because the other event responses will return null, at least this way is not an exploit of a bug.

Proof? Any native of return dying items other than using typecasting+GetTriggerWidget()?

 

[Troll-Brain]

Ok ok, it seems that Blizzard has forgotten the event response for the item, we have it for destructable and unit though.
Anyway you could still use an hashtable in a safe way :

http://www.wc3c.net/showthread.php?t=106307

 

[kingkingyyk3]

It does same functionality with Typecasting, did you realize that?

 

[Troll-Brain]

It does same functionality with Typecasting, did you realize that?

No i didn't, sorry.
But still, i would use only the typecast widget -> item.

 

[luorax]

Table is not open for saving handles.

The new Table is ready to save handles.
So what about a Table version now?

 

[Laiev]

the new Table is not 100% compatible with old table... lol

I dislike it...

People like to use the same name as other resources but don't make 100% compatibility

 

[luorax]

I don't get you... adding a Table version will not change the original system. You can still use the original one, if you have the old Table and don't wanna change (however it's worth to change)

Also, the whole system is like two textmacro. It could be easily done with some static ifs.