View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000546 | FSSCP | user interface | public | 2005-09-14 16:17 | 2005-09-16 02:17 |
| Reporter | Fractux | Assigned To | taylor | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000546: Unable to Change Main Hall | ||||
| Description | When Changing the +Main Hall flag (either 0 or 1) in a campain .fc2 file, the main hall does not change in fs2_open. I tried this using all CVS build from the 12th of august to the 12th of September. As a quick test I loaded up the FS2 campain file, and changed all +Flags: 0 (which selects the main hall), to +Flags: 1 and loaded the campain file. The main hall remained as the Terran hall, and not the Vasudan Hall. Tests were done on Linux. | ||||
| Tags | No tags attached. | ||||
|
|
"+Main Hall" sets the mainhall, not "+Flags:" so I'm not sure if that was just a mistake in writing it or what. :) The campaign file modification doesn't change what main hall gets shown, the pilot savefile does. The pilot savefile won't have the proper main hall value until you complete the current mission and the next mission has the new main hall number. Based on what you said this isn't a bug, unless it worked before and I just don't understand exactly what you are doing. By your description though the game is doing exactly what it should do. |
|
|
This is my bug, since I was the one who added +Main Hall to the SCP campaign files. In retail campaign files, the game should use +Flags... 0 for Galatea/Aquitaine, 1 for Bastion/Psamtik. In SCP campaign files, the game should use +Main Hall... 0 through 9 for any of 10 main halls defined in the table file. This went in a while ago and nobody's reported any problems with it. I'm not sure I understand your report, so I'm not sure if this is a true bug. |
|
|
Yeah, I was not sure it was a bug, which was why I had asked around first. [http://dynamic.gamespy.com/~freespace/forums/showthread.php?s=ae5a2f9321bcb1c905b2f46bbc524bcf&threadid=35158] "The campaign file modification doesn't change what main hall gets shown, the pilot savefile does. The pilot savefile won't have the proper main hall value until you complete the current mission and the next mission has the new main hall number." Ah, ok now I understand. You see, my situation was this. A small 3 mission campain I am working on has the player working as a vasudan. I set the main hall for the first mission as 1 - the vasudan main hall. So when the player selects the campain, I assumed that the main hall would change when I returned to the main hall. But, as Taylor explained, the player will have to complete the first mission before the main hall will change to the vasudan hall. I'll go check this now, and report back. One inevitable question of course, would this be a pain in the butt to change (after the freeze, of course) ? edited on: 09-14-05 18:34 edited on: 09-14-05 18:44 |
|
|
"One inevitable question of course, would this be a pain in the butt to change (after the freeze, of course) ?" Would what be a pain in the butt to change? Taylor: How hard would it be to force-update the player savefile as soon as he chooses a new campaign? In other words choosing a new campaign would immediately cause the player code to look at the first mission in the campaign and update the main hall immediately. I imagine this wouldn't be very hard, but I haven't delved too deeply into the player code to be sure. |
|
|
If I'm reading what Fractux is saying correctly it's not a pilot file issue but just the order in which the current main hall is set. By default it will be 0 in the pilot file and a save only will get what the current main hall is set to. So basically it's nothing related to the pilot file but how the main hall gets set otherwise. Whenever the mainhall changes in the current campaign for the player it's just not getting passed to the Player struct until after you play a mission. I think that if, on close of the readyroom we update the mainhall for the Player then it will be ok. It will end up in the pilot savefile too. Just do it before the mission_campaign_savefile_save() call in sim_room_close(). The pilot file and campaign savefile do force save when you change it in the campaign room btw. It automatically saves it when you hit the Accept button. edited on: 09-14-05 19:22 |
|
|
Well, it happned just like you said taylor. Once I completed the first mission, and exited back to the main hall, the main hall was vasudan. It would be nice if (once you guys have more time) it could switch over right away once a campain is selected, if that's technically feasible. I've been playing through the last CVS build and things are pretty rock solid. two thumbs up! Cheers! |
|
|
This could probably be fixed with one line of code but I'm not sure exactly how Goober has all of the setup. Something like: Player->main_hall = Campaign.missions[Campaign.current_mission].main_hall; after the campaign gets loaded in the readyroom should take care of setting it and then it will automatically get set in the pilot savefile. Goober really needs to check that though since I'm not sure if that one line is the best thing or not. |
|
2005-09-15 23:36
|
mainhall-update.diff (758 bytes)
Index: code/menuui/readyroom.cpp
===================================================================
RCS file: /home/fs2source/cvsroot/fs2_open/code/menuui/readyroom.cpp,v
retrieving revision 2.19
diff -u -r2.19 readyroom.cpp
--- code/menuui/readyroom.cpp 18 Jul 2005 03:45:07 -0000 2.19
+++ code/menuui/readyroom.cpp 16 Sep 2005 00:18:59 -0000
@@ -1920,6 +1920,11 @@
// unload the overlay bitmap
help_overlay_unload(CAMPAIGN_ROOM_OVERLAY);
+ // be sure that we are going to use the correct mainhall
+ if ( (Player != NULL) && (Campaign.current_mission >= 0) ) {
+ Player->main_hall = Campaign.missions[Campaign.current_mission].main_hall;
+ }
+
Ui_window.destroy();
common_free_interface_palette(); // restore game palette
write_pilot_file();
|
|
|
Attached diff would appear to fix this so unless you don't like it Goober I'll go ahead and commit later tonight/tomorrow. |
|
|
Looks okay to me. |
|
|
Should be... Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-09-14 16:17 | Fractux | New Issue | |
| 2005-09-14 19:28 | taylor | Note Added: 0003357 | |
| 2005-09-14 19:28 | taylor | Status | new => assigned |
| 2005-09-14 19:28 | taylor | Assigned To | => taylor |
| 2005-09-14 21:35 | Goober5000 | Note Added: 0003360 | |
| 2005-09-14 21:35 | Goober5000 | Assigned To | taylor => Goober5000 |
| 2005-09-14 22:31 | Fractux | Note Added: 0003361 | |
| 2005-09-14 22:34 | Fractux | Note Edited: 0003361 | |
| 2005-09-14 22:44 | Fractux | Note Edited: 0003361 | |
| 2005-09-14 22:44 | Goober5000 | Note Added: 0003362 | |
| 2005-09-14 23:22 | taylor | Note Added: 0003363 | |
| 2005-09-14 23:22 | taylor | Note Edited: 0003363 | |
| 2005-09-15 00:31 | Fractux | Note Added: 0003364 | |
| 2005-09-15 01:01 | taylor | Note Added: 0003365 | |
| 2005-09-15 23:36 | taylor | File Added: mainhall-update.diff | |
| 2005-09-15 23:37 | taylor | Note Added: 0003375 | |
| 2005-09-16 01:25 | Goober5000 | Note Added: 0003377 | |
| 2005-09-16 02:17 | taylor | Status | assigned => resolved |
| 2005-09-16 02:17 | taylor | Resolution | open => fixed |
| 2005-09-16 02:17 | taylor | Assigned To | Goober5000 => taylor |
| 2005-09-16 02:17 | taylor | Note Added: 0003380 |
