[GH-ISSUE #224] Feature requests #116

New Issue

2026-02-17T17:06:11-05:00

yindo commented

2026-02-17 17:06:11 -05:00

Originally created by @pjones112000 on GitHub (Aug 30, 2025).
Original GitHub issue: https://github.com/Drop-OSS/drop/issues/224

I'm currently using 0.3.3 #fd828d5 and I would like to suggest a few features:

First, I want to say that I'm liking what I'm seeing so far but I think it still needs a bit more work.
Second, if these feature requests are duplicate, I apologize as I thought I had done my due diligence and didn't find them anywhere.

When adding a game version, the Launch executable/command expects that the executable be in the downloaded folder without an ability to override this....not all games will get installed there. For example. games that came from GOG will generally have an installer that will install them into the c:\GOG Games folder. I've been able to overcome this by creating a Launch.bat file that go to the appropriate folder and launches the game; however, if the path was not locked to the downloaded folder, it would not require a work around.
Uninstall merely deletes the download folder. Please add an option to specifiy the uninstall command (again, not a locked path) that is run BEFORE deleting the download folder.
I would like the ability to edit an existing version's settings. For example. if I do not know the executable that will be run to play the game post install, I'll need to run the download/setup once before hand. Perhaps add a flag for "active" or "make live in store" or something that allows you to continue editing until active? Just a thought.
A "mature" flag might be important as this could be useful in a family situation where you want to make some games available to your family but don't want some games accessible to younger audiences and of course you'll need to somehow flag users as being able to access the mature content, or perhaps the ability to restrict some users from certain libraries?
Update the Docker documentation. It took me a while to even realize that there was a URL published in the logs that I was supposed to access to create an Admin user and initial library.
When adding a game that is Setup Only the Drop Windows Client (perhaps web as well) doesn't distinguish it from one with a play executable, so the Play button is still there but will give an error. Ideally, it would never say Play or at least state that the game cannot be run from within Drop and must be run from the OS.
After adding a new user as a NON Admin account, the Windows Desktop Client still has the Admin Dashboard, etc... shown, while it won't let them access it directly I don't think they should be displayed at all for non-admins.

Again, these are just suggestions rather than criticism. What I've seen is a great start.

Regards,
Phil

Originally created by @pjones112000 on GitHub (Aug 30, 2025). Original GitHub issue: https://github.com/Drop-OSS/drop/issues/224 I'm currently using 0.3.3 #fd828d5 and I would like to suggest a few features: First, I want to say that I'm liking what I'm seeing so far but I think it still needs a bit more work. Second, if these feature requests are duplicate, I apologize as I thought I had done my due diligence and didn't find them anywhere. 1) When adding a game version, the Launch executable/command expects that the executable be in the downloaded folder without an ability to override this....not all games will get installed there. For example. games that came from GOG will generally have an installer that will install them into the c:\GOG Games folder. I've been able to overcome this by creating a Launch.bat file that go to the appropriate folder and launches the game; however, if the path was not locked to the downloaded folder, it would not require a work around. 2) Uninstall merely deletes the download folder. Please add an option to specifiy the uninstall command (again, not a locked path) that is run BEFORE deleting the download folder. 3) I would like the ability to edit an existing version's settings. For example. if I do not know the executable that will be run to play the game post install, I'll need to run the download/setup once before hand. Perhaps add a flag for "active" or "make live in store" or something that allows you to continue editing until active? Just a thought. 4) A "mature" flag might be important as this could be useful in a family situation where you want to make some games available to your family but don't want some games accessible to younger audiences and of course you'll need to somehow flag users as being able to access the mature content, or perhaps the ability to restrict some users from certain libraries? 5) Update the Docker documentation. It took me a while to even realize that there was a URL published in the logs that I was supposed to access to create an Admin user and initial library. 6) When adding a game that is Setup Only the Drop Windows Client (perhaps web as well) doesn't distinguish it from one with a play executable, so the Play button is still there but will give an error. Ideally, it would never say Play or at least state that the game cannot be run from within Drop and must be run from the OS. 7) After adding a new user as a NON Admin account, the Windows Desktop Client still has the Admin Dashboard, etc... shown, while it won't let them access it directly I don't think they should be displayed at all for non-admins. Again, these are just suggestions rather than criticism. What I've seen is a great start. Regards, Phil

yindo closed this issue

2026-02-17 17:06:11 -05:00

yindo commented

2026-02-17 17:06:11 -05:00

@DecDuck commented on GitHub (Aug 30, 2025):

This is sort of intended. If you don't know, there are two kinds of games: portable and installer. Drop is designed to work best with portable games, where you don't need to run anything to set them up. We have support for installer games because that's how GOG distributes their games, but Drop has no way to track where they're installed. Despite this however, you can provide an absolute path to the game executable, like "C:\GOG Games\MyGame\launch.exe"
Again, Drop is designed to work with portable games, but that is a good idea to add for installer games. Could you please make a separate issue for that?
Coming soon™. There's a lot of small features/QoL stuff like that missing because it's really really boring to implement lol.
Good idea, we haven't really implemented any parental control stuff. Can you make a separate issue?
Do you mean in the Quickstart? It mentions it at the end of the section:

Once your instance is running, it will log a URL that takes you to the setup wizard. You can use it to create an admin account, and create your first library source.

Sounds like a bug, can you open an issue on https://github.com/Drop-OSS/drop-app
Also sounds like a bug, can you open an issue on https://github.com/Drop-OSS/drop-app

Just in future, generally GitHub issues are constrained to a single topic/issue, rather than several in one :)

