damageinc86

hmmm. should be as simple as running the mame import and pointing launchbox to the rom file folder within your mame folder.

Like I said before, you don't have to use that file structure if you don't want to. You can drop all of the artwork you download on your own into the main artwork folder of the system (LaunchBox\Images\Nintendo Entertainment System\Box - Front) for example, and that's it. There shouldn't really be any gaps in the Sega Genesis, so that's odd. Seems to be a very well covered system. Unless you have some image files that are named differently than the game name within launchbox. You also don't have to leave things how launchbox named them. There are a few tricky games that I've preferred to be named slightly different than what the Launchbox database insists it should be, just out of personal preference. So once I downloaded the metadata for that and had a blank entry like you do there, I went into the metadata area again and updated the title to what my image file and rom name is, ok'd the change, hit F5 on the selected game, and voila, my Box Front image I already had showed up since it was in the folder. Case in point actually, since I wanted to revisit my genesis box fronts after seeing your screenshot there. I noticed I had an old set and just searched for a higher quality one off emumovies and snagged it. Arch Rivals had the "arcade game" end to the name in launchbox, but the new image I just downloaded did not. So going through right now and re-naming a few. Also, for some reason my romset, that I've had for years, includes some Euro and i suppose World games. So I had to bring back a few of my old box front images into the folder to have those populate again, since this image set I just downloaded does not have those. But like, for Austrailian Rugby, or some Asterix Euro game, I did not go put those images in the World folder or Europe folder. I just plopped them right in the main folder. they populate just the same.

Oh, now I'd be interested to hear what things you were thinking of working on for the RL->LB connection. I can't let go of RL just yet, because for my needs, it still does a few things that LB won't fully engage in, or flat-out doesn't do.

I'd be curious what databases are incomplete in comparison? and the RL connection might require you to go through the systems once more and duplicate the settings you have now for the Hyperspin entry, if you want things exactly the same, as I'm sure you do. I feel like just because you think it should be done different doesn't necessarily mean that you shouldn't "bite the bullet" so to speak, and just get in there and get the conversion done. It's like putting a manual transmission in an automatic car. You need to fabricate some connections and working paths, but once they are made, it drives how it is intended to.

Between emumovies and the artwork packs that we've all made and contributed to the downloads section, you've got all the artwork covered really. The work is basically already done on the artwork front, as we've all renamed everything by now. It's ready to be dropped into the folders. I think being worried about the few regional folders that LB has in place is a little overkill. I never use them on purpose, but LB sometimes does put things in there when I download from within LB's metadata section. But really,...it's not that big of a deal. And if you drop artwork you've manually downloaded into the folders, it will all stay in the main folder. I've noticed that artwork only goes into those regional folders if it was downloaded from within the LB metadata artwork area. I came from hyperspin over 10 years ago, when Launchbox (Jason) had just figured out how to get a "wheel" display. Once the initial work was done, there really wasn't any reason to keep hyperspin. I gave it a while, but eventually I needed nothing from my hyperspin folders and finally hit the delete button. Haven't even needed to think about going back since then. I find the LB/RL connection to be great, and have kept using it, even with LB's attempts to integrate some of RL's features (Pause, loading screens). I feel that RL still does it better, and it is definitely needed for the keymapping. All i've ever had to do for system/platform creation is create my custom system in LB, set RL as the emulator, shut down LB, then go to RL and see the new system, and edit to preference. As you mentioned, the launching is then off-loaded to RL. Basically, just accept that you have to set up things in LB, so that LB is under the impression it knows where everything is and will be handling it, and thus presents it all correctly, regardless of RL ACTUALLY handling the launching. This is how they got around everything. To have LB stop what it's doing at the point of launch, because RL is set as an emulator, so LB just lets the "emulator" do it's work. As for the databases, you don't really need to think in terms of those xmls that we got used to in hyperspin anymore. Ditch that mindset and let LB do the database creation that it automatically does once you create a system via import, or otherwise. It handles that. Which is one of the biggest points of LB in the first place. Just get your roms all situated, which they probably still are, and run an import. You can even name the system something non-standard, but use the "scrape as" feature to tell LB to pull the metadata and artwork from the system set under "scrape as". Because if you use a non-standard name, by default LB might not see anything for it. But if you scrape it as another system, it might be able to import the correct items for it. All in all, the move to LB is well worth it. Just for the ability to be able to get rid of the need to edit those damn xml files manually or otherwise. It was always a hassle. And LB's internal database creation interface takes care of all that. I'd suggest don't lurk, don't wait, just set aside some time and get all the artwork packs from the downloads sections, link your emumovies account, go on an importing rampage, and take the plunge.

