0001646: Worn artifacts won't be moved to next scenario

(0004319)
Ivan (developer)
2014-01-12 20:33

It looks that this bug may lead to interesting results: http://forum.vcmi.eu/viewtopic.php?p=11332#11332 [^]

In previous mission Gem had art that gives +1 to scouting radius. And it looks that artifacts got transferred but only on server side (server assumes that that row of tiles is visible for player and haven't included them in FoW netpack).

(0004395)
Tow (developer)
2014-02-02 14:34

Desync, that's serious issue. :(
Do you have some easy way to reproduce this issue?

(0004396)
Ivan (developer)
2014-02-02 14:54

After a few restarts I got nice artifact in vicinity - everflowing crystal cloak. Check attached saves:
a) gemtestbefore - made just before picking up artifact. Load game, pick art, vcmisilmaril, end turn

b) gemtestafter - already in next scenario, just end turn and you'll get +1 to crystals despite that Gem no longer have the cloak.

Another problem is that in these missions artifacts should not transfer to begin with. So this desync may not be directly connected to this bug.

(0004397)
Tow (developer)
2014-02-02 17:52

Thanks, that helps.

Interestingly, I can't reproduce the issue using gemtestafter savegame. Whatever it is, it doesn't survive save/load.
Otherwise, using the before savegame, issue is perfectly reproducible. I'll investigate it.

(0004398)
Tow (developer)
2014-02-02 17:59

The artifact is not transferred. The issue is that bonus tree dependencies are transferred.

(0004402)
Tow (developer)
2014-02-02 21:46

I see two issues:
1) The CGameState::prepareCrossoverHeroes function does not properly remove things from hero (it goes around the bonus system). That's easy to fix.
2) Desync. What really puzzles me is why the hero on client doesn't have old stacks/artifacts from the beginning, while on server they are removed during init. That should not happen.

I'll leave 1) until I investigate properly 2).

(0004414)
Tow (developer)
2014-02-08 16:49

The source of this desync (and likely the others) is that server, when entering the next campaign mission goes like this:

1. newGame -> gh::init -> gs::init -> placeCampaignHeroes -> prepareCrossoverHeroes <= modifies the heroes that are part of start info
2. send start info (that has been already modified) all the clients, so they can perform their inits

The start info fed to the clients and server is different and that results in desync. I have even found TODO note in "prepareCrossoverHeroes" saying that heroes needs to be deep copied.

(0004430)
Tow (developer)
2014-02-08 23:08

Fixed all the issues in r3745.

(0004741)
Kantor (updater)
2014-06-02 11:28

This one may be closed.

Issue History
Date Modified	Username	Field	Change
2013-12-31 17:06	beegee	New Issue
2013-12-31 17:50	Ivan	Target Version	=> 0.94b
2014-01-12 20:33	Ivan	Note Added: 0004319
2014-02-02 11:30	Ivan	Target Version	0.94b => 0.94e
2014-02-02 14:34	Tow	Note Added: 0004395
2014-02-02 14:54	Ivan	Note Added: 0004396
2014-02-02 14:55	Ivan	File Added: gemtest.zip
2014-02-02 17:52	Tow	Note Added: 0004397
2014-02-02 17:52	Tow	Assigned To	=> Tow
2014-02-02 17:52	Tow	Status	new => confirmed
2014-02-02 17:59	Tow	Note Added: 0004398
2014-02-02 21:46	Tow	Note Added: 0004402
2014-02-05 20:52	Warmonger	Relationship added	related to 0001652
2014-02-08 16:49	Tow	Note Added: 0004414
2014-02-08 23:08	Tow	Note Added: 0004430
2014-02-08 23:08	Tow	Status	confirmed => resolved
2014-02-08 23:08	Tow	Fixed in Version	=> 0.94e
2014-02-08 23:08	Tow	Resolution	open => fixed
2014-06-02 11:28	Kantor	Note Added: 0004741
2014-06-02 11:28	Kantor	Status	resolved => closed

Notes
(0004319) Ivan (developer) 2014-01-12 20:33	It looks that this bug may lead to interesting results: http://forum.vcmi.eu/viewtopic.php?p=11332#11332 [^] In previous mission Gem had art that gives +1 to scouting radius. And it looks that artifacts got transferred but only on server side (server assumes that that row of tiles is visible for player and haven't included them in FoW netpack).

(0004395) Tow (developer) 2014-02-02 14:34	Desync, that's serious issue. :( Do you have some easy way to reproduce this issue?

(0004396) Ivan (developer) 2014-02-02 14:54	After a few restarts I got nice artifact in vicinity - everflowing crystal cloak. Check attached saves: a) gemtestbefore - made just before picking up artifact. Load game, pick art, vcmisilmaril, end turn b) gemtestafter - already in next scenario, just end turn and you'll get +1 to crystals despite that Gem no longer have the cloak. Another problem is that in these missions artifacts should not transfer to begin with. So this desync may not be directly connected to this bug.

(0004397) Tow (developer) 2014-02-02 17:52	Thanks, that helps. Interestingly, I can't reproduce the issue using gemtestafter savegame. Whatever it is, it doesn't survive save/load. Otherwise, using the before savegame, issue is perfectly reproducible. I'll investigate it.

(0004398) Tow (developer) 2014-02-02 17:59	The artifact is not transferred. The issue is that bonus tree dependencies are transferred.

(0004402) Tow (developer) 2014-02-02 21:46	I see two issues: 1) The CGameState::prepareCrossoverHeroes function does not properly remove things from hero (it goes around the bonus system). That's easy to fix. 2) Desync. What really puzzles me is why the hero on client doesn't have old stacks/artifacts from the beginning, while on server they are removed during init. That should not happen. I'll leave 1) until I investigate properly 2).

(0004414) Tow (developer) 2014-02-08 16:49	The source of this desync (and likely the others) is that server, when entering the next campaign mission goes like this: 1. newGame -> gh::init -> gs::init -> placeCampaignHeroes -> prepareCrossoverHeroes <= modifies the heroes that are part of start info 2. send start info (that has been already modified) all the clients, so they can perform their inits The start info fed to the clients and server is different and that results in desync. I have even found TODO note in "prepareCrossoverHeroes" saying that heroes needs to be deep copied.

(0004430) Tow (developer) 2014-02-08 23:08	Fixed all the issues in r3745.

(0004741) Kantor (updater) 2014-06-02 11:28	This one may be closed.