@DecDuck commented on GitHub (Aug 30, 2025): 1. This is sort of intended. If you don't know, there are two kinds of games: portable and installer. Drop is designed to work best with portable games, where you don't need to run anything to set them up. We have support for installer games because that's how GOG distributes their games, but Drop has no way to track where they're installed. Despite this however, you can **provide an absolute path to the game executable, like "C:\GOG Games\MyGame\launch.exe"** 2. Again, Drop is designed to work with portable games, but that is a good idea to add for installer games. Could you please make a separate issue for that? 3. Coming soon™. There's a lot of small features/QoL stuff like that missing because it's really really boring to implement lol. 4. Good idea, we haven't really implemented any parental control stuff. Can you make a separate issue? 5. Do you mean in the Quickstart? It mentions it at the end of the section: > Once your instance is running, it will log a URL that takes you to the setup wizard. You can use it to create an admin account, and create your first library source. 6. Sounds like a bug, can you open an issue on https://github.com/Drop-OSS/drop-app 7. Also sounds like a bug, can you open an issue on https://github.com/Drop-OSS/drop-app Just in future, generally GitHub issues are constrained to a single topic/issue, rather than several in one :)

yindo commented

2026-02-17 17:06:11 -05:00

@pjones112000 commented on GitHub (Sep 3, 2025):

I understand and will, however, there seems to be some confusion about #1. You can NOT enter an absolute path, the path is locked to (install path). I'll add a a separate request to default to install directory but allow overwriting.

@pjones112000 commented on GitHub (Sep 3, 2025): I understand and will, however, there seems to be some confusion about #1. You can NOT enter an absolute path, the path is locked to (install path). I'll add a a separate request to default to install directory but allow overwriting.

yindo commented

2026-02-17 17:06:12 -05:00

@DecDuck commented on GitHub (Sep 3, 2025):

Actually, what Drop does it invoke the executable you give it, and set the current working directory to the install path. So it acts like we prepend the install directory, but we don't, so you can use absolute paths.

The UI is like that because most people use the relative paths, and I feel like it's simpler.

@DecDuck commented on GitHub (Sep 3, 2025): Actually, what Drop does it invoke the executable you give it, and set the current working directory to the install path. So it acts like we prepend the install directory, but we don't, so you can use absolute paths. The UI is like that because most people use the relative paths, and I feel like it's simpler.

yindo referenced this issue

2026-02-17 17:06:27 -05:00

[PR #116] [MERGED] Combined fixes #220

yindo changed title from ~~Feature requests~~ to [GH-ISSUE #224] Feature requests

2026-06-05 14:21:31 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Drop-OSS/drop#116