Jump to content
LaunchBox Community Forums

Zombeaver

Moderators
  • Posts

    4,010
  • Joined

  • Last visited

  • Days Won

    54

Posts posted by Zombeaver

  1. 6 hours ago, stigzler said:

    as long as your releases contain all files necessary rather than a 'cumulative update' where you only include new or updated files.

    This is how it works currently, yes. Each subsequent release is complete. There is no update process per-se at the moment as there's too much in flux currently from one version to the next and I don't expect this to change until at least v1.0. It requires a complete delete and replace. There have been multiple instances of significant backend changes over the course of the project (and this will be true in the next release as well) so it would be impractical to do it any other way until that's no longer the case.

    The relevant folders for the purposes of importing would remain the same as those I listed above though. It would be those plus the main C64 Dreams subfolder of course.

    If you have any questions or need help with anything please feel free to hit me up on my Discord. That's where I typically post about ongoing progress and collaborate with other developers like StatMat of the OL64 project.

  2. 8 hours ago, stigzler said:

    Found it. You'd forgotten to add this to 'Files To Import.txt':

    Data\\Playlists\\C64 Dreams Magazines - Zzap!64.xml

    Also, you'd omitted the '.xml' on the end of `Data\Playlists\C64 Dreams Magazines All Magazines`

    Yep, I can confirm both of these are true. Both are corrected in the current WIP. Good catch.

    8 hours ago, stigzler said:

    Problem was it iterates through Files To Import.txt and uses its contents to auto copy the files therein. Errors in this spill through to the import.

    It would probably make more sense to simply pull everything from Data\Platforms and Data\Playlists as it will always be everything in both folders. The same goes for Images\C64 Dreams, Images\Platforms, Images\Platform Categories\, Images\Playlists, Music\C64 Dreams and \Plugins. It will always be everything in those folders regardless of what's specified (or not) in Files to import.txt. I will probably end up changing Files to import.txt to eventually just state that anyway just to simplify matters. The Parents and Platforms xml inserts would of course remain as they are by necessity.

    I appreciate the work on your app. Importing into an existing library has always been an overly fiddly process that's been more difficult than I would like for people to deal with so if this helps streamline that that's great. The next question would be is it able to deal with subsequent releases when existing (and potentially outdated) data is already present from a previous one? The process has to be repeated when a new version is released. In the case of the individual xmls for the platforms and playlists it's a simple overwrite. With images it's not quite that simple because sometimes files end up getting deleted between releases, or change filetypes (so they wouldn't be overwritten and an unneeded image is left behind if the existing folder isn't deleted beforehand). The inserted portions will change as well, usually just with new data, but sometimes with altered existing data. I'm not sure how difficult that would be to deal with - I would imagine a differential of old to new image files wouldn't be too horrendous albeit time-consuming (and it could always just outright delete the relevant folders beforehand instead, since that's the current process when doing it manually), but the Parents.xml and Platforms.xml changes I would expect to be more difficult since those would contain a lot of non-C64 Dreams data when incorporated into an existing library. Maybe it could just do a diff between the old and new insert files, then compare against the user's existing xmls and then update/add based on that? Sorry, I know this is a bit in the weeds but I just want to make sure that it wouldn't implode when someone attempts to import a new version on top of an existing one.

  3. So, looking at your video again, it looks like the icons for them aren't showing up which indicates a cache issue. I don't think I've ever seen that result in a completely ignored playlist before but admittedly I don't use BB a ton to begin with so maybe it's possible. You can refresh the BB cache manually via System Menu > Options > Image Cache; either that or you didn't pull the image files for them over. I assume it's the former though just based on the way it appears. This is why I said I would recommend testing in LB first. I wouldn't mess with BB at all until you've done that (note that LB needs to be set to Platform Category view to display correctly with C64 Dreams).

    If that doesn't fix it then I have to assume that something has gone wrong with the import process, either something wasn't pulled over or the sections that need to be added to the parents and platforms xmls weren't added completely/correctly. You'll also want to double check that all of the playlists have been pulled over - Zzap isn't technically a platform, it's a playlist. It's C64 Dreams (Platform Category) > Magazines (Platform) > Zzap!64 (Playlist). The implication if Zzap, specifically, is missing would be that either the Zzap playlist wasn't pulled over or that the parents xml wasn't updated correctly to include it under the Magazines platform.

  4. It's also worth noting that based on your previous demonstration you're not actually using the XML that defaults to the local versions of the magazines because it's loading up in a browser. I'm not sure if this was intentional or not since you show the relevant folder where the local one is, but to be clear the Default Local one needs to be used if you want the default launch behavior to use the local files (which I assume you do since you downloaded them).

  5. 1 hour ago, stigzler said:

    I was thinking they weren't available because not available in the Launchbox context menu, but they are totally available in BigBox!

    I'm not sure what you mean by them being in Big Box. The manuals aren't integrated into LB/BB in any way (unless BB is finding them and doing something with them in the background which I'm unaware of, its unintended if so). As I said, they're toggleable in-game via the hotkeys. Numpad minus + numpad enter on keyboard or back + right thumb stick button on controller. You can navigate them via arrow keys on keyboard or right thumb stick on controller. Pressing the keyboard or controller hotkey combo again brings you back to the game. Viewing them via LB/BB is not intended. The reason for this is because, functionally, everything is frontend agnostic/non-dependent. All functionality from manual toggling to custom music for text adventures, etc. is handled via external scripts and apps that use relative pathing. From Launchbox's perspective it's essentially just Windows shortcuts. You could remove LB/BB from the equation entirely and it would still be fully functional by just starting the .vbs files in each game folder, magazine folder, demo folder, etc. This is by design so that someone could theoretically import into any frontend and it would still be functional.

    I don't know what the issue is with the magazines beyond something has gone wrong with your importer since by your own demonstration they work in the normal version. I know that BB itself has its own separate cache, so that could be related. I would recommend checking in LB first.

     

  6. I'm not exactly sure what you're asking. If you mean in general, yes. If you mean with your importer I don't know as I haven't tested it. Manuals are toggled in-game via the keyboard/controller hotkeys. Magazines default to the web version but this can be changed if you replace with the included xml in the "Default Local" folder in the magazines subfolder.

    I appreciate the contribution.

  7. 3 hours ago, DCX918 said:

    @Zombeaver First post from me, mainly to appreciate your hard work and devotion. C64 occupies a huge part of my early memories, so this is absolute gold!

     

    Are you still accepting requests for the next update? If so, I'd love to see Pieces II (Protovision) and Space Station 23 (Vector 5 Games) added. They've taken up plenty of my free time recently, and would be worthy additions...

     

    Thanks again!

     

     

     

    Yes, I always accept requests for subsequent releases. Space Station 23 is actually already in the current WIP for the next version. I'll add Pieces II to the list as well. Glad you've enjoyed C64 Dreams!

    • Like 1
  8. Then there's something even more dramatically wrong with your system or files. I don't know if you've moved something you shouldn't have, didn't extract the entire archive, have a corrupted archive, have antivirus software that's interfering, have some other unknown software that's interfering. You've given me very little information so there isn't much I can tell you. You download the 7z, extract it wherever you want, start Launchbox.exe. That's literally the entire "setup" process. If that doesn't work, there's a problem with the archive that you downloaded, your system, the software that you're running, or some combination thereof. But again, the extent of the instructions to simply use this as intended is 1) download C64 Dreams v0.60.7z 2) extract it wherever you want (except for Program Files) 3) go into the extracted folder and start Launchbox.exe. That's it.

  9. Again, all I can tell you is that something you've done during that process is wrong. I can't tell you what that is because I don't know what you have or haven't done.

    Many users import the collection into their own libraries without issue using those same instructions. You could always use it in the standalone library as provided.

  10. Whatever is happening is an issue with your system. There's something seriously wrong with your system if 1) it's not restoring the native resolution when exiting and frankly if 2) you need to reduce the resolution to 1920x1080 to begin with. It sounds like your CPU isn't really up to par, as that's what audio problems generally indicate. You could try changing video_threaded to "true" which reduces hardware demands but increases input latency. All the other included settings that are relevant (hard sync, vrr runloop, and frame delay) are defaulted to their least-demanding values unless you've changed them. Beyond that the only thing I could suggest is to try changing the video driver setting to vulkan. If you do that though none of the shaders included in the configurator will work other than the Mega Bezel ones - which you absolutely should not use if you're having performance problems even without them - this means that you wouldn't have access to even the color-corrections shader, so everything would look a bit off, so I wouldn't exactly recommend that.

    Try video_threaded = "true" and stop messing with the resolution settings. Start there.

    ...and in the long term get a better CPU.

  11. 18 hours ago, Mateloaf said:

    Hi, first off can i just say thank you this is an amazing collection. Being a bit of a noob though have one odd problem. When i load any game the sound is horribly distorted, if i set the output resolution in retro-arch to 1920x1080 60hz, this fixes this issue, however every time i leave a game it resets everything and i have to change it every time. i changed my resolution in Windows to 1920x1080 and this doesn't help, any ideas what i could be doing wrong (if i try to save configuration it says its failed to save, i have tried changing it by just loading retroarch in the C64 Dreams folder and this hasn't saved the setting when loading launchbox) my resolution at present on my monitor is 3840x2160 if that helps. Any advice is much appreciated!

    You would need to go to C64 Dreams\C64 Dreams and start Configurator.exe. Then double-click on Config Editor at the bottom. Paste this below the other parameters:

    video_fullscreen_x = "1920"
    video_fullscreen_y = "1080"

    Then change video_windowed_fullscreen to "false"

    The refresh rate is already set to 60 by default.

    Go to File > Save and then close and you should be set.

  12. Thanks @EvoluZion3 glad you're enjoying it. It's always encouraging to hear feedback like that.

    On 11/18/2023 at 5:33 PM, EvoluZion3 said:

    Once it was up and running, a simple refresh media and the EmuMovies video clips and other media came straight down

    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.

  13. 27 minutes ago, Voljega said:

    I the end I might not be able to make all games work or work properly, but at least I can try to support the most and I'm willing to learn enough to make it work

    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.

    27 minutes ago, Voljega said:

    and I never said "Just use this and it will work" ...

    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.

  14. 7 hours ago, Voljega said:

    EDIT: it works with removing the " and putting that into an m3u, so I will do that :)

    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.

    7 hours ago, Voljega said:

    For the 3 games with missing disks in the m3u, I certainly didn't put them there myself, so at one part or another they were here for me and likely for a lot of users (I downloaded the collection in last August or July I think)

    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.

    7 hours ago, Voljega said:

    Same thing for the SID music which I don't even know what it is and how it's used.

    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.

  15. 6 hours ago, Voljega said:

    While working on the converter I found some small issues:
    https://github.com/Voljega/ExoDOSConverter/wiki/Known-Issues:-C64-Dreams

    image.thumb.png.b4e0d7c73d4041d277940988306fce8c.png

    This is erroneous. The existing contents of the m3u are correct.

    image.png.8be0905e24ea6eaeb5ce73b0b87c3f49.png

    The ":boot" portion refers to a specific sub-PRG in the disk image:

    image.thumb.png.723ff074bb4ff4aacbc9cf5936272dac.png

    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.

    image.png.47eb5c227556df94618a01902d42027a.png

    _________

    image.thumb.png.a6df5dcff4725cd7cca9af856313c0bd.png

    That's already the contents of that .m3u, so I'm not sure what you're talking about here.

    image.png.aab95fd02997948cfb76fc2070c8b201.png

    image.png.992942f080162f33812dd2d302d367c3.png

    _________

    image.thumb.png.8f055447e5097da1c2939ac20ad114e6.png

    Once again, that's already the contents of that .m3u so I'm not sure what you're talking about here either.

    image.png.aab95fd02997948cfb76fc2070c8b201.png

    image.png.4687910c7bdf19337db3e65ab1b7b4b8.png

    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.

  16. 14 hours ago, frank70 said:

    1. The Commodore key (left ctrl) and the CTRL key (tab) are not persistent. By that I mean that if I hold one of them down (like the Shift, Combo, or Windows keys which work fine) they only take effect on the first keystroke after one of them is depressed - after that, it's as if they are not depressed. This is in contrast to the C64 where they behave the same way as Shift, having their effect as long as held down.

    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.

    14 hours ago, frank70 said:

    2. The text adventure game entitled "Zork - The Undiscovered Underground" loads and runs fine but during play certain keys do not work (either do nothing, enter something random, or enter the wrong character); minimally these are the I, J, K, M, N, O, 9, 0 keys though there may be more. These same keys behave properly when playing any of the other "Zork" adventure games.

    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

    6 hours ago, frank70 said:

    My biggest surprise is that the F4 key invokes the Windows game bar video recording function, alternately starting and stopping the recording. The video is saved in Videos\Captures as an mp4. So if you actually want to enter F4, you need to do a SHIFT-F3 like in the good-ol-C64 days. Also the Windows keys just pass thru and perform their usual Windows functions.

    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.

  17. 6 hours ago, bigBOSS97 said:

    I followed the instruction above to copy the files to my LaunchBox. Now it seems to be working. But why haven't my games got thumbnails? Do I have to download them?

    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).

×
×
  • Create New...