[GUI] Take Aim - Dynamic Range Change

[Moderator]

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

15:38, 2nd Jan 2015
Maker: Check the replies in this thread.

 

[IcemanBo]

Hi! Could you post triggers in spell description? It makes it a lot easier to review the code. http://www.hiveworkshop.com/forums/miscellaneous-tutorials-456/how-easily-post-triggers-163285/

 

[The6thMessenger]

Hi! Could you post triggers in spell description? It makes it a lot easier to review the code. http://www.hiveworkshop.com/forums/miscellaneous-tutorials-456/how-easily-post-triggers-163285/

Yeah, sure. But this is really quite a mess, it takes a LOT of triggers to work. And it's hard coded, because there is just no way around it, i even find it confusing myself, and i made it. Just remember, this is an experimental thing.

 

[Kingz]

This has been known for a while afaik (changing unit range via upgrades) and the biggest problem is that it isnt configurable/generic enough to be a system.

Edit:

The code is kind of a big mess imo, should find a way to do without so many if/then/else (Arrays come to mind).
I noticed this isnt a system which i originally though.

 

[The6thMessenger]

This has been known for a while afaik (changing unit range via upgrades) and the biggest problem is that it isnt configurable/generic enough to be a system.

Edit:

The code is kind of a big mess imo, should find a way to do without so many if/then/else (Arrays come to mind).
I noticed this isnt a system which i originally though.

I never said that it is a system.

And no, this is not UPGRADES alone. Upgrades increase the attack range, transformation changes the unit to another form of unit without interruption, allowing you to either implement or revert any changes. So you can add 150 range, and take away. Which is impossible to upgrades, because you can't remove upgrades, while you can just transform back with -150 range.

Also, i'm sorry if everything is such a mess, i just never found any way around it - i brainstormed and found nothing other than that technique to make the transformation system work. I tried arrays but i couldn't find any good way in making them much easier. I'm still looking a good way to fix them, but i just don't have that luck.

If it makes you feel any better, i'm trying Hashtable.

 

[GywGod133]

i suggest use 0.03125 instead using 0.03

In Constant
just remove this

• Hero - Learn skill for Dwarven Sniper 0099 <gen>: Sniper - Take Aim
• Unit - Set level of Sniper - Take Aim for Dwarven Sniper 0099 <gen> to 4

just put them in other triggers

 

[Kingz]

Well here is a way:
1. Save indexes bound to unit type into a hashtable, for example SaveInteger(hashtable, unitTypeId, elevationIndex0, index0), etc
2. Make 3 (or whatever number of levels you want) sized arrays to hold Take Aim abilities. (make multiples for different elevation modes)
3. In the loop (transformation trigger that is), load index by unitTypeId, and use it to add/remove ability.

That would reduce code clutter a lot and it would look a lot better (since all those IF/THEN/ELSE branches would be replaced by a single case). At least that is the minimal work you can do to improve the code, without changing a lot of stuff.

 

[The6thMessenger]

Well here is a way:
1. Save indexes bound to unit type into a hashtable, for example SaveInteger(hashtable, unitTypeId, elevationIndex0, index0), etc
2. Make 3 (or whatever number of levels you want) sized arrays to hold Take Aim abilities. (make multiples for different elevation modes)
3. In the loop (transformation trigger that is), load index by unitTypeId, and use it to add/remove ability.

That would reduce code clutter a lot and it would look a lot better (since all those IF/THEN/ELSE branches would be replaced by a single case). At least that is the minimal work you can do to improve the code, without changing a lot of stuff.

Yes, i know, that is my approach. But i hit a snag with the Hashtable, turns out that the Save Ability will cause the WE to crash, and i don't know how to put it into custom script. I know how to work with hashtables, i know how to load a unit or anything at all, but i'm having problems registering the abilities that were to be used.

i suggest use 0.03125 instead using 0.03

In Constant
just remove this

• Hero - Learn skill for Dwarven Sniper 0099 <gen>: Sniper - Take Aim
• Unit - Set level of Sniper - Take Aim for Dwarven Sniper 0099 <gen> to 4

just put them in other triggers

No. So far, people all over taught me never to have a loop below 0.03, therefore such is the minimum i put, because it has the safest and most trigger count.

