Hiding specific additional applications in BigBox by single game: Is it possible?”

sbaby superbaby reporter

Update :

‌

First of all, it is important to distinguish between LaunchBox and BigBox. In LaunchBox, I think everything is perfect as it is, because it is more of a management system, while BigBox I see as a real gaming station, similar to a console, so controllable mainly by controller or integrated into an arcade cabinet. This means it has to be user-friendly and intuitive, even for those who are not very familiar with the system, such as children or other family members. I cannot always be the one to handle any problems that arise when someone accidentally starts an additional application that should not be selectable in BigBox.

In LaunchBox there are no problems, but in BigBox the additional applications could be confusing, as a user might mistake them for alternate versions of a game. This could ruin the gaming experience and, in some cases, cause malfunctions, forcing me to take action. I think this is an important issue that deserves to be reviewed.

Therefore, I am referring to specific cases where I would like to hide the application in BigBox, because it does not make sense to make it visible. BigBox has the ability to manage additional applications to start other versions of games, such as versions from other regions or revisions, and that is great. Additional applications also make sense in 80 percent of contexts, and it is fine for them to be visible in BigBox, but in certain special cases they should be neither visible nor selectable, because they could compromise the use of the frontend.

In the first case I mentioned to you a while back, unfortunately I don't remember exactly which game were referring to, but it was probably a situation that required an automatic mouse click to start the game in full screen or to get the focus. I don't remember exactly, but the concept can be extended to many other situations, so I'll give you more examples.

A classic example: the use of JoyToKey for controller management of some old and rare game that does not support joysticks, with two scripts: one to activate JoyToKey before starting the game and one to deactivate it when closing the game. If a child, seeing JoyToKey as an option in BigBox, started it manually without then starting the game, the controls would be defeated because there would be no way to properly deactivate JoyToKey. This would cause confusion and a negative navigation experience in Bigbox with wrong buttons.

You might suggest that I integrate JoyToKey into an AHK script that also includes game launching, and you are right: for example, for DemulShooter games, I do it this way. Game execution for LaunchBox is done through an AHK script, not the EXE of the game, and this script handles everything. However, there are cases when it is preferable to use the additional applications, such as when you want to configure something only for certain games that use a specific emulator in LaunchBox. In these cases, you cannot set up an AHK as an executable, because you have to keep the extension associated with the emulator. So the best solution is to configure an additional pre-game and post-game application, but it does not make sense for these to be visible or selectable/startable via a choice in BigBox.

Another reason why it is sometimes not ideal to use AHK as an executable is that BigBox struggles to handle it as a process, especially when it involves multiple processes, as is the case with Steam. This can compromise focus or pause management, but we are getting off the main topic here.

Back to us: another example is a pre-game script that synchronizes saves between Switch emulators. This script, too, has no reason to be visible or bootable in BigBox, since its purpose is purely functional and related to starting the game.

Another case concerns an additional application that starts for some adult MAME games and requires a password to be entered before startup. It makes no sense for this application to be visible as an option in BigBox, since it is not functional on its own. The password prompt is already handled perfectly via an AHK script set up as a pre-game application, which waits for the script to finish before starting the game. It works perfectly, so I don't see why it should be shown as a separate choice in BigBox, much less bootable on its own.

‌

You can watch a video in operation here :

https://forums.launchbox-app.com/topic/86235-passwords-for-games/#comment-474362

I could give many more examples, but the concept would remain the same: there are many situations where additional applications are critical to the gaming experience, but they should not be visible or manually accessible in BigBox, as this could be confusing and detract from the proper use of the system. I hope I have been clear on this point.

Basically : I believe there is a conceptual error in the handling of additional applications in BigBox. To make it clearer, I have prepared some pictures and considerations that can help you understand the problem and find a quick and easy solution.

In summary:

‌

In case 1: The additional application should be visible and bootable, so in this case the current behavior is correct and should not be changed

‌

In cases 2, 3, and 4, however, it makes no sense for the application to be visible or selectable in BigBox, since it is already started automatically. In fact, it should not be possible to start it separately.

‌

In conclusion, I think there are 3 possible solutions:

Give the ability to hide specific applications in BigBox.
Keep the applications visible as they already are, but without the ability to start them manually
It would be useful to develop a clear distinction between manual and automatic modes. In particular, if a user selects an additional application in automatic mode, he or she should not have the option to start it manually.

I hope this informations will help to better clarify the issue and I am always available to provide further details.

Thanks again for your time and the team's support!

2024-09-17T11:41:46+00:00

Comments (2)

