Project

Profile

Help

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...

Bug #824708

Cleanup in hut entering

Added by Alexandro Ignatiev about 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Server
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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.

History

#1 Updated by Alexandro Ignatiev about 2 years 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 about 2 years 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.

#3 Updated by Marko Lindqvist about 2 years ago

Alexandro Ignatiev wrote:

Also, maybe some checks on if unit has survived previous hut effects need to be added to the functions.

This is needed even for S2_6, right?

#4 Updated by Alexandro Ignatiev about 2 years 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.

#5 Updated by Alexandro Ignatiev about 2 years ago

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?

#6 Updated by Marko Lindqvist about 2 years 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 about 2 years 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 about 2 years 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?

#10 Updated by Marko Lindqvist about 2 years ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist

Also available in: Atom PDF