Yes, that and 360, etc., are still RATHER new compared to the rest in terms of emulation status. Still barely playable for most of us. The lifetime sub has taken care of over 90 percent of my collection over the last 10+ years that I've had it. You might be the one to spearhead the captures for these systems. Sometimes you just gotta do it yourself.

I'm just going to say that it took yeeeaaaarrrrrrrssss for Emumovies and everyone involved in the community to take care of the systems that are taken care of. xbox and up is still rather new to expect the entire sets to be taken care of. Sometimes it just takes one, or a few determined individuals to just do it and get it done and uploaded there, so everyone can enjoy it.

another comment on the bitbucket issue, which has 4 duplicates. I know it's still classified as minor, but I think it is an issue that on principle alone should just be addressed. Ezra Adding to this one because I go back and forth between controllers based on what games I intend to play. For example: If I play any PS2 / PS3 games, I usually am using a Dualshock 3 controller I use a separate controller for most Nintendo games I default to my Dualsense for most other games So at minimum I’m in a fairly consistent rotation of 3 controllers. Since the mappings are currently only configurable globally, I have to remember that circle is select and X is back on my Dualsense, but then Circle is back and X is select on my Dualshock. Additionally shortcuts, like closing the game, are going to be mapped differently per controller. I absolutely love Big Box for all that it does for combining emulators and storefronts, but I feel this is the one major pain point that really needs an overhaul to make the user experience excellent.

If you want to try an anydesk call someday I can attempt to walk you through some setup stuff If you'd like.

I just went ahead and uploaded all of the boxes I scanned during my GBA front box art project. https://archive.org/download/planet-monsters_202410

I have a hi-resolution scan of this box front if needed.

There are a lot of community made banners in this thread: https://forums.launchbox-app.com/topic/54534-bannerbox-community-banner-thread/

Yeah, I think that the point is for it to all be self-contained within launchbox. For the usability of launchbox to be buttoned down right out of the box vs. making the user have to set up an entirely different program just to tell launchbox that 3 controllers that launchbox can easily recognize already, need to all point to the same function for navigating launchbox. I understand not wanting to do the work when technically other programs exist. However, it seems odd to leave this one out, because A. there are so many other random features that are put into launchbox that are pretty out in left-field so to speak, B. It's never going to NOT be an issue, for any new user, and any long-time user, and C. Launchbox already sees all the controllers and is able to map at least once to apply to all controllers, so it's halfway there already. Why not have the mapping for Launchbox's internal navigation just go one step further than it does in order to create a simple, finished user experience within the program? Normally, it wouldn't be an issue, but because of the nature of the community (emulation), people will often have at least a few different controller styles. With development crossing over the 11 year mark and going strong, more than exceeding all of our expectations quite amazingly, I still feel that this is something completely glossed over, and adding that last piece of controller navigation to that option would do nothing but enhance the user experience. Especially users who just want to pick up any one of their controllers and navigate through launchbox without having to set up yet another external program just for one aspect of the program.

Are there any plans to consider the Launchbox navigation keybinding and it's mapping features? I.E., Allowing users to map launchbox navigation control sets to each one of their controllers? This would allow people to pick up any controller and be able to use the same button (because they mapped it) to perform a navigation action, even if that face button is different (A on xbox controller vs. B on switch controller). Navigation is one of the first usability issues that people encounter when using a program, and it would be extremely helpful for us to be able to map our navigation actions to each controller individually, regardless of what their face button labels are.