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.

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

games are still hardcoded in radiant (see #259) but I have an idea #659

Open
alcexhim opened this issue Sep 10, 2020 · 0 comments
Open

games are still hardcoded in radiant (see #259) but I have an idea #659

alcexhim opened this issue Sep 10, 2020 · 0 comments

Comments

@alcexhim
Copy link

So after attempting to create my own gamepacks for games like JK2 and OpenArena, I came across the bug #259 about hardcoded gamepacks which has since been closed (as far back as 2014!)

I respectfully disagree with the closing of this issue, as although it might have solved the immediate issue of getting a particular gamepack to work, it didn't solve the underlying issue of allowing us to create new gamepacks without having to tweak settings in several different places and then recompile the application.

I propose a simple addition to the gamepacks: a text file that contains the title, .game filename, and other attributes that were once hardcoded in the game. I have forked the repository and managed to build a working GtkRadiant (https://github.com/alcexhim/GtkRadiant) that dynamically loads whatever gamepacks are present in the "installs" directory.

There are a few downsides, however. The preferences.cpp defines several gamepacks that are not included in the "installs" directory. This will break things for new users who get those gamepacks from other distributions that do not provide a gamepack.def file. I have also skipped over implementing some of the stranger hardcoded functionality, such as changing the engine path based on the compile-time operating system, or copying a random "shaderlist.txt" file just because a particular gamepack has it at a different location (this should be fixed in the gamepack, not added to the main application as a compatibility shim).

As I don't have much experience collaborating with other users on GitHub, I don't feel comfortable submitting a pull request about this issue yet. I believe further discussion needs to take place about the benefits and/or disadvantages of this solution before considering it for inclusion into the official codebase.

I would be interested in hearing more experienced developers' opinions about this issue and my proposed solution. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant