Jump to content
LaunchBox Community Forums

stigzler

Members
  • Posts

    115
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

stigzler's Achievements

32-Bit GPU

32-Bit GPU (5/7)

41

Reputation

1

Community Answers

  1. Great response, thanks retrogirl. I suspected from looking at the files that it would be constructing the folder structure right with the right files in etc. Just started expanding my C64Dreams Importer to automate this process. It's the edge cases that'll get me (all the bats and vbs' looked the same, for example - but I bet there are edge cases that require different code somewhere). I know @Zombeaver is super busy so likely doesn't have time,. but if anyone knows these edge cases let me know!
  2. Does anyone know how to add your own C64 games to this collection. I'm guessing you add it to the C64Dreams/Games folder, but given they all seem to follow a cutom format (with a folder for each game and also other bat files etc) - I didn't want to do this via Launchbox Import File process as it asks for an emulator etc. Search on this long topic wielded too many results to be helpful.
  3. Annyywhooos... Just revisited this @Zombeaver + again - fab bit of work. Installing it on my 'final' emu machine. I've had a poke around as I'm trying to dovetail C64D's controls with those I've globally configured across all other retroarch systems. Is there any way to choose a different hotkey? I'd like to change it from Back to [what is essentially] the Guide button (long story short PS4>DS4Windows>Xbox Controller). Route irrelevant: shows in retroarch as button 10 rather than button 7 (Back). Changing it in C64D retroarch doesn't change the hotkey. I notice you have some AHK scripts working alongside other utility apps, so rather than guess what's inside the black box, thought I'd ask first! Unfashionable of me, I know! Also had a quick search on this topic - couldn't find anything - although it may be buried deep in the details somewhere. EDIT: Nemmind - found it - you do this via C64Dreams/Configurator.exe>Config Editor.
  4. Hi all. Just checking whether this is possible through LB natively before I go down a rabbit hole of coding this. I have an old console shell fitted with a PC and a LB installation. I also have a server full of roms. Given file sizes for the later generations and limited space (2TB) on the unit's SSD, I'm looking to have a mixture of local roms (e.g. Soul Calibre and Crazy Taxi for dreamcast) and also importing full sets from my server. So, in this example, the full DC set would be available when the unit's plugged into my home network, but when not networked (or in another home) only Soul Calibre and Crazy Taxi would be available in LB/BB. I've tested this, and unfortunately the network roms are still visible in LB when it is detached from the network. I'm just checking whether there are any settings I'm missing which would make the network roms invisible when unit's not attached to the LAN? Failing that, any thoughts on the best design approach for a plugin? I'm currently developing one that already has the facility to monitor all LB/BB actions and has the ability to augment LB functionality via individual platform setting etc. My first thought would be via leveraging the "hidden" property in the roms - that is have a setting in a plugin that registers the root of your network roms and at an event (e.g. change of selected platform event), see if this network location is available. If not, go through each rom in the local db, making them hidden if they are on the network location. Only drawback is if you were to set a game to be hidden in all scenarios (but could work around that by having a per-game setting in my plugin to make it hidden no matter what). I haven't really looked into the LB/BB views objects in the plugin API - but guess that's also a possible approach (and possibly better given I wouldn't be messing with the db entries and it may be quicker) Would welcome thoughts (+ hopefully a simple box I can tick in LB natively to do this all for me!)
  5. Thanks for this. Having tried no end of other approaches (involving a dummy emulator, launch application before etc) this is by far the easiest way to achieve this.
  6. Nice work brother - exactly what I needed. I did try to distinguish between the user or windows awakening the PC as also wake @ 3am on a Sunday to do updates, but couldn't find a way to do it. I'm just hoping my AV amp doesn't turn on when it senses the PC waking up else I'm going to hear the BB launch video at full blast early hours of a Monday morning! I wouldn't hold your breath for the LB team fixing issues like this. They seem to struggle with the 'smaller' issues.
  7. Can also confirm this. Problem is lunchbox side. 2.5 years later and still no fix?
  8. Hey. Just to contribute. I often had the same problem during development of a plugin and testing. From exploring files on my test machines and from Jason's posts here, I think it has to do where there are competing .dlls between those in Launchbox/Core and any plugins or possibly themes (or anything that uses its own individual dlls). Often for me, it occurs when my plugin uses dlls that are also used in launchbox and those in my plugin directory are more current than those in laucnhbox (i.e. launchbox likely requires an update). In short: if you're having these errors, ensure Launchbox is updated first. Then you can manually compare the dll referenced in the error message to any in the Launchbox\Core directory. If the Launchbox version is older, then that might be your problem.
  9. I'd probs raise a separate post with a few more details.
  10. God that was bloody horrible. Never make me do that again.... 12 hours straight and finally upgraded about 7 different projects to .net 9. To be fair to M$ - their Upgrade tool is really good. The hassle came from resolving references and fixing breaking changes in .net 9. Curses! I know I'm going to be finding bugs for a while yet.. Goodbye Framework - you served me well, but like an ex-wife - don't think I'll be visiting for tea again any day soon. So yes, in conclusion, upgrading to .Net9 solves this issue. However, if you've got any kind of complexity (read: multi-local library, old platform etc) make sure to bring a 4-pack of patience.
  11. Thanks Joe. God I've got a horrible feeling this is going to go really, really badly.
  12. Cheers dude. @JoeViking245 has suggested referencing LB/Core/Drawing.Common - so need to find a way to try this first as my plugin is v complicated (5 projects + leveraging some potential framework only features) - so if Joe's suggestion works this would be the preferable path rather than the upgrade. However - is there a "reverse" upgrade option? The Framework/Core/.net transition is one I've never braved!
×
×
  • Create New...