System Advanced Indexing & Data Storage

[tooltiperror]

It's logical, in a way. I don't think modules are even what they sound like. Modules should be like 'oh yeah, you implement in blah blah blah' but they came out more like special textmacroes. What right now is a 'module' should be some sort of struct textmacro and then we should get real modules that initialize in a better order.

 

[13lade619]

hey J4L,

is there any way to write some debug script that forwards the name of the AIDS property when it is called/accessed?

like when some var[unit] is used the name of 'var' and 'unit' will pop on the screen.

NVM, i made it..

 

[muzzel]

Im not sure whether its a new feature in AutoIndex or you just forgot to implement this in AIDS to provide compatibility, but AIDS does not have the functions:

function IsUnitIndexed takes unit u returns boolean
function OnUnitIndexed takes IndexFunc func returns nothing
function OnUnitDeindexed takes IndexFunc func returns nothing

Can you tell me a simple painless way to write those functions? (I did not want to read through the whole AIDS code, im sry). Propably you even might want to upload a newer version of AIDS which contains these functions, I'd appreciate that.
thx

 

[Bribe]

1. That function doesn't exist, but can be replicated as:

function IsUnitIndexed takes unit u returns boolean
    return GetIndexUnit(GetUnitId(u)) == u
endfunction

2. AIDS_RegisterOnEnter
3. AIDS_RegisterOnDeallocate

 

[muzzel]

The first one is not the Problem, but anyway its easier with

function IsUnitIndexed takes unit u returns boolean
    returnGetUnitId(u) != 0
endfunction

But the other two:

function OnUnitIndexed takes IndexFunc func returns nothing
function OnUnitDeindexed takes IndexFunc func returns nothing

take a function interface as argument:

function interface IndexFunc takes unit returns nothing

The AIDS functions OnEnter and OnDeallocate Bribe posted just register triggerconditions. I cant see any simple way to register those function interfaces as trigger conditions and use GetTriggerUnit() as argument.

I know it would be easier just to use the AIDS functions, but im using a system that requires those AutoIndex functions and I do not want to change that one.

 

[Jesus4Lyf]

Unfortunately, those functions in AutoIndex actually came out well after AutoIndex support was added to AIDS. AIDS uses the AIDS struct paradigm instead (the functions mentioned by Bribe are not actually.. documented, ie. not supposed to be used). The simple solution is to write an AIDS struct which supports the OnUnitIndexed and OnUnitDeindexed functions. Not particularly hard, but I haven't the time right now. Perhaps after the 12th of Jan I will have some more, else you or somebody else can try, I'm happy to review it if someone posts a nice shot at it.

 

[tooltiperror]

Can you make it no need to use UserData()?

Very old quote, but still relevant.

I need AIDS to use stuff like Status and Damage, but the map I am editing is someone else's original work (ofc I have permission to modify it) but they use Point value everywhere. It'd be too much of a mess to try to fix it.

 

[muzzel]

You could just replace all UserData calls with Hashtable Lookups.

SetUnitUserData(u, i) -> SaveInteger(myHash, GetHandleId(u), 0, i)
GetUnitUserData(u) -> LoadInteger(myHash, GetHandleId(u), 0)

But this is like 70% slower.

 

[tooltiperror]

You could just replace all UserData calls with Hashtable Lookups.

SetUnitUserData(u, i) -> SaveInteger(myHash, GetHandleId(u), 0, i)
GetUnitUserData(u) -> LoadInteger(myHash, GetHandleId(u), 0)

But this is like 70% slower.

I guess I'll have to do that.

Thanks.

EDIT: Untested, but if anyone wants it, here it is.

 

[vuongkkk]

Damn YOU! This system is sooo goooddddddd ! + rep. :thup:
A small question:
What the hell are your brain made by Just kidding :-j

 

[Jesus4Lyf]

Thanks! I'm glad you've found it helpful.

My brain is made out of bullets.

 

[vuongkkk]

What happen if i makes 2 different struct for only one unit ? Or I should make a struct has all method.

I need speedddd !!!! more and more

 

[Bribe]

One unit will never have more than one struct. What are you worried about?

 

[tooltiperror]

Wrong, Bribe.

struct AIDSone extends array
	//! runtextmacro AIDS()
endstruct

struct AIDStwo extends array
	//! runtextmacro AIDS()
endstruct

 

[Bribe]

Yeah now I see. I couldn't understand what he was talking about

 

[vuongkkk]

yep , i know it can be. But i dont know which way is faster?

struct AIDSone extends array
	//! runtextmacro AIDS()

        method A takes nothing returns nothing
        endmethod
endstruct

struct AIDStwo extends array
	//! runtextmacro AIDS()

        method B takes nothing returns nothing
        endmethod
endstruct

OR this

struct AIDSonlyOne extends array
	//! runtextmacro AIDS()

        method A takes nothing returns nothing
        endmethod

        method B takes nothing returns nothing
        endmethod
endstruct

Because my English is NOT good so i must have a example

In the fact, my map has more than one AIDS struct for each unit (each struct for a spell)

 

[SerraAvenger]

I don't see any difference in speed? There should be only one struct id assigned to any unit at any time. One version loads faster and consumes less memory. And that's it.

My advice: Take whichever is more logical in that situation.

EDIT: Just to make sure you understand, the difference in loading time will probably be around 0.02 seconds or something.

 

[Jesus4Lyf]

In theory, merging may make units entering/leaving the map unsubstantially faster.
You can typecast between the structs, so there isn't going to be a speed difference in using them, if you do so.

I mean, depends on your use? lol

One version loads faster and consumes less memory. And that's it.

I thought that as well, until I remembered that AIDS_onCreate methods will still fire for each unit as it enters the map.

My advice: Take whichever is more logical in that situation.

/Agree. :thup:

 

[SanKakU]

surprised the system still gets attention. haven't seen a spell i can't live without that uses it...and it's overkill to do this crazy coding for every unit...u never dream of doing this crap on trees so why the special treatment for units?

best reason to use it would be it lets you use the damage system...can't you make a version that focuses solely on that?

we have multuple flavors of timerutils why not for aids like an aids that only supports the usage of damage system and does nothing else for example would be kinda nice...? or is it not so much different from current aids? or did someone already make a system or two like what i described?

 

[PurgeandFire]

It isn't doing much. Indexers are pretty light unless you are going to mass-spawn units. The thing they do is allow you to convert a unit's user data to a unique integer that is usable for arrays. (i.e. 0-8191 [and they also have some extra features, like controlling what happens on index/deindex... etc.]) Tbh, if you really don't care about speed and simplicity, just use hashtables. However, it can become annoying to manually get the kind of control that indexers have.