brian
- changed status to open
- 2024-09-12T13:32:19+00:00
sbaby superbaby reporter
Update :

‌

First of all, it is important to distinguish between LaunchBox and BigBox. In LaunchBox, I think everything is perfect as it is, because it is more of a management system, while BigBox I see as a real gaming station, similar to a console, so controllable mainly by controller or integrated into an arcade cabinet. This means it has to be user-friendly and intuitive, even for those who are not very familiar with the system, such as children or other family members. I cannot always be the one to handle any problems that arise when someone accidentally starts an additional application that should not be selectable in BigBox.

In LaunchBox there are no problems, but in BigBox the additional applications could be confusing, as a user might mistake them for alternate versions of a game. This could ruin the gaming experience and, in some cases, cause malfunctions, forcing me to take action. I think this is an important issue that deserves to be reviewed.

Therefore, I am referring to specific cases where I would like to hide the application in BigBox, because it does not make sense to make it visible. BigBox has the ability to manage additional applications to start other versions of games, such as versions from other regions or revisions, and that is great. Additional applications also make sense in 80 percent of contexts, and it is fine for them to be visible in BigBox, but in certain special cases they should be neither visible nor selectable, because they could compromise the use of the frontend.

In the first case I mentioned to you a while back, unfortunately I don't remember exactly which game were referring to, but it was probably a situation that required an automatic mouse click to start the game in full screen or to get the focus. I don't remember exactly, but the concept can be extended to many other situations, so I'll give you more examples.

A classic example: the use of JoyToKey for controller management of some old and rare game that does not support joysticks, with two scripts: one to activate JoyToKey before starting the game and one to deactivate it when closing the game. If a child, seeing JoyToKey as an option in BigBox, started it manually without then starting the game, the controls would be defeated because there would be no way to properly deactivate JoyToKey. This would cause confusion and a negative navigation experience in Bigbox with wrong buttons.

You might suggest that I integrate JoyToKey into an AHK script that also includes game launching, and you are right: for example, for DemulShooter games, I do it this way. Game execution for LaunchBox is done through an AHK script, not the EXE of the game, and this script handles everything. However, there are cases when it is preferable to use the additional applications, such as when you want to configure something only for certain games that use a specific emulator in LaunchBox. In these cases, you cannot set up an AHK as an executable, because you have to keep the extension associated with the emulator. So the best solution is to configure an additional pre-game and post-game application, but it does not make sense for these to be visible or selectable/startable via a choice in BigBox.

Another reason why it is sometimes not ideal to use AHK as an executable is that BigBox struggles to handle it as a process, especially when it involves multiple processes, as is the case with Steam. This can compromise focus or pause management, but we are getting off the main topic here.

Back to us: another example is a pre-game script that synchronizes saves between Switch emulators. This script, too, has no reason to be visible or bootable in BigBox, since its purpose is purely functional and related to starting the game.

Another case concerns an additional application that starts for some adult MAME games and requires a password to be entered before startup. It makes no sense for this application to be visible as an option in BigBox, since it is not functional on its own. The password prompt is already handled perfectly via an AHK script set up as a pre-game application, which waits for the script to finish before starting the game. It works perfectly, so I don't see why it should be shown as a separate choice in BigBox, much less bootable on its own.

‌

‌

You can watch a video in operation here :

https://forums.launchbox-app.com/topic/86235-passwords-for-games/#comment-474362

I could give many more examples, but the concept would remain the same: there are many situations where additional applications are critical to the gaming experience, but they should not be visible or manually accessible in BigBox, as this could be confusing and detract from the proper use of the system. I hope I have been clear on this point.

Basically : I believe there is a conceptual error in the handling of additional applications in BigBox. To make it clearer, I have prepared some pictures and considerations that can help you understand the problem and find a quick and easy solution.

In summary:

‌

In case 1: The additional application should be visible and bootable, so in this case the current behavior is correct and should not be changed

‌

‌

‌

In cases 2, 3, and 4, however, it makes no sense for the application to be visible or selectable in BigBox, since it is already started automatically. In fact, it should not be possible to start it separately.

‌

‌

‌

In conclusion, I think there are 3 possible solutions:
1. Give the ability to hide specific applications in BigBox.
2. Keep the applications visible as they already are, but without the ability to start them manually
3. It would be useful to develop a clear distinction between manual and automatic modes. In particular, if a user selects an additional application in automatic mode, he or she should not have the option to start it manually.
I hope this informations will help to better clarify the issue and I am always available to provide further details.

Thanks again for your time and the team's support!
- 2024-09-17T11:41:46+00:00
Log in to comment