Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: mjn.mixael on February 19, 2014, 03:28:37 pm
-
I originally asked CommanderDJ for these requests. He was interested, but doesn't have the time... so I'm posting them again here hoping to find anyone who might be interested in adding such functionality. Original thread is here. (http://www.hard-light.net/forums/index.php?topic=85702.0) (SCP Internal Board)
I honestly think that with these sort of additions, and these (http://www.hard-light.net/forums/index.php?topic=86881) sort of mods popping up... modders would be able to completely redefine what the FSO Interface could be used for.
The first feature is a +Door Region addition to the mainhall.tbl, and involves making the actions that each door in a mainhall does definable by the modder as opposed to hardcoded.
+Door Region: STRING (So, like +Misc Anim Group, this would need one entry per door.. but be optional)
-For mainhall.tbl
-sets the region for the door (options, exit, ready room, etc.)
-Optional
-Could make duplicate doors.. that's up to the tabler to fix!
-allow Lab and Multi to be settings among others
-Goober's Thoughts
---<@Goober5000> the best way to specify a door action would be to indicate an event in the state machine
---<@Goober5000> the game has a state machine
---<@Goober5000> i.e. it has a number of defined states, meaning configurations or modes
---<@Goober5000> gameplay vs. viewing main hall vs. viewing options, etc.
---<@Goober5000> so if you say "clicking on this region will trigger this state" you could make your region to any number of useful things.
OK, so the +Door Region would still need the mask. The 'regions' of the doors are currently hardcoded. The first door in the list is always 'Exit Game', the third door is always 'Ready Room', etc. The mask just tells FSO what door the mouse is currently hovering over. It does this by color index. The masks look like they are black and white, but they are actually black and 6 shades of white... one for each index, aka, one for each door.
What I'm looking for is a way to remove the hardcoded set of what each door does. So the mouse is over index 1 on the mask, which lines up with door 1 in the list which normally leads to Exit Game. I was hoping to get a new flag, +Door Region:, where I could list pretty much anything from FSO's state machine. (http://www.hard-light.net/wiki/index.php/List_of_Game_States) Obviously, some of those would not make much sense, but others would be awesome (Think Multi, since the need for a separate multi player is removed.) This should also increase the number of doors from 6 to n. (Which is handy for people who make button based mainhalls.) In general, the door listed first should = the door listed first in the mask, 2=2, 3=3, etc. But I'll need to double check that's how the retail ones work. Obviously, retail compatibility should default to the regular 6 doors listed in the proper order.
CommanderDJ's notes:
My initial look over the code suggests that it's not as simple as just using FSO's state machine since each transition involves a little more than simply changing the game's state (not to mention most of the state machine's values are completely useless in relation to this), but that's a small issue. The main issue that I have with this is that (if I understand it correctly, someone slap me if I don't!) the mainhall mask tells FSO both the position of each door in the mainhall and the what the door does. If we want to shift the information relating to each door's function to mainhall.tbl, I think it'd be good to decouple those two uses of the mainhall mask (obviously maintaining retail compatibility and all that), which is effectively what this +Door Region property will do: if this is present for a particular door, FSO will only use the corresponding mask value to determine the door's position, and get its function from the table instead. Does this make sense? Opinions, criticisms? From my preliminary look at the code this may or may not be a bigger task than it sounds because, well... :v:.
Goober also had some thoughts:
My initial look over the code suggests that it's not as simple as just using FSO's state machine since each transition involves a little more than simply changing the game's state
Make sure you understand what you're looking at. There is a fair amount of work in actually changing a game's state, but the state machine handles all of that behind the scenes. All you have to do is initiate the state change, which you can do with something like gameseq_post_event(GS_EVENT_MAIN_MENU).
The main issue that I have with this is that (if I understand it correctly, someone slap me if I don't!) the mainhall mask tells FSO both the position of each door in the mainhall and the what the door does.
This is true, but not actually a problem. The postition of the masking square tells where the door is. The color of the square tells what it does (specifically, the color index in the palette corresponds to a #define of 0, 1, 2, etc.). So they are already decoupled.
This should also include the ability to have more than 6 doors/buttons as well.
I have some other mainhall related requests, but this one is easily my most preferred.
-
I've implemented this as follows:
The mainhall.tbl supports two new keys: "+Door region" and "+Door description"
"+Door region" specifies what happens when the user clicks on that door. Currently allowed are Exit, Barracks, Readyroom, Techroom, Options, Campaigns, Load Mission, Quickstart, Skilllevel and Script.
The first six are the default doors. Load Mission is defined in the code (LOAD_MISSION_REGION) but not implemented (it does nothing). You can trigger it by default by pressing "L".
Quickstart immediatly starts a mission by skipping the briefing screens but works only in debug builds. This can be triggered by pressing "G" right now.
Skilllevel increases the pilot's skill.
Script initiates the GS_STATE_SCRIPTING game state and sets "hv.MenuButton" in LUA to the index of the clicked door. This way the script can tell which door the user chose.
"+Door description" specifies a new description.
"+Door region" comes after "+Door pan" and after that comes "+Door description".
The six first "+Door region" and "+Door description" options overwrite the default options. If you want to add more options you have to edit the mainhall mask and add new areas (with new colors). You also have to add the new options to menu.tbl.
Every door has its own line in menu.tbl which normally looks this:
"" COLOR_NUM NULL NULL NULL
You can also write a single letter behind COLOR_NUM to connect that door with a key. COLOR_NUM is a number between 0 and 255. To get the actual color for the mask you have to substract COLOR_NUM from 255 and write the result in hexadecimal.
I.e., if COLOR_NUM is 6:
255 - 6 = 249 = 0xf9
In this case the color is #F9F9F9 (since the mask is greyscale).
Right now the code contains a limit of 20 entries for menu.tbl (in the MAIN HALL section). If you add more, FS2 will (most likely) crash.
I've put together a demo. (http://dev.tproxy.de/fs2/test-mainhall.zip) Just extract that archive in your FS2 folder, select the test directory as your mod and start the patched build (which you have to compile yourself, sorry).
Here is the patch. (http://pastebin.com/XugqKG52)
What do you think?
-
Wow, I can't believe I missed this post. Give me a few days to look into it and test it.
Also, can Multiplayer and F3 Lab be allowed options?
EDIT: First thoughts. I understand the menu.tbl route completely and it makes sense. But requiring menu.tbl recreates a mainhall limitation that we recently removed, that being modularness. Menu.tbl is not modular and so any mainhall that needs it for these functions loses that ability. Would it be possible to either make menu.tbl modular (I'm not hopeful, it's syntax is weird and unlike any other table), or incorporate these necessary table lines in a "header" of the mainhall.tbl? I dunno, just ideas off the top.
For the number to hex thing. Any chance we can make that easier on the modder like allowing the specification of the color code or something?
-
So I was talking to mjn with this, playing with it also and I have a suggestion.
It seems to me that your planned way of doing things is when we hit a "script" button, we leap into the scripting state and then we route to other screens depending on what hv.MenuButton is. It makes sense anyway. But there's a problem with that, there's quite a few uses of GS_EVENT_PREVIOUS_STATE that the Exit button of those screens use. Eg: the F3 lab. When we go to the previous state, we go back to the scripting state which says... go to F3 lab.
So maybe instead could you have it so $On State End (or something else that makes sense) will have available the MenuButton variable? So then you could so something like this...
$State: GS_STATE_MAIN_MENU
$On State End: [
if hv.MenuButton == '6' then
ba.postGameEvent(ba.GameEvents["GS_EVENT_OPTIONS_MENU"])
end
if hv.MenuButton == '7' then
ba.postGameEvent(ba.GameEvents["GS_EVENT_LAB"])
end
]
-
Yup, 7 clickable & animated areas. Win.
To recap. This. Is. Awesome. Here are a few final notes from my testing.
- The scripting should do more what Axem requested to avoid endless state-loops.
- None of the Multiplayer states really work. They would load the interface and then promptly return to the mainhall. It'd be handy if that was a built-in option though, because the option already exists in the code somewhere thanks to the old Multiplayer players. (Readyroom was replaced with Multiplayer). Perhaps any other generic-use states?
- +Door Description should probably link into the XSTR stuff for translations? Yes? No? Maybe? Does it already?
- Menu.tbl needs to be modular or some way included so as to not suddenly bring that limitation back to mainhalls.
- **** yeah
EDIT: I thought about the menu.tbl thing a bit... so each door index in the mainhall.tbl has a menu.tbl line that corresponds to it, right? And all that does is match the door index to a hex value that leads to a color for the mask file, right? Could we just include this line or some variation of it in the mainhall.tbl and then not require menu.tbl at all for that? Perhaps we'd have +Door Value added as well simple include the info that is currently found in menu.tbl. I dunno, just another idea I had.
-
End-of-the-month BUMP!
Original coder of this neat patch is not responding to my PMs. Halp. I refuse to let this die. :)
-
I didn't see that video before - it's brilliant! Does this mean Axem's new fiction viewer thing wont have to bump the barracks any more?
-
I didn't see that video before - it's brilliant! Does this mean Axem's new fiction viewer thing wont have to bump the barracks any more?
Yup!
-
So.. guess ngld isn't coming back to this. Who do I bribe now?
-
Me! But then you have to put up with my characteristic tardiness.
(And I'm not claiming exclusive implementation rights either. Other coders, feel free to volunteer yourselves!)
-
(Bi)Monthly Bump!
-
Um... sorry for my long absence. :nervous:
So the remaining changes are:
- Make hv.MenuButton available to "$On State End".
- Fix Multiplayer.
- Make sure translations work for "+Door description". (They should be handled by parselo already but I'm not sure.)
- Add "+Door Mask" (any better ideas for the the option name?) to avoid depending on menu.tbl.
I've avoided this because I'll probably have to make some changes to SnazzyUI to make this work. - Anything I forgot?
-
That looks about right.
Could be +Door Mask Value: or +Door Mask Hex.
That one's pretty important because without it we lose one of the biggest upgrades to mainhalls (modularability) we've gotten so far.
-
thought this was what that webkit stuff was for.
-
Nope. This is not a thread about WebKit... That is a separate issue, and separate thread.
This is about extended features that don't require new library integration into FSO, thank you.
-
ok, I had gotten the impression that was the way forward, nevermind then.
-
I've updated the patch (http://pastebin.com/XugqKG52) and the example (http://dev.tproxy.de/fs2/test-mainhall.zip).
The new patch ignores the menu.tbl completely (which means that keyboard shortcuts won't work anymore).
The "+Door mask value" tells FSO which color the masked area has. You can put a decimal or hexadecimal number here. (i.e. 255 means (255, 255, 255) aka #FFFFFF, 0x01 means (1, 1, 1) aka #010101)
The "+Door action" can be one of Exit, Barracks, Readyroom, Techroom, Options, Campaigns, Load Mission, Quickstart, Skilllevel or "Script <LUA code>".
If "+Door description" is "default" it will use the hardcoded default description.
+Door mask value: 0xf9
+Door mask value: 254
+Door mask value: 253
+Door mask value: 252
+Door mask value: 251
+Door mask value: 250
+Door mask value: 255
+Door action: Exit
+Door action: Barracks
+Door action: Readyroom
+Door action: Techroom
+Door action: Script ba.postGameEvent(ba.GameEvents["GS_EVENT_LAB"])
+Door action: Script testMessage()
+Door action: Script ba.postGameEvent(ba.GameEvents["GS_EVENT_SCRIPTING"])
+Door description: Exits are to the rear, left and right
+Door description: To the barracks
+Door description: Launch the mission...
+Door description: View the tech
+Door description: Script 4
+Door description: Script 5
+Door description: Script 6
I've fixed the multiplayer, however for it to work the third door has to be the Readyroom door. To get the default multiplayer description you have to set the description to "default".
-
I'll test this when I get home. Can you explain the multiplayer bit more? It seems to mean that you can't have ReadyRoom and Multiplayer coexist.
Did you fix the script issue where we had loops. (I think related to $On State End)?
-
Multiplayer and Readyroom can't coexist because you need a single player pilot for the Readyroom and a multiplayer pilot for Multiplayer.
If the player is using a multiplayer pilot and the third door has the action Readyroom, then FSO will automatically change it to Multiplayer.
A better way to do this might be to add a Start action which uses the Readyroom action when in single player mode and Multiplayer when in multi mode.
The script issue should be solved since I'm not switching to scripting state anymore. I'm simply running the LUA code in the mainhall.
You can still change the game's state using LUA (using ba.postGameEvent) but you can also do LUA scripting on the mainhall.
In my example you can click on the campaign screen to toggle a short text in the upper left corner.
-
The Multiplayer may be worth a deeper look (which may go beyond this patch) because I'm under the impression that player files are no longer distinguished between single and multi. I suspect the difference now is only interface-deep, but I could be wrong.
-
The pilot files are indeed now unified between single- and multi-player. I think the only difference between the singleplayer tab and the multiplayer tab in pilot selection is what the game mode is currently set to, but I haven't looked at that code very deeply.
-
What's 'Script 6' supposed to do in your test? It hooks GS_EVENT_SCRIPTING, looks like it's supposed to display string 'You pressed button 6'.. but for me it just exits FSO.
Otherwise, this is working great. All of the previous issues have been fixed. Multiplayer is the only remaining thing I'm wondering about, but it is likely beyond the scope of this particular patch.
-
Just FYI. This won't patch to latest Trunk anymore because the unstretched mainhall stuff was committed.
-
I just fixed the multiplayer stuff. You can now use the Readyroom and Multiplayer regions. Once the user selects the Readyroom or Multiplayer the game mode will be updated accordingly.
I also added a Start region which keeps the retail behaviour (Readyroom if single player was selected and Multiplayer if multi was selected).
Your issue with "Script 6" was a problem with the descriptions. If you look at the "+Door mask value"s, you'll notice that "Test" is supposed to quit FSO and the normal Exit region shows the scripted screen.
I've opened a new pull request on GitHub (https://github.com/scp-fs2open/fs2open.github.com/pull/36) (which applies against current trunk).
Here's a Windows build (https://build.tproxy.de/fs2/fs2open-ngld/windows-mainhall_caps-latest.7z) and a Linux build (https://build.tproxy.de/fs2/fs2open-ngld/linux-mainhall_caps-latest.tar.gz).
-
That pull request as a patch (add.patch to the URL) still doesn't apply to the latest SVN trunk. But that's OK, I can test with your supplied builds.
Start, Multiplayer, and Readyroom all work! Nicely done. :)
Here's the rejected patch hunks.
--- code/menuui/mainhallmenu.cpp
+++ code/menuui/mainhallmenu.cpp
@@ -1532,36 +1582,30 @@
*/
void main_hall_maybe_blit_tooltips()
{
- int w, text_index;
+ int w;
// if we're over no region - don't blit anything
if (Main_hall_mouse_region < 0) {
return;
}
- // get the index of the proper text to be using
- if (Main_hall_mouse_region == READY_ROOM_REGION) {
- // if this is a multiplayer pilot, the ready room region becomes the multiplayer region
- if (Player->flags & PLAYER_FLAGS_IS_MULTI){
- text_index = NUM_REGIONS - 1;
- } else {
- text_index = READY_ROOM_REGION;
- }
- } else {
- text_index = Main_hall_mouse_region;
+ if (Main_hall_mouse_region >= (int) Main_hall->regions.size()) {
+ Error(LOCATION, "Missing region description for index %d!\n", Main_hall_mouse_region);
}
// set the color and blit the string
if (!help_overlay_active(Main_hall_overlay_id)) {
int shader_y = (Main_hall->region_yval) - Main_hall_tooltip_padding[gr_screen.res]; // subtract more to pull higher
+ const char *desc = Main_hall->regions.at(Main_hall_mouse_region).description.c_str();
+
// get the width of the string
- gr_get_string_size(&w, NULL, Main_hall->region_descript.at(text_index));
+ gr_get_string_size(&w, NULL, desc);
gr_set_shader(&Main_hall_tooltip_shader);
gr_shade(0, shader_y, gr_screen.clip_width_unscaled, (gr_screen.clip_height_unscaled - shader_y), GR_RESIZE_MENU);
gr_set_color_fast(&Color_bright_white);
- gr_string((gr_screen.max_w_unscaled - w)/2, Main_hall->region_yval, Main_hall->region_descript.at(text_index), GR_RESIZE_MENU);
+ gr_string((gr_screen.max_w_unscaled - w)/2, Main_hall->region_yval, desc, GR_RESIZE_MENU);
}
}
Basically it still looks as if your changes aren't made on mainhallmenu.cpp that includes the new defined width and height. I tried to do those hunks manually, but I'm too dumb. :p
-
This should apply cleanly (http://pastebin.com/XugqKG52).
-
It did, thanks! No issues found, either. :)
I have no more requests for this patch.
EDIT.. I loaded the wrong mod. This patch against latest trunk gives me. ERROR: Missing required token ($Main Hall). Found [+Door mask value: 255] instead.
Looks like this chunk gets patched into the wrong place. It should go below Door Pan section and not above Num Door Animations. Dunno why Tortoise patched it there. *shrug*
Anyhow, I got it working together once I moved that to the correct place.. and NOW I have no issues.
region_info_init(*m);
int mask;
for (idx = 0; optional_string("+Door mask value:"); idx++) {
// door mask
stuff_string(temp_string, F_RAW, MAX_FILENAME_LEN);
mask = (int) strtol(temp_string, NULL, 0);
mask = 255 - mask;
m->regions.resize(m->regions.size() + 1);
m->regions.at(idx).mask = mask;
}
for (idx = 0; optional_string("+Door action:"); idx++) {
// door action
if (optional_string("Script")) {
m->regions.at(idx).action = SCRIPT_REGION;
stuff_string(m->regions.at(idx).lua_action, F_RAW);
} else {
stuff_string(temp_scp_string, F_RAW);
int action = -1;
for (int i = 0; Main_hall_region_map[i].name != NULL; i++) {
if (temp_scp_string == Main_hall_region_map[i].name) {
action = Main_hall_region_map[i].mask;
break;
}
}
if (action == -1) {
temp_scp_string = "";
for (int i = 0; Main_hall_region_map[i].name != NULL; i++) {
temp_scp_string += ", ";
temp_scp_string += Main_hall_region_map[i].name;
}
Error(LOCATION, "Unkown Door Region '%s'! Expected one of: %s", temp_string, temp_scp_string.substr(2).c_str());
}
m->regions.at(idx).action = action;
}
}
for (idx = 0; optional_string("+Door description:"); idx++) {
// region description (tooltip)
stuff_string(temp_scp_string, F_MESSAGE);
if (temp_scp_string != "default") {
m->regions.at(idx).description = temp_scp_string;
if (idx == 2) {
m->default_readyroom = false;
}
}
}
-
You were right. I updated the patch so the parsing code is in the right place.
So... I guess I'll poke someone to commit this to trunk?
-
it needs to be reviewed first.
-
Looked over the patch, found a couple issues (which ngld promptly fixed), and tested it out. Seems to work, does what it says it does, and doesn't break existing functionality (as far as I could tell).
-
I know it's awfully late for 3.7.2, but I'm hoping this can make it in. I'm working toward a late 2014 release of BtA which will make use of this.