Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: mjn.mixael on August 21, 2015, 02:51:03 pm
-
So.. I'm looking for hopefully a quick and easy request. I'd like to be able to do per-mission briefing backgrounds (brief.ext and 2_brief.ext) very similar to per-mission loading screens.
The idea is partially motivated in that my briefing grid has slight color that matches the system most of the campaign takes place in... buuut sometimes it's different. I'd like to change that when I need to. The other part of the idea is to use the brief background to help immerse the player in current events of the upcoming mission.
-
Heh, so if the ship you're stationed on has just been hammered, maybe you could have background lit by red emergency lights? Or similar; not sure if you could go that far or not.
-
Yes, you can definitely do that. I mean.. it's just a static image, but you can do a lot with a little creativity. My other ideas were if it's just a surgical strike, you only need to show just like 4 pilots in the room. If it's a big operation, fill the room up with pilots.
-
I'll take a look over the weekend if someone doesn't get to it first. It seems to me that this would be very easy - just adapt the loading screen code to a different bit of interface art.
-
Yup, that's what I'm hoping!
-
At a quick glance, it should be as simple as making brief_ui_init() (missionbrief.cpp:745) load something other than Brief_filename[gr_screen.res].
-
I suspect we're going to get requests for this to also happen for command brief, debrief and fiction viewer soon after this feature is done. So sticking this in a separate dialog and calling with a button from mission notes might be worth considering. Probably best to keep it with the briefing editor.
-
Here's the PR: https://github.com/scp-fs2open/fs2open.github.com/pull/327
-
Wait, so what's the syntax and where in the file does it go?
-
Immediately under the $start_briefing tag, add these lines, changing filenames as needed:
$background_640: image.png
$background_1024: 2_image.png
EDIT: Might as well upload some builds. FRED is included so that you won't lose those lines when you load/save a mission. It doesn't currently have dialog support.
http://staff.hard-light.net/goober5000/temp/pr_327.zip
-
Having played around with this a bit, I found I could definitely make use of C.Brief, Debrief as well. Kara also suggestion Fiction Viewer (which I might actually use, too... unsure). Did you set this up with that functionality in mind? I thought you mentioned that on IRC.
And if I'm being really honest, I'd use something for Select Ship/Select Weapons, too. But I might be dreamin' too big there. It's all about immersion, man!
-
Having played around with this a bit, I found I could definitely make use of C.Brief, Debrief as well. Kara also suggestion Fiction Viewer (which I might actually use, too... unsure). Did you set this up with that functionality in mind? I thought you mentioned that on IRC.
The supporting function was made with extending it to other sections in mind, but they still need the code added to have the options available.
-
What AdmiralRalwood said. Although I realized today that I should have made the save functions in FRED extensible in the same way I made the load function in FS2. But that's not too hard to fix.
I figured the screens would mushroom like that. What do we have - cbrief, debrief, ship select, weapon select, fiction viewer... any others? That's six places (counting briefings). That really is not hard to do in the FS2 source, but it would involve a bunch of annoying FRED dialog coding. A bit less if we use karajorma's (pretty good) idea about making it a dialog you call from Mission Notes.
-
I can't think of any others since we already have loading screens. And to be fair.. the cutscene stuff still doesn't have a FRED dialog, soooooooo :p
-
I keep meaning to add one of those. I'll see about doing it as a testbed for getting used to git. It's probably a much better one than my sprawling SEXP containers code.
-
Goober, any chance the rest of these can make the next release? They are the only feature BtA will use that's not in the release branch. Given that we are unbelievably close to release, I'd hate to have to cut the feature or wait for the following FSO release.
-
If that's the right pull request then it's already been merged: https://github.com/scp-fs2open/fs2open.github.com/pull/327
-
Yes and no. That's just briefings. I'm hoping to get the rest (command, fiction, ship select, weapon select, debrief) too.
-
I think I can follow Goober's changes and implement this feature for all the briefing and debriefing screens.
-
I've got code for the rest of the features in my working branch. If Yarn hasn't posted a PR yet, I can put the finishing touches on it and make a PR.
(I would have done this before September 3rd but I ran out of time before vacation.)
-
I'm actually almost ready to post a PR. The only thing that isn't finished yet is the fiction viewer.
-
It will be the battle of the PRs then! Did you use a common function for saving data to the mission file and loading the background bitmap? Because I realized that the same common function used for loading from the mission file could be applied to the other two cases:
void CFred_mission_save::save_custom_bitmap(const char *expected_string_640, const char *expected_string_1024, const char *string_field_640, const char *string_field_1024)
{
if (Format_fs2_open != FSO_FORMAT_RETAIL)
{
if (*string_field_640 != '\0')
{
fout("\n%s %s", expected_string_640, string_field_640);
}
if (*string_field_640 != '\0')
{
fout("\n%s %s", expected_string_1024, string_field_1024);
}
}
}
// Try to load background bitmaps as appropriate
int mission_ui_background_load(const char *custom_background, const char *single_background, const char *multi_background)
{
int background_bitmap = -1;
if (*custom_background != '\0')
{
background_bitmap = bm_load(custom_background);
if (background_bitmap < 0)
mprintf(("Failed to load custom background bitmap %s!\n", custom_background));
}
// if special background failed to load, or if no special background was supplied, load the standard bitmap
if (background_bitmap < 0)
{
if (Game_mode & GM_MULTIPLAYER)
background_bitmap = bm_load(multi_background);
else
background_bitmap = bm_load(single_background);
}
// return what we've got
return background_bitmap;
}
With these functions, the code across all background bitmaps is the same, with only minimal work to link them together.
-
I'll add those functions to my branch (which you can find here: https://github.com/Yarn366/fs2open.github.com/tree/per_mission_ui_backgrounds (https://github.com/Yarn366/fs2open.github.com/tree/per_mission_ui_backgrounds)).
-
Here's my pull request: https://github.com/scp-fs2open/fs2open.github.com/pull/353 (https://github.com/scp-fs2open/fs2open.github.com/pull/353)
And here are some test builds: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/per_mission_ui_backgrounds.7z (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/per_mission_ui_backgrounds.7z)
For briefing backgrounds, use this syntax in the #Briefing section, just below $start_briefing:
$briefing_background_640: image.png
$briefing_background_1024: 2_image.png
$ship_select_background_640: image.png
$ship_select_background_1024: 2_image.png
$weapon_select_background_640: image.png
$weapon_select_background_1024: 2_image.png
The $briefing_background_xxx fields apply to both standard and red-alert briefings.
For debriefings, command briefings, and the fiction viewer, use this syntax at the beginning of the appropriate section:
$Background 640: image.png
$Background 1024: 2_image.png
Keep in mind that if you specify a fiction viewer background, then the FreeSpace 2 layout will be used unless an explicit layout is specified via one of the methods below.
All fields above apply to both single-player and multiplayer. Also, in team-vs.-team missions, you need to specify custom backgrounds for every team that should use them.
I also added two ways of setting which fiction viewer layout to use. One way is to specify it in the mission file. To do so, add the following line just below the $Background xxx fields in the fiction viewer section (assuming they exist):
$UI: FS2 ;; can be "FS2" (for FreeSpace 2) or "WCS" (for Wing Commander Saga)
You can also specify the layout in game_settings.tbl. To do so, place the following line in the #OTHER SETTINGS section just after $Beams Use Damage Factors (if it exists):
$Default fiction viewer UI: FS2 ;; can be "FS2", "WCS", or "auto" (the default setting)
Missions that specify a fiction viewer UI will override this setting.
None of this can be edited in FRED yet, although these fields should be preserved when the mission is resaved.
-
Super. :yes: I will check out the PR.
-
Question. How does this code handle CommanBrief vs CommandBriefB? (The B version has the scroll buttons for text that goes below the text box.) Does this code consider that or is that the responsibility of the modder?
-
Yarn's code assumes that if you specify a custom command briefing background, it will be the type that supports scroll buttons.
Also, I merged the PR, so it should appear in the next nightly build. Be advised that $background_640 was changed to $briefing_background_640 (and ditto for 1024), since there are now ship and weapon selection background definitions in the same section.
-
OK, that works for me! I just tested everything out and it works great.
BtA has no more holdout features for a new SCP release.
-
The initial implementation of this feature in the FS2Open engine has incorrectly used low-level memory handling.
See here (https://github.com/scp-fs2open/fs2open.github.com/commit/05d4e44c97100486fa68328fbfc89be68bed9a04#diff-ab185d1da47e85d3068a1f5e6626ade5R191) for the comment. Would strongly advise you await a release with the eventual fix for this (should be simple enough).
-
Err, crap. Will fix that.
-
I submitted a PR (https://github.com/scp-fs2open/fs2open.github.com/pull/370).
During my search through the codebase for other instances of similar errors, I ran across this bit in the options_multi_vox_button_pressed() function in optionsmenumulti.cpp:
// clear the comp buffer
memset(Om_vox_comp_buffer,128,OM_VOX_COMP_SIZE);
The value 128 doesn't fit in an unsigned char, so this may not produce the expected result. (I'm surprised this hasn't been found by clang. Technically the middle argument is an int but it's always converted to unsigned char.)
-
If it's an unsigned char then the biggest value is 256 so 128 is a valid value. However "clearing" a buffer by setting every byte to 128 seems a little weird so it might be some kind of programming error.