Zombeaver

Thanks @EvoluZion3 glad you're enjoying it. It's always encouraging to hear feedback like that. If you actually rescraped them you shouldn't have. Many of the games don't have DB entries so it will incorrectly associate them with the wrong games if you do this. If you follow the instructions to import into existing libraries you shouldn't need to do this to begin with as you'll already have all the media and metadata for everything. If you specifically only pulled EmuMovies video clips and disabled any scraping of media or metadata from the LBGDB that would be okay.

Fair enough. Godspeed. I appreciate the effort and intent, I just hope you know what you're getting into is all. If you have questions my Discord is open, that would be a better place for this sort of thing. I know you didn't. But you do understand that most users are going to go in thinking that right? That's the reality of the internet. And when they use it, and it doesn't, my concern is that they won't even know what to report. They might not know what is missing or not working as intended - as evidenced by your own post, neither do you. I'm not trying to be harsh with that, so don't take it that way. I just have major concerns with this. I do like the idea of more people being able to use C64 Dreams but I don't like the idea of people getting an incomplete or substandard version of the experience that I've spent 6 years of my life creating. I don't think that's an unreasonable concern.

This isn't always an option. There are limitations to its implementation in .m3u form that aren't present for .cmds. You will break things if you do this across the board. .m3us and .cmds are both natively supported by retroarch-vice. You need to leave them alone. I did go back and check the public release for v0.60 and can confirm that Energy Manager and Ultima II m3us do have extra disks referenced, so apparently I fixed both of those in the current WIP at some point post v0.60 release. So no issues with those two. Well that's kindof my whole point here. There are multiple systems built on top of each other to achieve the end result. So when you start a project to ostensibly allow people to "Just use this and it will work" but you yourself don't know about all the systems that you're supposedly replicating, we have a problem. This project is absolutely chock full of bespoke solutions to various scenarios presented by individual games. You have games like Deus Ex Machina that were designed to be played in sync with an audio cassette so I have scripts and external software setup to play the cassette audio when the game starts, allows you to pause and resume as requested by the game, and change sides, while playing/without leaving the game. That's a single game. There are hundreds of one-off scenarios like this. I appreciate what you're trying to do here. I do. But I fear that you don't really understand the complexity of what you're getting into here, and the end result will be one of two things: A) you create a complete nightmare for yourself trying to address the one-off stuff that I'm talking about, likely for years or B) you hand wave it away (or more likely just don't know about it to begin with) and people that use this now associate my work with an end product that isn't representative of the intended experience. People can't report what they don't know about or don't understand to begin with - the entire point of this project is based on an understanding of the reality that most people don't know how to make this stuff work the way it should and so it's designed to remove that barrier for entry. That's achieved by taking an extremely hands-on approach to, essentially, everything. So the idea that someone with some pi handheld is going to know when or what to report to you when something doesn't work as is actually intended is a bit naïve in my view. It's well and good to say that it's "not on me" but if you'd received as many requests for support on, for example, Retroarch usage, as we have here on the Launchbox forums, you'd be as equally dubious about that statement as I am. It's never that simple.

This is erroneous. The existing contents of the m3u are correct. The ":boot" portion refers to a specific sub-PRG in the disk image: Any instances where this is specified it's needed and there for a reason. There are many instances where this is handled via the .cmd, but in cases where it's multi-disc it's done via the .m3u. In this specific case you'll literally never be able to play the game with the way you've changed it. The starting PRG allows you to set the trainers, then saves them to disk. Then you reset and load BOOT and the game starts. With what you have you'll be stuck in a perpetual loop of setting the trainers and never playing the game. The VICE Retroarch core reads specified sub PRGs in both .cmd and .m3u format, though the formatting is slightly different between them - quotes are used in .cmds but not in .m3us. Crystal Fever is an example of the latter. 2000 Kung-Fu Maniacs (below) is an example of the former. Any time these are specified they should never, ever, be removed. You will break games any time you do this. _________ That's already the contents of that .m3u, so I'm not sure what you're talking about here. _________ Once again, that's already the contents of that .m3u so I'm not sure what you're talking about here either. I'm not sure if you're using some old version of C64 Dreams or what, but there's nothing wrong with any of these. And in the first case the change you're making is incorrect outright. I appreciate you working on your project, it's definitely cool in theory, but I don't use any of the software you mentioned so I don't really have a way to confirm whether or not anything breaks as result of it so I can't exactly provide a complete endorsement here. I can tell you just in the limited scope of that issues page you linked that there are some problems here. Considering how much I end up using external (and Windows-based) software for things like manual swapping, custom controller mapping, custom SID music, etc. I would honestly be really dubious that this would be able to accomplish more than the most basic functionality.

In what context would this ever actually be an issue? I'm not aware of ever needing this for anything in the context of these games. I've never needed it in the course of testing anyway. Generally speaking the only thing you're going to use either one of those for in this setting is on their own to invoke some in-game function i.e. press C= to continue or CTRL to access a menu, etc. I honestly can't think of a single example where I've ever needed/wanted to hold one of them down and start continually typing for some reason. So if there's an actual use case for that, I don't know what it is even after testing nearly 4000 games at this point. If the contention is simply that "it's different", and not a needed usability/functionality problem, I'm not all that concerned about that to be honest. Confirmed. Looks like it's the result of a faulty auto-state. Go into the game's folder and replace with the contents of the attached file. Zork - The Undiscovered Underground.state.7z No, it doesn't. If that's occurring, it's something on your end that is causing it to do that. My suggestion would be to disable the Windows game bar inputs (or disabling it altogether). I have no control over whatever external software you're running on top of C64 Dreams that's designed to continually read inputs. If you have inputs for Nvidia Shadowplay, for example, that interfere, there's nothing I can do about that. Your software is going to do what you tell it to do. The only thing that F4 does in the context of C64 Dreams is (on its own) send an F4 input in-game or when combined with the combo key loads a savestate. Nice job on the keymap, minus the F4 thing. That's otherwise accurate. It's probably worth noting that all of the combo key functions minus the stuff on the numpad and arrow keys aren't actually specific to C64 Dreams though, those are just normal RA hotkey functions for those keys. You've covered pretty much all the relevant stuff there already though.

Then, again, you've done something wrong. Presumably you didn't copy the screenshots (and potentially other image folders) over just like the 3D boxes. You need to copy them all.

Did you refresh? You may need to select all the games and press F5 to refresh media. If that doesn't work it means you didn't do something right (like not copying over the images).

I'm not sure why you're asking, you don't need to put it anywhere/do anything with it. It's something that I used for testing purposes but is not relevant to end-users.

The only reason that would be happening is if you didn't copy the C64 Dreams folder into your existing Launchbox folder structure. This is step one in the instructions.

Based on your description, yes. You have to import the music files too.

That's because you have to hold down the enable hotkey button for those functions to work - F1, ESC, etc. are used in the C64 emulation itself, so to use RetroArch's hotkeys instead you have to hold down the enable hotkey key. It's Numpad Minus.

That would be my suggestion, yes. You'll want to delete the previous C64 Dreams folder as well as the relevant image folders too i.e. not overwrite on top because overwriting wouldn't address any files that were outright removed in the update.

Instructions are in this post.

Quick note, I just made a stealth update to the hotfix. Same filename/link. Newer version was uploaded at 6:18PM EST. It fixed a very minor issue introduced with the original upload if you happened to be using any of the backgrounds by TheNamec.

A new hotfix is now available. This should be the last one. You can grab it here. This is a combination of the previous hotfix as well as new fixes so you only need to grab this one if you hadn't gotten the previous hotfix, and if you did install the previous one you can overwrite with this one. Like last time, this needs to be placed in the base folder next to Launchbox.exe and then extract/merge/overwrite. Make sure Launchbox isn't running when you do this. - Corrected joystick port mapping for players 2-4 in all games that used 3+ joystick adapters (multitap). Some were correct as-is, others needed adjustments. Games corrected are below: Frogs Hockey Mania Shotgun IK+ Ivan 'Ironman' Stewart's Super Off Road Bugbomber* SNAFU '64 Zatacka *the port mapping has been corrected but it needs to be noted that the joystick controls for ports 3 and 4 don't seem to entirely work - player 3 can't move up and down and player 4 can't use bombs. This has been true in every version of the game I've tested (and I've tested several). I've also tested the emulated Kingsoft adapter (which Bugbomber uses) in Joyride v1.6 and everything worked as expected there which makes me think that there is just something odd/wrong going on with this particular game. - Slightly adjusted aspect ratio for Mega Bezel as it was just a little bit wider than it should have been previously - Made some slight adjustments to brightness and color settings in 4k Mega Bezel presets - Corrected all custom cropping configs so that they now maintain the correct aspect ratio when using the Mega Bezel shader (standard shaders were unaffected). There are 96 games where this is relevant. - Changed Mega Thrusterball's auto-warp value to "Ignore Audio" to bypass load screen (which plays music) - Corrected Barry McGuigan World Championship Boxing and Cloud Kingdoms to use Joystick Port 1 - Added missing notes overlay for Dominion - Updates the Extras plugin so that it will work with newer versions of LB; only relevant if you A) enable updates in the included version of LB or B) import into a separate newer version of LB I've actually been hard at work on the next version already rather than taking my typical couple-month break from it. That's probably still going to happen at some point but I figured if I can keep going and not feel burned out I should. I have to kindof shift gears mentally when I'm working on C64 Dreams versus anything else so I guess if I can still maintain focus I should. I'm actually really excited about some of the new things that'll be in the next version, but that can wait until next time 😉

You can't. C64 Dreams has to be a platform category to itself because that's the only way to have enough levels to have playlists for the different categories of content. Platform Category > Platform > Playlists i.e. C64 Dreams > Magazines > Zzap!64 C64 Dreams > Games > RPGs etc. You can't have Computer (or Commodore 64 or anything else) > C64 Dreams > Magazines > Zzap!64 because it's too many levels.

No worries! Glad to help. We all have those days haha 😅

Because the project isn't called "Launchbox C64 Dreams" so making the folder that you're presented with when unzipping it named that would be rather odd. When you install a game on Steam the folder it installs isn't called "Windows Doom Eternal" or "Steam Doom Eternal" either. C64 Dreams is what it's called, so that's what the folder is named. The C64 Dreams subfolder can function on its own regardless of Launchbox or any frontend and is portable, so it's also called C64 Dreams. It's not as complicated as you're making it out to be, you just have to read the instructions. Then there's nothing wrong here to begin with. You just have to select the category on the left... If you add your own license to my package this is what it will look like: Choose the C64D category (the only option, because there are no other categories here) and it'll take you to this: "Games" will take you to the playlists within games. You can also choose "All games" from there, etc. You can customize the views as you see fit. If you're using a controller you can change them with R3.

C64 Dreams is designed to function as its own standalone package, so that's not going to happen. It's working fine here. You must have either not imported all the parents/playlists/platforms or something to that effect. Instructions for importing are in this post. You need to follow them.

You're probably either pressing spacebar too soon after changing them or you're not pressing insert/eject disk again after changing them, something to that effect. You have to use insert/eject > next or previous disk > insert/eject again and then continue. After the the last eject/insert you sometimes need to wait a couple seconds to make sure it reads the new disk. It definitely works. I played Alice in Wonderland in particular not that long ago. Just tested for good measure:

Some games do require manual disk swapping. Alice in Wonderland is such a case. The process for how to change disks is explained in the video.

There's not really an easy way to do that. If there's a specific magazine that you're wanting added I'll consider it. I'm planning to at least add Commodore User and Commodore Disk User in the next version.

I made a hotfix for a couple of issues. I've added a link to the opening post as well. Download Hotfix Place this in the base folder (next to Launchbox.exe) and extract/merge/overwrite. This makes the following changes: -Updates the Extras plugin so that it will work with newer versions of LB; only relevant if you A) enable updates in the included version of LB or B) import into a separate newer version of LB (which doesn't exist yet) -Fixes input mapping for players 2-4 in Frogs, Hockey Mania, and Shotgun

Ah yep, that would do it as well. Glad you got it sorted.

No it doesn't. Start, by itself, is Runstop. Show controls is combo + start. When combo is held down whatever the button you then press would normally do is disabled and the combo function is performed instead. i.e. A is normally fire but Combo + A is save state (and not fire). Whatever is causing this is not related to what you're talking about. Quit is Combo + LB. So if it's quitting when you press Combo + start it's something weird happening with your controller. It could be you have something running in the background that's also reading controller inputs like say Xbox Gamebar. Steam can be setup to read them / do things as well. Both of these (and presumably other third party apps) can be configured to read inputs at all times to do things like focusing the Xbox app, focusing Steam, closing apps, etc. My suggestion would be to try disabling these one at a time and see when the issue resolves and go from there.