Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[WIP] Initial mod menu #361

Closed
wants to merge 3 commits into from
Closed

[WIP] Initial mod menu #361

wants to merge 3 commits into from

Conversation

mattiascibien
Copy link

@mattiascibien mattiascibien commented Dec 14, 2016 •
edited

Hello,

after a year of hiatus I was able to port my mod menu back from my messy fork of Doom3 to RBDoom3-BFG.

The intent of this is to provide a way to load mod like it was possible in the original Doom 3 version.

TODO list:

  • Implement mod menu loading GUI
  • Implement folder looping to populate the full list
  • Prevent the MODS menu from hiding the EXIT item when DEV is present (low priority as it is still possible to quit the game with ALT+F4)

I am opening as a WIP as I may need some help with populating the list of mods (loop through the folders alongside the exe, read the file description.txt inside those folders and add them to the list). I was not able to find a function to loop through the folders (maybe it is still possible to port the code that was used from the original doom source)

EDIT: found some code https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/framework/FileSystem.cpp#L1708-L1787

@BielBdeLuna
Copy link

BielBdeLuna commented Dec 14, 2016 •
edited

this is great news!

one should be able to re-add fullscreen GUIs to the engine, all the code is there.
some time ago I took a look to the code in order to re-add a fullscreen GUI for the map loading. it didn't seem difficult, it was just calling some classes that weren't called from the map loading code. all those classes are still there.

@mattiascibien
Copy link
Author

@BielBdeLuna thanks. I am now working on how I can loop the folders as ListOsFiles is private. I am seeking also @RobertBeckebans support on this if he is available.

@BielBdeLuna
Copy link

the big barrier won't be the c++ but the flash system. although motorsep made some flash menus, i still think bringing back the fullscreen GUIs would benefit the most, and it is a project of mine in the future.

before you act on it I'd propose you to look at the GUI code in dhewm3, maybe the ListOsFiles is there so you don't have to do the work

@mattiascibien
Copy link
Author

@BielBdeLuna ListOsFiles is already in BFG but is in a subclass (idFilesystemLocal) and therefore cannot be accessed from the filesystem variable I have inside the Menu file. I think that porting back the ListMods function from original doom3 will be nice.

The flash system itself does not have any problem as you can see the code to find and launch the mod is preetty complete at the moment. Whats is needed to d now is to populate the options var with the as many modOption_t as the number of folders found alongside the executable.

Not sure on how the whole game works on linux though (is the base directory still alongside the executable)?

@BielBdeLuna
Copy link

BielBdeLuna commented Dec 14, 2016 •
edited

in linux it changes, the config files and the saved games is saved in the /home/'username'/.rbdoom3bfg/'modfolder'/ where 'username' is the name of the linux user and 'modfolder' is the name of the mod.

how has it changed from dhewm3? in dhewm3 ListOsFiles is in the idFileSystemLocal class?

@mattiascibien
Copy link
Author

mattiascibien commented Dec 14, 2016 •
edited

Yep I know. The fact is that to outside only idFilesystem is exposed, and casting it for my merge seem quite a hack :)

Edit: filesystem local is not exposed to the public I think.

@mattiascibien
Copy link
Author

mattiascibien commented Dec 14, 2016 •
edited

I guess I will go with something like the old ListMods inside idFilesystem as per original doom3 so the code will resemble the old doom3 code.

EDIT: so it will be used like this: https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/framework/Session_menu.cpp#L228-L243

@BielBdeLuna
Copy link

merda? shit? what? :)

@mattiascibien
Copy link
Author

@BielBdeLuna ?

@BielBdeLuna
Copy link

I don't know what you said above... :)

@BielBdeLuna
Copy link

how different do you wish to do the mod menu?

besides the menu, you would need to separate the engine from the game code, how difficult will this be? is it just a matter to create a separate dll/so file from the cmake script or it will be more difficult than this?

@mattiascibien
Copy link
Author

mattiascibien commented Dec 14, 2016 via email

@BielBdeLuna
Copy link

@mattiascibien can't compile your code:

CMakeFiles/RBDoom3BFG.dir/d3xp/menus/MenuScreen_Shell_Mods.cpp.o:
In function idMenuScreen_Shell_Mods::HandleAction(idWidgetAction&, idWidgetEvent const&, idMenuWidget*, bool)': /home/biel/src/MattiascibienD3BFG/neo/d3xp/menus/MenuScreen_Shell_Mods.cpp:192: undefined reference to Sys_Exec(char const*, char const*, char const*, bool ()(), void ()(char const*), int, unsigned int&)'
collect2: error: ld returned 1 exit status

@mattiascibien
Copy link
Author

mattiascibien commented May 1, 2017 via email

@mattiascibien
Copy link
Author

mattiascibien commented May 15, 2017 via email

@BielBdeLuna
Copy link

alongside this, could opening pk4 files be implemented again?
I was looking at all this while working for the OTE (a derivative from the RBDoom3BFG, a OS platform for building games) and made a list of priorities related to mod folders and base folders, what do you think about this?

@mattiascibien
Copy link
Author

mattiascibien commented May 15, 2017 via email

@BielBdeLuna
Copy link

ok

@mattiascibien
Copy link
Author

mattiascibien commented May 15, 2017 via email

@BielBdeLuna
Copy link

BielBdeLuna commented May 15, 2017 •
edited

which is the reason that makes it difficult to make them work alongside *.resources files? I mean, aren't the files inside pk4 treated the same as the files outside in a folder only that they are zipped inside the file?

@mattiascibien
Copy link
Author

Sorry for updating this after this very long time.

@RobertBeckebans
Copy link
Owner

I close this because mods that require C++ changes are not covered by this and those mods need a new .exe anyway that can automatically set fs_game to the certain mod folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@mattiascibien @BielBdeLuna @RobertBeckebans