kurzih

Could be the duplication bug of the database. This happens sometimes when adding new entries. I've had it numerous of time for my entries as well. Looks like at least this has gone through: https://gamesdb.launchbox-app.com/games/details/152931 Please check the rejection comments by hovering over the "i" symbol next to the red "rejected" text. You should see moderation comments there, impossible to know otherwise why your entry has been rejected.

Might this solution work for you for games requiring DOS to Boot?

Hi! Slightly off-topic, but controller type related: Any chance of getting this "Missing media files - Back cover" feature added in the near future? It's now more relevant with the new the controller feature, maybe some up-votes might help https://bitbucket.org/jasondavidcarr/launchbox/issues/5870/games-missing-media-option-for-boxes-back Back covers in many cases gives you information/confirmation of: - controller types - player number offline - player number online and other good information for filling missing metadata fields on the database. EDIT: Got some good feedback on bitbucket - the Audit tools has the Back covers in one column, so that does the job well enough to find the missing ones fast and easy. Happy with that!

I personally think that game demo versions should be left as separate entries in the database. In many cases the actual demo version differs from the final product. And in the Amiga section for example there are magazine exclusive demo levels that are not found in the final product. And on the console front as well, for example: https://hiddenpalace.org/Patlabor_-_The_Game_(Taikenban_1.0) turned out to be a different game in the end. No reason why they should be deleted/not uploaded. Game demos are part of the gaming culture, read this article for example: https://www.eurogamer.net/articles/2021-02-26-the-joy-of-treating-demos-like-a-finished-game My guess is that someone didn't quite understand the word Taikenban, which is just "Trial/Demo version" in Japanese and thought it was a duplicate Japanese language alternative version of a game that had a Western (ie. North American) entry. These demo versions have been in the database for a long time and I'm giving my voice to let them be there in the future as well.

It's sometimes really sad seeing people having no use of their time but to try to spam a database. It's doesn't even sound fun. Could be also a mental issue, who knows - but it's quite pathetic. What you can do is PM @Jason Carr, show him a screenshot like you just did and then he can ban trolls. I also think that a simple "Report misuse" button might make it easier for moderators and sending the troll back to its cave faster. (And of course misusing that button would also result into a ban ) Edit: I agree with neil9000 about keeping moderators anonymous to each other on the database. We can openly discuss about moderating differences on the forum when necessary.

You can use the core option to change those settings and you can also access the BIOS menu the same way described in the tutorial you mentioned (holding down the END key while booting). You can also save those core options for games that have unique settings as "Save Game Options" for each game. Otherwise it'll use the last used core options, but in most cases the options you have chosen for the core should work just fine. I have some special default settings for games that are basically for the PC-9821 model (CD games as such). I actually tested Touhou 01: The Highly Responsive to Prayers, and I only needed to Switch to 2.5mhz on the bios menu and worked just fine with my other default settings I'm using on most PC-98 games. And Touhou 2 also then started without any need to change any options: I guess you just need to choose the settings once for them to work best and then that should be it

I recommend using Retroarch for PC-98 using the np2kai_libretro core. It can detect disk images, hd images and cd images. You can even nowadays get CD-based games working with that setup using .cmd files as "roms" in launchbox (basically a plain text file) where you list the actual files like this for example: Policenauts.cmd file has this as text: np2kai "L:\Policenauts User Disk.FDI" "L:\Policenauts.ccd" This would automatically boot up with the user system disk and attach the CD image. Works perfectly. Or if you only have a single .HDi file, then you can skip the .cmd files and point/import directly to the HDi file in Launchbox. It will load it automatically as well.

Did you double check from that second Amiga platform settings that you have the correct "Scrape As" selected? And you didn't manually just copy over the images etc. when you added that second Amiga Category? I also have a few other platforms for Amiga (coverdisks - using the database, scene demos/intro/cracktros - that one is just manual work, no scraping from database except videos from Emumovies). And for C64 I have the C64 and C64GS as a separate platform using the same C64 scraping for only cartridge based games there were (mostly) compatible with the infamous C64GS. So there's normally no issues having multiple ones from the same platform.

