[side] recalls=

[Darker_Dreams]

"Prefer" is the operative word here. Preferences are funny like that--they don't have to make sense. Let's pick a unit at random... say, loyalist bowman. There's no magical formula that dictates the bowman must have 33 HP or have a 6-3 ranged pierce attack; these values are wholly arbitrary. Why should recall costs not be the same?

But there is, theoretically, a magical formula that yields a constellation of values as balanced (I was going to say "relatively balanced," but all balance is relative). It's a multivariable formula (including at least 2 straightforward variables you omitted; base cost and level, and 3 variables you haven't included which would need their input numeralized values calculated- one for damage types, any extra abilities, and the relationship between those features and their larger faction). Not that one anyone's sat down and figured out precisely what those formulas would be (afaik)- it does mean that those values, in the aggregate, are not wholly arbitrary.

I can make a wholly arbitrary unit, and I would imagine most units start out simi-arbitrary in their values before they get refined towards a "balanced" value. (balance having been defined by mp-devs by equality between recruit cost and the remainder of the equation.)


You're right, preferences don't have to make sense. However, in the context of a game, structures for a game, and asking coders to add structures to a game, they should have some value external to "I like."
Now, in osj's case, after looking at the goblin alchemist in question, either adding wml that generates gold or partially refunds recall cost makes easily as much sense as reducing it's base recall cost (both of which cabd). Here, preference comes into play- generating gold is weaker short-term on a recall and stronger both on recruitment and in a long-term recall situation than reduced recall rates. Refunding part of the recall cost is strictly weaker than reducing the recall rate because it requires that reserve. Choosing the value (option) he likes is perfectly valid.


Anyway, my question was, really, an attempt to find out how people wanted to use it. Looking for a way to make it implementable without it having to invade the whole game. I think what I'm seeing is that it's still going to require a [scenario] tag or (more likely) [side] key something akin to unit_recall_values=yes/no. It would need a default of "no," so as not to invade the rest of the game. This would also allow it to work well with the scenario values I'm proposing, because you can choose which option is dominant- if unit_recall_values=no, then the general scn defined value is operative, if unit_recall_values=yes then, for units with internal recall values, it doesn't matter if recall is the default 20 or some other random value.

blah.

[opensourcejunkie]

Units that cannot advance further levels are considerably less useful recalls than units of equal cost and level that have further advancements.

I just wanted to point out that TL makes a very nice justification here - stronger, I think, than my own. You'll probably want to include that when you make the feature request.

[TL]

But there is, theoretically, a magical formula that yields a constellation of values as balanced (I was going to say "relatively balanced," but all balance is relative).

If such a thing existed, then first off, it itself would be arbitrary. You freely admit that the magical impossible balance equation would rely on a number of quantitative factors being converted to qualitative one, which requires an arbitrary value judgment on how certain factors should be weighed.

Moreover, even if there did exist a universal objective balance formula it would yield a great many constellations of values as balanced. It is entirely possible to create two versions of a unit with different statistics, one version strictly superior to the other, and have both versions yield entirely balanced games without having to make any adjustments elsewhere, because players make those adjustments themselves; making a certain unit choice more attractive also provides an intrinsic boost to the value of options that effectively counter that certain unit. The two different versions play differently but cannot be said to have any meaningful difference in terms of overall balance.

(balance having been defined by mp-devs by equality between recruit cost and the remainder of the equation.)

I would be astounded if any of the MP devs actually used this as their benchmark of balance.

You're right, preferences don't have to make sense. However, in the context of a game, structures for a game, and asking coders to add structures to a game, they should have some value external to "I like."

In the context of asking coders to revisit an existing structure and open it up to be more customizable, logically they should be extended to be as customizable as practicable, no? Unless it's shown to be considerably more difficult to alter recall cost on a unit-by-unit basis I don't see much reason not to, if someone's going to go in and change how recall cost works anyhow.

Anyway, my question was, really, an attempt to find out how people wanted to use it. Looking for a way to make it implementable without it having to invade the whole game.

