HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Cleanup in hut entering
Some changes should be done to achieve desired hut behaviour:
hut_frighten callback and
hut_get_limited() must be called for each hut on a tile, each such hut must be deleted, and sandbox callbacks must suppress default ones (?), see bug #802768. Also, maybe some checks on if unit has survived previous hut effects need to be added to the functions.
#1 Updated by Alexandro Ignatiev over 1 year ago
Attach patch for unittools.c for 3.0, for 3.1 likely is resolved and for script.lua there is another patch. It would produce a complicated code to enter huts correctly after a unit is dead in a previous hut on the same tile, so it is dropped; if some ruleset author wants it, it can be achieved by scripting means. As long as the unit survives previous enterings and frightenings, next call is processed correctly (if no problems with bug #824815).
#2 Updated by Marko Lindqvist over 1 year ago
- Category set to Server
Looks good in first review.
I can handle it from here, but if you want to further prepare your patches for easier consumption, you could make them with 'git format-patch' from local commits (in a local branch). With commit message in place. It would also make you to appear as the commit author when they are pushed to the repository.
#4 Updated by Alexandro Ignatiev over 1 year ago
As I can understand, we are not supposed to have two huts on a tile in 2.6, though it's possible to put two such extras and this should be handled somehow. Currently, frighten and hut_get_limited displace one hut and stop while the normal signal is called for each extra with a possibility of using killed punit, we should decide what is a bug here: if we also stop it after one hut, or run the cycle as long as unit lives (I personally prefer this), or just displace the remaining huts without calling any code, or maybe just make "Hut" extra flag unique.
I'll take a notice of the git format-patch option for later tasks.
#6 Updated by Marko Lindqvist over 1 year ago
Alexandro Ignatiev wrote:
Also, maybe we should say somewhere in what order the huts are entered, I could not grok this but likely in the same as they are defined?
I'd leave it not documented - undefined implementation specific detail that may change as implementation changes.
#7 Updated by Marko Lindqvist over 1 year ago
- Sprint/Milestone set to 2.6.1
Alexandro Ignatiev wrote:
or run the cycle as long as unit lives
That's what S3_0 with this patch will do (there's actually an bug in that it should not 'break' even when unit has died but to do destroy_extra() part also to the remaining huts), so S2_6 should adopt the same for making update from 2.6 to 3.0 to go smoother. I think this patch works almost as is for S2_6.
When looking closer, I noticed one style issue with the patch. Comment "AI with H_LIMITEDHUTS only gets 25 gold (or barbs if unlucky)" should go inside the block it refers to, not to the end of previous block.
#8 Updated by Marko Lindqvist over 1 year ago
Marko Lindqvist wrote:
(there's actually an bug in that it should not 'break' even when unit has died but to do destroy_extra() part also to the remaining huts)
Or is that intentional? To not handle at all those huts that unit does not enter before death, but to leave them to the next unit to enter?
#9 Updated by Marko Lindqvist over 1 year ago
- File 0017-Handle-entering-multiple-huts-in-the-same-tile-corre.patch 0017-Handle-entering-multiple-huts-in-the-same-tile-corre.patch added
- File 0006-Handle-entering-multiple-huts-in-the-same-tile-corre.patch 0006-Handle-entering-multiple-huts-in-the-same-tile-corre.patch added
- Status changed from New to Resolved