System Faster Table

[Jesus4Lyf]

Fair enough. Just pointing out the fallacy of assuming H2I(x)-MIN_HANDLE is secure.

(I'm off to bed. Wonder if mods will shut this discussion down before tomorrow... It's been fun... )

 

[Troll-Brain]

Hmm i'm lost, i don't see how you can preload it, since they are dynamic triggers.
An example ?

 

[Viikuna]

Fair enough. Just pointing out the fallacy of assuming H2I(x)-MIN_HANDLE is secure.

Yea, I see that you are right. I just didnt think that someone could fuck up that baddly.

That idea of using TriggerExec count for attaching triggers, is pretty neat idea, actually. I have to keep it in mind, in case I need to attach something for trigger someday.

The wonderful thing is KT2 is faster to code with, and stable.

Stable, but not more stable than struct arrays.
OK, its faster to code with, so I guess it has its uses for coding spells that need periodic timers.

Still, it cant replace H2I based timer attaching entirely. ( If I remember correctly, this is from where this discussion started )

edit. Studied KT2 a bit. It looks pretty cool actually, and now I remember why I didnt read it trought at the first time. Your code is pretty hard to read, because of those variable names. I actually need to read them to separate them from each other, instead of just looking at them.

Anyways, I might end up writing something similiar, because this looks pretty neat...

 

[Romek]

//
        // A "protected" keyword would've been really nice here.
        // Don't play with "base" in your map.
        // Looking for ideas on how to protect it, still.
        string base

How about "readonly string base"?
It's better than nothing.

And, if this is only 10% faster than Table, then it really isn't worth it.

 

[Builder Bob]

And, if this is only 10% faster than Table, then it really isn't worth it.

Unless you can mention a drawback, I see this as definite improvement and absolutely worth it when using Table.


Since I can't see any (drawback), I'll just give support - Well done Jesus4Lyf!

 

[Azlier]

Well, it erases itself after you save/load the game. I don't think 10% justifies that.

 

[Builder Bob]

Well, it erases itself after you save/load the game. I don't think 10% justifies that.

How so?

I was of the impression that string id's are reset when a game is loaded. Not that all strings loses their content. It's just a string variable. No typecasting or anything.

