stigzler

Good catch.

Finally braved the Invision Community setting to auto-follow content I post! Thanks for the reply, Joe. Yeah - it's all a bit baffling. Just realised that the Default theme references libraries in it that don't event exist (now?) in the Core folder. For example, there is no Unbroken.LaunchBox.Windows.Transitions dll, but the (working) defualt theme references it? Bizarre. I'm really just trying to find a way to display just the panels and manipulate things like borders, backcolors etc. Really not even a need for placeholders as you'll be able to figure out from the page you're editing what is what. However, as it stands, with 85 errors just on one page (seemingly mostly because of failures to resolve the references) not sure about commenting all these out of every page. Screenie illustrating these points: I'm guessing the default theme was designed at a time when these references were live - that's why I was wondering if just setting up a dummy environment (with a dummy folder structure for the old dlls in a Core Dir two levels below where putting the Default theme for development - i.e. NOT developing inside the Launchbox folder) would be sufficient to at least remove all the errors and at least render a preview (of the panels and basics). I wouldn't expect it to build, just seeking to use the preview function. Given BigBoxTheme.csproj points towards these: <Reference Include="BigBox"> <HintPath>..\..\Core\BigBox.dll</HintPath> </Reference> My hope was just nabbing the old dlls would be sufficient. Nemmind. I DO like the default theme, but just looking to tweak it with a splash of color to match the theme of my build. Thanks anyway.

I've returned to this after giving up a while ago. I'd prefer to do theme editing in VS as I'm familiar with WPF. However, there's an issue with the references which prevents any xaml previews from being built. Not fussy about placeholders for things like carousels, but would be helpful to see panels, border colors etc. So, the project file for default.csproj lists references as: <ItemGroup> <Reference Include="BigBox"> <HintPath>..\..\Core\BigBox.dll</HintPath> </Reference> <Reference Include="Caliburn.Micro"> <HintPath>..\..\Core\Caliburn.Micro.dll</HintPath> </Reference> <Reference Include="Caliburn.Micro.Platform"> <HintPath>..\..\Core\Caliburn.Micro.Platform.dll</HintPath> </Reference> <Reference Include="LaunchBox"> <HintPath>..\..\Core\LaunchBox.dll</HintPath> </Reference> <Reference Include="System.Windows.Interactivity"> <HintPath>..\..\Core\System.Windows.Interactivity.dll</HintPath> </Reference> <Reference Include="Unbroken"> <HintPath>..\..\Core\Unbroken.dll</HintPath> </Reference> <Reference Include="Unbroken.LaunchBox"> <HintPath>..\..\Core\Unbroken.LaunchBox.dll</HintPath> </Reference> <Reference Include="Unbroken.LaunchBox.Plugins"> <HintPath>..\..\Core\Unbroken.LaunchBox.Plugins.dll</HintPath> </Reference> <Reference Include="Unbroken.LaunchBox.Windows"> <HintPath>..\..\Core\Unbroken.LaunchBox.Windows.dll</HintPath> </Reference> </ItemGroup> VS is unhappy with most of these. There seems to be a variety of issues. Some dlls are just missing from Launchbox\Core (e.g. Caliburn.Micro.dll) whilst some are in incompatible versions (bigbox.dll is presently .NETCoreApp,Version=v9.0 from .netpeek whilst the theme proj is built on .net Core 3.1 - copilot says these are incompatible?). My question is this - is there any way of getting hold of these 'older' libs (I'm assuming the default theme was built from a specific version of launchbox with the specific file in Core referenced in the theme.csproj). It would essentially just be an older build of LB but I could find anywhere to download historic versions (I know updates are stored in a folder, but I'm suspecting the specific build likely pre-dates my install of a few months ago). It would be super handy if a 'pack' of the required dlls were avaiable to help theme development. I could be missing something crucial of course...

Oooo nice - dynamic Marquee! What software you using for that?

Just a quick note to say well done, chaps. You're wrangling this majestic beast like it's a simple house cat. 👍 (Especially after this recent update! To make an omelette, you gotta break a few eggs, right?)

Amended with humility and contrition...

Oh bloody hell, you did. My apologies. (Will add some chalk to his worm dinner)

