MantisBT - VCMI | ||||||||||||||||||||
View Issue Details | ||||||||||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||||||||||||
0001416 | VCMI | Mechanics - Town structures | public | 2013-08-21 15:19 | 2023-07-15 17:06 | |||||||||||||||
Reporter | Zamolxis | |||||||||||||||||||
Assigned To | Ivan | |||||||||||||||||||
Priority | normal | Severity | minor | Reproducibility | always | |||||||||||||||
Status | resolved | Resolution | fixed | |||||||||||||||||
Platform | OS | OS Version | ||||||||||||||||||
Product Version | 0.93 | |||||||||||||||||||
Target Version | Fixed in Version | |||||||||||||||||||
Summary | 0001416: Retreat / Surrender sends hero to the left Tavern slot only - H3 used both slots to place them | |||||||||||||||||||
Description | H3 was making use of both slots, giving player the chance to keep 2 of the best heroes recently retreated or surrendered. I'm not very sure about the exact pattern and I didn't find info on this in Strategija. I played a bit with the VCMI_Tests map in WoG, retreating / surrendering each of the 8 heroes in different orders, and noticed the following: - first retreated/surrendered hero went into the left Tavern slot - from the 2nd onward, as long as I kept retreating only, they all went to the right slot (leaving the 1st retreated/surrendered hero there) - this went on until I surrendered with a hero, which went as well to the right slot; but after that, the next retreated/surrendered hero went to the left slot, overriding the hero that's been sitting there for a while. So H3 seems to prioritize surrendered heroes, to keep them there as long as possible; but if we have 2 surrendered heroes, the one who surrendered first (pending there unhired the longest) will be lost & replaced by the next hero retreating/surrendering. H3 does not look at hero/army strengths though: I had a retreating hero override the first surrendered hero, even though it was stronger (level, artifacts, army) than the second surrendered hero. This was a bit of a bummer, but the odds of having 2 surrendered heroes, and no chance to hire the best of them until you have to retreat/surrender another, are pretty small, so I guess we shouldn't bother to further tweak the H3 logic on that. My assumption of the OH3 pattern is the following: 1. Look, from left to right, for the "most vulnerable" hero to be replaced. In order, that would be the Default (randomly generated weekly) hero, considered weaker than a Retreated hero, which is weaker than a Surrendered hero. i.e.: so if a Default hero is found in the left slot, the algorithm stops here as that's the one replaced. 2. If both slots have retreated heroes, or both have surrendered heroes, then replace the "oldest". Or, in other words: 1. Check left slot > If Default hero, replace (> End) 2. Else check right slot > If Default, replace hero in right slot (> End) 3. Else check if both heroes have Retreated > If yes, replace the oldest (> End) 4. Else check if both heroes have Surrendered > If yes, replace the oldest (> End) 5. Else replace the one who Retreated > End __or split from step 3 into: 3. Else check if left slot = Retreated 3A. If Yes > Check if right slot = Retreated > Yes = replace oldest / No = replace left slot 3B. If No > Check if right slot = Retreated > Yes = replace right slot / No = replace oldest | |||||||||||||||||||
Steps To Reproduce | ||||||||||||||||||||
Additional Information | ||||||||||||||||||||
Tags | No tags attached. | |||||||||||||||||||
Relationships |
| |||||||||||||||||||
Attached Files | ||||||||||||||||||||
Issue History | ||||||||||||||||||||
Date Modified | Username | Field | Change | |||||||||||||||||
2013-08-21 15:19 | Zamolxis | New Issue | ||||||||||||||||||
2013-08-21 15:33 | Zamolxis | Summary | Retreat / Surrender places hero only in the left Tavern slot - H3 used both slots => Retreat / Surrender sends hero to the left Tavern slot only - H3 used both slots to place them | |||||||||||||||||
2013-08-21 15:33 | Zamolxis | Description Updated | bug_revision_view_page.php?rev_id=2382#r2382 | |||||||||||||||||
2013-08-21 15:39 | Zamolxis | Description Updated | bug_revision_view_page.php?rev_id=2383#r2383 | |||||||||||||||||
2013-08-21 15:42 | Zamolxis | Description Updated | bug_revision_view_page.php?rev_id=2384#r2384 | |||||||||||||||||
2013-08-21 16:56 | Warmonger | Relationship added | related to 0001344 | |||||||||||||||||
2013-08-21 16:57 | Warmonger | Relationship added | related to 0001413 | |||||||||||||||||
2015-12-24 19:02 | SXX | Relationship added | related to 0001569 | |||||||||||||||||
2016-01-22 10:29 | vmarkovtsev | Note Added: 0006341 | ||||||||||||||||||
2016-01-22 10:41 | SXX | Note Added: 0006342 | ||||||||||||||||||
2016-01-22 19:45 | vmarkovtsev | Note Added: 0006345 | ||||||||||||||||||
2023-07-15 17:06 | Ivan | Note Added: 0008672 | ||||||||||||||||||
2023-07-15 17:06 | Ivan | Status | new => resolved | |||||||||||||||||
2023-07-15 17:06 | Ivan | Resolution | open => fixed | |||||||||||||||||
2023-07-15 17:06 | Ivan | Assigned To | => Ivan |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|