Imperial sentry returns more wares when dismantled than it needed

[wl-zocker]

Build costs: 1 stone, 1 trunk, 1 wood (short: 1s, 1t, 1w)
Returned when dismantled: 1s, 1t, 2w

I think this is because the sentry is an enhanced building (from the barrack), so the build costs of the two buildings are added:
Barrack: 1t, 2w + Sentry: 1s, 1t, 1w = 1s, 2t, 3w
These values are divided by two and rounded up to calculate the returned resources. This gives 1s, 1t, 2w, as observed.

The same issue appears for the Imperial barrier (costs: 2s, 2t, 2w, 1 marble) because of the outpost (costs: 1s, 1t, 1w, 1m). Added, it is 3s, 3t, 3w, 2m, which leads to 2s, 2t, 2w, 1m when dismantling. These are the actual build costs (although it should be 1s, 1t, 1w, 1m).

These are the only two buildings where the problem appears because the are buildable directly (using less resources) and via upgrade (using additional resources for the lower building), but return the same wares in both cases.

[Nicolai Hähnle (nha)]

Should all upgraded buildings only return resources relative to the last upgrade step? Or should there be a special case for upgraded buildings that can be built directly? Discuss.

[wl-zocker (wl-zocker)]

I think the other upgraded buildings (fortress, Barbarian warmill, mines) should return all the wares they needed summed up (and divided by 2) because there is no other way to obtain them.
Only for buildings that can be built directly there should be a special case (if there is no line "buildable=no" in the config file).
If the player upgrades e.g. his barrack, he will not get all the resources back. I think that nothing to worry about: The player chose himself to do it that way.

[SirVer (sirver)]

Wow, good catch. And a nice cheat, actually 8).

I agree with wl-zocker. Seems reasonable to only give back wares for the last stage if it is buildable=yes, otherwise for all stages. Setting to triaged if noone complains.

[Nasenbaer (nasenbaer)]

I would go even further and see the bug in a different place - when upgrading a barracks to a sentry, the sentry should cost less than when it is built directly (however the whole building process - from nothing over barracks to sentry should maybe cost a bit more (e.g. 1 more trunk))

[cghislai (charlyghislain)]

So lets say building X costs X, building Y costs Y. X may be enhanced to Y.
I like Nasenbaer suggestion.

enhancing X to Y costs Y/2
destroying X returns X/2
destroying Y returns Y/2
destroying enhanced Y returns (X+Y/2)/2

[SirVer (sirver)]

I think making the return values explicit in the conf files (like the build cost) gives us more control. Don't you think?

[cghislai (charlyghislain)]

Yep, sounds good too me as well.
What about allowing a second value to be given in the buildcost section, so 'trunk=2' would become 'trunk=2 1' if only 1 is needed for enhancing. Or maybe is it better to add a new section?

[cghislai (charlyghislain)]

Reading #6 again I see you were talking about return values. If they are put in the conf file, which I'm not against, this does not solve the issue with returned ware of enhanced buildings vs directly built ones. So we must allow two values in that section as well.

I think of keeping a pointer (or vector of pointer) to the Descr of the former building if enhanced - this is already done in constructionsite. This way we can easily track down the return values for all enhancement steps.

[SirVer (sirver)]

Mmmh - I like the idea of having everythig explicit in the conf files (new sections, much easier to read). But I cannot come up with a format that is easy to read and understand and flexible enough to fullfill all our needs. Could you conjecture a conf example that deals with the most complex scenarios? remember that theoretically buildings could be enhanced multiple times and/or build directly.

[cghislai (charlyghislain)]

Then i think [buildcost] [enhancecost] [returngain] [enhancementreturngain] sections are explicit and enough to deal with all cases. enhancementreturngain could have a better name though

[cghislai (charlyghislain)]

Concerning the flexibility, a single building can only be enhanced to an other single one, and only be the ehancement of a single third one. I don't know if such limitation is intended or if we should better considerate multiple enhancements.

IMO multiple enhancements involve too much work to be considered now.

[SirVer (sirver)]

You are right I think. I think good names for the sections are return_on_dismantle (you could drop the _ for symmetry with the other names, but I think they add readability) and return_on_dismantle_on_enhanced. I see no pain in making these long and explicit - we will not write them often and tab completion is your friend.

[cghislai (charlyghislain)]

If buildable, [buildcost] and [return_on_dismantle] are mandatory
If enhaced building, [enhancement_cost] and [return_on_dismantle_on_enhanced] are mandatory

[SirVer (sirver)]

Makes sense. I am not too happy with the las section name but could not come up with anything better. Feel free to use a better name :).

[SirVer (sirver)]

Released in build-18 rc1.