[Solved] Unit Ranking System

[Kadel]

Hello everyone, I am back after a long time to ask for some help. I am trying to implement a Ranking Unit System. There is a game you may know called "Battle for Wesnoth" where units on the field can gain exp for kills and they advance to the next rank after reaching some value.

Spoiler: Wesnoth Unit Advancement

------------------>

I decided to implement something like that but a bit simpler, so what I have (explanations are below all tables):

Table 1 - EXP gain within range (Xp1, Xp2) by killing a unit of determined level

LvL	Xp 1	Xp 2
1	1	9
2	10	19
3	20	29
4	30	39
5	40	49
6+	50	60

Table 2 - Unit Ranking System

From Rank 1 ->	-> To Rank 2
Unit ingame LvL	Required EXP
LvL 1	20
LvL 2	40
LvL 3	60
LvL 4	80
LvL 5+	100

Table 3 - Theoretical Example of my Hashtable

Saved Value	Parent Key	Child Key	Saved Value	Parent Key	Child Key
Unit	unit_index	0	Unit EXP	unit_index	1
Footman	0	0	20	0	1
Grunt	1	0	12	1	1
Footman	2	0	34	2	1

Basically, Table 1 shows how many EXP points would gain a unit if it killed a unit of a certain LvL. For example, if Footman kills a default forest Troll it will gain from 10 to 19 EXP points.
Table 2 is about how many EXP points a certain LvL needs to advance to the next rank. For instance, again, Footman is lvl 2 unit, so he needs 40 points to advance to Captain, while Grunt needs 60 XP because he is a LvL 3 unit.
Table 3 represents my understanding and approach of how I will save a unit and its exp...

As usual, I came up with something but messed up with the implementation, so I pin my custom map here where I tried to implement the mentioned system. Even those who have the same level of practice with triggers as I do can understand that something went wrong, but to be honest it’s still difficult for me to understand whether I messed up with the code or the approach, because the tools of debugging other than outputting variable values are absent...
Therefore, I ask you to take a look and help solve the problem that has arisen with this system. (Ignore anything that doesn't relate to the topic when looking at the map)

 

[Pyrogasm]

You can make units into pseudo-heroes that gain experience, which may be relevant to (or massively simplify) your approach here. Even if you just manually award the XP when they kill something it would reduce a bunch of the data you have to store and use. A comprehensive resource about the method to achieve this is here: HeroicUnit - Engineering Upgrade on non-hero units!

 

[Uncle]

Using a Hashtable for this is really awkward in my opinion.

Unit Indexing gets the job done with far less trouble and you can use Unit Groups instead of For Loops to manage multiple units at once.

This allows you to create simple triggers like so:

• Unit Group - Pick every unit in Player_Units[1] and do Actions
  • Loop - Actions
    • Set Variable Rank_CV = (Custom value of (Picked unit))
    • Set Variable Rank_Level[Rank_CV] = (Rank_Level[Rank_CV] + 1)

^ I increased the Rank of each unit owned by Player 1.

I attached a map demonstrating this. It may be missing some important functions but they won't be difficult to implement.

 

[Kadel]

Using a Hashtable for this is really awkward in my opinion.

Unit Indexing gets the job done with far less trouble and you can use Unit Groups instead of For Loops to manage multiple units at once.

This allows you to create simple triggers like so:

• Unit Group - Pick every unit in Player_Units[1] and do Actions
  • Loop - Actions
    • Set Variable Rank_CV = (Custom value of (Picked unit))
    • Set Variable Rank_Level[Rank_CV] = (Rank_Level[Rank_CV] + 1)

^ I increased the Rank of each unit owned by Player 1.

I attached a map demonstrating this. It may be missing some important functions but they won't be difficult to implement.

I am sorry for being late in response, my idea was exactly to remove the ranking unit from the map and create a new one, i.e. Footman becomes Captain (captain appears on the field instead of the Footman), then Captain becomes General and so on... I started only with a simpler solution that a Unit can advance only once, so I don't need to create many custom units... Maybe I just need to give the unit a new model and change some stats instead of creating a new one... But I saw that I can't do the last thing because of "cons" of unit indexer though I don't really understand what the author meant...
But your idea is a good one too.

 

[Uncle]

I am sorry for being late in response, my idea was exactly to remove the ranking unit from the map and create a new one, i.e. Footman becomes Captain (captain appears on the field instead of the Footman), then Captain becomes General and so on... I started only with a simpler solution that a Unit can advance only once, so I don't need to create many custom units... Maybe I just need to give the unit a new model and change some stats instead of creating a new one... But I saw that I can't do the last thing because of "cons" of unit indexer though I don't really understand what the author meant...
But your idea is a good one too.

If you replace the unit it will be given a new custom value since it's a new unit, but it's not difficult to cache the old data and pass it onto the new unit:

• -------- A unit ranked up -> replace it with a more powerful unit ---------
• Set Variable Rank_Level[0] = Rank_Level[Rank_CV]
• Set Variable Rank_Experience[0] = Rank_Experience[Rank_CV]
• Set Variable Rank_Exp_Needed[0] = Rank_Exp_Needed[Rank_CV]
• Unit - Replace Rank_Source with a ...
• -------- Now that it's a new unit we will have to re-apply all our previous variables to it --------
• Set Variable Rank_Source = (Last replaced unit)
• Set Variable Rank_CV = (Custom value of Rank_Source)
• Set Variable Rank_Level[Rank_CV] = Rank_Level[0]
• Set Variable Rank_Experience[Rank_CV] = Rank_Experience[0]
• Set Variable Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed[0]

^ This could go directly into my Rank On Level Up trigger.

The different Unit-Types that each Unit uses could be stored in a Hashtable beforehand using the Unit-Type Id as the Parent key.
Hashtable[Footman Id] -> Captain
Hashtable[Captain Id] -> Knight
Hashtable[Knight Id] -> Gryphon Rider
etc...

Note that you'd have to do the same thing with a Hashtable since a new unit has a new handle id.

 

[Kadel]

If you replace the unit it will be given a new custom value since it's a new unit, but it's not difficult to cache the old data and pass it onto the new unit:

• -------- A unit ranked up -> replace it with a more powerful unit ---------
• Set Variable Rank_Level[0] = Rank_Level[Rank_CV]
• Set Variable Rank_Experience[0] = Rank_Experience[Rank_CV]
• Set Variable Rank_Exp_Needed[0] = Rank_Exp_Needed[Rank_CV]
• Unit - Replace Rank_Source with a ...
• -------- Now that it's a new unit we will have to re-apply all our previous variables to it --------
• Set Variable Rank_Source = (Last replaced unit)
• Set Variable Rank_CV = (Custom value of Rank_Source)
• Set Variable Rank_Level[Rank_CV] = Rank_Level[0]
• Set Variable Rank_Experience[Rank_CV] = Rank_Experience[0]
• Set Variable Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed[0]

^ This could go directly into my Rank On Level Up trigger.

The different Unit-Types that each Unit uses could be stored in a Hashtable beforehand using the Unit-Type Id as the Parent key.
Hashtable[Footman Id] -> Captain
Hashtable[Captain Id] -> Knight
Hashtable[Knight Id] -> Gryphon Rider
etc...

Oh, thank you, before I read this I had already started doing the same things.
But I have a few questions:

1. Why are you overwriting the array value Rank_Level[0] with Rank_Level[Rank_CV]? Our current unit data may not be stored in cell [0] because it was previously stored in [Rank_CV]. Like we had in Rank Setup:

Set VariableSet Rank_Level[Rank_CV] = 1
Set VariableSet Rank_Exp[Rank_CV] = 0
Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[1]

Maybe I misunderstand something?

2. Second question may be a bit off-topic but I don't want to do a new thread. Do you know how I can check (in conditions) whether another trigging is running at the same time? I have a kind of situation where I replace a new unit and another trigger with Events-
Unit - A unit enters (Playable map area) runs at the same time because the unit was replaced and entered a map area.. So I don't need a trigger queue, I just need to check whether the trigger is running. I don't want to turn it off either and the triggers queues are not an option...

 

[Uncle]

1.

I'm simply storing the pre-replaced unit's data in variables. What variables those are doesn't really matter. Here I'm reusing some of my existing variables to save space. I know that index [0] is unused and is safe to use this way since the Unit Indexer only uses index [1] and greater.

When you replace a unit it's Removed from the game and a brand new unit is Created at it's position. This new unit has a new handle id and will be assigned a new custom value by the Unit Indexer. That means the new unit loses any old data references it might have had. My solution here is to store and transfer the old unit's data to the new unit like so:

A) Store the old unit's data in those [0] variables. (or any vars of your choosing)
B) Replace the unit. It now has a new custom value and lost all of it's data.
C) Apply the old data to the new unit.

