Garrett

You are probably not going to find much information about these releases outside of detailed fan sites about that game or series. I don't think there would be any sort of comprehensive source for this sort of thing. MobyGames has listings for some of these, but like anything this is not complete (e.g. there is a listing for Taco Bell promotional games, but your Frogger example is missing). In most cases, promotional releases of games didn't have any differences in game content.

Yes, but going by the Redump dumps it looks like only some releases used it (it isn't mentioned for any of the Eagle Watch dumps). Going by the wiki, SafeDisc 1.x/2.x games have a file on the disc called SecDrv.sys; if your disc doesn't have that file it isn't using SafeDisc. Many games also removed the SafeDisc check in a later patch (which wasn't necessarily mentioned anywhere in the patch notes), so those games run fine from a protected disc after patching. I don't know whether this is the case with Rainbow Six. Back in the SafeDisc era, SafeDisc protection didn't always apply to all regions (this could depend on the publisher/distributor or other factors) and was often dropped for bundles and updated releases. Game releases that didn't use SafeDisc would often still have a basic disc check that simply looked for the necessary files on the disc (rather than verifying the physical disc's authenticity). Things get even more confusing in later years where you find cases like a game using SecuROM in one region and StarForce in another (some older versions of StarForce don't work at all on newer versions of Windows whereas SecuROM versions from that same era should still work).

While there is no guideline for this, most series name clashes have been resolved by having the series name end with the developer (or publisher, or whatever is suitable), e.g. Series:Dracula (Frogwares) - this also has a disambig for the other (unrelated) Dracula series.

This was due to an unexpected behaviour change with how the Cargo query was working; I have updated how the Warnings are generated to avoid this happening in the future--when the data is missing those pages will now correctly omit the warning (some affected pages may need to be purged but this should carry over to most pages).

Sure, I have added these steps to MDK's Issues fixed section now. Feel free to make any corrections or improvements to the steps on the wiki page, or you can suggest them here (whichever works for you).

Installation is failing because the actual SETUP.EXE used to install the game is 16-bit (which won't work on a 64-bit version of Windows). Make a copy of the complete CD contents somewhere, and extract the InstallShield 3 32-bit Generic Installer into the SETUP\ENGLISH folder there. Run setup32.exe and follow the steps. You should be able to install the game normally. This sort of workaround will also work for other games using a 16-bit version of InstallShield, but you might need a different version of the replacement installer (InstallShield 2, InstallShield 3, InstallShield 5). You can find out what version you need by going to the Properties for SETUP.EXE (or similar) and noting the file version listed there. For MDK you won't need your temporary installer folder (the game will load things from the CD as usual), so you can simply delete it, but some other games might actually point configuration files etc. to the specific path it was installed from. In those cases you could simply make a semi-permanent place to store your fixed installer folder while you're playing that game, or correct whatever config file is looking there.

There wasn't really a strict distinction of what sort of platforms would and wouldn't be covered back when the wiki was started. Windows/OS X/Linux were there, of course, and the inclusion of classic Macintosh and DOS/PC booter games came about naturally, in part because those are part of the modern system lineage to some degree (you can't necessarily run them on the newest systems today, but there is or was support for running that legacy software on the modern successor OS at some point along the way). I've tried to distinguish classic Mac OS from OS X where possible while editing (this isn't made easy by sources like MobyGames treating this as an unbroken lineage). I don't know enough about the classic Macintosh era to say whether a singular classic division is sufficient or even correct. Defining what a PC 'is' might be a bit broad; if you would like to see a particular system added I'd suggest making a topic for discussing that individual case. Streaming services are probably never going to be covered (except as an aside on pages for games with normal versions) because you're not actually playing it on your PC in the traditional sense, you're just using your PC to send commands and view the resulting output (identical to using that streaming service on your TV, phone, tablet, etc.) Some clarification in this area will inevitably be required in the near future with Android apps coming to Windows 11 through the Microsoft Store (these apps will run directly and function just as you'd expect a real native app would)--especially if there end up being weird cases where there is (or was) both a native version for some OS and also the Android version in the store.

This should be fixed now.

It would probably make more sense to tag this on just the file rather than the past, e.g.: {{file|config.cfg|binary}} This would mean the result would be other other way around out of necessity: This would also make it possible to tag files when mentioned individually, e.g. for games where there is a breakdown below the table for what each file does.

I drafted an accessibility template a while back which included a save system section, but at the time I hadn't considered handling permadeath, respawning, etc. One option would be to have fields that support keywords, similar to the infobox taxonomy, so that multiple options can be specified to accommodate games where multiple possibilities apply (e.g. Minecraft optionally supports permadeath). Death/failure: What happens when the character dies or you trigger a failure state in a mandatory task required to progress the story (the enemies destroy the base, a critical NPC gets killed, etc.) Reload - you can only roll back to the last save/checkpoint, no progress is retained (other than maybe some meta thing like achievements) Respawn - infinite lives: games like Minecraft - death/failure jumps you back to the last rest point etc. as often as needed and retains at least some form of progress (unlike rolling back to a checkpoint) Respawn - limited lives: as above but you can only try again if you have lives (or equivalent) remaining, after that it's game over Permadeath - dying means game over (in some games this might unlock additional characters etc. for the next run, but that particular run is over) Save system: How you can save the game Continual save - games like Minecraft (everything you do is constantly saved with no player input) Autosave - game progress is saved automatically (based on some criteria specific to the game) Save anywhere - you can do a manual save whenever you like Save anywhere (outside combat) - games like Mass Effect where you can save anywhere as long as you are not actively in combat Password - games that save through a password that must be entered to return to that point None - games that can't be saved at all (you have to finish the game in a single run) N/A - games where the concept of saving does not apply (e.g. multiplayer-only games where everything is retained online) There should maybe be some way of identifying whether you get save slots (so many games now have a single save per character or whatever with no way of going backwards to an earlier state). Anyway, see what you think.

When you combine existing OS drives like that, your system will start with whichever drive is set to boot first in the UEFI/BIOS settings. You'll then see the other OS drive and you can move over whatever files you want (you'll need to "take ownership" to get to files inside your old user profile).

Install folder is not particularly useful. If it's a retail or DRM-free game you most likely got a choice of where to install/extract it to, and if it's a digital game there is an easy UI option in that store's client for jumping right to the install folder. The install path also varies greatly between stores. As for your captures, if you really can't find that you could use Everything (or the Windows search in a pinch) to track down wherever it got saved to.

I have now updated the Audio template to support the new row. As always, let me know if there are any problems with this.

Games referred to this as "Red Book" quite a lot back in the day, often using both terms interchangeably (some like Descent II actually call it Red Book most of the time). The template text has both terms, so even if a reader has never heard of Red Book its meaning can be easily inferred (and is then confirmed by the tooltip). Putting this term in the template will hopefully also reduce situations where this is set incorrectly (e.g. for games that stream audio files from the CD rather than playing actual tracks). Based on a few test searches, internet search engines do not appear to know that Red Book is another term for CD audio in the context of gaming (search results are completely different unless pages happen to mention both terms), so search keyword accessibility is another strong reason for putting both terms in the displayed text. As I said there are implementations that don't use APIs at all, so handling this with an API focus would inevitably involve ambiguity (which can already occur with some parts of the API table, e.g. being able to set "OpenGL versions" to unknown) and therefore should be avoided when less ambiguous options are also available.

Going by the documentation, $wgPageImagesLeadSectionOnly should be enabled to ensure only images above the first section (in this case Availability) will be considered. It might also be necessary to change the resolution values to ensure any valid image will qualify (the extension page is a bit vague regarding the non-Wikimedia default values). A ParserFunction-style way of tagging the exact image to use would still be preferable to trusting any sort of algorithm, but with a bit of tinkering this should work reliably for at least game pages and probably the company and engine pages as well. The PageImages extension added OpenGraph support in MediaWiki 1.29, so this feature probably didn't exist at that time.