mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-04-25 07:46:01 +03:00
[GH-ISSUE #614] [Feature Request] Allow to enable/disable loaded sys_modules #145
Labels
No labels
Bloodborne
bug
contributor wanted
documentation
enhancement
frontend
good first issue
help wanted
linux
pull-request
question
release
verification progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shadPS4#145
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mavethee on GitHub (Aug 27, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/614
Quick summary
Add ability load only certain sys_modules
Details
Similarly as RPCS3 handles it, as it might be quite useful with e.g Bloodborne (hate to say it nowadays) where removing some modules allowed the game to run better and/or avoid some issues with loading.
Would also help in detection if sys_modules were dumped correctly and none of it is broken?
Due to specifics of done things, could be in debug tab?
@georgemoralis commented on GitHub (Aug 27, 2024):
it can be made into a config i guess . Let's see if someone is interesting in doing it
@dima-xd commented on GitHub (Aug 27, 2024):
That's me
@georgemoralis commented on GitHub (Aug 27, 2024):
ok , in future we can also maybe doing user/config/cusa00000.toml for game specific settings
@kiwidoggie commented on GitHub (Aug 30, 2024):
I'm currently working on something for this, hopefully going to have a PR soon
@DanielSvoboda commented on GitHub (Feb 5, 2026):
Would this look too visually cluttered on the debug screen, or would a new tab be needed just for this? with 'recommended modules' alongside 'other modules'
*This is just a draft in Qt; the logic isn't fully developed yet.
@StevenMiller123 commented on GitHub (Feb 5, 2026):
I think it would be better if the two module lists were small enough to fit onscreen without scrolling the main tab (then have a scroll bar for the recommended list).
@StevenMiller123 commented on GitHub (Feb 5, 2026):
I'd also probably recommend ditching any idea of an "other modules" section, since we're going to end up seeing a lot of people enable all those, then complain because their games "regressed".
If there's anything I've learned here, it's that no amount of warning labels is enough to stop the people who don't like reading 😅
@red-prig commented on GitHub (Feb 5, 2026):
Is it possible to add some kind of magic keyboard shortcut that turns on visible developer options?
@DanielSvoboda commented on GitHub (Feb 5, 2026):
@red-prig "Developer options"? What exactly? In ShadPS4 we have Ctrl+F10, or is it something related to the PS4?
@StevenMiller123 So it would look something like this.
@red-prig commented on GitHub (Feb 5, 2026):
I meant that these options were not displayed in the GUI by default, but were activated by a keyboard shortcut, so that they would not be accessed accidentally.
@GHU7924 commented on GitHub (Feb 6, 2026):
As a regular user, I can say that these modules are completely unclear to me—what each module does and how it might impact the game. Therefore, I would say it's like opening Pandora's box. I agree that users will simply start switching these modules without a clue, simply by reading guides from equally clueless people (this can't be ruled out). Therefore, at a minimum, this should be added not to the general settings, but to the specific ones, or even better, to the debug menu (by the way, there's already a list of modules there).
P.S. Sometimes users complain about game performance (for example) and might send a log, but then it turns out they have something enabled that affects performance, and they don't even know it. So it's better to be a little more careful with such serious changes and hide them a little further than necessary.
@DanielSvoboda commented on GitHub (Feb 6, 2026):
@GHU7924 System modules in shadPS4 are like factory departments (audio, video, json...). Games ask these departments for help.
The emulator can use the original PS4 department (.sprx) or a recreated one that only imitates what the original does.
Example (Ngs2): The audio department. When a game needs sound, shadPS4 uses the original PS4 audio module libSceNgs2.sprx.
There are hundreds of modules. Some are not used because their behavior was recreated in the emulator.
For example, when saving a game, the original modules are not used, because this behavior was recreated and adapted for PC: save data must be stored in a PC folder and does not need to behave exactly like on a PS4.
@GHU7924 commented on GitHub (Feb 6, 2026):
@DanielSvoboda Yes, thanks for the clarification.
That's roughly what I assumed, but I meant it should be something limited. I see that you've only included the core modules, as per the Wiki, but it would be better to move this to the per-game settings, i.e.,
Game-specific Settings...Also, perhaps we should replicate something similar to what we have for Vulkan layers, so that it's an intentional action, rather than the user seeing the checkboxes and just toggling them. Otherwise, I'm not against this implementation; it could indeed be useful, but then we need something like adding information about the impact of modules to the game compatibility list, such as disabling a specific module will help improve performance. The emulator has a fairly large user base, so a little more needs to be done to prevent developers from wasting time on repetitive answers and questions out of simple user curiosity, like, "Why do you have this enabled or disabled?"
@mavethee commented on GitHub (Feb 6, 2026):
I would say leaving it in general works for me, but again end users have to stick to settings game needs (and they probably wont most of the time). I wouldnt hide it in Debug, maybe adding Advanced tab for things like this?
@georgemoralis commented on GitHub (Feb 6, 2026):
at the very least this should go to experimental features , and should be game specific .
@GHU7924 commented on GitHub (Feb 6, 2026):
This should be hidden from regular users, so I agree with georgemoralis about the experimental tab and game-specific settings.
In terms of tabs, everything is fine, but if we were to add a new one, then personally I would add a second Path tab to separate game content (games, add-ons, mods...) from emulator settings (save locations, system modules, fonts, etc.). But this is my personal opinion, and I don’t know whether the developers share it.
In my opinion, this will look fine, judging by the sketch: