Limit number of upgrades for a building

[Fingolfin]

I am trying to make a map where each player controls a number of cities. Each city can have addons built onto them, like hospital, tax office, etc. Each city should only be able to chose 3 out of 5 available addons, once you have built 3, the rest should be greyed out (or just be made unavailable). How do i do this?

 

[Dr Super Good]

Sadly you are using WC3 where this is very difficult to do. Here are some far from perfect but acceptable ideas.

Make each update a hireable unit that have unlimited charge cooldown. Use triggers to detect when the unit has purchased 3 and then remove the charges for the remaining two (or all of them since it does not mater and is easier logically). The icons will still be there but the player can never buy any more upgrades as the charges will never replenish.

Make each upgrade an ability. Every time the player uses the ability you remove it. After 3 abilities were used you remove the remaining two (again, you can just bulk remove all abilities, no need for complex logic). You will need to trigger any cost and refunds associated with the abilities. No disabled icons but units are removed.

Each upgrade is a normal trainable unit. To prevent the same upgrade twice use triggers to cancel the train order (may need 0 timeout timer). You also cancel any training once 3 upgrades are applied. Cost is perfect but no disabled icons after 3 upgrades, just refunds and possibly a trigger generated error message.

In SC2 this is so easy to do as you just need to set the requirement for the various actions to not have the dummy used as queued or better with an additional requirement that once any 3 are queued or better then all are disabled.

 

[sethmachine]

I think this goes in line with what Dr Super Good said.

You can just make them trainable units, and for each city, keep track of the number of upgrades it has and each type. You could have an array holding some representation of a city, and each member has fields for each type of upgrade and the number of each researched so far.

When a player trains a unit, i.e. tries to make a 4th upgrade when already has done 4, detect this and simply refund the player, with an error message as Dr Super Good suggested.

This doesn't gray them out, however. Instead if you wanted a physical indication, you could change the city's look through various triggers. If you went really good, each upgrade would add on the bank, hospital, etc. visibly placed on the unit.

 

[Fingolfin]

Another idea i had was to simply make a tree of all possible events. Lets say that we have one building unit which can upgrade hospital, tax office, etc. What it does then is to upgrade it to another city unit which in turn can upgrade all options, minus the one you just upgared. And so it goes on until you are at the third "tier" - this unit cannot upgrade to anything (or has dummy upgrades which are greyed out). It should work as long as the number of possibilites is low. If you are to chose 3 options out of 4, the number of possible outcomes would be:

4!/(4-3)! = 24

With 3 options out of 5, it would be:

5!/(5-3)! = 60

Which frankly is a LOT of structures. Does anyone know how you could simplyfy this approach?

 

[Dr Super Good]

Another idea i had was to simply make a tree of all possible events. Lets say that we have one building unit which can upgrade hospital, tax office, etc. What it does then is to upgrade it to another city unit which in turn can upgrade all options, minus the one you just upgared. And so it goes on until you are at the third "tier" - this unit cannot upgrade to anything (or has dummy upgrades which are greyed out). It should work as long as the number of possibilites is low. If you are to chose 3 options out of 4, the number of possible outcomes would be:

Would certainly produce good results but I am not sure the extra object overhead is worth it. You would need to weigh the pros and cons of 24 to 60 or more objects against a single object with one of the above trigger systems. 24 to 60 objects has a non-trivial affect on load time which might be better spent on objects with more useful purposes.

 

[aple]

Am I missing something here? Why not just:

• Untitled Trigger 001
  • Events
    • Unit - A unit Begins construction
  • Conditions
    • (Constructing structure) Equal to Your Building
  • Actions
    • For each Variable from 1 to PlayerMaxIndex...
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • (Owner of (Triggering unit)) Equal to PlayerArrayIndex
          • Or - Any (Conditions) are true
            • Conditions
              • (Number of units in (Units owned by Player 1 (Red) of type Footman)) Greater than 0 \\Replace obvious stuff with obvious stuff
              • (Number of units in (Units owned by Player 1 (Red) of type Footman)) Greater than 0
              • (Number of units in (Units owned by Player 1 (Red) of type Footman)) Greater than 0
              • etc...
        • Then - Actions
          • Dr Super Good's idea
        • Else - Actions

Everything else needed can be worked into this, such as MUI/MPI.

 

[Dr Super Good]

You are missing cleaning up the group leaks.

(Units owned by Player 1 (Red) of type Footman) returns a unit group which has to be destroyed after use to prevent a leak.