And no, if they are to import, they need to at least know how to remove such lines of code. That is required to show how the "not revealed when attacking behind the fog" deal.

 

[IcemanBo]

Use the the AbilityId (integer), but not the ability type, for hashtable.
The AbilityId equals the rawcode that you can see in object editor.

Then for loading you can load value of key GetSpellAbilityId().
Of course this function now will also return an integer value, not an ability.

Edit:

No. So far, people all over taught me never to have a loop below 0.03,

The suggestion was to use 0.0312500. And 0.03 is smaller, so you it would not be below.

 

[The6thMessenger]

Use the the AbilityId (integer), but not the ability type, for hashtable.
The AbilityId equals the rawcode that you can see in object editor.

Then for loading you can load value of key GetSpellAbilityId().
Of course this function now will also return an integer value, not an ability.

Can someone give me the codes to be used in a custom script?

Also, there is an additional Axxx within, so it's really confusing.

Edit:


The suggestion was to use 0.0312500. And 0.03 is smaller, so you it would not be below.

Yes, and the point was, it's already faster to the safest limit, yet he/she wanted to complicate things.

 

[IcemanBo]

I see you created a thread about this problem, let's move the discusson there if still needed.
And using 0.0312500 would not really complicate it.

 

[GywGod133]

I see you created a thread about this problem, let's move the discusson there if still needed.
And using 0.0312500 would not really complicate it.

She/he dont know what is the different in 0.03125 in 0.03

 

[The6thMessenger]

I see you created a thread about this problem, let's move the discusson there if still needed.
And using 0.0312500 would not really complicate it.

Well, i have to change it when it's not needed.

Oh and i managed to clean things up with the hashtable, just give me a moment.

She/he dont know what is the different in 0.03125 in 0.03

And i don't care. But okay:

http://www.hiveworkshop.com/forums/lab-715/0-03-vs-0-03125-a-240479/#post2410684

0.03125 adds up to 1, with 32 updates per second, while 0.03 does not add up to 1, and with 33.3333 updates per second. But the thing is that it's not necessary, because there is no timing calculated here.

 

[GywGod133]

i add something...

Take Aim Attack, Visibility Attack Reveal, Visibility Cast Spell

In Take Aim Attack
(Level of Sniper - Take Aim for (Attacking unit)) Greater than 0

Visibility Attack Reveal
(Level of Sniper - Take Aim for (Attacking unit)) Less than or equal to 0

