Universal Cost function

Since the stats menu is going through some changes, would it make sense to implement a single cost function that would work with all abilities.

Use arrays in the defaultvalues section:
Code:

 allowedclass[0]='ClassWeaponsMaster'
 allowedclass[1]='ClassAdrenalineMaster'
 
 MinimumWepSpeed=0
 MinimumHealth=0
 MinimumAdrenaline=0
 MinimumDB=50
 MinimumDR=30
 MinimumAmmo=0
 
 MinimumLvl=30
 LvlStep=6   // 30,36,42,48...etc
 AbilityLevelCap=5
 
 //or
 
 ReqLevel[0]=30
 ReqLevel[1]=36
 ReqLevel[2]=42
 ReqLevel[3]=48
 ReqLevel[4]=54

The reason for this is:
1: This should eliminate the need for each ability to have its own cost function. Especially since many abilities have no need for anything different.
2: Simplify requirement revisions. If the requirements can exist in the config file, a server admin only needs to update the config file instead of subclassing the ability. Even if the config file is not an option, subclassing the ability will only involve changing the defaultvalues.
3: Self documentation. I could write a script to parse the config file, and defaultvalues to document requirements for each ability.

It may be worth doing, if only for giving other server admins an easier way of configuring the abilities without subclassing them.

Thoughts:

Restrictions based on class are no longer in the Cost function. That is handled by the SubClass code - assuming no showstoppers prevent this. However, having all abilities using the same Cost function may allow an extra check to be incorporated - to cope with the situations we sometimes get of the wrong list of abilities being presented.

Making all the relevant variables config variables should allow them to be overriden by updating the ini file

You will still end up with a Cost function for abilities like Loaded Artifacts, that have varying costs per level. Unless you add extra variables for that.

You may want to add one (or more) prerequisite abilities - so you can configure that you can only buy this if you already have this other ability

You may also want to configure in exclusion abilities. So, you can't buy this ability if you already have x

Basically, you would create a "CostedRPGAbility" that subclasses RPGAbility, that all the DruidsRPG abilities are subclassed off. Including RPGDeathAbility and MonsterAbility. This ability would have your Cost function in it

DruidsRPG currently subclasses a lot of UT2004RPG classes e.g. Vampire. This change would require these abilities be based on your CostRPGAbility, rather than the UT2004RPG ability - so a chunk of code would need to be copied across for each of them

Some of the abilities you can buy on DC are native UT2004RPG ones e.g. Smart Healing. We may have to create new Druid versions of these abilities just to have the new cost function - or we stick with the old cost function for those

Not sure what the AbilityLevelCap is for? Doesn't MaxLevel achieve the same? Ah - things like Loaded Weapons where only two of the levels have player level caps? But this could be configured 1,40,55,55,55,55

The exact level you can currently buy up to is now configured in the SubClass code. It may be possible to put this level checking also into this cost function. It wasn't possible without having all abilities subclasses off the same ability

One other thing we have never done in the past, is to have different costs based upon other things. So for example Adrenal Drip could be 2,8,14,... for players with "Class Adrenaline Master", but double that for other players.

EDIT: I notice Mysterial specifically states that this is not a good idea. So perhaps best to shelve for the moment.

EDIT: Perhaps this also applies to having prerequisite or excluding abilities. If it gets read back on startup in the wrong order, the wrong cost will be calculated.

If you want to implement the CostRPGAbility (or whatever you want to call it) base ability with the Cost function, and post me the code, then I will modify all the abilities to use.

It would probably also make sense for me to do the Class/SubClass checks, unless you are feeling brave.

Making the values configurable may not work. There is no easy way to replicate any configured values to the client.
Which would mean the server configuration would not be implemented at the time the player is buying the ability clientside.
So, all values fixed in the abilities

Szlat wrote:

One other thing we have never done in the past, is to have different costs based upon other things. So for example Adrenal Drip could be 2,8,14,... for players with "Class Adrenaline Master", but double that for other players.

EDIT: I notice Mysterial specifically states that this is not a good idea. So perhaps best to shelve for the moment.

EDIT: Perhaps this also applies to having prerequisite or excluding abilities. If it gets read back on startup in the wrong order, the wrong cost will be calculated.

I can see how the book keeping can get messy.
I don't have the source in front of me, but I wonder if there is a way to implement cleanup code that can remove abilities with unmet dependencies, and correct cost issues. If possible it could also be used to catch exploits where players can buy abilities that they shouldn't.

greg11 wrote:

Szlat wrote:

One other thing we have never done in the past, is to have different costs based upon other things. So for example Adrenal Drip could be 2,8,14,... for players with "Class Adrenaline Master", but double that for other players.

EDIT: I notice Mysterial specifically states that this is not a good idea. So perhaps best to shelve for the moment.

EDIT: Perhaps this also applies to having prerequisite or excluding abilities. If it gets read back on startup in the wrong order, the wrong cost will be calculated.

