What is the best attachment system?

[Matrix]

Hi everyone! I'm working with structs now and I need a good system for attaching data.
So can u describe every system or at least say what's system is fastest, better and most furious.

 

[Flare]

AFAIK, CSData is the fastest attachment system, but I think it has problems with direct unit attachment (i.e. not using custom value) which can cause leaks. If you don't do unit attachment, or you can use custom value for it, that isn't gonna be much of a problem. And it has 6 handle types to which it can't attach, but you probably won't need to attach to them (read the CSData documentation to find out what they are, I can't think of them off the top of my head)

Then, there's HAIL and HSAS (they are around the same speed from what I remember). HSAS is only for struct attachment I think, not sure what it can attach to though. And it's weakness being that it will be slowed down by any handle leaks (including struct members that extend handle) to the point where you've got single-figure FPS But, it doesn't have to clear data like ABC and HAIL (I've never used CSData so I don't know if you need to clear data).

Then, there's ABC. It's the safest regarding handle leaks (they won't affect ABC in any way) but it's slower, and limited since it can only attach to timers, triggers and dialogs.

Finally, HAIL can attach any type of data that you specify (through the textmacro initializer) to any type of handle. Not sure how handle leaks affect this one though. And I'm fairly sure that it's safe to use with direct unit attachment (unless you lose the reference to the unit, and can't reset the data as a result)

 

[Hatebreeder]

You don't realy need to attach to anything else than Timers,Dialogs and Triggers... Honestly.

 

[Flare]

Attaching to units can be very useful though (I use it mainly to prevent spell stacking, but custom value isn't an option for me) And, you don't necessarily have to attach a struct, perhaps you only want to attach a single object which can be useful (let's say you want to make a timed SFX function, you can just attach the effect to a timer, and destroy it within the timer callback, without any structs). Attaching to other types may not have a huge number of uses, but it can help out

 

[chobibo]

CSData + structs + avoiding memory leaks, fast and safe.

 

[Magentix]

My preferences:

Attachment: ABC+PUI
Attachment for spells with intervals/moving particles: ABCT or TT (depends on interval)


Why all Cohadar's systems?

Even though he can act like a total dick sometimes,
- He makes his systems very user friendly (especially ABC)
- His systems (almost) never leak anything
- Protects the user from himself (Leaks/Wrong attaching)


And let's face it: Working with textmacros (HSAS) can be a pain.
(Especially since you can't have textmacros within textmacros IIRC)

 

[Uberplayer]

Magentix is so correct here.

 

[Vexorian]

CSData is the fastest attachment system, but I think it has problems with direct unit attachment (i.e. not using custom value) which can cause leaks. If you don't do unit attachment, or you can use custom value for it, that isn't gonna be much of a problem. And it has 6 handle types to which it can't attach, but you probably won't need to attach to them (read the CSData documentation to find out what they are, I can't think of them off the top of my head)

- CSData doesn't leak. No, it doesn't.
- There's absolutely nothing wrong with not using custom values to attach to units. In fact, if you are doing something to release to the public, using custom values is quite intrussive. And no, using custom values does not fix any leak.
- If you ever find yourself attaching to fake handles like unittype, lightning, ubersplat, etc, you got issues.

You don't realy need to attach to anything else than Timers,Dialogs and Triggers... Honestly.
Reply With Quote

You only need to attach to timers and dialogs. And for dialogs attaching is probably not the best solution, will try something later. There are cases in which you need to attach to units, but like 99% of the times, what you need to attach is a boolean value, then using a group and IsUnitInGroup tops anything else (yes, even SetUnitUserData, by far) And when you need to get a number from a unit, you are getting a struct id from it on an event that stops a channeling spell, then even "Table" is good enough.

He makes his systems very user friendly (especially ABC)

humbug

--
Anyway, the best attaching system is not to use any attaching. Everything out there has fatal flaws, the lesser evil being gamecache just because its flaw is that it is *slow*, unlike the other ones with their loooow limits (really, ABC is limited to 8191, CSData is limited to 400000, but that's only counting one instance of the attaching, the limits are quite low in comparison to gamecache), specificity for each handle type, lack of multi-instancibility (Really, try going text macros then the system will be terribly unfriendly and the amount of code will grow up so much... Or you could try only having three instances called A, B and C! That sounds about smart, only that the maker of a spell can't freely use them on objects that are public, so they get the same problem UserData and CSData have )

So, in all seriousness:
Best attaching systems:

• First place: No attaching.
• Second place: unit groups
• Third place: gamecache.

Of course, you could just look away of the fatal defects all attachment systems other than gamecache have, just in the name of holy speed. If speed was really so necessary, it is better not to use any of them at all. The only place in which speed is necessary is in animation timers, but then, using a single loop and an array is forever going to be faster than even Array[H2I()-minhandle] not to mention TT, or CSData.

 

[Flare]

- CSData doesn't leak. No, it doesn't.

Hmmm. I remember someone saying something about CSData losing the reference to units when they died (or fully decayed, I can't remember which) and as a result, you could have a struct instance floating around with no way to reference it.

If that is true, would the 'lost' struct not be referred to as a leak?

And if I'm completely wrong on this, sorry

 

[TheDamien]

Hmmm. I remember someone saying something about CSData losing the reference to units when they died (or fully decayed, I can't remember which) and as a result, you could have a struct instance floating around with no way to reference it.

If that is true, would the 'lost' struct not be referred to as a leak?

And if I'm completely wrong on this, sorry

The biggest danger is that the unit might be removed from the game and, another unit make take its ID and hence also the attached data. Used in a poorly designed spell/system, this might cause an error. This is the only explanation I can imagine for why custom values are meant to be "so much better" than attachment to units.

 

[Cohadar]

The best systems (not attaching, but all systems generally) are those that are user friendly and make your life easier.

And in the end no one cares what systems you used if your map is bullshit.

 

[Matrix]

I just not clearly understand
is custom value == SetUnitUserData()
coz I attach user data (some integers) to creeps

 

[Flare]

Ye, custom value is UnitUserData

 

[Hatebreeder]

Hmm.. Why not try out what System feels good to mess around with?
I personally use ABC, other use HAIL n stuff... Which I find more difficult to use...
Anyways, happy jassing =)

 

[Magentix]

In the end it's all about force of habit.

Once you found a system you're familiarized with, you'll usually stick with it until you encounter its limits or critical flaws.


After using KaTTaNa's handle vars, I stumbled upon ABC.
I liked it, it didn't require any caches to be set, so I stuck with it.

Ever since, I have always looked for Cohadar's systems (which rarely use any cache) and therefore I'm not familiar with gamecaches and hence not prone to start using them any time soon.


It's all about habits and how the thing your accustomed to suits your needs, really.

 

[TheDamien]

It's all about habits and how the thing your accustomed to suits your needs, really.

This is a very good argument against progress.

 

[Vexorian]

Hmmm. I remember someone saying something about CSData losing the reference to units when they died (or fully decayed, I can't remember which) and as a result, you could have a struct instance floating around with no way to reference it.

If that is true, would the 'lost' struct not be referred to as a leak?

And if I'm completely wrong on this, sorry

Why would you make a struct instance per unit? It doesn't sound like a good idea.

 

[chobibo]

CSData won't leak anything, it would only lose reference to a handle if you accidentally forgot to clean a leak in your spells. If handle id's get recycled properly, then a struct instance that was attached to a unit may get overwritten, no leaks, it got re-used.

 

[Cohadar]

Why would you make a struct instance per unit? It doesn't sound like a good idea.

It is if you need to have default values for attached properties: PUI Tutorial

 

[Matrix]

If I uderstand right the best are CSData and ABC+PUI

Probably I'll be using CSData

P.S. Soryy Cohadar