2.

You could use a Boolean variable. Set it to True when the first trigger runs right before you Create the unit, then check for this Boolean in the second trigger, and finally set the Boolean to False after the Create unit action.

 

[Kadel]

1.

I'm simply storing the pre-replaced unit's data in variables. What variables those are doesn't really matter. Here I'm reusing some of my existing variables to save space. I know that index [0] is unused and is safe to use this way since the Unit Indexer only uses index [1] and greater.

When you replace a unit it's Removed from the game and a brand new unit is Created at it's position. This new unit has a new handle id and will be assigned a new custom value by the Unit Indexer. That means the new unit loses any old data references it might have had. My solution here is to store and transfer the old unit's data to the new unit like so:

A) Store the old unit's data in those [0] variables. (or any vars of your choosing)
B) Replace the unit. It now has a new custom value and lost all of it's data.
C) Apply the old data to the new unit.

2.

You could use a Boolean variable. Set it to True when the first trigger runs right before you Create the unit, then check for this Boolean in the second trigger, and finally set the Boolean to False after the Create unit action.

2. Oh, it was not obvious to me but it looks simpler than I could imagine. Will do.

1. I added your mentioned part of code to the Rank On Level Up trigger [let it sign as 1.1]. And there is only two things I have changed in your code:

In Rank Setup I did Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[LvL of Picked unit] instead of Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[1]

AND
In Rank on Kill I added before the first IF block

Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[LvL of Killing Unit] also to track Unit Lvl. Because I intended to do EXP system based not on Rank, but on Unit LvL itself. So not 20->40 an so on, but 40 (because Footman lvl is 2) and 80 (because Knight is 4 lvl unit)

And it seems like the game crushes when I added 1.1 and I am wondering why...

 

[Uncle]

2. Oh, it was not obvious to me but it looks simpler than I could imagine. Will do.

1. I added your mentioned part of code to the Rank On Level Up trigger [let it sign as 1.1]. And there is only two things I have changed in your code:

In Rank Setup I did Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[LvL of Killing unit] instead of Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[1]

AND
In Rank on Kill I added before the first IF block

Set VariableSet Rank_Exp_Needed[Rank_CV] = Rank_Exp_Needed_Table[Unit_Level] also to track Unit Lvl. Because I intended to do EXP system based not on Rank, but on Unit LvL itself. So not 20->40 an so on, but 40 (because Footman lvl is 2) and 80 (because Knight is 4 lvl unit)

And it seems like the game crushes when I added 1.1 and I am wondering why...

I guess I'm a little confused.

1) How many upgrades can a unit have? Does a unit only ever upgrade once?

2) If a unit can upgrade more than once, Footman -> Captain -> Knight, what happens if say a Footman gains 1000 experience? Does it go from a Footman to a Knight and skip becoming a Captain?

3) Continuing on #2, if say a Level 1 Footman has 0/20 exp, gains +30 exp and upgrades to a Level 2 Captain, would it now have 10/40 exp? Or would it now have 30/60 exp?

Also, I can only guess why things wouldn't work if you don't show me your triggers.

 

[Kadel]

Yeah, I am sorry, I uploaded your file that I modified with mentioned way...
I also replaced a unit rank in its name and now I show their EXP instead. Also I fixed the names for trained units ["entered units" must be on but I haven't fixed it] because they had only name with no rank and then after advancing they had only number [2] or more but like I mentioned now all units have XP showed instead of ranks...

1) In general I wanted to advance a unit once and later make a list of units that can advance or not. For example, Footman advances to Captain but Captain cannot. So it's like every type of unit would have a field which says whether it can advance or not... So every unit in future will have a unique number of ranks if I wanted them to. Because I could create custom unit "General" and wanted Captains advance to Generals and someone, like, Grunts would only advance to "Great Grunt" and Great Grunt would not advance. So actually any unit is specified. But now I am focusing only on one advancement because it is easier.

