Sort out hut entering finally
Same problem as was addressed in Bug #775572, Bug #775424 for 3.0 and to less extent (since no rulesets for 2.6 use multiple huts) 2.6: hut_enter callback is not emited for any bonus extra as advertised (but not as we want for Ruins) and can't know extra type. There wasa semantical messup in what a hut is. In the patch attached (designed for 3.0) the huts are more or less clearly defined as extras with not appear but cause, the new cause ERM_ENTER. Not am shure if it goes for client's vision setting "Show huts", so it is left to EC_HUT. The callback receives the extra name and a boolean value if the unit is frightening (but the frighten beaviour is unhardcoded); additionally, lua is extended with (Unit_Type):hut_behavior() string callback.
#1 Updated by Alexandro Ignatiev 7 months ago
The scripts need minor improvement: default.lua must not check extra type and might not return false, it's the bottom fallback; sandbox/script.lua should inform the player if the Hermit has left nothing.
Plans for future development:
1. Different hut behaviours for same units for different huts;
2. Some hints for AIs and autotasks about different bonuses value (even normal hut is better not to be enteted if bulbs are low and freetech fine is high);
3. Different bonuses removed by different actions, with a callback
bool bonus_removed(unit, type, rmcause).
#5 Updated by Alexandro Ignatiev 7 months ago
I think, for here we can keep the rule "that is enter removed what has "Hut" cause", just revert for both 3.0 and 2.6.1 what has commit:13f4a8097821152907155bc0b560e25fe1e9a578 done to unittools.h (this does not workas expected and may work as not wanted, it's a bug). Then, for 3.0 add the second callback parameter and maybe
char * frighten_message; to
struct extra and corresponding optional line
frighten_message = "Your unit is so fearful, the extra runs away!" to extra description format, since defaul one doesn't suit for Hermit's Nest. (with optional %s for unit type); in other aspects, frighten behaviour seems not needing unhardcoding. I can prepare the 3.0 patch in a week. All other ideas are to be planned more careful and left to 3.1 (wanna add appearing and quickly disappearing UFOs to sandbox which are "entered" by aircrafts).
#6 Updated by Marko Lindqvist 7 months ago
Alexandro Ignatiev wrote:
I think, for here we can keep the rule "that is enter removed what has "Hut" cause", just revert for both 3.0 and 2.6.1 what has commit:13f4a8097821152907155bc0b560e25fe1e9a578 done to unittools.h
Yes, that commit has been ill advised. Reverting it would be the first step, and the only one that affects also S2_6 -> please open a new ticket about that.
#7 Updated by Alexandro Ignatiev 7 months ago
Prepared the 3.0 patch. The most straightforward way to produce sensible frighten messages appeared to be just make a new callback for them,
hut_frighten; so only default/default.lua and sandbox/script.lua are modified in datafiles for now. The behaviour, as I see it, should be much changed in 3.1, so no capital changes a made for now.
#9 Updated by Alexandro Ignatiev 6 months ago
Since the huts detection is reverted for 3.0 by #782719, two lines shold be excluded from the patch as already changed.
Also, it redefines a callback with one more parameter. This is said to not be done, but I propose to lax a bit the rules and allow to add parameters for a good reason if the callback which does not check it will work as before. Lua functions are not really called with prototypes, they just get from the stack as many arguments as they want and assume
nil's for what they have not found; there is a way to check what's there in the actual Lua stack, but I can't pretend a sane mean to use it in callbacks.
#10 Updated by Marko Lindqvist 3 months ago
- File 0009-Scripting-API-Add-hut_frighten-signal.patch 0009-Scripting-API-Add-hut_frighten-signal.patch added
- File 0016-Scripting-API-Add-hut_frighten-signal.patch 0016-Scripting-API-Add-hut_frighten-signal.patch added
- Status changed from New to Resolved
- Target version set to 3.0.0
General refresh of the patch so they apply cleanly to current HEADs.