Feature request: upgrade detection

[planetfall]

I have a lot of custom friendly units in my maps, and would find it useful if I could make forge upgrades to apply to them.
What's more, upgrades are probably a better indicator of overall progress than, say, unit count, for adapting enemies.
Unfortunately, a crpl command to see what upgrades the player has seems to be lacking.

It would take a string as input and output the number of levels of that upgrade purchased by the player.
Example: "ENERGYEFFICIENCY" GetUpgradeLevel

[Flabort]

I would like to second this, and also the obvious companions, SetUpgradeLevel, UpgradesRequireForge (default true), and SetUpgradeLimit.

Even better, if using SetUpgradeLimit allowed for higher max values then the current hardcoded max. Such as going to level 40 in ore efficiency.

Such as the following control code, with external codes that increment CurrentLevel through SetScriptVar.

Code Select Expand

once
  false UpgradesRequireForge
  "OREEFFICIENCY" 40 SetUpgradeLimit
  "FORGE" 0 SetBuildLimit
  0 ->CurrentLevel
endonce

"OREEFFICIENCY" GetUpgradeLevel <-CurrentLevel lt if
  "OREEFFICIENCY" <-CurrentLevel SetUpgradeLevel
endif

[planetfall]

I would like to second this, and also the obvious companions, SetUpgradeLevel, UpgradesRequireForge (default true), and SetUpgradeLimit.

Actually, there's GetTechLimit and SetTechLimit (separate from Get/SetBuildLimit) already. They're used in the Egos system so that no matter what order you visit planets in, the first will have the fewest upgrades available and the last will have the most. It always struck me as a little odd that you could mess with the limits, but not even look at the actual upgrade state.

Even better, if using SetUpgradeLimit allowed for higher max values then the current hardcoded max. Such as going to level 40 in ore efficiency.

Such as the following control code, with external codes that increment CurrentLevel through SetScriptVar.

Code Select Expand

once
  false UpgradesRequireForge
  "OREEFFICIENCY" 40 SetUpgradeLimit
  "FORGE" 0 SetBuildLimit
  0 ->CurrentLevel
endonce

"OREEFFICIENCY" GetUpgradeLevel <-CurrentLevel lt if
  "OREEFFICIENCY" <-CurrentLevel SetUpgradeLevel
endif

Pretty sure upgrades are stored in the forge's unit data. That's why you lose upgrades if the forge is destroyed and why they are disabled if the forge is turned off. So upgrades without the forge is probably a thing to come much later (if ever)

But my 2 cents on how that would work:
It would be stored on a per-upgrade basis. So you could say
"OREEFFICIENCY" false UpgradeWithForge
This would make it impossible to upgrade ore efficiency at the forge, as though the tech limit were 0, but allow it to be set to other values behind the scenes. The "behind the scenes" value would be used by ore mines and/or crpl cores regardless of whether the forge is present, powered, etc. and will not go away if the forge is lost.
Meanwhile it would allow other things to be upgraded at the forge like normal.

[Flabort]

*facepalm about Tech/Upgrade Limit part* I even went to the reference to get the right notation for buildLimit, and accidentally clicked Tech instead.  ::)

And that is far more eloquently put and organized then I could have ever made that. Thank you, that was exactly what I was thinking.

[Vanguard]

While certainly nifty, simply caclulcating the tech gained from totems by time does the same trick. So if you want to strengthen enemies when a player has 200 technites/ether, you could simply say that it takes a totem 5 seconds for one ether, so with 3 totems on the map its ((200*5)/3)*30 Frames before taking your enemies to the next level. Works for me so far. :)

Edit: Rereading it, it is quite a nice idea to apply The players tech to your units. I am not far enough into the CRPL to mess with that for now, so I will keep looking into that later.

[Grayzzur]

While certainly nifty, simply caclulcating the tech gained from totems by time does the same trick. So if you want to strengthen enemies when a player has 200 technites/ether, you could simply say that it takes a totem 5 seconds for one ether, so with 3 totems on the map its ((200*5)/3)*30 Frames before taking your enemies to the next level. Works for me so far. :)

Edit: Rereading it, it is quite a nice idea to apply The players tech to your units. I am not far enough into the CRPL to mess with that for now, so I will keep looking into that later.

Are you taking into account that someone can turn off the totems to conserve energy, and won't be gaining ether during that time?

[Vanguard]

Are you taking into account that someone can turn off the totems to conserve energy, and won't be gaining ether during that time?

Depends on the layout of the map. I agree the scripted way of getting the Techs upgrades "scales" a bit better. But the simple timing method has the advantage of a more streamlined difficulty, making scores on the map better to evaluate. How do you, for example, take into account people who accumulate 30000 Aether without upgrading?

[Grayzzur]

Are you taking into account that someone can turn off the totems to conserve energy, and won't be gaining ether during that time?

Depends on the layout of the map. I agree the scripted way of getting the Techs upgrades "scales" a bit better. But the simple timing method has the advantage of a more streamlined difficulty, making scores on the map better to evaluate. How do you, for example, take into account people who accumulate 30000 Aether without upgrading?

People who gather 30,000 aether without bothering to upgrade aren't going to be competing for top scores. I wouldn't bother to account for them.

[Annonymus]

What if someone uses most of the aether he/she gathers for the singularity weapon?

[Vanguard]

People who gather 30,000 aether without bothering to upgrade aren't going to be competing for top scores. I wouldn't bother to account for them.

The ironic thing is that writing a script is MORE bother than just counting the seconds. Haha, never argue with me. I drag you down to my level and beat you with experience.  ::)

Nah, just kidding. I agree. The more you can script, the better ( usually ) it gets. I will probably still conitnue to use the linear time method, simply because I like to time my map(s soon) meticulously.