2) I think it must be like in Battle for Wesnoth - Unit that has a lot of XP will advance to latest rank immediately.

3) It would be better if he preserved his xp, i.e. 10 value, and then, because captain is lvl 3 unit if am not mistaken, captain must have 10 of 60... But if a Footman is a 2 lvl unit, it has to gain 40 xp, not 30.... to become captain that is lvl 3 unit in game...

 

[Uncle]

Okay that makes sense. I edited my last comment which you may have missed, how about this question?

3) If say a Level 1 Footman has 0/20 exp, it gains +30 exp and upgrades to a Level 2 Captain, would it now have 10/40 exp? Or would it now have 30/60 exp?

So does the exp sort of "reset" when it upgrades? It's not super important but it'll change the way I do the math.

It shouldn't be difficult at all to add support for multiple ranks.

 

[Kadel]

Okay that makes sense. I edited my last comment which you may have missed, how about this question?

3) If say a Level 1 Footman has 0/20 exp, it gains +30 exp and upgrades to a Level 2 Captain, would it now have 10/40 exp? Or would it now have 30/60 exp?

So does the exp sort of "reset" when it upgrades? It's not super important but it'll change the way I do the math.

It shouldn't be difficult at all to add support for multiple ranks.

I Edited my a moment ago, could you please read again?

 

[Uncle]

Okay, you're changing the Exp Table to be 10 * Level? Your original post said 20/40/60/80/100.

Edit: I think I misread.

Anyway, I understand.

I have to go for a bit but here's what I came up with so far. It's not finished but I think it's very close to what you want.

 

[Kadel]

Okay, you're changing the Exp Table to be 10 * Level? Your original post said 20/40/60/80/100.

Anyway, I understand.

I write again just in case and to make it as clear as possible.

For example, we have Footman. We all know he is a LvL 2 unit in the game. We don't see his ingame LvL because he is not neutral hostile (we all know that). In my original post, the table 2 referred to info, that unit has amount of xp to gain based on his ingame lvl...

I think it will be more balanced If footman needs 40 xp to become Captain and Grunt requires 60 Xp to become [new unit we will decide]. Because if both grunt and footman needs 20 xp because they rank is 1, it is unfair..


I hope we dealt with minor misunderstanding.

UPD: Object Editor allows us to set Unit Level too whatever we want with some restrictions I don't remember. But If a unit that we will advance has ingame lvl > 5, we set it to 5 anyway, or we just can expand our array that gives us max exp based on its lvl... I just came up with 5, but it doesn't matter anyway. It only will affect how large our exp_needed array will be...

 

[Kadel]

Okay, you're changing the Exp Table to be 10 * Level? Your original post said 20/40/60/80/100.

Edit: I think I misread.

Anyway, I understand.

I have to go for a bit but here's what I came up with so far. It's not finished but I think it's very close to what you want.

Thank you, I am going to upload and dive into every detail you added.

UPD: It seems that everything is working fine. I will play around more with it later, but I think the thread should be set to [Solved] relatively soon.

 

[Uncle]

Thank you, I am going to upload and dive into every detail you added.

UPD: It seems that everything is working fine. I will play around more with it later, but I think the thread should be set to [Solved] relatively soon.

Alright, here's the "final" product. I've added a Hashtable to track data for upgrading units and for defining their starting stats.

The system automatically registers newly created units whether they're trained, sold, created in triggers, etc. It doesn't matter what rank the unit is, everything should work as expected. But that's only if you've defined all of the important variables in the Rank Setup triggers and have given the Unit Rank ability to unit's that can "rank up".

You'll see I've setup these units:

Footman = Rank Tier 1, Upgrade Exp Needed: 40, Upgrades into Captain.
Captain = Rank Tier 2, Upgrade Exp Needed: 60, Upgrades into Knight.
Knight = Rank Tier 3, Maxed out.

Grunt = Rank Tier 1, Upgrade Exp Needed: 60, Upgrades into Tauren.
Tauren = Rank Tier 2, Maxed out.

The Exp Needed is tied to the unit's Level (the value defined in the Object Editor).

Note: This ability is very important, it's used as a Condition to determine what can and cannot rank up:

You'll see I've added it to the Footman, Captain, and Grunt since they can rank up. Knights and Taurens do not have it since they're max rank. I've hidden the button so it won't show up in the command card but you'll see it added in their Abilities field.

 

[Pyrogasm]

I imagine Uncle might have said this somewhere in the thread but I didn't see it with a cursory look. Replacing units directly with a trigger will have a few side effects that may or may not matter in your map:

• Any control-groups the unit was part of will not include the upgraded version. (Like Ctrl+1..0 groups for fast access)
• The unit's current order will be lost so it will default to a smart at its current location (though the most recent order could be found with a trigger and reissued).
• Any orders targeting the previous unit will also be lost (and is much harder to account for), and units that were attacking that target before may no longer auto-acquire it.
• The unit will no longer be selected if it was selected before (though this too could be done manually).
• Any active cooldowns for abilities shared between both unit-types (say both Footman and Captain can cast Holy Light) will be reset and the abilites will no longer be on cooldown (could also be accounted for with new editor natives to start ability cooldowns).

These are relatively minor issues but may affect map flow for players if many units are upgrading constantly such that it's hard to keep track of them. All of them can be avoided by using a reverse bear form morph to change one unit-type into another unit-type, though that will require a few abilities properly configured in order to actually do the morphing.

 

[Kadel]

I imagine Uncle might have said this somewhere in the thread but I didn't see it with a cursory look. Replacing units directly with a trigger will have a few side effects that may or may not matter in your map:

• Any control-groups the unit was part of will not include the upgraded version. (Like Ctrl+1..0 groups for fast access)
• The unit's current order will be lost so it will default to a smart at its current location (though the most recent order could be found with a trigger and reissued).
• Any orders targeting the previous unit will also be lost (and is much harder to account for), and units that were attacking that target before may no longer auto-acquire it.
• The unit will no longer be selected if it was selected before (though this too could be done manually).
• Any active cooldowns for abilities shared between both unit-types (say both Footman and Captain can cast Holy Light) will be reset and the abilites will no longer be on cooldown (could also be accounted for with new editor natives to start ability cooldowns).

These are relatively minor issues but may affect map flow for players if many units are upgrading constantly such that it's hard to keep track of them. All of them can be avoided by using a reverse bear form morph to change one unit-type into another unit-type, though that will require a few abilities properly configured in order to actually do the morphing.

Certainly, you are right, I was aware of it and the next step I would like to do is: to save the unit selection if it was, add it to the control group if it was there and so on. I might not know exactly how to do this, but I saw at least Turnro guides and he was doing something similar but before he played cinematics. Maybe I find out something like that in the Net too or just keep going to work by myself.

 

[Uncle]

Certainly, you are right, I was aware of it and the next step I would like to do is: to save the unit selection if it was, add it to the control group if it was there and so on. I might not know exactly how to do this, but I saw at least Turnro guides and he was doing something similar but before he played cinematics. Maybe I find out something like that in the Net too or just keep going to work by myself.

The good news is that you could tie what Pyro is suggesting into what we've been working on so far, or probably any solution for that matter. The logic should remain mostly the same, it's just this one Action that changes:

• Unit - Replace Rank_Source...

I'll have to look into Hero Passive Transformation, it sounds too good to be true, lol.

 

[Kadel]

Alright, here's the "final" product. I've added a Hashtable to track data for upgrading units and for defining their starting stats.

The system automatically registers newly created units whether they're trained, sold, created in triggers, etc. It doesn't matter what rank the unit is, everything should work as expected. But that's only if you've defined all of the important variables in the Rank Setup triggers and have given the Unit Rank ability to unit's that can "rank up".

You'll see I've setup these units:

Footman = Rank Tier 1, Upgrade Exp Needed: 40, Upgrades into Captain.
Captain = Rank Tier 2, Upgrade Exp Needed: 60, Upgrades into Knight.
Knight = Rank Tier 3, Maxed out.

Grunt = Rank Tier 1, Upgrade Exp Needed: 60, Upgrades into Tauren.
Tauren = Rank Tier 2, Maxed out.

The Exp Needed is tied to the unit's Level (the value defined in the Object Editor).

Note: This ability is very important, it's used as a Condition to determine what can and cannot rank up:
View attachment 470942
You'll see I've added it to the Footman, Captain, and Grunt since they can rank up. Knights and Taurens do not have it since they're max rank. I've hidden the button so it won't show up in the command card but you'll see it added in their Abilities field.

Thank you, good job, that I was supposed to do by myself. I will specify more units that can be upgraded soon and it can say that the ranking system is implemented.

UPD: Yeah I heard something about passive hero transformation, even founded the thread here. Or maybe I can do that units just morph into another unit, like druid of claw...

 

[Uncle]

Thank you, good job, that I was supposed to do by myself. I will specify more units that can be upgraded soon and it can say that the ranking system is implemented.

UPD: Yeah I heard something about passive hero transformation, even founded the thread here. Or maybe I can do that units just morph into another unit, like druid of claw...

Apologies if I sort of stole a fun project for you, I started out wanting to show a proof of concept but was having fun making it and ended up "finishing" it. Hopefully you can improve upon the system and make it your own with unique additions and other features.

Also, you should try what Pyro suggested, the Morph solution looks super simple. You can modify the Hashtable to save the Ability id's rather than the upgrade Unit-Type id's. Then adjust the the "On Rank Up" trigger to use this new Morph method rather than Replacing the unit.

 

[Kadel]

Apologies if I sort of stole a fun project for you, I started out wanting to show a proof of concept but was having fun making it and ended up "finishing" it. Hopefully you can improve upon the system and make it your own with unique additions and other features.

Also, you should try what Pyro suggested, the Morph solution looks super simple. You can modify the Hashtable to save the Ability id's rather than the upgrade Unit-Type id's. Then adjust the the "On Rank Up" trigger to use this new Morph method rather than Replacing the unit.

No problem, you didn't steal anything and this is not a fun project cause I planned to use it in my future projects (maybe a campaign) I do appreciate that you are helping me even faster I can imagine.
I don't mind either if someone in future would use this system because he/she considered it interesting.

UPD: Okay, I did as you said: I created 3 spells that transfer one Unit to another after reading this. I store an Ability Code instead of Rank_Hash_Upg_Unit and retrieve an ability when I need to add and remove it from the ranking unit. It seems all works smoothly but before I did all the stuff I noticed that we have a problem: the ranking up unit does not have a name after he ranks up.

I tried to change Rank_Hash_Upg_Unit to Rank_Hash_Upg_Unit_Name and store it converting from string to integer and then vice versa to give the unit a new name. But it somehow does not work and it uses "0" instead of a new proper name. And I don't know what functionality needs to be removed because now, for example, we do not replace a unit. I leave the modified map here, please give me feedback.

 

[Uncle]

No problem, you didn't steal anything and this is not a fun project cause I planned to use it in my future projects (maybe a campaign) I do appreciate that you are helping me even faster I can imagine.
I don't mind either if someone in future would use this system because he/she considered it interesting.

UPD: Okay, I did as you said: I created 3 spells that transfer one Unit to another after reading this. I store an Ability Code instead of Rank_Hash_Upg_Unit and retrieve an ability when I need to add and remove it from the ranking unit. It seems all works smoothly but before I did all the stuff I noticed that we have a problem: the ranking up unit does not have a name after he ranks up.

I tried to change Rank_Hash_Upg_Unit to Rank_Hash_Upg_Unit_Name and store it converting from string to integer and then vice versa to give the unit a new name. But it somehow does not work and it uses "0" instead of a new proper name. And I don't know what functionality needs to be removed because now, for example, we do not replace a unit. I leave the modified map here, please give me feedback.

You were overcomplicating the unit name stuff, you could simply do this after morphing the unit:

• Set VariableSet Rank_Unit_Name[Rank_CV] = (Name of Rank_Source)

Morph is great here because it remains the same unit so our variables aren't unset.

I fixed it in the attached map and removed anything else I found unnecessary -> IE: Since no new unit is created when upgrading we don't have to disable the Rank Register Unit trigger.

 

[Kadel]

You were overcomplicating the unit name stuff, you could simply do this after morphing the unit:

• Set VariableSet Rank_Unit_Name[Rank_CV] = (Name of Rank_Source)

Morph is great here because it remains the same unit so our variables aren't unset.

I fixed it in the attached map and removed anything else I found unnecessary -> IE: Since no new unit is created when upgrading we don't have to disable the Rank Register Unit trigger.

Thank you. I think we have done anything I came up with, now everyone can set up the ranking system and use it whatever.