I wonder if the mame devs checked these docs out: http://www.icdia.co.uk/docs/ based on what they were replying here: https://github.com/mamedev/mame/issues/1170 this might be one of the things they are looking for? http://www.icdia.co.uk/docs/dsp56001.zip The icdia site has been updated quite recently too.. I don't have a github account so I can't reply to that mame issue directly to see if they have those docs already or not.

Just wanted to inform you that I have contributed a "few" additional missing games these past days in the Mac platform I strongly recommend this page if you are interested in Mac OS emulation, especially for older software: https://www.emaculation.com/doku.php PS. Sorry for the extra moderation work on the few duplicate entries, it's again the old database bug causing this and it really seems random - I haven't done anything different while adding those entries. Take care!

There shouldn't be any doubt of the release date, since there can only be one in the DB per game entry at the moment. It's the first release date the game was released on. Doesn't matter which country it was released later, only the first date matters: I'm just reminding this, since I can see that someone is trying to change first dates into later (North American dates) in the DB, like NES where there is gaps of years in between in some cases. The release date rule is also mentioned in the first post of this thread and since there is no regional dates yet implemented you should only put the earliest date available: A game's release date must require at least a release year. If the game has documentation for the release day and month then please provide. Older games may not have accurate data on release dates. In case of no year, leave blank until that information can be found. The release date should be the first date the game was released on. Regional Date categories are going to be implemented, which will then require each game to have the proper date for the proper region.

You're right about Australia. There's even local publishers/developers for the Amiga there, so no doubt there has been official releases there that are based on the European version and have been localized in some way or even local Australian-made games shipped to Europe. The only tricky thing is to know for sure if the shops were selling imported UK/European versions or versions that were intended for the Australian market - that would be the difference to make: to what market the game was intended to be sold in the first place. But back then, who knows for sure That's why I'd stick with the main information available on the front/back covers, disk labels and bar codes. Another good thing to look at, are advertisement flyers (from magazines), you've got currency and addresses there quite often as good hints. HOL and LemonAmiga are pretty good sources indeed . Yes, I agree that especially Cinemaware and Sierra covers are really basically the same everywhere with the US address included (unless a UK budget release), maybe the disc labels are the ones to spot in those. And thank you for bringing this up to the forum, there are too many back-and-forth going on in the database because mostly the only discussion there is been done in the moderator comment field and that doesn't cover all moderators and some contributors do not even moderate and see any of those comments.

I don't know if this related, but I can see that someone is trying to "world-it" in the commodore Amiga section and making a few mistakes along the way. You can determine in most cases the region the game was released on based on the cover's indications/language - especially the publisher/address/bar codes etc. on the back cover. And if you want to double check your sources then go check out platform specific fan-pages for old computers. It is REALLY rare that a game cover would be a "World" cover when it comes to (vintage) home computers even if the artwork would look the same, like on the commodore 64 and commodore Amiga. There are also cases where a retailer had bought a PAL game batch from Europe and sells it in another country outside Europe, it doesn't mean it's a "world" game unless it has been officially published in that country. My recommendation is that if you are not 100% sure a cover could be classified as "World" - it's better to stick with the information that is already available on the database. That's what I would think anyway.

A quick double check of the "Game type" "Unreleased" metadata field. It's quite clear it works for games that were officially cancelled etc. but is it for something else too? What about the many games on "pre-order" that we tend to see added in the database nowadays, games that are future releases. The "Unreleased" choice is most likely for games that were never released, it's not meant for "future" games that will be released, or is it? Could the developers please confirm this? If adding "Unreleased" to a game that hasn't been released yet, but has an official release date (in the future), wouldn't this happen: a) some of those entries will be forgotten to be updated after release day is past to "released" from "unreleased" b) Even if it will be updated from release day or a bit later, people using the default metadata update process will not get this updated since the datafield is already occupied and will not get overwritten (default metadata update only fills empty fields, not occupied ones) if they already have that game in their collection when it was still marked as "unreleased". Wouldn't it be better to leave this field empty if someone really wants to put a game that is going to be released, but hasn't yet. Any thoughts on this, is this field a multipurpose field when it comes to the "unreleased" type or?

