MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000169VCMIAI - Adventure Mappublic2009-10-15 22:562022-04-12 10:47
ReporterZamolxis 
Assigned ToSXX 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version0.73c 
Target VersionFixed in Version0.98g 
Summary0000169: The visiting hero does not collect the best troops from garrison to fill in his empty army slots when the town is under siege.
Description0.73c#37 - The visiting hero does not collect the best troops from garrison to fill in his empty army slots when the town is under siege.
Additional InformationTo reproduce, load the map attached to 0000146, R-click on Inferno town (to see all troops in Garrison), then attack it. Only the troops of the visiting hero will defend against the siege. Forum report: http://forum.vcmi.eu/viewtopic.php?p=3682#3682 [^]
TagsNo tags attached.
Attached Filesjpg file icon fizmig_merge_291_1.jpg [^] (53,317 bytes) 2016-02-19 11:58


jpg file icon fizmig_merge_291_2.jpg [^] (62,568 bytes) 2016-02-19 11:58


jpg file icon fizmig_merge_291_3.jpg [^] (64,665 bytes) 2016-02-19 11:58


jpg file icon fizmig_merge_291_4.jpg [^] (70,641 bytes) 2016-02-19 11:59


? file icon SXX_Siege_army_merging_v1.h3m [^] (2,729 bytes) 2016-02-19 12:31

- Relationships
related to 0002344resolvedIvan Dwellings: auto stack merge needed like we have with joining creatures on adventure map 
has duplicate 0002252closedSXX Town-visiting hero's army replaces garrison army completely when town is attacked 
related to 0002417closed Feature: advanced garrison and visiting hero army merging for siege 

-  Notes
(0001189)
Boulie (reporter)
2010-07-27 07:46

Propose to change severity. It could be tweak if hero does collect any of troops for free slots but it isn't. Problem with choosing which creatures/slot are the best could be tweak. But as I know troop are chosen at random. So if you know that siege is possible you should leave the best troops in your hero.
(0001198)
Zamolxis (viewer)
2010-07-27 18:39
edited on: 2012-03-16 22:46

I'm pretty sure the troops are not chosen at random, I just don't remember now what was the criterion used: creature rank or stack strength.

EDIT: The criterion is the most logic one - stack strength. I did a very short test, giving AI the chance to pick between 1 Royal Griffin and a couple of Pikemen, and it chose the Royal Griffin. But when I increased the stack of Pikemen to 10, it chose the Pikemen.

(0002290)
Warmonger (administrator)
2012-03-09 18:17

Is that supposed to apply for player attacked by AI as well?
(0002291)
Zamolxis (viewer)
2012-03-09 19:19

Yes. To reproduce, make the purple player in the 'VCMI Tests' map Human, start the map as Purple in WoG and hit End Turn.

