Option to hide an additional application in BigBox

[Sbaby]

Is it possible to hide certain additional applications ? not all...

For example, I have an application that makes a mouse click when I start a game, it serves at start-up, but I don't need to see it in BigBox, if one of my children clicks on it, an unnecessary click starts

[Sbaby]

Unfortunately, I have not received any response and am still looking for a solution. 

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

 

I have created an official request here, please vote for it as soon as it is confirmed by the staff

https://bitbucket.org/jasondavidcarr/launchbox/issues/9185/hiding-specific-additional-applications-in

 

Edited August 28 by Sbaby

[Sbaby]

I'm not asking out of arrogance, but simply to understand better: could you please clarify why my request has remained in the 'Submitted' status for the past five days? 🙄

 

Thanks 

[AstroBob]

Hi @Sbaby hope you're well and apologies you haven't received any follow-up here. Just to let you know I'm going to look into this with the team, and will follow up on your request and also the ticket submission.

Please allow me some time to get some clarification here, but I just wanted you to know that we're looking into this and will get back to you as soon as possible.

Appreciate you bearing with us here

[Sbaby]

Hi @AstroBob, thanks for the update!

No problem, I'm happy to wait while you take a look, talk to you when you have more information.

Thanks again for keeping me informed

[AstroBob]

Hi @Sbaby

Thanks for bearing with me here.

To answer your question regarding the ticket status, there have been some changes to the way tickets in BitBucket are handled. Previously, upon submitting the ticket, you would instantly see it. However recently the team had to put changes in place that require the ticket to be reviewed and opened on our end before you would see it. This was implemented due to a large amount of spam flooding that inbox, and to allow the team to review and clean up issues such as duplicates. It's still a far-from-perfect system, and we have plans to completely overhaul how the BitBucket works to allow users a much more transparent and useful way to vote on features.

That said, for now, you should be able to see your issue as open. For full transparency, I can say that the ability to hide individual alternative apps is not something that we are actively considering.

That said, I'd love to learn a bit more about your specific use case. I realise the need to keep additional apps tidy, but I am curious as to the purpose of the mouse click additional app. If that additional app is used in BigBox, does the additional click interrupt any games from launching? And are there other instances where you would want to hide an additional app, or is it just for this specific use case? 

While it's not actively being considered right now, it would be great to understand the use case a bit more, and if possible update the BitBucket ticket so we have as much information as possible.

Cheers,

[Sbaby]

Hi @AstroBob

Thanks for your interest.

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 :

 

 

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.

In conclusion, I think there are two 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..

I hope this information is helpful to better understand my use case and, if possible, to update the ticket on BitBucket.

 

 

[AstroBob]

Hi @Sbaby 

Thanks for the detailed insight into your use cases here, this is very much appreciated and provides a lot more context for our team. Many thanks for also updating the BitBucket ticket so we can refer to this.

While I can't guarantee that this will be addressed, what's incredibly useful is the use cases you're describing. For example, the need to create an additional app to password protect a game, whereas that use-case would likely go away if we were to have the ability to password protect or implement a better way of hiding games (perhaps based on age rating or other criteria).

I really appreciate you taking the time to write this up, and while I understand it's frustrating as this is an important feature for you, we want to make sure we're solving it in a way that not only addresses a sub-set of use-cases, but a bigger problem at large. But again, really appreciate the lengths and detail you've put into this, it's logged on our end and we'll make sure to refer to this if it becomes a priority in the future.

[Sbaby]

5 hours ago, AstroBob said:

I really appreciate you taking the time to write this up, and while I understand it's frustrating as this is an important feature for you, we want to make sure we're solving it in a way that not only addresses a sub-set of use-cases, but a bigger problem at large. But again, really appreciate the lengths and detail you've put into this, it's logged on our end and we'll make sure to refer to this if it becomes a priority in the future.

Thank you very much for your response and for your appreciation of the use cases I shared. I would just like to point out that I would not want too much emphasis placed on the password protection case, as the other two cases I mentioned, and the several other cases I did not mention, are equally important and deserve equal attention.

Upon further reflection, I realize that, despite the length of my description, I may not have emphasized the main point enough: 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.

 

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 additional “quick” information will help to better clarify the issue and I am always available to provide further details.

I also updated the BitBucket ticket

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

Edited September 20 by Sbaby

[Jeffit]

You can usually hide specific apps in BigBox. Just go into the settings and look for the "Manage Applications" section. There, you can toggle visibility for apps you don’t want showing up. 

[Sbaby]

On 9/22/2024 at 5:28 PM, Jeffit said:

You can usually hide specific apps in BigBox. Just go into the settings and look for the "Manage Applications" section. There, you can toggle visibility for apps you don’t want showing up. 

That's not true. BigBox doesn't manage additional apps for each game separately. You're confusing it with the classic options. I'm talking about the ADDITIONAL APPS managed by LaunchBox, which are only visible in BigBox in the game details section, and only if they've been assigned. Otherwise, they don't show up at all. Take a look at the screenshots and video in this topic, and you'll understand.

Anyway : @JeffitSend us a screenshot of the menu you mean ...

Edited September 23 by Sbaby