Thanks for you feedback! regarding that point, I have a good example concerning specifically 80's-90's box images: I'm about to replace my own previous scans with better scanned versions of some Amiga games like The Cycles for this database (the material is printed cardboard, no plastic case + paper sleeve in this one): I could remove the "Cool Sun Glasses" sticker, I could remove the Amiga sticker on the bottom. But those were original, authentic pieces of the physical box I had bought in the UK a long time ago. If you think of collectors, the value is always higher if everything is intact, manuals, promo stuff (sun glasses!) etc. But having said that I 100% agree with you that if someone has a better source in their collection (with less scratches for example) and does an even higher or equal quality scan, then there is no reason to not replace the lower quality one. And like I've said before, we are all individuals and have different tastes and it's objective how you look at things and what kind of images you prefer. Everyone has their different tastes. You can read again my first post on this regarding reconstructions and authentic/original images. Both can co-exist in this database and both are excellent alternative for Launchbox/BigBox users. But the issue here, in my case, wasn't a debate about original scans, but about the edits made to those scans (some quite significant changes) with an image editor that were being uploaded in a way that would have destroyed the original, authentic scans instead of simply uploading them as a new image with the Box - Front - Reconstructed tag. A behavior that was disrespectful, misleading (some of those edits actually weren't reconstructive) and breaking the rules of this database.

Well, at least that person isn't replacing/destroying the authentic ones anymore then I hope ? But even then, there is a risk that the untouched and edited cover images might be seen as duplicates and we'd have some issues ahead if some moderators are unaware of what happened in the future and might delete one of them. Hidden agenda? I really hope not, because then it would be an egotistical thing to do. I want to believe that this is just a misunderstanding, because there is not really much to debate here, the rules are clear and there is room for both image types to co-exist with the correct image tag. It shouldn't be horrible to choose the right image type that isn't going to be the default image. The correct image type for reconstructions isn't anywhere hidden or at the bottom of the drop-down menu: Maybe @Jason Carr might be willing to check, when he has the time, if some time off from the database for that person would make him understand he is still breaking the rules + wasting moderation time. This would have been quickly over with appropriate contribution behavior. Sounds a bit like Jason from time to time has to take the role of a "school principal" - I think he'd prefer to have some other things to do to be honest ?. Let's see if there will be clarity before having to take that role again... I'll leave this to you guys, time to chill for the weekend (we've actually had some light snow in the morning, so real chilling might take place). Take care!

Thank you for you kind support on this! Let's hope we'll finally see an end to this chapter, since we all know it only requires (in this case at least) to upload those edits as new images with the reconstructed tag. That is the database rule, I honestly don't buy any of those excuses/pretexts in the database submit comment field like "minor tweaks" "removed a few marks", "fixed color based on real physical box" etc. Those are rule-breaking, ban-risking actions which could so easily be avoided with respecting the rules and the authentic material which is already present on the database. I find it hard to understand that behavior and how time consuming this is while totally avoidable. As I said before and now with more detail: if you feel the image should look better/cleaner either A) scan a higher quality brand new image of an authentic physical box from your (Amiga) collection or B) upload your photoshop-edited version as a reconstructed new image and stop making excuses/reasons that try to justify those actions that are rule-breaking and disrespectful to persons like me and others who appreciate the variety, authenticity and options of what Launchbox lets us choose from. This actually makes me want to go high quality scanning some of my own Amiga collection (and yes, some of my boxes do have signs of wear, prize stickers etc. and would like to keep it that way). I guess I'll have to dig some out at least and look again what we have on the database if it would be worth the effort.

Indeed, the game name on the same platform cannot be identical, the way you did should work fine "Game Name (Year)". One of the biggest reasons they need to be uniquely named is that the images are named after the game's name, so those would get mixed up as well. The biggest challenge is Emumovies, those still do get mixed up and need to be manually downloaded and renamed (unless there has been a change this year). You can read more about this here for example:

It's mainly happening in the Commodore Amiga section right now: Someone is making their own photoshop "clean-up" edits for Box - Front images and replacing authentic scans. In some cases the edits actually do not look better than the original (pixelized, oversharp, loosing texture, color is off etc.), but that's not the main point here since that is objective and most of the photoshop edits are quite all right. The primary thing here is that those originally submitted scans etc. are being destroyed in the process. I've been trying to moderate this saying that it's OK to make your own "cleaning", but it's not OK to destroy the original image in the process. We have Box - Front - Reconstructed that is meant for that. Looking at the moderation situation it looks like the majority would agree. Thing is, me and I would believe, lots of other people love nostalgia, and I have to admit for myself at least, are perhaps a bit obsessed by that we love the way our games boxes looked like back in the days and how they would look today. If the authentic box has scratches and imperfections - the better (like antiques, you usually don't clean them so you can keep the sentimental and actual price value etc.) and we can see they look physical and see how the material/texture (cardboard, golden color etc.) reflects the light. But then some people (probably also obsessed, aren't we all ) are loving to have everything in a certain order and look, with templates, no scratches and have their own liking of how colorful/dark/light all of the covers should look like, pixel perfect, one-size-fits all. I think this is a matter of respecting both sides and using the proper images types so that we can choose which version we would download. Short message: please, do not destroy authentic images. And if you feel it's a bad quality image, then try to get a brand new authentic image or upload your edited version as a new image using the box - front - reconstructed image tag. I have reported this to Jason, since the person making those edits doesn't show any sign of understanding this situation. Lets see if the message gets through to that contributor if not from here. EDIT: Sigh... Looks like the radar isn't working on that person and besides this is not just a request, it's also about breaking the database rules. This is a reminder to moderators as well - there is no reason to accept those reconstructions with the wrong image tag/category used on them, especially since they would overwrite the original, authentic image in the process: Rule #7: Front and Back Box Art must have the proper regional tag and be added to the proper category. Reconstructed box art can not be used in any other category then the reconstructed section.

I totally agree with you that the format used should be considered what is appropriate to have for each image type and I think also depending on the source and age of the platform. A combination/balance of best quality and best usage experience is at least what I would hope for. And as you said, if there would be only JPEG allowed, then you couldn't even upload anything else. For example, you can't upload gif (vga source) screenshots, because the system doesn't technically allow it. Looks like someone got confused about the meaning of scalability, which at least on my part I've been "promoting scalability" with screenshots as (native) PNG, not JPEG. Random assumptions have been an issue in moderation from time to time, there seem to be unwritten rules sometimes that come from a personal opinion into a "rule" in the moderation opinion field. That's why it's good to double check from the devs/owner once in a while. Like I did for Wikipedia URLs, since there was some really strong opinions/assumptions that got turned into a wild west situation despite the common sense of the name of that metadata field. On the other hand the uploader would hopefully think on top of image quality the overall Launchbox/Bigbox user experience before uploading the most perfect looking image despite how much space it takes. For example it might not be best for the user experience to download at worst 8-9MB sized 1920x1080 background images from the database when they would look almost identical (without any significant quality loss if properly saved in high quality (or Max) JPEG) and would take 30-40% less space and load quicker. Just make the calculation: 6-9MB per BG images x 30 000 games (my total is over 60 000, but I guess that 30k is something many have). That's quite some number for just background images: around 18-24GB. But even saying that, I would find it wrong to replace a big PNG image with a significantly lesser quality JPEG image - that would also ruin the user experience. And finally, I'm using this opportunity to give feedback about something that ruins a bit of my own user experience, which might not be an issue for some of you, but is to me: some of those backgrounds have sadly the wrong aspect ratio, the main visuals have been force-stretched to just fit a certain size/template. Love to have the correct/original aspect ratio in all cases, despite if it means black bars on the sides etc. PS. We've had this conversation before with PNG on screenshots and also mentioning those cover and background images, please see this thread where I defended PNG for scalability:

May I comment on this topic? I think lately things have gone much better when it comes to clear logos, but at one point there was a lot of logos being uploaded with a huge amount of empty space around them (not cropped). That resulted in the logo looking really small, particularly in BigBox and also the logo being impossible to, for example, place in the far left or top, if they would have a big amount of empty space (thinking of Theme makers). This is something worth keeping in mind, because however big the resolution is, the logo will look smaller than wanted, if there is uncut space around it. I've submitted quite a lot of missing games, new games and when I upload/see a logo with empty space around it I just bring the logo in photoshop and click the none-empty layer with CTRL pressed down and then use image/crop - that takes around 5 secs and works like charm.

Sorry, self-quoting, since I need to get back to this with a bigger issue: If someone really needs to have those Alt names in Katakana/Hiragana etc., then do not region tag them at all, or at least not with the same region as the default name has. Otherwise the scrapping will be a total mess, look at this - I've tried to update metadata for MSX and some of the Default title name for Japanese-only games have been overwritten with that Alt name. To be on the safe side, it's perhaps best to stick with Latin Alphabet ONLY in the database, unless we can figure out a way which always works - I guess the default name could be region tagged, but is there an option for that?

To my understanding those little "i" icons only come up if it has been fully rejected. If it's something like 6 approvals and 3 rejections, then you can't see what those 3 rejections were all about.

This is one of the reasons I've more or less stopped moderating. I've seen this case too, wrong image type + missing region tags. Nowadays there's just too many people (new moderators perhaps?) just pressing the "Accept" button without really taking the time to check the entry and reading the database rules or actually have proper knowledge of the information for moderation. It's also possible that there could also be a language barrier. I'm sure no one is making trouble on purpose, but it's a waste of time when someone submits something - takes at least 3 moderators to accept it and then someone fixes it - takes at least another 3 moderators to accept the fix. And worse if someone undoes the fix and we go at it again.* Learning by mistake is one of the best ways of getting things better and faster. But you can't really learn if you don't know you're making a mistake. I've made mistakes on the database a few times and by moderating I've learned what to avoid and what to concentrate on. So I'd hope moderators would take more time checking those entries and also using more than just one source of information (Moby Games is really good, but not all information is correct/accurate there). Be more critical, you're not being nasty if you reject (as long as your comment is appropriate) and you can always use the yellow "skip" button if you are unsure of accepting or rejecting. By rejecting something wrong the submitter will at least get a reason what went wrong and most likely avoid doing it again. * a recent example of fix, unfix, fix unfix: https://gamesdb.launchbox-app.com/games/details/40383 By rule the name should always be the way it is written on the cover, in that case: "1994 (The Year After)". We can use the alt names field for scraping if someone has difficulties getting that game imported. But I didn't have any problem importing it when it was properly named "1994 (The Year After)". False claims or just opinions on the comment field is also an issue if some moderators take them for granted instead of actual database rules. I think the forum should be used for cases like you just brought up: continuous corrections, instead of using the moderation comment field. Otherwise only the few moderators reading the comment on the database will see it.

Thinking of this, separation & additions (for more than just regions) by extension, instead of separate entries/sub-entries actually sounds very much like the new GUI updates that were made in the Launchbox App, which allows for more content to be handled in the Edit option. That approach could indeed work with the database and could be the most likely way to go. But as I've said before, my guess is that it looks to be much more complicated/time-consuming making changes in the database structural code (it also needs to work properly with the App, changes will be needed to be done there too) than we'd expect - not about the will of doing those changes. Probably some longer downtime would be needed too, lots of testing etc. And who knows if the database coding was made by someone not part of the team anymore. And we shouldn't forget that the To-Do-List from the last Poll isn't complete yet. But those are just guesses, nothing to make any conclusions of. I'm sure Jason will clarify as soon as he can. Hopefully everyone is OK in the US with the LB team. Things look very critical there with the virus etc. All we can do now is patiently wait. I appreciate everyone's input/feedback on this so far, thank you! Looks to be more than just a guideline discussion