I can see how the book keeping can get messy.
I don't have the source in front of me, but I wonder if there is a way to implement cleanup code that can remove abilities with unmet dependencies, and correct cost issues. If possible it could also be used to catch exploits where players can buy abilities that they shouldn't.

Actually it looks like the prerequisite and exclusion should be ok. By the time the checks are made, the complete list of abilities purchased has been read in.

I think we will hit problems if we have different costs based on the existence of another ability. If you end up with both, the system will not know which order you bought them in, so cannot calculate the cost you paid.

So the generic Cost function should be able to cope with prerequisite and excluding abilities.

On a wider issue, I think there have been a number of variables in abilities that have been set to be config, when they will not work. We will end up with the server using one value and the client another. And since purchasing is done clientside, things like costs and minimum requirements cannot be config variables. Things like DamagePercent, which would only be used serverside, are ok.

So likewise, the list of excluding and prerequisite abilities cannot be config variables - which takes a lot of the use out of them.

Szlat wrote:

things like costs and minimum requirements cannot be config variables.

The last line of RPGStatsInv.ServerAddAbility passes the cost value to ClientAddAbility. Doesn't this mean that the cost function does not need to be replicated? If so, why is it a simulated function?

greg11 wrote:

Szlat wrote:

things like costs and minimum requirements cannot be config variables.

The last line of RPGStatsInv.ServerAddAbility passes the cost value to ClientAddAbility. Doesn't this mean that the cost function does not need to be replicated? If so, why is it a simulated function?

Agreed that the main calculation is done serverside, and the correct points adjustment will be made clientside by the calls to ServerAddAbility and ClientAddAbility. Once you have bought the ability.

However, consider an ability that has a compiled cost of 10, and a min level of 50.
The server may have a configuration that sets the cost to 5 and the min level to 20.
On the StatsMenu, you will be told the cost is 10, and the min level is 50, and the request will not get passed onto the server until those checks succeed. Once the server gets the request, it will only subtract 5 points for the cost (ServerAddAbility), and tell the client the ability has been bought for 5 (ClientAddAbility).

A more extreme problem would be if an ability has AbilityRegen say as a prerequisite. Let's say on the server they replace AbilityRegen with DruidAbilityRegen. On the server side, the config is changed to say DruidAbilityRegen is the prerequisite. However, the client will not let you buy it until you have the AbilityRegen fucntion, and will disable the Buy button.

I really like the idea of a standardised Cost function. It would mean I could build in some extra SubClass code for checking the odd situations that occur.

Have you started on it yet greg11, or would you like me to take it on?

I haven't started on it yet.
I have a final on the 8th that I will need to get ready for, but I can work on this afterwards.

I was thinking about also standardizing the ability descriptions with a template that the cost function can automatically add the appropriate info like cost, class, and level requirements.

greg11 wrote:

I haven't started on it yet.
I have a final on the 8th that I will need to get ready for, but I can work on this afterwards.

Good luck on the exam. I might try to build a prototype then that I can stick some SubClass checking into, because I want to try to get that in for the next build - whenever that is. I am not happy about people managing to circumvent the subclass checks, and I want to plug any gaps ASAP.
You could then add whatever enhancements you like - if that is ok with you?

greg11 wrote:

I was thinking about also standardizing the ability descriptions with a template that the cost function can automatically add the appropriate info like cost, class, and level requirements.

Sounds like it could be good. However, creating the descriptions runtime is not as straightforward as it could be. Ideally, you would just put in the PostBeginPlay some code that sets the description text. However, abilties are abstract, and the PostBeginPlay never gets called - and it is always default.description that gets used. However, the Description only gets used by the client stats menu. So the Stats Menu code instead of just copying the description to the screen could build it. However, you would still need the text which explained what the ability did.
I have already subclassed the RPGAbilityDescMenu screen which shows the ability description.
And by the way, there are no class restrictions inherent in the abilities anymore - that is down to subclass configuration.

I just exported 2.21 today. I haven't had a chance to look at how the subclasses work yet.
I will try and get my test server updated tonight (still using 2.00)

ShowAbilityDesc should be able to implement a template to combine the base description with the cost.
Since only the abilities that apply to the class are shown, we shouldn't need the required classes in the descriptions.

How are you maintaining the AbilityConfigs list? Are you using a script or just manually creating everything?

greg11 wrote:

ShowAbilityDesc should be able to implement a template to combine the base description with the cost.
Since only the abilities that apply to the class are shown, we shouldn't need the required classes in the descriptions.

Agreed. I added a line to say what the max level is that can be bought by that subclass - it is the subclass that is important purchasing-wise, not the class.

greg11 wrote:

How are you maintaining the AbilityConfigs list? Are you using a script or just manually creating everything?

Manually

I had the configuration in an excel spreadsheet, and decided it would be as quick to manually create the config with cut-and-paste as it would generate an excel script.
EDIT: and then of course repeat the process for the wiki.