Real-like Cavalry Attack v1.6

Tank-Commander · Jan 28, 2017

I skimmed over the code (will go over more in-depth at a later time, some quick things I noticed:
- You have duplicate code for "Custom script: call RemoveLocation( udg_point[1] )" when you recycle, it would need to be done regardless of the outcome of the IF statement so just use the lines once after the IF statement instead of duplicating the code and putting it in both the then and else actions
- Your variable names are too generic, please attach a meaningful prefix to them like "CavAtk_" or something similar, and make the names match their purpose "real" is too generic to understand the purpose of the variable
- Use an in-game screenshot, there's little to no reason for a spell to not use one
- Your trigger/folder names aren't appropriate "123" as a folder means nothing, and "Init" & "dead", etc. don't mean much either please name them appropriate to their purpose (Prefix also applies here)
- Spells should note have game message code inside them, remove this or put it in separate triggers in a different folder to differentiate them
- The same as above applies for test features
- You lack a proper configuration (this should be in the same location as your hashtable setup, rather than put inside the other triggers
- Your spell doesn't support multiple levels
- Why is temp_unit an array variable? from what I can tell there's no need
- Why do you need two hash tables? this could surely be done with 1 and reserve much less memory
- Your loop should be turned off when the ability isn't in use at all rather than being permanently on

For the time being this will be set to awaiting update due to the above points

Fruit Forest · Jan 28, 2017

Tank-Commander said:
- You lack a proper configuration (this should be in the same location as your hashtable setup, rather than put inside the other triggers

It is made if you want for example add a buff which increases damage of the ability of the certain unit. Spell configuration is more flexible in this way.

Tank-Commander said:
- Why do you need two hash tables? this could surely be done with 1 and reserve much less memory

One hashtable is for cavalry attack and second one is for stun duration.

Tank-Commander said:
- Your loop should be turned off when the ability isn't in use at all rather than being permanently on

What does it mean? What loop?

EDIT: I FIXED 1,2,4,5,6,8,9,10,11 suggestions of Tank Commander

Tank-Commander · Jan 29, 2017

Well that's certainly improved pretty quickly obviously the few things not fixed last time carry over but I digress

((This trigger) is on) Equal to True

Isn't needed - if the trigger is off the trigger will never run that condition check
same goes for

Trigger - Turn on (This trigger)

- The method you're using to support multiple levels is not common practice your code should not need to be extended in order to have the support, should be default.

The two methods we use to do this typically are in a config trigger (CAV INIT in this case)

Set CAVSpeed[0] = 420
Set CAVSpeed[1] = 500
Set CAVSpeed[2] = 580

and then in your cast trigger reference

Hashtable - Save (CAVSpeed[CAVLevel]) as 0 of CAVinteger2 in HASHCAVALRY

where CAVLevel is the level of the ability cast - 1 (alternatively save the values starting at index 1 rather than 0
Or something like

Set CAVSpeedBase = 340
Set CAVSpeedPerLevel = 80

and then in your cast trigger reference

Hashtable - Save (CAVSpeedBase + (CAVSpeedPerLevel * CAVLevel) as 0 of CAVinteger2 in HASHCAVALRY

We also put all other configurable aspects into the initialization trigger - Map makers don't want to have to go through code looking for where they can modify things, it should be as obvious and easy to find as possible

- Your variable names are still too generic as well (see point 2 last time, I mentioned more than just needing a prefix)
- Your Cavalry Engage range is fixed - this should also be configurable on a per-level basis
- You're still creating the second hashtable, just now you don't set a variable to it
- Abilities used should be configurable
- Handles that are referenced a lot such as "picked unit" should be stored in temporary variables in order to speed up access time
- you use the line

Custom script: set udg_CAVeffect = AddSpecialEffectTarget("Abilities\\Spells\\Other\\Stampede\\StampedeMissileDeath.mdl", GetEnumUnit(), "chest")

and then destroy the effect the next line, if you're going to use custom script to create effects it should look more like

Custom script: call DestroyEffect(AddSpecialEffectTarget("Abilities\\Spells\\Other\\Stampede\\StampedeMissileDeath.mdl", GetEnumUnit(), "chest"))

and then you can get rid of the following line, also the special effect used should be a variable that can be configured as well as the attachment point (arguably)
- AttackType and DamageType should be configurable
- Your cavalry can currently go up and over cliffs (which isn't very realistic behaviour if you asked me) see the screenshot I posted below
- Give your spell a proper tooltip and icon ingame, it should be similar to other ingame spell screenshots

Wark · Feb 20, 2017

I really need something like this for my map, so I sat down and took a look at which variable is doing what. I think what Tank-Commander means by:

Tank-Commander said:
Your variable names are too generic

Is, basically, it's really hard to follow what exactly your trigger is doing with all those reassigned "CAVreal" and "CAVinteger" variables, unless you skim through each re-assigned variable constantly. Also, those variable constants by convention usually go in the "init" trigger then are modified when the ability is cast mostly to speed things up, but I don't think this needs a "per-level" configuration since it's better suited for units. (unless there's some techtree stuff to upgrade the charge)
I do agree with this though:

Tank-Commander said:
Your cavalry can currently go up and over cliffs (which isn't very realistic behaviour if you asked me)

And came up with a solution. Try this:

Code:

If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    If - Conditions
        (Terrain pathing at CAVpoint[1] of type Walkability is off) Equal to True
    Then - Actions
        Unit - Turn collision for (Picked unit) On
        Set CAVgroup3 = (Load 0 of CAVinteger in HASHCAVALRY)
        Custom script:   call DestroyGroup( udg_CAVgroup3 )
        Animation - Reset (Picked unit)'s animation
        Unit - Remove Cavalry Attack Ability 0 from (Picked unit)
        Animation - Change (Picked unit)'s animation speed to 100.00% of its original speed
        Unit - Order (Picked unit) to Stop
        Hashtable - Clear all child hashtables of child CAVinteger in HASHCAVALRY
    Else - Actions

after the variable set in the loop trigger:

Code:

Set CAVpoint[1] = (CAVpoint[0] offset by (CAVreal[3] x (Load 0 of CAVinteger from HASHCAVALRY)) towards (Load 6 of CAVinteger from HASHCAVALRY) degrees)

One thing I cannot understand, however, is the stun duration thing. It doesn't seem like that second hashtable is doing anything, and the stun duration for the dummy ability is zero. How is it working exactly?
I also recommend the "Animal War Training" upgrade icon for the ability, it seems to suit the skill.

Edit:
One more thing, I also suggest a condition in your CAV CLEAN HASH trigger so that it doesn't fire off every time anything and everything dies.

Second Edit:
Had a major problem importing the item abilities for the triggers into another map that already had custom item abilities. I spent a couple hours re-organizing all the trigger spots that checked for "Cavalry Attack" and "Ready to Charge" since it auto-assigned other item abilities, even though I copied those first before the triggers. You may need to assign variables in the "INIT" trigger for all abilities.

Fruit Forest · Feb 20, 2017

THE SKILL WAS UPDATED.
UPDATE:
-Now Cavalry can't pass through doodads and cliffs.
-Added Friendly INITIALIZATION CONFIGURATION where yoU can set all parameters and even add more ability levels.
-Added additional Paragraph: coefficient of damage for stunning unit. So you may regulate what damage the caster deals to stunned enemy.
-The kinight stop moving while: sutcked with doodads, stunned, immobilised, rooted, sleeping (you may add more non standard buffs)

Wark said:
Had a major problem importing the item abilities for the triggers into another map that already had custom item abilities. I spent a couple hours re-organizing all the trigger spots that checked for "Cavalry Attack" and "Ready to Charge" since it auto-assigned other item abilities, even though I copied those first before the triggers. You may need to assign variables in the "INIT" trigger for all abilities.

Also I made it to import the ability much easier with all abilities and units.

Wark said:
One more thing, I also suggest a condition in your CAV CLEAN HASH trigger so that it doesn't fire off every time anything and everything dies.

Done. Now It will remove leaks only who have detection dummy ability and dummy which stuns victims.

Wark said:
One thing I cannot understand, however, is the stun duration thing. It doesn't seem like that second hashtable is doing anything, and the stun duration for the dummy ability is zero. How is it working exactly?

When unit start casting Dummy Stun ability the system gives to target's ID the certain value. This value is decreased if unit has Stun buff. When value becomes 0 then stun effect is removed.

Wark said:
I also recommend the "Animal War Training" upgrade icon for the ability, it seems to suit the skill.

It's on your own. It's graphic question.

Tank-Commander said:
Well that's certainly improved pretty quickly obviously the few things not fixed last time carry over but I digress

Tank-Commander said:
- The method you're using to support multiple levels is not common practice your code should not need to be extended in order to have the support, should be default.

Tank-Commander said:
- Your variable names are still too generic as well (see point 2 last time, I mentioned more than just needing a prefix)
- Your Cavalry Engage range is fixed - this should also be configurable on a per-level basis
- You're still creating the second hashtable, just now you don't set a variable to it
- Abilities used should be configurable
- Handles that are referenced a lot such as "picked unit" should be stored in temporary variables in order to speed up access time
- you use the line

Custom script: set udg_CAVeffect = AddSpecialEffectTarget("Abilities\\Spells\\Other\\Stampede\\StampedeMissileDeath.mdl", GetEnumUnit(), "chest")

and then destroy the effect the next line, if you're going to use custom script to create effects it should look more like

Custom script: call DestroyEffect(AddSpecialEffectTarget("Abilities\\Spells\\Other\\Stampede\\StampedeMissileDeath.mdl", GetEnumUnit(), "chest"))

and then you can get rid of the following line, also the special effect used should be a variable that can be configured as well as the attachment point (arguably)
- AttackType and DamageType should be configurable
- Your cavalry can currently go up and over cliffs (which isn't very realistic behaviour if you asked me) see the screenshot I posted below
- Give your spell a proper tooltip and icon ingame, it should be similar to other ingame spell screenshots

DONE

Tank-Commander · Feb 20, 2017

Did a very quick glance over the code and test and I noticed two small things immediately:
- You're leaking points[1] and [2] in your loop in the second last IF statement
- Currently the knights stop animating properly if they collide with a wall (this is later solved by casting the spell again, I assume you forgot to reset their animation completely

as an aside, your group selection in your loop would be better if it didn't select all units that are stunned for any reason (also if the group were more strictly controlled via adding/removing specific units instead of entirely reselecting the entire group it would be better
You also forgot to use the temp variables in a few places (and forgot some temp variables such as one storing the level of the ability being cast)

Wark · Feb 20, 2017

I just tested it again, and importing it is MUCH better now. I did notice, however, some weird problems with the ability stalling on both the default Raider and Huntress units. Give it a shot, slap "Cavalry Attack" on them units and watch how they react.
For the record, the "walk" animation number (thanks to your -anim command) is 2 for the Raider, 1 for the Huntress.
I don't have any suggestions for solving that problem...

Fruit Forest · Feb 20, 2017

Wark said:
I just tested it again, and importing it is MUCH better now. I did notice, however, some weird problems with the ability stalling on both the default Raider and Huntress units. Give it a shot, slap "Cavalry Attack" on them units and watch how they react.
For the record, the "walk" animation number (thanks to your -anim command) is 2 for the Raider, 1 for the Huntress.
I don't have any suggestions for solving that problem...

i'm still fixing. Tank Commander noticed some problems. i'll report when it will done.

Wark · Feb 20, 2017

Keep it up, I really like this concept. I plan to put it in my next map, giving each race a "cavalry" unit. So far, I have it working reliably with modifications on the base Knight unit.

Fruit Forest · Feb 20, 2017

Tank-Commander said:
as an aside, your group selection in your loop would be better if it didn't select all units that are stunned for any reason (also if the group were more strictly controlled via adding/removing specific units instead of entirely reselecting the entire group it would be better

I'm afraid i have lack of skills to operate with it. Anyway the system pick only certain units so the player wouldn't feel lags or something.

Tank-Commander said:
You also forgot to use the temp variables in a few places (and forgot some temp variables such as one storing the level of the ability being cast)

DONE

Tank-Commander said:
Did a very quick glance over the code and test and I noticed two small things immediately:
- You're leaking points[1] and [2] in your loop in the second last IF statement
- Currently the knights stop animating properly if they collide with a wall (this is later solved by casting the spell again, I assume you forgot to reset their animation completely

DONE

Fruit Forest · Feb 20, 2017

Wark said:
Keep it up, I really like this concept. I plan to put it in my next map, giving each race a "cavalry" unit. So far, I have it working reliably with modifications on the base Knight unit.

It seems I fixed dangerous bugs. You can download now.
Did you understand how to use animation?
If it didn't I made an example how to implement aniamtion indexes for each unit type: See it in the CAN USE ABILITY, ANIMATION INDEX.

Wark · Feb 20, 2017

I have an understanding of it, and was using some if/then/else statements to assign the animation index variable according to the unit. Let's me take a look-see here.

Edit:
Yea, that's what I did for that animation index number with if/then/else statements. However, there's still that weird stalling problem when using Cavalry Attack on anything that is not a Knight. I'll attach the test map so you can see what I mean: select the Raiders, Huntresses and Knights separately and check, then see what happens when they are all selected.
I am thinking it has something to do with the variable called for each picked unit in the loop, as well as the ability animation for "Serpant Ward" (note how the Raider sits there derpily spamming spell-throw)

Also, I had another idea in case you want to make the effect end when colliding with a structure. In the same condition for checking "Walkability," you can just add this condition within an "Or":

Code:

Or - Any (Conditions) are true
    Conditions
        (Terrain pathing at CAVpoint[1] of type Walkability is off) Equal to True
        (Number of units in (Units within 100.00 of CAVpoint[1] matching (((Matching unit) is A structure) Equal to True))) Greater than 0

Fruit Forest · Feb 20, 2017

Wark said:
Also, I had another idea in case you want to make the effect end when colliding with a structure. In the same condition for checking "Walkability," you can just add this condition within an "Or":

It causes leaks. I'll edit it normally. and upload it in the description.

Fruit Forest · Feb 20, 2017

Wark said:
I have an understanding of it, and was using some if/then/else statements to assign the animation index variable according to the unit. Let's me take a look-see here.

Edit:
Yea, that's what I did for that animation index number with if/then/else statements. However, there's still that weird stalling problem when using Cavalry Attack on anything that is not a Knight. I'll attach the test map so you can see what I mean: select the Raiders, Huntresses and Knights separately and check, then see what happens when they are all selected.
I am thinking it has something to do with the variable called for each picked unit in the loop, as well as the ability animation for "Serpant Ward" (note how the Raider sits there derpily spamming spell-throw)

Also, I had another idea in case you want to make the effect end when colliding with a structure. In the same condition for checking "Walkability," you can just add this condition within an "Or":

All right. Download now, but see that I changed in unit parameters in the object editor. I didn't add ability only but i also changed the Art parameter.
I also miss Aniamtion speed parameter, but now it works fine.

Wark · Feb 20, 2017

Ah, now THAT is more like it. Great. Now to put this to use on Ol' Molly the dwarven bear rider. I'll let you know if I come across any other problems!

Fruit Forest · Feb 20, 2017

Wark said:
Ah, now THAT is more like it. Great. Now to put this to use on Ol' Molly the dwarven bear rider. I'll let you know if I come across any other problems!

Art - Animation - Cast Point must be 0.001 or else the system removes the dummy ability which makes the unit to charge.

Tank-Commander · Feb 20, 2017

my point was adding units when they cast the spell, rather than every unit that has certain spells - it's possible to make this using only 2 abilities (the stun buff and the spell cast), you half do this already via enabling/disabling the trigger when a spell is cast (just add them to the strict group then, rather than always reselecting) I'm not sure I got that across with my phrasing before

IcemanBo · Feb 21, 2017

Can you post code in description?

Fruit Forest · Feb 21, 2017

IcemanBo said:
Can you post code in description?

i still don't know how and why?

IcemanBo · Feb 21, 2017

So it's easy viewable without opening the map, How To Post Your Trigger.

Fruit Forest · Feb 21, 2017

IcemanBo said:
So it's easy viewable without opening the map, How To Post Your Trigger.

I did and... you can see in the CODE spoiler.

IcemanBo · Feb 21, 2017

Ah, I see, yeh it sucks the editor uses an other language. I fixed the code to english, I can do it some later, too, on an update.
Will read it soon.

Fruit Forest · Feb 21, 2017

IcemanBo said:
I fixed the code to english

thx i didn't know about the language issue. anyway i have english version too, i can use it to post right code.

Eagle XI · Feb 21, 2017

Is displacing the targets as cavalry runs through them, probably supposed to be knockback ?

Fruit Forest · Feb 21, 2017

Eagle XI said:
Is displacing the targets as cavalry runs through them, probably supposed to be knockback ?

Maybe i'll add it then i have free time.

IcemanBo · Feb 21, 2017

Look here Convenient Unit Group Filtering in GUI, there's explained why not tot to write everything in 1line, it gets pretty unreadable in GUI.
Actually, hm, do you know about Visualize: Dynamic Indexing ? I believe it would benefit some from it,
not at last with readability. For example:
(Load 10 of CAVinteger from HASHCAVALRY) Less than or equal to 0.00
^is pretty much none-saying to me what it should mean. One have to lookup each possible thing that is stored there to understand it's purpose.
There is no documentation, too, that helps.

Sometimes variables aren't used, for example in the death trigger (Triggering Unit) is still used multiple times.
By the way, the variable name doesn't need to be specific for temp variables, example
CAVtemp_unit_DEAD
can be
CAV_Unit
explained here [GUI] - GPAG - GUI Proper Application Guide.

Things like (Picked Unit) should be stored into a variable if used very often, as each () is a function call, which is slower than a variable lookup.

You could take usage of a stun system, so you don't create always dummy units on your own, else you might use anyways just 1 dummy for all casts instead of one dummy per stun.
I think BPower has one in spells section.

Does the orc raider animation looks weird? It doesn't "run" properly I think.

Fruit Forest · Feb 23, 2017

UPDATE 1.3
New parameter: Knockback
The knockback also depends on the ACCELERATION PENALTY
Added new function to detect and undetect units to be knockbacked or to be under Cavalry moving. (Allow to remove CLEAN HASH trigger)
The CODE spoiler is changed (with proper language)

Tank-Commander said:
as an aside, your group selection in your loop would be better if it didn't select all units that are stunned for any reason (also if the group were more strictly controlled via adding/removing specific units instead of entirely reselecting the entire group it would be better

DONE.

Eagle XI said:
Is displacing the targets as cavalry runs through them, probably supposed to be knockback ?

DONE

IcemanBo said:
Sometimes variables aren't used, for example in the death trigger (Triggering Unit) is still used multiple times.

THE DEATH TRIGGER WAS REMOVED.

IcemanBo said:
Things like (Picked Unit) should be stored into a variable if used very often, as each () is a function call, which is slower than a variable lookup.

DONE

Wark · Feb 27, 2017

Yo Fruit Forest, I noticed this version has its periodic event always running. Since my map will have multiple timed systems, I thought it prudent to suggest a check at the end of the loop for when:
CAVResetGroup, CAVStunGroup, CAVKnockbackGroup, and CAVDetectGroup = 0, to turn off that loop. I find it works fine having the loop initially off with that variable check in place.
Also, do you think it would be more effective if you turn on the "CAV LOOP" trigger after setting the variables in the initial spell cast?

Also, is there a parameter to increase the range of the change?

Fruit Forest · Feb 27, 2017

Wark said:
Also, do you think it would be more effective if you turn on the "CAV LOOP" trigger after setting the variables in the initial spell cast?

The idea is every 00x sec. the system check the number of already created group. Previous variant create every group and destroy it. If you have 999999 units in your map then don't worry - this system will pick only right units without lag spikes. If you have 0 units in each group then then the system just check the integers which "consume" a bit of computer memory.

Wark said:
Also, is there a parameter to increase the range of the change?

Maybe range of the charge? It's the TIME OF CHARGE (IF UNIT IS STUCKED) paramemeter.

IcemanBo · Feb 27, 2017

Actions
- Trigger - Turn off (This trigger)
- Set CAVDetectGroup = (Units in (Playable map area) matching (((Matching unit) is Plagued) Equal to True))
- Unit Group - Remove all units from CAVDetectGroup
- Set CAVKnockbackGroup = (Units in (Playable map area) matching (((Matching unit) is Plagued) Equal to True))
- Unit Group - Remove all units from CAVKnockbackGroup
- Set CAVResetGroup = (Units in (Playable map area) matching (((Matching unit) is Plagued) Equal to True))
- Unit Group - Remove all units from CAVResetGroup
- Set CAVStunGroup = (Units in (Playable map area) matching (((Matching unit) is Plagued) Equal to True))
- Unit Group - Remove all units from CAVStunGroup
- Set CAVinteger = 0
- Set CAVinteger2 = 0

^hm, what purpose of these lines? : )
The GUI variables are automaticaly initialisized with "null", "0" or "false". The extra group creations leads to memory leak, because you overwrite the already existing group.

Things like (Picked Unit) should be stored into a variable if used very often, as each () is a function call, which is slower than a variable lookup.

There were other things, too, next to (Picked Unit), like any other event responses like (Triggering Unit) etc, -- each time "()" is used like in (Triggering Unit), it means it is a funtion call inside. Variable lookups are better.

The hash's name style differs from rest. ;P

Have a look at other things mentioned in my post.

Set CAVgroup = (Units within CAVreal[2] of CAVpoint[0] matching (((((Matching unit) is in CAVDetectGroup) Not equal to True) and ((((Matching unit) is in CAVResetGroup) Not equal to True) and (((Matching unit) is alive) Equal to True))) and (((Level of CAVMainAbility for (M

^something like this is not even readable, because it's too long for GUI. And opening all the tabs is a just huge mess to read it properly.

Add basic documentation, I have no idea why for example do this:

Set CAVpoint[2] = (Point(CAVreal[0], CAVreal[1]))

It becomes just all hard to read and to follow.

[GUI] - GPAG - GUI Proper Application Guide

When using custom script you don't need the BJs anymore. Like in the GetHandleId function.

The config for animation index for unit types should happen in the config trigger instead of run per if statements somewhere in the cast trigger.
The hashtable can/should be used to bind the animation index to a unit type.

I still strongly recommend to switch from hashtable instances to dynamic indexing for example. It's very hard to read and maintain at the moment.
The way I see it that hashtables are acceptable is when you don't work directly with the hashtable operations in the core, but only use it to init your variables. Example:

Set CAV_Unit = (Triggering Unit)
Set CAV_Damage = 50
Set CAV_Player = (Triggering Player)
Hashtable - Save CAV_Unit as 1 of CAV_Key in CAV_Hash
Hashtable - Save CAV_Damage as 2 of CAV_Key in CAV_Hash
Hashtable - Save CAV_Player as 3 of CAV_Key in CAV_Hash
..
..
// and when load :
..
..
Set CAV_Unit = Load 1 of CAV_Key in CAV_Hash
Set CAV_Damage = Load 2 of CAV_Key in CAV_Hash
Set CAV_Player = Load 3 of CAV_Key in CAV_Hash

And then to operate only with the variables instead of having "Load 13" and "Load 9" everywhere in the actions, and noone knows what it is. It's honestly just very bad for readability.

Set CAVDamagecCoef[1] = 2.00

^Is this damage per second? Or only once. It's not very clear, but usually all config data should be in "per second" if not stated otherwise.

Fruit Forest · Feb 27, 2017

IcemanBo said:
Set CAVDamagecCoef[1] = 2.00

^Is this damage per second? Or only once. It's not very clear, but usually all config data should be in "per second" if not stated otherwise.

It's multiplier of damage if canavlry hit stunned unit.

IcemanBo said:
^hm, what purpose of these lines? : )
The GUI variables are automaticaly initialisized with "null", "0" or "false". The extra group creations leads to memory leak, because you overwrite the already existing group.

I thought you need to create group and clear it to use it well.

IcemanBo said:
Add basic documentation, I have no idea why for example do this:

I'll add an additional description, but it will help only for code viewers. For those who are using this ability and don't mind about the "skeleton" it doesn't important.

Fruit Forest · Feb 28, 2017

UPDATE v 1.4
1. Removed some leaks in the StunGroup
2. Added description in the LOOP section.
3. Triggering unit is now stored as variable.
4. Added new parameter ANIMATION TIME PERIOD - allow to avoid ugly steps on the ground while charging.

Tank-Commander · Mar 28, 2017

I noticed that sometimes when you order the units as a group to charge at a point 1 or 2 of them won't do it, any idea why this may be the case? it's pretty irritating when not all the units you tell to charge actually do so
Just thought I'd note that you don't need to set your temp unit variables to "no unit" - they're global variables so it doesn't really do anything to do that

Fruit Forest · Mar 28, 2017

Tank-Commander said:
I noticed that sometimes when you order the units as a group to charge at a point 1 or 2 of them won't do it, any idea why this may be the case? it's pretty irritating when not all the units you tell to charge actually do so
Just thought I'd note that you don't need to set your temp unit variables to "no unit" - they're global variables so it doesn't really do anything to do that

V 1.5. I increased the periodic interval. Now units must have more time to cast spell.

Tank-Commander · Apr 23, 2017

Apologies that this resource hasn't been moderated in a long time but most of IcemanBo's previous review still stand as issues with the program, in addition to that I noticed the following things:
- There are many execution routes in the loop which result in memory leaks, in the 4th group selection for example there's a clear case where none of the point variables are cleared
- The loop is never turned off
- Since your loop shouldn't even be on if all the groups are empty "Set CAVreal[0] = 0.05" should only need to be set once and by all rights should just be a constant since it's always going to have that value

Fruit Forest · Apr 23, 2017

Thx for suggests. The loop is on because it causes some problems with execution. But then I learned the "channel" spell. It should allow me to turn off loop because it can order all selected group to execute the order. If I have time I'll fix it.

Fruit Forest · Mar 7, 2018

Version 1.6
1. The system turns off periodic trigger now.
2. Added additional trigger that counts index animation. So you don't need to go in the "CAV USE ABILITY" trigger anymore. But you still have to check animation for your own unit models.
3. Leak removed.

MyPad · Jun 3, 2018

@Tank-Commander

^^
Status?

Tank-Commander · Jun 3, 2018

It's been a while since I've looked at the code, some older review points still stand:
- CAV loop still has memory leaks within it, please make sure you have eliminated all of the leaks before updating, my previous point about CAVreal[0] in the loop still stands as well
- You have inconsistent usage of temp variables - you use temp unit a lot but don't use it at all when you create a CAVDummyUnitType - this dummy should also not be owned by a player as this messes up the scoreboard results
- IcemanBo's point of not using BJ functions in custom script still stands
- Special effects you create should use configurable effects (the effect string this being) attachment point is also an option for an added configurable though not necessary

I may have missed previous points brought up in reviews that may still be relevant, please go over these for things that may need to be fixed before updating the system

I appreciate the dedication you have to this resource

Hazop · Jun 26, 2018

The way "How to Import" is written is confusing, can you better explain? Or look at the map itself to see if maybe I'm missing something?

Chaosy · Jul 8, 2018

I was looking for something similar to this just now.

While the charge itself looks decent enough the impact effect on units could use better visuals.
Rather than a boring knockback I'd want to have something more meaty. Would be super cool if it could be a arching knockback

Fruit Forest · Jul 8, 2018

1. Added "rounded" trajectory for the knockback.
2. Leaks are fixed.
3. Fixed minor errors.
4. CAVreal[0] is replaced on CAVLoopPeriod
5. The "INIT" trigger allow to set speceffect for moved cavalry units and speceffect + attachment for damaged unit.
6. The occured dummy units are now neutral. They couldn't hurt the statistic board, I think.

KILLCIDE · Jul 10, 2018

Hmm there seems to be a bug with the spell. I was just having them randomly charge as 6, and then all of a sudden... they stopped charging as 6?

Pinzu · Jul 14, 2018

This is great, but I think you should separate the knockback duration from the stun duration. So that you can increase the time the target is stunned from the time they are being knocked back.

Lt_Hawkeye · Nov 25, 2018

Is this usable at its current state?

Gumberbunbder · Feb 13, 2020

Very nifty, this is the only charge system i could find.

Real-like Cavalry Attack v1.6

Real-like Cavalry Attack (Map)

Attachments

Attachments

Attachments

Attachments

Similar threads