I think the ideal implementation as I see it would be to put recall costs in the unit tag (defaulting to 20, or whatever the game's recall value has been set to, natch) and let them be edited on the fly. For example, adding a consider_recall event, or even just having the game run prerecall events before checking recall costs, so that scenario creators can edit the cost of recalling a particular unit at recall time based on whatever they want (this may increase overhead marginally since it would entail generating a unit and then discarding it if the recall cost couldn't be met, but I don't think that would be very noticeable. I've never dug into Wesnoth's code structure myself though, so I dunno.)

[zookeeper]

I think the ideal implementation as I see it would be to put recall costs in the unit tag (defaulting to 20, or whatever the game's recall value has been set to, natch) and let them be edited on the fly.

Agreed. If someone wanted to file a feature request or implement it, the ideal way would be to enable a recall_cost= key both in [unit_type] and single [unit].

For example, adding a consider_recall event, or even just having the game run prerecall events before checking recall costs, so that scenario creators can edit the cost of recalling a particular unit at recall time based on whatever they want (this may increase overhead marginally since it would entail generating a unit and then discarding it if the recall cost couldn't be met, but I don't think that would be very noticeable. I've never dug into Wesnoth's code structure myself though, so I dunno.)

Not really needed. If one would need to adjust the costs for single units, they could just define them when the units are created or do it in some other event, like prestart or advance. Or whatever event in their scenario which is supposed to change the costs.

[TL]

Not really needed. If one would need to adjust the costs for single units, they could just define them when the units are created or do it in some other event, like prestart or advance. Or whatever event in their scenario which is supposed to change the costs.

Oh yeah, doy. Not stinking thraight today. Don't know why I thought a unit someone was recalling would ever be generated there on the fly...

[Darker_Dreams]

rant about balancing forumulas in which you obviously disagree with me.

Instead of encouraging the derailing of this thread, I'm just going to say that my experience with multivariate analysis and observations of MP devs discussing unit cost/value/effectiveness differ from what you're saying.

Anyway, my question was, really, an attempt to find out how people wanted to use it. Looking for a way to make it implementable without it having to invade the whole game.

I wrote that in a hurry and rereading that, I don't think I worked it all the way through or was clear. I had two things that got jumbled together as I tried to turn thought into words.


Everyone's in the same place about the recall_cost= key in the unit_type/unit...

The first thing I needed was a strong example of a place where UMC creators want to use this. Both OSJ and TL have provided this. (other examples welcome though)

The other thing was trying to get is a resolution to the problem of (depending on your standpoint) a trigger to have scenarios adopt it rather than the default cost or to allow the scenario to override the unit-defined recruit cost. This is a concern for me partially because I'm looking at putting in both FRs, so I feel I should suggest a resolution between the inevitable conflict in states. This is not an actual situation (obviously), but an example of what could happen; I want to set a scenario recall value of 10, but have a unit with it's own (unit_type determined) recall value of 16. What value gets used?

[TL]

The other thing was trying to get is a resolution to the problem of (depending on your standpoint) a trigger to have scenarios adopt it rather than the default cost or to allow the scenario to override the unit-defined recruit cost. This is a concern for me partially because I'm looking at putting in both FRs, so I feel I should suggest a resolution between the inevitable conflict in states. This is not an actual situation (obviously), but an example of what could happen; I want to set a scenario recall value of 10, but have a unit with it's own (unit_type determined) recall value of 16. What value gets used?

As zookeeper points out, if there is a recall cost key defined not only for unit types but for individual units (loaded from the unit type definition), then you as a scenario developer can simply edit the recall cost for individual units to be whatever you want. If the Goblin Masseuse unit has a recall cost of 16 and you want side 2 to be able to recall them for 10 gold, you just modify the recall cost of every Goblin Masseuse that side 2 recruits to be 10.

[Darker_Dreams]

The other thing was trying to get is a resolution to the problem of (depending on your standpoint) a trigger to have scenarios adopt it rather than the default cost or to allow the scenario to override the unit-defined recruit cost. This is a concern for me partially because I'm looking at putting in both FRs, so I feel I should suggest a resolution between the inevitable conflict in states. This is not an actual situation (obviously), but an example of what could happen; I want to set a scenario recall value of 10, but have a unit with it's own (unit_type determined) recall value of 16. What value gets used?

As zookeeper points out, if there is a recall cost key defined not only for unit types but for individual units (loaded from the unit type definition), then you as a scenario developer can simply edit the recall cost for individual units to be whatever you want. If the Goblin Masseuse unit has a recall cost of 16 and you want side 2 to be able to recall them for 10 gold, you just modify the recall cost of every Goblin Masseuse that side 2 recruits to be 10.

So you're saying that a [unit_type]'s recall_cost should supersede any [side] recall_cost key, requiring an independent unit alteration for each unit_type you want the scenario to override? then, of course, you have to go back through at the end of the scenario and re-instate the "default" recall values on each unit_type.

I think my solution is more elegant in that it allows the scenario designer to choose which cost should override within a given scenario without requiring a bunch of unit edits on the start and end of the scenario. At this point I'll probably leave it to whatever coder has mercy on the FR to decide what's more practical to do.

[MDG]

How does it currently work for recruit cost? The point being, it may be 'easier' for any code dev that does pick this up to implement it similarly to the way recruit cost currently works (i.e. in terms of how and when you can manipulate it in any content...). Probably makes it easier to support and maintain going forward if the functionality is as similar as possible (code devs would be the judge of that though ).

[Darker_Dreams]

FRs submitted;

https://gna.org/bugs/index.php?13073
https://gna.org/bugs/index.php?13074

[FangoWolf]

Since I was working on something like this at the moment and someone mentioned a magical formula. The formula I was thinking of was :

Base cost + (units % to next level) (upgrade cost-base cost) + fixed.

so taking a specific example of spearman with 20 xp and a fixed surcharge of 1 GP

14 + (20/42) (25-14) + fixed 1 = 20.23 ~ 20

Peasant with 18 xp and a fixed surcharge of -1
8 + (18/23) (14-8) - 1 = 11.69 ~ 12

just how I would do it...

[Yojimbo252]

Sorry to drag up an old thread but I was wondering if these FRs were ever implemented?

[Darker_Dreams]

you can check the status by clicking on the links above- neither have been implemented. Apparently the ability to do a scenario-wide recall-cost-change is apparently doable with lua. I'd rather have a method that was "native" to WML, and thus a little simpler once you're already setting up scenarios... but it's better than nothing. There is still no way to set a unit to have it's own unique recall cost.