Capturable Building System (League of Legends)

[Moderator]

12th Dec 2015
IcemanBo: Too long as NeedsFix. Rejected.

16th Jan 2012
Bribe: The SimpleBars library should be its own resource, if you want to use it as a library. Otherwise, just inline it. The library itself needs a review on its own because it could use some work.

@static@ if SHOW_BARS then //Note the keyword "static" which I added. You should do this for all constant booleans.

call TriggerRegisterUnitEvent(onDamageTrig, u, EVENT_UNIT_DAMAGED)

/*
This is going to need a damage detection system or a better method.
If a unit is removed from the game, the event persists, racking up the
handle count as the game goes on.
*/

        private static method abortTaking takes nothing returns boolean
            @local unit u@ = GetTriggerUnit() //Forgot to null this

This could also take advantage of RegisterPlayerUnitEvent, because it's the one of the best resources around.

 

[The_Witcher]

Hope you like it and if you are using this system in a large project please tell me

if you have improvement proposals send them by PM!

YOU NEED THE JNGP AND THE NEWEST JASSHELPER VERSION!!!! and of course minor jass knowledge!

 

[Luorax]

I don't think that the hashtable is needed. Just get an indexing system (AIDS/UnitIndexer; both of them is perfect, and you don't even need static ifs) and create a bunch of global arrays. Then instead of storing things in the hashtable, store them in the arrays using GetUnitUserData()

You also don't have to inline TriggerRegisterAnyUnitEventBJ(); it's only use is adding to map size.

 

[LvL100EtC]

Lol, i like it. Good job mon!
5/5

 

[Magtheridon96]

In your onInit method, you're doing 2 iterations over the same indices.
You can combine those loops and just add an extra local trigger.
OR, you can use TriggerRegisterAnyUnitEventBJ

The Bar handling should be done in an extra library that gets implemented through optional textmacros (The user might not want them ;P)

The hashtables could be replaced with Tables (Makes things more readable)
You're going to need 4 or 5 Tables here.
Or, better yet, you could use a TableArray (Set it to TableArray[5] on map initialization)

In the "startTaking" method, GetSpellTargetUnit and other functions that are being called repeatedly should be cached into locals for efficiency.

Your event Handler should allow the user to simply pass a function (code) and a struct instance instead of a trigger and an instance. (Sort of like SpellEffectEvent, RegisterPlayerUnitEvent, OrderEvent, etc..)

This way, you don't have to bother yourself with all the triggers.

You'd have to store the code in the form of boolexprs (Filter(code))

For efficient code/boolexpr executing/evaluating, you can use FireCode (in my signature)

I figured it's best to blame one system on how functions are being executed rather than blaming every other system that needs to execute functions

edit

Also, if you're up for it, could you convert this system so that it uses CTL instead of T32?

There are a lot of things that could be improved here and there, but with all those hashtable functions, the code's really hard to look at :x

You should link us to PlayerColorUtils. (It's infamous, unlike AIDS, TimerUtils, UnitIndexer and all those other systems used by practically everyone modding warcraft III)

 

[The_Witcher]

Quote

In your onInit method, you're doing 2 iterations over the same indices.
You can combine those loops and just add an extra local trigger.
OR, you can use TriggerRegisterAnyUnitEventBJ

The Bar handling should be done in an extra library that gets implemented through optional textmacros (The user might not want them ;P)

The hashtables could be replaced with Tables (Makes things more readable)
You're going to need 4 or 5 Tables here.
Or, better yet, you could use a TableArray (Set it to TableArray[5] on map initialization)

In the "startTaking" method, GetSpellTargetUnit and other functions that are being called repeatedly should be cached into locals for efficiency.

Your event Handler should allow the user to simply pass a function (code) and a struct instance instead of a trigger and an instance. (Sort of like SpellEffectEvent, RegisterPlayerUnitEvent, OrderEvent, etc..)

This way, you don't have to bother yourself with all the triggers.

You'd have to store the code in the form of boolexprs (Filter(code))

For efficient code/boolexpr executing/evaluating, you can use FireCode (in my signature)

I figured it's best to blame one system on how functions are being executed rather than blaming every other system that needs to execute functions

edit

Also, if you're up for it, could you convert this system so that it uses CTL instead of T32?

There are a lot of things that could be improved here and there, but with all those hashtable functions, the code's really hard to look at :x

You should link us to PlayerColorUtils. (It's infamous, unlike AIDS, TimerUtils, UnitIndexer and all those other systems used by practically everyone modding warcraft III)

Thanks for your fast and useful reply!
I will improve my system a lot in the next days thanks to your hints

I will think about it, but atm I'm not going to handle the bars seperately, because players won't have any indication of how far they captured the building, so they are essential...

I won't convert my system to use CTL cause i simply prefere T32 and it's easier to implement!

I will link to the other ressources in the next update

Thanks again!

 

[xorkatoss]

hmm...for some reason i can't open the map...?
anyway i play LoL and i could point out some things you forgot to mention...

If you are interrupted by an attack, or because you gave an order, while capturing,
your unit will stop

after that happens you have to w8 a fixxed amount of time,about 3 seconds(you could make this customizable) before you can attempt to recapture the tower

When you right click a capturable building, your hero will charge and
release a beam which captures the building over time.

normal units like minions will attack the tower and can also capture it(not sure if you included that since i didn't try it yet)

plus when a hero tries to capture the tower, when he begins capturing the tower will stop attacking nearby enemy units but when minions attack the tower, the tower attacks them and at the same time deals AoE damage around it that damages only minions

well that's all for now...i hope i can test the map soon...good luck

 

[Teldrassil]

Just stick with the hashtable witcher, its more reliable and easier for people to work with.

no point in over complicating something or breaking what isn't broken.

 

[The_Witcher]

Just stick with the hashtable witcher, its more reliable and easier for people to work with.

no point in over complicating something or breaking what isn't broken.

Yes I will keep on using hashtables since tables are just wrappers (so theres no speed improvement)...

UPDATE: fixed the issues magtheridon mentioned and added a simpleBars library for bar handling.

@xorkatoss
will be included in the next update!

 

[Luorax]

Tables are not used to gain speed, but to reduce the amount of hashtables needed. Less handle -> more speed.

Without Table I would have to create like 20 or even more hashtables on my map, but with Table I need only one beautiful snippet.

And why are hashtables easier to use for people? Guess writing this:

call SaveInt(thistype.hash,GetUnitUserData(this.caster),SPELL_LEVEL_ID,5)//Considering you have some sort of an indexing system

is easier than writing this:

set thistype.levels[GetUnitUserData(this.caster)]=5

 

[Bribe]

Table is a good thing to reduce handle count and keep the hashtable 255 limit low, and is a good feeling to use it because you really maximize the potential of your hashtable (I always feel like I am wasting one when I only use the "0" key of the hashtable, for example).

However, using a hashtable instead of a Table is not really a problem unless you are creating hashtables dynamically, which I have only ever seen Nestharus do and he had a very good reason for doing so. Other than that, if it's only one hashtable per trigger and you have more than 255 triggers your map that will also break it. But that many trigger is insane, and if a mapmaker is considering something so epic then yeah (s)he should consider using Table as a resource.