Jump to content
LaunchBox Community Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

32 Excellent

About Z3R0B4NG

  • Rank
    32-Bit GPU

Recent Profile Visitors

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

  1. I thought i'll give this awesome new project a quick shoutout, This is a relatively new Project, SNES is the first system they tackled and it is complete with 232 Translations now. They made all the Translations that are available on romhacking.net work with up to date No-Intro roms (so no more digging through old "GOOD sets" or whatever for specific CRC values), practically all you need to to is download this app, point it at your (extracted!) No-Intro set (7zip support is coming later) and it will scan the CRC hashes, apply all the translations without any extra interaction and just dump the 232 translated roms in another folder of your choice. Just to be clear, this does of course not supply the roms, it just patches them. The process went through for me without a problem, along with text files that give credit to the original authors and have some more information about the translations in question (not all translations are complete, some games have 2 translations for the same game and this will tell you the differences), links to the original projects and readme files are included as well. https://www.romhackdb.com https://www.romhackdb.com/news.html The next System they tackle is probably gonna be Sega Genesis. As a Bonus i've made a pass over all games that have been translated in the LaunchBox Database, to make sure they have JAP version 3D Boxes as far as stuff is currently available. And so the games get matched to the correct entries. So make sure when importing to do a fresh scrape of the media. I imported the set in a new folder like this:
  2. ok, i double checked all the covers of the different region names and they do all line up with the one that is already posted with the blue background ...i also submitted the german box front just now, the others were just unusable photos from ebay but enough to clearly identify that they are the correct game. so removing the one wrong alt name was all that needed to be fixed. thanks, this looked more messy than it actually was.
  3. This mess makes no sense to me... Yu-Gi-Oh! Duel Monsters II: Dark Duel Stories Yu-Gi-Oh! Duel Monsters III: Tri Holy God Advant are they supposed to be the same game? all evidence indicates that that is the case? or is III the same game as the US game and II is a different one, or II is the correct and III needs its own DB entry? or just mash it all together? ...confused. https://www.mobygames.com/game/gameboy-color/yu-gi-oh-dark-duel-stories/release-info https://gamesdb.launchbox-app.com/games/details/8465 https://gamesdb.launchbox-app.com/games/details/26269 The alternate Names are overlapping as well.
  4. a little preview for you before:after: i'm at M now ... about half done, it will take a few more nights (i'm guessing about a week or more)
  5. aaaah... so the Nintendo Power one was like a digital only version re-release 2 years later kind of thing, makes perfect sense then that no real cover / box exists for that. welp, good thing i asked and didn't just start merging stuff.
  6. I'm currently making a pass over GameBoy Color (been at it for a few days), adding mostly existing 3D Boxes and Fanart Carts (i don't have cartridges for Jap region games, if anybody knows a good set let me know), but i'm cleaning up some other stuff along the way and throwing in some clear logos here and there where i happen to have some. I'm a bit stuck on this one game... there are two entries for it and two roms for it, but it appears to be the same game, i playstested both up until the menu, screenshots on the net seem practically identical, i'm 98% sure it is the same game, except that there are some different Jap/Asian region text letters being thrown around (all hieroglyphs to me) in the in-game menu and on the cover. It might be a re-release or just different regions like Japan, Korea, China (No Intro says Japan for both roms, i don't know...) Game 1: "Karamuchou wa Oosawagi! Okawari!" No-Intro rom: Karamuchou wa Oosawagi! - Okawari! (Japan) (SGB Enhanced, GB Compatible) (NP) ...by the way, what does that (NP) mean? i keep seeing that. LBDB: https://gamesdb.launchbox-app.com/games/images/117450 gamefaqs: https://gamefaqs.gamespot.com/gbc/954844-karamuchou-wa-oosawagi-okawari/images Game 2: "Karamuchou wa Oosawagi! Porinkiis to Okashina Nakamatachi" No-Intro rom: Karamuchou wa Oosawagi! - Polinkies to Okashina Nakama-tachi (Japan) (SGB Enhanced) (GB Compatible) LBDB: https://gamesdb.launchbox-app.com/games/images/117451 gamefaqs: https://gamefaqs.gamespot.com/gbc/571631-karamuchou-wa-oosawagi-porinkiis-to-okashina-nakamatachi/images If anybody could clear this confusion up, that would be nice. this is the media i got to add, i just don't know which goes where, or if we should merge both entries into one and which one ... Clear Logos (notice the different lettering): these are the Jap 3D boxes i'm uploading this one is just the in-game title screen, not an actual cover... i would rather not use this one, but seems like the guy who made the boxes stumbled over the same issue and this was his solution. I do NOT upload these 3D boxes for Jap region, only for US and EU, i think they just look less authentic for Jap Boxes (i might use it as fallback option when a game does not have the other type of boy, did not need to do that so far but i'm only at letter K).
  7. hmm... MAME updates once each month, i don't know how often LaunchBox refreshes its data for that, but No-Intro .dat files get compiled on a daily basis at Dat-o-Matic (at least the daily pack here https://datomatic.no-intro.org/?page=download&op=daily ), but people may have roms from 6 months ago or just random single roms from wherever instead, i would not want to split that into different import processes, many people will not know what they have. You have to also consider the Userbase will have all levels of know how, from hardcore collectors to absolute noob level casuals who never heard about No-Intro or dat files or any of that stuff and just got some roms from a friend on a disc and want to "throw it in there" etc. and ideally you want LaunchBox to match stuff correctly, no matter who imports roms or where they came from. The hash values from the known dat files would really just add another, more reliable level of accuracy to the existing matching process. And AFAIK LaunchBox, when importing roms only scans for database entries of that specific System you told it to import, so hash values of say SNES and Sega 32X would have no chance to ever collide because it isn't even looking there, not to mention that hash values are unique and should NEVER collide for different files anyway, heck that stuff is precise enough for copyright lawyers to sue torrent users over, hash values are practically a digital finger print, i don't think it is even possible for 2 different files to randomly have the same values ...not AFAIK anyway. I am personally not using TOSEC, not yet... but from what i've seen they upload full packs only every once in a while and post them in news posts, which is a weird contrast to how automated Dat-o-matic does it for No-Intro. Ideally you want to support all hash values from all .dats and databases you can possibly get your hands on. But i'm just not sure if i would trust users with submitting hash values, if they submit it to a wrong game or system, there is no way to know that it was an error after the fact, because all you got is a bunch of numbers and letters that human moderators can't understand unless they randomly happen to have the identical file with the identical hash value and notice a wrong match has happened somehow.
  8. The ultimate clean solution would be using hash values of course... and that appears to be on the radar already.
  9. I would suggest, just like the alternate names field to let us add hash values to database entries. Instead of regions you could have a drop down menu with No-Intro / Redump / TOSEC / GOOD / other. There are roms that of course do not come from the common sources or are scene rips (C64 scene for example, the stuff used in C64 Dreams). Another thing i recently learned is that Dat-o-Matic has Parent/Clone sets for No-Intro, those exist so you can make "1G1R" (1 game 1 release) sets with it, with that data i think it could be possible to make it a bit easier because you should be able to extract every hash for a specific game and group them together right from the .dat file. The filenames should match for the largest part with the LBDB already, if you can apply the same algorithms when importing roms into launchbox to add these hash values to DB entries then a good chunk of it should happen automagically, anything that doesn't get matched you could put in a list and post it so we moderators can edit it in. That parent/clone .dat isn't a thing for Redump, and i don't know about TOSEC, never used it myself. There is an app called "Hash Tab", it adds a Tab in the windows explorer's file properties menu and you can copy/paste and compare CRC / MD5 / SHA-1 hashes easily with it, do recommend (and its free). The next level crazy idea is, if you already have to deal with .dat files, hash values and check the content of .zip / .rar / .7z files for hash values, you might as well go the extra mile (or extra 10 miles) and add a proper rom manager right into launchbox ... boom who needs CLRMamepro anymore? That would be a feature that other front ends don't have at all, not AFAIK. No idea if other users would want that, no idea if that makes the whole idea cooler or just more daunting :D ...good night. //edit: good morning, so i've done some more thinking and a few things would still be problemativ even after perfect hash value recognition is implemented into LaunchBox. 1) C64 Dreams / eXoDOS For starters C64 is a system that is NOT well covered by No-Intro, the three dat files are horribly incomplete and full of games that can't even be emulated because the No-Intro roms include copy protections, so with C64 you want to do the opposite and go with cracked scene released that often do have Intros. Which is what C64 Dreams from Zombweaver does, but even then C64 Dreams does not directly link to the rom files but has come up with some hacky solution with .vbs .bat and .cmd files to launch games with added instructions for retro arch and other stuff (which i don't quite understand). Point being you would have to trace the URL to the actual rom file through those vbs and bat files. Adding the hash values of those .bat files directly would be a very messy solution and i don't even know if those files are unique enough to be identified that way (i think a lot of it is actually copy&paste). The thing is, C64 dreams has kind of kickstarted this entire discussion because that triggered me to deal with this problem of C64 having one time even up to 8 games with the identical name and LaunchBox only displays the first result it finds. And if that still wouldn't work, even after hash values being a thing... that would annoy the hell out of me. eXoDOS has a hacky system of its own that i have not messed with at all. Those kind of projects certainly deserve consideration if something can be done to improve rom detection there as well, ...after the .dat files have been dealt with. 2) Nintedo 3DS decrypted roms No-Intro has a set for encrypted and decrypted Nintendo 3DS roms, i have to this day not found out how you can decrypt a rom from the encrypted set and get a decrypted rom that matches the No-Intro dat file's hash value. All decryption tools that are flying around the internet have different methods of culling trash data from the roms to reduce filesize further, that of course results in practically all roms having different hash values. That has been annoying me for a long time now and i got no solution to it. Of course the name recognition would still work as fallback here, that is a selfmade problem of the 3DS scene. 3) Redump multi disc games M3U / CUE / BIN You added M3U support recently so you know how that stuff works. It isn't ideal for how i do stuff so i still make my own m3u files and import those in LaunchBox. So you would again need to follow the path through those text files to the actual rom file through the .m3u and .cue to get to the .bin's hash value .... actually i think the .cue file hash is inside the redump .dat file as well, maybe that would be enough already (and the .cue files are a lot smaller, faster to scan for hash values). Again, this is something where the regular name recognition would still kick in as fallback option if that isn't done. 4) Moderation: ...people also make like .pbp files out of their PlayStation images and all kinds of compressed files that aren't gonna be listed in any .dat file. I would expect a lot of hash values being added to the database with NO idea where they even came from, which makes it hard to impossible to moderate and keep the DB clean after the fact. It might be a good idea to have people who add hash values manually give a bit more info on filename and source and have that visible to other moderators. Or maybe just stick to the actual clean .dat files so it doesn't end up being a huge mess and just don't allow user contributions. ...but then that wouldn't help at all with our current C64 situation. ...mmmmh. I guess the question is what the goal is of doing this, do we want to promote people using clean and up-to-date .dat sets or do we just want LaunchBox to recognize everything it possibly can, even including the old "GOOD" sets that everyone will tell you not to use anymore because its full of outdated bad dumps. That i can't answer for you... ...well now you got a few more things to think about.
  10. First of all, welcome and thanks for all the work, C64 is what i consider a "hard mode" system to deal with, thanks to the open nature and all the homebrew. The console systems with practically complete No-Intro sets are certainly much easier to deal with and magnitudes smaller in scale. My idea with the super moderator thing would also include a pinned thread on the forum where everyone can bring up problems, how to best handle those issues would then be discussed between the moderators and the decision would be locked permanently. Priority would of course be to lock as little stuff as possible and i would not expect the two or three super mods to look around all day for just these cases but to act when users need help with something specific, just the stuff that counts as edge cases, where the regular rules are not enough and people keep making a mess again and again because of circular logic. The thing is we are all just users here and are saying what we think, none of us have any power to say how it has to be or to decide on new rules or sub-rules etc. i don't even know who we would talk to about that. Having 2 or 3 somewhat active users be named super moderators who deal with little inconsistencies and these pesky back and forth looping situations just makes sense to me, it would also be relatively easy to implement from a coding perspective by the developer, giving a few users the function to lock and unlock certain fields in a database should not be the hardest thing ever or even all that time intensive to create (you would have that nailed down in a weekend). If we talk about making polls and stuff that gets more coding intensive fast with every extra feature and button that is needed. (...or so i imagine.) Throwing in a sticky thread where people can bring up issues that the "super moderators" then have to decide on how to deal with is a matter of minutes. And this still gives everyone an easy option to bring up issues and get problems resolved, have their voice heard... or at least get a "NO and this is why" as an answer. I fiddled a bit with making websites and coding myself here and there, my natural way of thinking is lowest effort way to implement a solution that gets you the result you want out of it. Anything too complex or wild is an uphill battle to convince any Developer to implement. But that is just MY idea/suggestion to deal with it and i have no say in what, if anything, actually happens.
  11. Thanks for defending, i just rejected a bunch of those as well.... heck i probably made most of these changes a few weeks back myself (and 3 moderators accepted the changes!). The only idea to permanently stop this sort of thing i have is to add another level, like a Super Moderator with elevated rights who then will LOCK certain fields from being changed. More candidates for locking would be all the "Pokémon" games that again and again get renamed to "Pokemon"... i see back and forth there every few days now, i just press ignore for 24 hours by now when i see anything pokemon related, i don't know about that stuff and i don't care anymore i let others deal with that noise ... Astérix / Asterix maybe ... anything leading with Disney / Disney-Pixar presents ... (not 100% sure but i think we don't want that, even though it is written on the box, the No-Intro and Redump naming is super inconsistent with that as well, i just know some people went through all of those and removed the Disney stuff some time ago). ---- A few more issues or rather "odd behavior" i noticed with media is that for Filenames specifically "TITLE NAME (PUBLISHER)" ... the (PUBLISHER) part is ignored by Launchbox (because that is where No-Intro naming puts all the tags like regions or Disc 1 Disc 2 and so on) unless there is a -01 behind it. So a picture with the name "TITLE NAME (PUBLISHER).png" will show up for all games with that Name, but "TITLE NAME (PUBLISHER)-01.png" only shows up for the correct game from that publisher. For scraped Media that is done automatically, except for VIDEOS from EmuMovies. Even more fun, if you have GAME (Publisher 1) and GAME (Publisher 2), you scrape the first game and you get a GAME (Publisher 1).AVI file, which will be displayed for both games. You then scrape game 2 and the video for game 1 will be DELETED, when video for game 2 with different filename is downloaded, now both games show video number 2. So now you need to go outside the app and manually move the one video you have out of there, download the other and throw your backup back in for both games to display their own video. I would not be surprised if i am the only one who ever even noticed that happening. I bet even @Jason Carr isn't aware of his app doing that. 🙊 🙉 🙈
  12. I third this! This has been a long time pet peeve of mine. I've been using this DB for at least 2 years now and i'm still having the occasional OH SH*T moment when i press the SEND button and notice that i clicked the wrong thing. Then you got to remember your error for 24 or so hours until the moderators got through to it and double check if they rejected it or waved it through and then fix it. It should be simple enough to just add a button to your own Change Status that just instantly REJECTS your own change without waiting for moderators. Just increase the rejection count by 3 and done, you don't even need to come up with any new mechanics really, i don't even care if that adds more rejections to your stats in that account overview window.
  13. You can only see in your change status window why somebody rejected a change and only if the submission was actually rejected. If one guy rejects and 3 wink it through, you will not see his reason, which always has me wondering why. Because this is against the naming rules of the LaunchBox Database. We are supposed to use "common sense" for alternate names but some people stick to the rules a bit too much. LaunchBox is intelligent enough when importing roms to make "Die Siedler" out of "Siedler, Die" and it searches in the Database for that name, not for the filename. There are some exceptions where LaunchBox gets confused ("Sieder, Die - Gold Edition, Die" may as theoretical example be changed into "Die Sidler, Die: Gold Edition" which is of course wrong, but THAT is what you then should add as alternate name so it gets detected), ultimately you should not be working of the filenames but of the names that LaunchBox has imported. And generally you should only add a alternate names if LaunchBox failed to find the DB entry, you can "arrange by" in LaunchBox after "LaunchBox Database ID", that way you can work your way through only the stuff that has not been found. (that is how i always do that anyway and i've added a ton of No-Intro names myself already). Sadly no, i have suggested one or two times myself to use the No-Intro / Redump / TOSEC .dat files. eeeeh... i'd rather not have the normies that just use the program spam wrong submissions into the DB. Keep in mind it also scrapes media from EmuMovies and people might not understand the difference if they don't look directly at the LBDB entry. We have enough in-fighting in the database as it is, some times i wish we had a few people with Admin rights or super moderators who could lock certain entries. Like naming for the Pokemon games is a constant and annoying back and forth between "Pokemon" and "Pokémon" and we constantly have to defend those. I've recently noticed with C64 games that there are a lot of games (most of it Homebrew) that have identical names, LaunchBox will only see the first game in the database that has an identical name for the same system. So i went through a lot of them recently and gave them unique names, like adding the publisher after the name "Aliens (CP Verlag)" and "Aliens" as alternate name, that way all 5 "Aliens" games will show up but it will also show the unique name with enough information so you can decide what game to click on (that is the point where hash values would be super convenient). Now of course that is the "common sense" approach and not the "stick 1:1 by the rules"-rule approach, so we constantly have people that try to revert those changes (changes that by the way 3 other moderators have accepted). There is no way of telling people about this issue, i can't see who makes the changes so i can't direct message them on the Forum, there is no way for them to see the "Reason" why the change was made so of course they think its wrong. So we get stuck in this dumb loop of renaming stuff and defending our changes by rejecting changes from people that didn't get the memo... and chances are that the current 3 moderators don't know the reasons either and just wink the changes through. So ... eeeeh, i'd rather keep the little barrier up and not have that implemented in the App.
  14. Awesome! Do that on a more regular schedule please, i don't remember it ever being this fast and i'm using it obsessively for at least 2 years now, the usability difference is bonkers.
  15. ok, so it's not just me then... *pfew* a little communication from above would be nice, so we yes/no click monkeys don't go into panic mode
  • Create New...