If gamecaches are reset when a game is loaded (I don't know really), then the original Table has the same problem.

 

[Azlier]

This uses the strings place in the string table as an integer (last I checked). The string table is erased after loading. Any strings will be assigned new positions within the table, making attachment to strings useless upon loading.

 

[Builder Bob]

Hmmm... I don't know how the gamecache works internally. If StoreInteger's missionKey actually uses the string's position in the string table, then wouldn't the original Table also break on save/load?

native  StoreInteger    takes gamecache cache, string missionKey, string key, integer value returns nothing

 

[Azlier]

Normal Table doesn't return bug a string into an integer to get the string table position. This does.

method operator [] takes $type$ key returns integer
            set sid=StringID(this.base+$key$)
            set dat=sid-(sid/MAX_STRINGID)*MAX_STRINGID+1
            loop
                if dat.stringid==sid then
                    return dat.value // d.stringid=stringid
                endif
                exitwhen dat.drill==0
                set dat=dat.drill
            endloop
            return 0
        endmethod

Note the StringId() part.

function StringID takes string s returns integer
    return s
    return 0
endfunction

 

[Builder Bob]

This is what I'm talking about. Not the Table-X system.

library Table initializer init
//***************************************************************
//* Table object
//* ------------
//*
//*   set t=Table.create() - instanceates a new table object
//*   call t.destroy()     - destroys it
//*   t[1234567]           - Get value for key 1234567
//*                          (zero if not assigned previously)
//*   set t[12341]=32      - Assigning it.
//*   call t.flush(12341)  - Flushes the stored value, so it
//*                          doesn't use any more memory
//*   t.exists(32)         - Was key 32 assigned? Notice
//*                          that flush() unassigns values.
//*   call t.reset()       - Flushes the whole contents of the
//*                          Table.
//*
//*   call t.destroy()     - Does reset() and also recycles the id.
//*
//*   If you use HandleTable instead of Table, it is the same
//* but it uses handles as keys, the same with StringTable.
//*
//***************************************************************
 
//=============================================================
    globals
        private constant integer MAX_INSTANCES=8190 //400000
 
    //=========================================================
        private gamecache gc
    endglobals
 
    //Hey: Don't instanciate other people's textmacros that you are not supposed to, thanks.
    //! textmacro Table__make takes name, type, key
    struct $name$[MAX_INSTANCES]
        private string base
        
        static method create takes nothing returns $name$
            local $name$ d=$name$.allocate()
            set d.base=I2S(d)
            return d
        endmethod
        
        method reset takes nothing returns nothing
            call FlushStoredMission(gc,this.base)
        endmethod
 
        private method onDestroy takes nothing returns nothing
            call FlushStoredMission(gc,this.base)
        endmethod
 
        method operator [] takes $type$ key returns integer
            return GetStoredInteger(gc,this.base,$key$)
        endmethod
 
        method operator []= takes $type$ key, integer value returns nothing
            call StoreInteger(gc,this.base,$key$, value)
        endmethod
 
        method flush takes $type$ key returns nothing
            call FlushStoredInteger(gc,this.base,$key$)
        endmethod
 
        method exists takes $type$ key returns boolean
            return HaveStoredInteger(gc,this.base,$key$)
        endmethod
 
    endstruct
    //! endtextmacro
 
    private function H2I takes handle h returns integer
        return h
        return 0
    endfunction
    
    //! runtextmacro Table__make("Table","integer","I2S(key)" )
    //! runtextmacro Table__make("StringTable","string","key" )
    //! runtextmacro Table__make("HandleTable","handle","I2S(H2I(key))" )
 
    //=============================================================
    // initialize it all.
    //
    private function init takes nothing returns nothing
        call FlushGameCache(InitGameCache("libtable.gc"))
        set gc=InitGameCache("libtable.gc")
    endfunction
endlibrary

 

[Azlier]

Then I am clearly unable to keep track of things. *bows while walking backwards out the door*

 

[Builder Bob]

Then I am clearly unable to keep track of things. *bows while walking backwards out the door*

Don't worry about it. It was just a little miscommunication.

 

[Jesus4Lyf]

>Hmm i'm lost, i don't see how you can preload it, since they are dynamic triggers.

Simple. Create 50 triggers on startup. Assign their ExecuteCount to be unique (1..50). Write a NewTrigger function which pulls one off the stack. Set Data[TriggerExecCount(trig)] to your value for O(1) complexity attaching, due to preloading the unique exec count.

>That idea of using TriggerExec count for attaching triggers, is pretty neat idea, actually

I came up with it in my bid not to use H2I. :thup:

>edit. Studied KT2 a bit. It looks pretty cool actually

That's why I tell people to use it!!

>Anyways, I might end up writing something similiar

Gah. -.-
I worked on it for a year or so, optimising it as tightly as possible (well, at least for the fast bit - small periods). Note the graph on post #161. You can write your own, but I honestly recommend using KT2 instead. It's so damn fast. You're better off understanding KT2 thoroughly and then using it. Feel free to ask questions about the code in the KT2 thread. I feel if more people understood how it works, more people would use it.

And somehow back on topic... (thankyou Romek for not blatantly shutting down the conversation, as it's really quite constructive imo).

>Since I can't see any (drawback), I'll just give support

Yayyy! Sorry for the confusion, Azlier. I think I need to chuck this over the top of the Table-X post. It's... faster Table! Haha...

I did find one drawback. With the original table you can declare stupid things, like Table.create() and then use it as if it was a HandleTable. You can't with this. But maybe thats a good thing.

 

[Troll-Brain]

Simple. Create 50 triggers on startup. Assign their ExecuteCount to be unique (1..50). Write a NewTrigger function which pulls one off the stack. Set Data[TriggerExecCount(trig)] to your value for O(1) complexity attaching, due to preloading the unique exec count.

Sure i've thought about that, but you will destroy them after (dynamic triggers and since you can't remove events) and then you will execute the new one again.
Or i still miss something ?

 

[Jesus4Lyf]

>since you can't remove events
You can with GTrigger.

 

[Troll-Brain]

As far i see you don't add new events, and then don't remove them.
I don't say it's bad or what, symply that you can't remove events.

Just for the knowledge, i've found a silly lame way to disable an event (not destroy it), bus as i said it can't really be used, or at least i have no clue about it.

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

EDIT : Sorry for the off-topic again, but it's interesting for me.

 

[Jesus4Lyf]

To be honest, I think these off-topics are worthwhile.

>i've found a silly lame way to disable an event
I saw that. I was thinking of mentioning it, actually. I did think you were the author.

I don't know if that could cause desynchs in a real game, however.

>As far i see you don't add new events, and then don't remove them.
Eh? What's wrong with GTrigger for registering/unregistering events? This is a brilliant solution to recycleable dynamic triggers along with TriggerExecCount. :nuts:

To be honest I was thinking of just adding optional data attaching to GTrigger. It would be suprisingly easy. And ridiculously efficient. If you think there's demand for this, let me know in the GTrigger thread.

 

[Troll-Brain]

To be honest, I think these off-topics are worthwhile.

So say me when i must stop.

I don't know if that could cause desynchs in a real game, however.

Hmm, why it should ?

Eh? What's wrong with GTrigger for registering/unregistering events? This is a brilliant solution to recycleable dynamic triggers along with TriggerExecCount. :nuts:

Probably nothing, it's just that you don't add events.

To be honest I was thinking of just adding optional data attaching to GTrigger. It would be suprisingly easy. And ridiculously efficient. If you think there's demand for this, let me know in the GTrigger thread.

i will take a closer look of the code, later

 

[Jesus4Lyf]

>So say me when i must stop.

*Shrugs* That's probably more for the moderators to decide.

>it's just that you don't add events.

Not real events, but it may as well. The idea is they're substitute events. Like substitute cheese in fast-food burgers. It's not really cheese but no one really cares.