(cheers that did it. I'm going off to eat some worms now...)

It would be best to create your own, project specific thread here: https://forums.launchbox-app.com/forum/85-third-party-applications-and-plugins-development-and-beta-testing/ That way, discussion will be limited to your app. Will certainly take a look when it's up and running.

I don't run yuzu, but I do Citron (a derivative, I believe). In instances like this, I'd just cut out the GUI entirely and alter the config files (make sure you back up any existing first). There're two in Citron that may be relevent: user/config/qt-config.ini and user/config/input/default.ini (this may be the fall-back mapping so try the above first). in qt-config, you'll find: player_0_button_a\default=false player_0_button_a="engine:sdl,port:0,guid:030000005e0400008e02000014017801,button:1" player_0_button_b\default=false player_0_button_b="engine:sdl,port:0,guid:030000005e0400008e02000014017801,button:0" player_0_button_x\default=false player_0_button_x="engine:sdl,port:0,guid:030000005e0400008e02000014017801,button:3" player_0_button_y\default=false player_0_button_y="engine:sdl,port:0,guid:030000005e0400008e02000014017801,button:2" You'll also see "player_1_button [etc]" in the same file. Just copy the working first controller, edit separately replacing 0's with 1's and paste over the existing player_1 entries. 🤷 Untested, but just an idea. The other thing to check is how you're interfacing your physical controller with your PC. The picture would seem to imply that two separate controllers are being given the label "XBox One controller 0" - thus, the emu is going to see them as one and the same controller giving you the behaviour you're experiencing. Do other emus see them as 0 and 1? If not - it's a mapping problem, bnot the emu's problem. Joy.cpl (in win search) may be a good starting point.

This may be useful to other amateur coders like myself for making plugins. The problem: You have different classes which implement the interfaces with the Launchbox Plugin system (e.g. ISystemEventsPlugin, IGameLaunchingPlugin, IGameMenu). You want to unify these events into a single 'entry point' for your plugin's application (e.g. you may need to receive results from the different plugin interfaces in a single class or return results form a centralised point). The issue is, when events fire, they fire in the instance created in Launchbox, not in any instances that are created with your plugin. Thus, even if you create an instance of the class you've authored which implements the interface, you will not receive the events. The solution: A Singleton Class I had a bit of knowledge about singletons, but not really how to apply them. However, this is just the ticket. The way I think about them for this application is that it's almost like a static class, but you can have class members outside of any methods. Clearly, each plugin interface class cannot know about each other, thus cannot share a common instance of a class. You cannot use a static class for obvious reasons. Thus, a singleton saved the day. It kinda instantiates itself the first time it is referenced (that is you don't have to instantiate it anywhere) and all other references to it in any class will end up only refencing that one class instance. It's also thread safe. It's a little hard to explain, but there's a good video here: So - the code I hear you cry? Your 'entry point' singleton: internal sealed class PluginController { private PluginController() { } private static PluginController _instance = null; private static readonly object _padlock = new object(); private Guid Guid = Guid.NewGuid(); internal static PluginController Instance { get { lock (_padlock) { if (_instance == null) { _instance = new PluginController(); } return _instance; } } } internal void SystemEventRaised(string eventType) { Logger.Log($"[{Guid.ToString()}] System Event received: {eventType}"); } internal void SystemMenuItemSelected() { Logger.Log($"[{Guid.ToString()}] System Menu Item selected"); } } The GUID is just there to show you that it's the same instance when referenced from other classes. Obs, you'll need to use Debug.WriteLine or something instead of my Logger class. Examples of the plugin interface classes: internal class SystemEventsPlugin : Unbroken.LaunchBox.Plugins.ISystemEventsPlugin { public SystemEventsPlugin() { } public void OnEventRaised(string eventType) { Logger.Log($"Received event: {eventType} on thread {System.Threading.Thread.CurrentThread.ManagedThreadId}"); PluginController.Instance.ProcessSystemEvent(eventType); } } and internal class SystemMenuItemPlugin : PluginHookBase, Unbroken.LaunchBox.Plugins.ISystemMenuItemPlugin { public SystemMenuItemPlugin() { } public string Caption => "Your Plugin"; public System.Drawing.Image IconImage => Gearbox.Presentation.Properties.Resources.icon; public bool ShowInLaunchBox => true; public bool ShowInBigBox => false; public bool AllowInBigBoxWhenLocked => false; public void OnSelected() { PluginController.Instance.ProcessSystemMenuItemSelected(); } } What you will notice with SystemEvent is that it's sent from numerous different threads, but the Singleton seems to be reasonably thread agnostic. Anyways, I'm sure there are software engineers on here who can rip this apart, but for all you other code grifters like me - hope it helps. P.S. Sorry to those of you viewing in dark mode + the poor syntax highlighting colors - nothing I can do about that- it's about how it's set up at LB's end.

Yeah - had trod that path already. writeconfig is set to 0, although weirdly, cfg files for individual games are still being created. I am using bgfx, so wondering whether if it's something to do with that. I did get vertical.ini working via: aspect 4:3 keepaspect 1 🤷Dunno what the Musk is going on there. Given this small victory, I tried applying the same logic to horizontal.ini setting aspect to 3:4 and then once that made no difference to 16:9 (which also made no difference). wtf, mame? Totally unintuitive, inconsistent and infuriating. Still, we're not allowed to criticise the big M! Have attached relevant config files in case there's any Mame wizards out there. mame.ini horizontal.ini vertical.ini default.cfg

Well done, chaps. 🎂 Looking forward to seeing where you guys take it next.

0.9.9.0 - Beta [Improvements] Improved UI - now fully suited to windows surface/tablets and touch controls [Feature] Added ability to set URLs, local applications and notes against each Platform. For example, on selecting a Platform, you can open a link to your rom source, run an associated application (e.g. NPS) and view notes (e.g. which rom extension is best suited to your setup). File link in original post. Pic: (P.S. It'd be nice if anyone who's downloaded this could provide some feedback so I can know whether to take this out of Beta or not!)

No worries - likely something deeply esoteric. 😟