Anonymous | Login | 2024-11-21 15:25 UTC |
My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001597 | VCMI | Campaigns | public | 2013-11-23 14:31 | 2014-06-02 11:34 | ||||
Reporter | Ivan | ||||||||
Assigned To | beegee | ||||||||
Priority | normal | Severity | major | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | 0.94b | Fixed in Version | 0.94d | ||||||
Summary | 0001597: Heroes are not moving to next scenario | ||||||||
Description | Mostly to keep this logged on tracker - one quite large missing piece of campaigns support. Currently game will correctly generate list of heroes that will be passed over to next scenario BUT selecting next scenario causes server to restart, losing all information related to these heroes. Possible ways to solve this problem: A: allow using same server instance for multiple games. In this case - information won't be lost because server won't restart B: save campaign data on hard drive & load it when server restarts. We need mid-campaign saves anyway. C: keep all this data on client and send it to server once it restarts. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0004174) beegee (developer) 2013-12-15 11:36 |
I would like to implement that feature based on solution C. I think that the campaign state is client-only information. (like mod settings, game settings, personal highscores,...) Solution A seems to be hard to implement and is a special case for campaigns and if you want to re-start a mid-campaign save you'll either need solution B or C additionally. Solution B seems to be a little intransparent (server stores data implicitely in /Games subfolder) and takes more effort than solution C. The server already sends campaign state along with list of heroes that will be passed to next scenario to the client. The campaign state is part of the StartInfo struct, will be sent to the server and CGamestate::init initializes the game then. The init method should take care of transfered heroes. Mid-campaign saves should be named like this and consists of 1 or 3 parts: camp.vcmp (stores campaign state only) along with possible camp.vccmp1 and camp.vscmp1 (instead of .vsgm1) If you save during a scenario, the save consists of 3 files and if you save between a campaign scenario, the save consists of 1 file. The file scheme should clearly separate those savegames from normal scenarios. I don't know if the server needs to know about the campaign state at all. It's only used 4 times in the server when a campaign scenario ends. The server could then load the campaign save like any other normal game. The client should first load the campaign state (which is always available) and evaluate this information. If the campaign scenario is not finished, it loads the game based on the other two savegames. If the campaign scenario is finished, the client shows the campaign bonus selection screen first and creates a server instance when the player starts the scenario. |
(0004175) Ivan (developer) 2013-12-15 13:05 edited on: 2013-12-15 13:10 |
My main concern against C is possibility of multiplayer campaigns in future - keeping this info on server would be more secure approach. On the other hand - having working campaigns right now is much more important. >> Mid-campaign saves should be named like this and consists of 1 or 3 parts: IIRC campaign state is already part of save game (located in CGameState) so camp.vcmp would be needed only for mid-scenario saves. When this feature will be implemented - make sure that you can start 2nd scenario of Long Live the Queen campaign from RoE - this is quite special scenario because on game start player owns only hero placeholders, currently resulting in instant loss. |
(0004176) beegee (developer) 2013-12-15 14:54 |
I thought about multiplayer campaigns too, but we can add support for it later. C is a minimal solution where the server doesn't validate if your allowed to start mission X. This is OK for now, I think to support proper cheat-proof and secure MP games, we need to do a few more steps anyway:) |
(0004334) beegee (developer) 2014-01-30 19:02 |
IMO, general support is given. For more specific problems a new mantis point should be created. |
(0004746) Kantor (updater) 2014-06-02 11:34 |
This one may be closed. |
Issue History | |||
Date Modified | Username | Field | Change |
2013-11-23 14:31 | Ivan | New Issue | |
2013-12-15 11:36 | beegee | Note Added: 0004174 | |
2013-12-15 13:05 | Ivan | Note Added: 0004175 | |
2013-12-15 13:10 | Ivan | Note Edited: 0004175 | View Revisions |
2013-12-15 14:54 | beegee | Note Added: 0004176 | |
2013-12-17 18:08 | beegee | Assigned To | => beegee |
2013-12-17 18:08 | beegee | Status | new => assigned |
2013-12-31 17:52 | Ivan | Target Version | => 0.94b |
2014-01-30 19:02 | beegee | Note Added: 0004334 | |
2014-01-30 19:02 | beegee | Status | assigned => resolved |
2014-01-30 19:02 | beegee | Fixed in Version | => 0.94d |
2014-01-30 19:02 | beegee | Resolution | open => fixed |
2014-06-02 11:34 | Kantor | Note Added: 0004746 | |
2014-06-02 11:34 | Kantor | Status | resolved => closed |
Copyright © 2000 - 2024 MantisBT Team |