Not collecting the troops could have some strategic value in some rare situations (can't think of many), but most of the time would just be annoying, because you didn't micro-manage enough before hitting End Turn. So I wouldn't bother coding that, or if you do, should be a mod-option, as it wouldn't be like OH3.
(0002312)
majaczek (reporter)
2012-03-16 11:27

It may be resolved with showing garrison window to move units manually (AI should make some decision but it's up to AI writers what to choose).

I think it's better resolve than oryginal concept
(0002313)
Zamolxis (viewer)
2012-03-16 22:57
edited on: 2012-03-16 23:00

I think the original concept is not that bad either, as long as we know what criteria exactly H3 used for ranking stack strengths. We would actually need that for coding the AI.

As for the human player, the Garrison interface may be a nice addition. However (unless the hero has Enhanced WoG Tactics perhaps), the player should not be allowed any creature management, except the move from Garrison to his army. So he should not be allowed to move weaker creatures to the Garrison to make place for stronger, or to even dismiss creatures (for whatever tactical reason), as that breaks the balance of the original game (particularly exploitable in multiplayer): other human players, and perhaps even an advanced AI, should be able to asses what's waiting them if they attack, based on the army the hero at the gate already has, and not have the surprise that a slot of a pikeman was replaced by a dragon.

(0002314)
majaczek (reporter)
2012-03-18 18:00

I think all moving up/down, merging, splitting should be allowed (but not buying, upgrading etc). the arrange troops garrison dialog should show before battle start (so before the player know what attacked him).
 AI wouldn't be a problem too if town with hero is threated as single object, and summary threat will be counted.

PS: some mods include creatures which upgrades for free and has circular upgrades, so maybe allow any change which do not cost resources ? (including upgrades which are free). Also we can make changes (and it's parts) optional.
(0003614)
Zamolxis (viewer)
2013-05-31 08:00
edited on: 2013-05-31 08:02

There is a related behavior I see now (0.92c): after defeating the visiting hero, the town is not flagged (and rest of garrisoned creatures vanished), but we have to fight another siege against those creatures. I'm not sure if it was there before or a new behavior.

In OH3, if no hero garrisoned, the creatures not used to fill the ranks of the visiting hero were vanishing. If there was a hero garrisoned, then no creature was used to fill in the ranks of the visiting hero, but then also attacking the visiting hero did not open a siege, but a normal battle screen.

I kinda like the extra challenge (and I wouldn't mind if we got two sieges also when there's a hero in garrison as well), but it's not like OH3. I guess it could be an option associated with one of those WoG scripts that increase difficulty (like 'karmic battles').

(0003896)
Ivan (developer)
2013-08-26 10:51

Found full description (but in Russian) on how this feature should work. Will translate later.

1.Когда в гарнизоне и в гостях есть герои - их армии не объединяются никогда.
 2.В гарнизоне героя нет, а в гостях - есть:
 2.1.Если суммарно в армии гарнизона и в армии героя не более 7 типов существ, то армии объединяются под руководством героя.
 2.2.Если суммарно более 7 типов существ, то армии объединяются - в объединённой армии отсутствуют самые "слабые" отряды (видимо по AI values). В случае победы атакующего, он получает город. В случае победы защитника - "пропавшие" существа остаются в армии гарнизона, а участвовавшие в битве остаются в армии героя.
 2.3.Если в гарнизоне один тип существ разделён на несколько отрядов, но всего у гостя и в гарнизоне не более 7 типов существ - армии объединяются (разделённые отряды сливаются в один).
 2.4.Если в гарнизоне один тип существ разделён на несколько отрядов, и суммарно у гостя и в гарнизоне более 7 типов существ, то армии объединяются - разделённые отряды сливаются в один, в объединённой армии отсутствуют "самые" слабые отряды.
 2.5.Если у героя один тип существ разделён на несколько отрядов, то армии объединяются - в объединённой армии отсутствуют самые "слабые" отряды (разделённые отряды НЕ сливаются в один).
(0006217)
SXX (administrator)
2015-12-24 19:08

Really wish we can unify all merging code (e.g 0002344) so the same code used everywhere, but with different rules. Would be also cool to avoid issue that H3 has (when ally hero get creatures he didn't own after battle ended).
(0006438)
SXX (administrator)
2016-02-19 11:57

So my current plan is to implement merging multiple merge options for VCMI:
- No merging. So it's as it's works now.
- H3 merging according to FizMiG (efficiently what Ivan posted) and tested by custom map.
- VCMI advanced merging. We'll do it as in H3, but will as well always merge stacks of same type so you can get bigger army.
- VCMI full merging. Basically idea is to have option to put more stacks into town garrison than H3 normally allowing.
(0006439)
SXX (administrator)
2016-02-19 12:01

Also FizMiG is in Russian, but there is illustrations of merging mechanics that don't need translation. I'll implement all 4 cases on my test map that I'll hopefully finish and upload shortly after.

I'll of course test FizMiG description in H3 just to be sure it's right, but so far it's was always explaining H3 behaviour right.
(0006440)
SXX (administrator)
2016-02-19 12:31

Map all, also checked FizMiG examples using it and they are totally correct.
(0006442)
SXX (administrator)
2016-02-21 19:49

https://github.com/vcmi/vcmi/pull/196 [^]

- Issue History
Date Modified Username Field Change
2009-10-15 22:56 Zamolxis New Issue
2010-05-29 23:44 Zamolxis Product Version 0.74 => 0.73c
2010-07-27 07:46 Boulie Note Added: 0001189
2010-07-27 18:39 Zamolxis Note Added: 0001198
2012-02-27 12:22 Warmonger Category Mechanics - Other => AI - Adventure Map
2012-03-09 18:17 Warmonger Note Added: 0002290
2012-03-09 19:19 Zamolxis Note Added: 0002291
2012-03-16 11:27 majaczek Note Added: 0002312
2012-03-16 22:46 Zamolxis Note Edited: 0001198 View Revisions
2012-03-16 22:57 Zamolxis Note Added: 0002313
2012-03-16 22:57 Zamolxis Status new => feedback
2012-03-16 22:59 Zamolxis Note Edited: 0002313 View Revisions
2012-03-16 23:00 Zamolxis Note Edited: 0002313 View Revisions
2012-03-18 18:00 majaczek Note Added: 0002314
2013-05-31 08:00 Zamolxis Note Added: 0003614
2013-05-31 08:00 Zamolxis Status feedback => new
2013-05-31 08:02 Zamolxis Note Edited: 0003614 View Revisions
2013-08-26 10:51 Ivan Note Added: 0003896
2015-12-24 12:37 SXX Assigned To => SXX
2015-12-24 12:37 SXX Status new => assigned
2015-12-24 12:37 SXX Relationship added has duplicate 0002252
2015-12-24 19:06 SXX Relationship added related to 0002344
2015-12-24 19:08 SXX Note Added: 0006217
2016-02-19 11:57 SXX Note Added: 0006438
2016-02-19 11:58 SXX File Added: fizmig_merge_291_1.jpg
2016-02-19 11:58 SXX File Added: fizmig_merge_291_2.jpg
2016-02-19 11:58 SXX File Added: fizmig_merge_291_3.jpg
2016-02-19 11:59 SXX File Added: fizmig_merge_291_4.jpg
2016-02-19 12:01 SXX Note Added: 0006439
2016-02-19 12:31 SXX File Added: SXX_Siege_army_merging_v1.h3m
2016-02-19 12:31 SXX Note Added: 0006440
2016-02-21 19:49 SXX Note Added: 0006442
2016-02-22 01:43 SXX Relationship added related to 0002417
2016-02-22 17:01 SXX Status assigned => resolved
2016-02-22 17:01 SXX Fixed in Version => 0.98g
2016-02-22 17:01 SXX Resolution open => fixed
2022-04-12 10:47 Povelitel Status resolved => closed

Site | Forums | Wiki | Slack | GitHub


Copyright © 2000 - 2024 MantisBT Team
Hosting provided by DigitalOcean