Unit split

[Arathor]

Could anyone please post the triggers for this:
I have alot of units in a region i want to split into 4 groups and then teleport those new 4 groups into 4 new regions. How do i do this?

 

[Kusanagi Kuro]

Will the group be random? I mean the unit will be randomly add to random group.

 

[Kitabatake]

• Unit split
  • Events
    • Player - Player 1 (Red) types a chat message containing split as An exact match
  • Conditions
  • Actions
    • -------- Big region --------
    • Set Region[4] = Region 004 <gen>
    • -------- Other regions --------
    • Set Region[0] = Region 000 <gen>
    • Set Region[1] = Region 001 <gen>
    • Set Region[2] = Region 002 <gen>
    • Set Region[3] = Region 003 <gen>
    • -------- Move units from big region to other regions --------
    • Set UnitGroup = (Units in Region[4])
    • For each (Integer A) from 1 to (Number of units in UnitGroup), do (Actions)
      • Loop - Actions
        • Set Point = (Random point in Region[((Integer A) mod 4)])
        • Set Unit = (Random unit from UnitGroup)
        • Unit Group - Remove Unit from UnitGroup
        • Unit - Move Unit instantly to Point
        • Custom script: call RemoveLocation(udg_Point)
    • Custom script: call DestroyGroup(udg_UnitGroup)

 

[Arathor]

Thanks!

+rep

 

[Radicool]

You do not need to set the regions each time the trigger runs. Set them at map initialization.

 

[Kitabatake]

You do not need to set the regions each time the trigger runs. Set them at map initialization.

Bad idea.
That both prevents you from reusing the variables elsewhere and splits the trigger.
Also, it doesn't actually improve anything.

 

[Radicool]

That both prevents you from reusing the variables elsewhere and splits the trigger.

Given the variables are only used for this trigger, they will not need to be used elsewhere. And you dont need to create another trigger, every map should have 1 map initiallization trigger.

Also, it doesn't actually improve anything.

If they are set upon map initalization, that removes 5 lines of code off this trigger correct? Therefore it must run faster. Only logical.

 

[sentrywiz]

Bad idea.
That both prevents you from reusing the variables elsewhere and splits the trigger.
Also, it doesn't actually improve anything.

Actually the way you did is the bad idea and coding.
The idea given by Radicool is the correct way of action.
Unless the point of this is to dynamically add or remove regions from variables, which isn't.

In that case, setting the regions on map init and then reusing those variables is both smarter way and much simpler. You don't need to recreate the already existing variables with the already existing regions inside those variables.

You are just wasting extra lines of code doing the same thing which was already made the first time trigger ran. Not very smart or logical.

 

[Kitabatake]

And you dont need to create another trigger, every map should have 1 map initiallization trigger.

The problem is not creating another trigger.
The problem is having the functionality of a single "action" being splattered over more than one trigger, which can slow down and complicate debugging when the map project grows.

Also, it doesn't actually improve anything.

If they are set upon map initalization, that removes 5 lines of code off this trigger correct? Therefore it must run faster. Only logical.

Not really.

Optimization is worth it when it's a massive loop or a rapid periodic trigger.
But eliminating a tiny trigger element that has constant time complexity from a trigger that has linear time complexity for the sake of "optimization" is both ridiculous and vain.

 

[sentrywiz]

The problem is not creating another trigger.
The problem is having the functionality of a single "action" being splattered over more than one trigger, which can slow down and complicate debugging when the map project grows.


Not really.

Optimization is worth it when it's a massive loop or a rapid periodic trigger.
But eliminating a tiny trigger element that has constant time complexity from a trigger that has linear time complexity for the sake of "optimization" is both ridiculous and vain.

Triggers can be turned off. And its far simpler to create 5 triggers and turn them off at some point when they did what they were meant to instead of putting everything into one trigger and forcing recreation of same variables under same regions for the same purpose. They won't take any resources once they are properly turned off.

How can debugging be simpler when you debug one giant trigger that forces stuff to reoccur over and over and over because one was too lazy to create a trigger for each action, then turn them off when they aren't needed? I fail to see that logic.

Functionality will extend to more than one trigger when the project grows. Even triggers have a limit on the lines you can put there.


Let's look at this way:

You have one trigger that forces recreation of already existing variables with already existing regions that have been already given to the variables the first time the trigger ran. Now you split the units and recreate the same variables over and over. This trigger is never off

I have a map init trigger that gives regions to variables and it doesn't activate anymore than once. I can turn off that trigger right from the start to prevent it happening again ( not that it will ). Then another trigger that splits the units using the variables that have been created in the first trigger.

IF the project grows:

-you will have to add stuff to your trigger and force it to run every time the group splits. Then you'd have to implement the new changes of the project in the same trigger because that is the actual trigger that does the stuff

-I will simply add another trigger, make the changes there, use the new trigger from the split group trigger.

Which one is easier to both maintain and debug?