0001695: Custom campaign - crash.

Notes
(0004428) Ivan (developer) 2014-02-08 22:27	Crash happens due to missing Gelu - he should have been in front of that town. I assume you should have received him in one of previous scenarios (e.g. rescue from prison) but have not. So most likely this is not a bug and was caused by completing campaign via vcmisilmaril instead of following way defined by map author. Can you (or somebody else) check campaign and find out why Gelu is not where he was supposed to be?

(0004431) Povelitel (updater) 2014-02-08 23:29	Im testing it's map in SoD. Gelu appears in 3 mission. He is in mission 4. there are in 5. Proceeds normally and 6 mission. In vcmi he does not appear in mission 3

(0004434) Ivan (developer) 2014-02-09 10:20	So in SoD Gelu will be in 3rd mission even if you won't rescue him from prison in mission 2 and complete mission with victory cheat code? He is in prison in mission 2 and you must free him in order to win the mission. So technically not a bug - if you free Gelu he should appear in mission 3. And he is the key to win this mission.

(0004438) Povelitel (updater) 2014-02-09 12:01	In Sod I passed cheat code. Or anyone with a prison is not pulled out, he appeared В сод я проходил чит кодом. Ни кого с тюрьмы не вытаскивал, он появился сам.

(0004442) Ivan (developer) 2014-02-09 12:13	Ok, then I'll assign this to beegee as well. Summary: Mission 2: Gelu is in prison Mission 3: Gelu placeholder will be replaced by hero even if he was not rescued from prison in previous mission. However in vcmi Gelu is missing in 3rd mission.

(0004448) beegee (developer) 2014-02-09 14:06	OK, I'll fix this.

(0004451) beegee (developer) 2014-02-09 18:48	I don't know if this is standard behaviour. I couldn't create a campaign where a prisoned hero appears as a normal hero in the next scenario. I'll look into this further, perhaps the placeholdedHeroes list in the CMapHeader contains some important information.

(0004454) beegee (developer) 2014-02-09 19:14	The placeholdedHeroes list contains the type ID of Dracon and Gelu in the 3rd scenario and in the 2nd scenario Dracon only. Perhaps this is also a solution to reappearing heroes like Xeron, etc.

(0004455) beegee (developer) 2014-02-09 19:24	Mhhm, it seems to be that placeholdedHeroes list contains only a list of hero placeholders by hero ID. So sadly this isn't the solution to our problem :(

(0004485) beegee (developer) 2014-02-16 18:15	OK, I think I know what's going on:) Asylum uses AB campaign, that's the same campaign where Xeron will be recreated. The mechanics are simple, if a specific hero (by hero type ID) couldn't be found, the hero will be newly created without any experience or whatever. Gelu and Xeron will be recreated without any reference to any scenarios before. The mechanics affect the whole campaign, not only scenario Armageddon H.

(0004512) beegee (developer) 2014-02-19 19:19	Should be fixed in revision 3761.

(0004513) beegee (developer) 2014-02-23 14:25 edited on: 2014-02-23 14:29	I have to reopen this mantis point. The hero recreate handling wasn't implemented correctly. Heroes which are defeated reappear in the same state (experience, ...) as in the last scenario. Travel options are applied as normal. So I can't simply recreate dead heroes as fresh new heroes with level 1. In OH3 a hero will only be created newly when the hero placeholder can't be replaced and the hero mustn't be lost. (loss condition) I think no original campaign relies on this feature and NWC implemented this to be sure that no scenario can't be lost instantly and to make the winning cheat code work under any conditions. I could implement this feature as well for VCMI, but we have now logical expressions where more complex loss and victory conditions are possible. I can't simply test all loss events if there is a condition which makes the loss event happen if a particular hero placeholder couldn't be replaced. I would need to mock the data input for the victory / loss condition check and call it twice, once with the hero and once without the hero. But what happens if scenario will always be lost, if I need to replace two hero placeholders where both heroes aren't available. I don't think that it's required to make sure that scenario can't be lost instantly because of hero placeholders. That's the task of the one who creates a campaign to make sure that this can't happen. If a hero mustn't be lost in the next scenario, then the hero mustn't be lost in the current scenario. So there is one point left, I think that we shouldn't put so much effort and complicate the code just to make the winning cheat code work for campaigns. It will not work 100% perfectly anway. I would suggest to set a boolean flag when the player entered a winning cheat code. This will be used when a hero placeholder couldn't be replaced, then the hero will be created newly (because player didn't rescue hero out of prison or any map event which didn't happen). This won't work 100%, what happens if the loss condition is to lose a specific artifact (it's not possible ATM, but could) but hero which should carry that artifact couldn't be replaced and will be created newly? We could add more cheat codes, but I think that's out of scope now.

(0004514) beegee (developer) 2014-02-23 14:39 edited on: 2014-02-23 14:40	Just to inform you, a crash won't happen in scenario 3 because Dracon will be used as the hero the player mustn't be lost. Why VCMI behaves like this is another story (OH3 compatibility and corrupt H3M format)

(0004516) Ivan (developer) 2014-02-23 15:13	Maybe use logic like this: 1) On ending scenario copy only living heroes into scenario-specific storage. 2) On starting scenario, place hero placeholders by ID 2.1) Try to find such hero from latest scenario 2.2) Try to find the hero in previous scenario(s) 2.3) Generate new, lvl 1 hero 3) Place hero placeholder by power, using only set from latest scenario. Notes: - when hero is placed on map he must be copied so original instance from campaign state won't be destroyed. - hero handler must contain new, lvl-1 heroes, unless he was replaced during hero placement. This will fix our Xeron issues since he will be used from last scenario where he was player controlled ( =not yet defeated, present on map ) This will also fix issues like this (hero won't be found during search at all and will be recreated as lvl-1 hero) This will still work for situations where player-controlled heroes appear in non-continuous scenarios - here we will use latest available "version"