You must save the Ability in variable then change the (Level of Sniper - Take Aim for (Attacking unit), (Level of Sniper - Take Aim for (Attacking unit)

so like this
(Level of AbilityVar for (Attacking unit), (Level of AbilityVar for (Attacking unit)

===============

In your Visible Cast Spell
add Ability Cast equal to AbilityVar

 

[The6thMessenger]

i add something...

Take Aim Attack, Visibility Attack Reveal, Visibility Cast Spell

In Take Aim Attack
(Level of Sniper - Take Aim for (Attacking unit)) Greater than 0

Visibility Attack Reveal
(Level of Sniper - Take Aim for (Attacking unit)) Less than or equal to 0

You must save the Ability in variable then change the (Level of Sniper - Take Aim for (Attacking unit), (Level of Sniper - Take Aim for (Attacking unit)

so like this
(Level of AbilityVar for (Attacking unit), (Level of AbilityVar for (Attacking unit)

===============

In your Visible Cast Spell
add Ability Cast equal to AbilityVar

What.

 

[The6thMessenger]

Where is the mod?

 

[IcemanBo]

I think you have to be more patient, because it might take a while until a moderator reviews it. There are also some older resources waiting to be reviewed.

• Take usage of hashtable instead of looping in trigger "Take Aim Attack".
• This And - All block is not needed at all:
  

  (And - All (Conditions) are true) Conditions (Level of Sniper - Take Aim for (Attacking unit)) Greater than 0 ((Attacking unit) is in DS_TA_Learned) Equal to True

  You just can move them out. Same here:
  

  (And - All (Conditions) are true) Conditions ((Attacking unit) is A ranged attacker) Equal to True (Level of Sniper - Take Aim for (Attacking unit)) Less than or equal to 0 ((Attacking unit) belongs to an enemy of (Triggering player)) Equal to True

• Hardcoded things like following with using pre-placed units in main code is not acceptable:
  

  Hero - Learn skill for Dwarven Sniper 0099 <gen>: Sniper - Take Aim Unit - Set level of Sniper - Take Aim for Dwarven Sniper 0099 <gen> to 4

• Again, you can use hashtable and save index for all UnitTypes. This would prevent not needed checks. (Take Aim Transformation - trigger)
• Don't use the BJ functions of hashtable if you use custom script.
• In your init trigger you can use a hardcoded loop through all UnitTypes to save into hashtable, so the user has not to bother with it.
• Following should be in destroy & deindex part:
  

  If (All Conditions are True) then do (Then Actions) else do (Else Actions) If - Conditions Visibility_MUI_Index Less than or equal to 0 Then - Actions Trigger - Turn off (This trigger) Else - Actions

• You leak player groups
• Cast/Death/Visibility Attack Reveal trigger are to general. They would fire each time in a normal game even they are not needed.
• Combine both triggers with same event "A Unit Is Attacked".
• I'm in opinion naming of variables should be shorter and just more simple. Something like "MUI_INDEX" is not needed. Just call it Index. Also all these Temp_Integer_A/B/C for example, just unnecessarily long.
  You should use a general prefix that is used for all variables of your system, then one underscope and then a short and simple variable name.

Have a nice day.

 

[The6thMessenger]

I think you have to be more patient, because it might take a while until a moderator reviews it. There are also some older resources waiting to be reviewed.

• Take usage of hashtable instead of looping in trigger "Take Aim Attack".
• This And - All block is not needed at all:
  

  (And - All (Conditions) are true) Conditions (Level of Sniper - Take Aim for (Attacking unit)) Greater than 0 ((Attacking unit) is in DS_TA_Learned) Equal to True

  You just can move them out. Same here:
  

  (And - All (Conditions) are true) Conditions ((Attacking unit) is A ranged attacker) Equal to True (Level of Sniper - Take Aim for (Attacking unit)) Less than or equal to 0 ((Attacking unit) belongs to an enemy of (Triggering player)) Equal to True

• Hardcoded things like following with using pre-placed units in main code is not acceptable:
  

  Hero - Learn skill for Dwarven Sniper 0099 <gen>: Sniper - Take Aim Unit - Set level of Sniper - Take Aim for Dwarven Sniper 0099 <gen> to 4

• Again, you can use hashtable and save index for all UnitTypes. This would prevent not needed checks. (Take Aim Transformation - trigger)
• Don't use the BJ functions of hashtable if you use custom script.
• In your init trigger you can use a hardcoded loop through all UnitTypes to save into hashtable, so the user has not to bother with it.
• Following should be in destroy & deindex part:
  

  If (All Conditions are True) then do (Then Actions) else do (Else Actions) If - Conditions Visibility_MUI_Index Less than or equal to 0 Then - Actions Trigger - Turn off (This trigger) Else - Actions

• You leak player groups
• Cast/Death/Visibility Attack Reveal trigger are to general. They would fire each time in a normal game even they are not needed.
• Combine both triggers with same event "A Unit Is Attacked".
• I'm in opinion naming of variables should be shorter and just more simple. Something like "MUI_INDEX" is not needed. Just call it Index. Also all these Temp_Integer_A/B/C for example, just unnecessarily long.
  You should use a general prefix that is used for all variables of your system, then one underscope and then a short and simple variable name.

Have a nice day.

Yeah, the other ones i can take. Leave my variable naming alone.

 

[IcemanBo]

Are you going to update this?

 

[Maker]

You could get rid of the hashtable bj functions (use natives) and the map specific unit actions in the initialization trigger.
Do the rest of the stuff IcemanBo mentioned.
Use a variable for the ability.

I really recommend using a hashtable for this since if there are lots of unit types and upgrades for each unit type, the system can become a nightmare to set up.

Needs Fix

 

[The6thMessenger]

You could get rid of the hashtable bj functions (use natives) and the map specific unit actions in the initialization trigger.
Do the rest of the stuff IcemanBo mentioned.
Use a variable for the ability.

I really recommend using a hashtable for this since if there are lots of unit types and upgrades for each unit type, the system can become a nightmare to set up.

Needs Fix

Just hold on...