MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001597VCMICampaignspublic2013-11-23 14:312014-06-02 11:34
ReporterIvan 
Assigned Tobeegee 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version0.94bFixed in Version0.94d 
Summary0001597: Heroes are not moving to next scenario
DescriptionMostly 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.
TagsNo tags attached.
Attached Files

- Relationships

-  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

Site | Forums | Wiki | Slack | GitHub


Copyright © 2000 - 2024 MantisBT Team
Hosting provided by DigitalOcean