(0004517) beegee (developer) 2014-02-23 16:30	>>> This will fix our Xeron issues since he will be used from last scenario where he was player controlled In OH3 Xeron will be used from last scenario (not from the last scenario where he was player controlled) >>> This will also fix issues like this (hero won't be found during search at all and will be recreated as lvl-1 hero) The default case is that if a hero isn't available the hero placeholder simply won't be replaced (not created as lvl-1 hero). >>> This will still work for situations where player-controlled heroes appear in non-continuous scenarios - here we will use latest available "version" That's how it's implemented currently. The problem we have is that if the player doesn't complete the mission in the way he should, e.g. via cheat code, a hero from prison or later also through python scripted hero creation can't be transfered to the next mission. So it's just to get the cheat code working.

(0004518) Ivan (developer) 2014-02-23 16:48	>> The default case is that if a hero isn't available the hero placeholder simply won't be replaced (not created as lvl-1 hero). Maybe recreate only in case of "placeholders by ID"? IIRC there are no scenarios in H3 with optional heroes. Can't say about every user-made campaign though. If you don't like this idea - then I guess mark this one as acknowledged/won't fix - seems to be pretty much identical to 0001702 and 0001704 (map with invalid conditions)

(0004523) beegee (developer) 2014-02-24 19:34 edited on: 2014-02-24 19:36	I don't want to adjust or extend current placeholder logic. Perhaps it is possible to "fix" game state as a last ressort if the game is over instantly after the start by simply replacing ALL hero placeholders (by ID) with lvl-1 heroes. Therefore some changes are necessary when initializing victory / loss conditions. That should keep the game behave good-natured and the cheat code will work. This point has low priority and may be fixed later.

(0008650) Ivan (developer) 2023-06-27 12:23	Tracked in this PR: https://github.com/vcmi/vcmi/pull/2259 [^]

(0008891) Ivan (developer) 2024-01-30 19:18	Closing issues that were migrated to Github

Issue History
Date Modified	Username	Field	Change
2014-02-08 21:16	Povelitel	New Issue
2014-02-08 21:16	Povelitel	File Added: Asylum.h3c
2014-02-08 22:19	Povelitel	File Added: games.rar
2014-02-08 22:27	Ivan	Note Added: 0004428
2014-02-08 22:27	Ivan	Status	new => feedback
2014-02-08 23:29	Povelitel	Note Added: 0004431
2014-02-08 23:29	Povelitel	Status	feedback => new
2014-02-09 10:20	Ivan	Note Added: 0004434
2014-02-09 12:01	Povelitel	Note Added: 0004438
2014-02-09 12:13	Ivan	Note Added: 0004442
2014-02-09 12:13	Ivan	Assigned To	=> beegee
2014-02-09 12:13	Ivan	Status	new => assigned
2014-02-09 14:06	beegee	Note Added: 0004448
2014-02-09 18:48	beegee	Note Added: 0004451
2014-02-09 19:14	beegee	Note Added: 0004454
2014-02-09 19:24	beegee	Note Added: 0004455
2014-02-16 18:15	beegee	Note Added: 0004485
2014-02-19 19:19	beegee	Note Added: 0004512
2014-02-19 19:19	beegee	Status	assigned => resolved
2014-02-19 19:19	beegee	Fixed in Version	=> 0.94f
2014-02-19 19:19	beegee	Resolution	open => fixed
2014-02-23 14:25	beegee	Note Added: 0004513
2014-02-23 14:25	beegee	Status	resolved => confirmed
2014-02-23 14:29	beegee	Note Edited: 0004513	View Revisions
2014-02-23 14:39	beegee	Note Added: 0004514
2014-02-23 14:40	beegee	Note Edited: 0004514	View Revisions
2014-02-23 15:13	Ivan	Note Added: 0004516
2014-02-23 16:30	beegee	Note Added: 0004517
2014-02-23 16:48	Ivan	Note Added: 0004518
2014-02-24 19:34	beegee	Note Added: 0004523
2014-02-24 19:34	beegee	Status	confirmed => acknowledged
2014-02-24 19:36	beegee	Note Edited: 0004523	View Revisions
2014-03-03 18:03	Ivan	Relationship added	related to 0001742
2014-03-03 18:04	Ivan	Relationship added	has duplicate 0001740
2014-03-03 18:48	beegee	Assigned To	beegee =>
2023-06-26 16:47	Ivan	Assigned To	=> Ivan
2023-06-26 16:47	Ivan	Status	acknowledged => assigned
2023-06-27 12:23	Ivan	Note Added: 0008650
2023-06-27 12:23	Ivan	Status	assigned => confirmed
2023-06-30 12:28	Ivan	Assigned To	Ivan =>
2024-01-30 19:18	Ivan	Note Added: 0008891
2024-01-30 19:18	Ivan	Status	confirmed => closed