You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: