All Activity

Wow, thank you very much!

If you're still interested in RDA archives from No Man's Land game, here's a quick bms script that will extract and import data for you https://github.com/bartlomiejduda/Tools/blob/master/NEW Tools/No Man's Land/No_Mans_Land_RDA_script.bms Here's the tutorial on how to use it: https://ikskoks.pl/tutorial-what-is-quickbms-how-to-export-and-import-with-quickbms/ Enjoy 🙂

I do not expect this to be implemented since the ”release history” parameter of the introduction template is intended for that purpose. Like, it wouldn’t just be about GOG as Steam, Microsoft Store, and even Epic sometimes sees similar re-releases. Right now there’s multiple ways of handling these re-releases: * Introduction template’s release history parameter, for straight re-releases on modern platforms. * Separate year-dated article for the re-release, for re-releases that also sees larger/more noteworthy changes.

Add GOG.com re-release date to Template:Infobox game as well as Template:Infobox_game/row/date. Thanks in advance.

I understand why it works like that, but I still feel like there is something wrong without knowing exactly what. Just for context most mac game articles are lacking this API section (support or not of Metal), and knowing if a game supports Metal is kind of a deciding factor and key information. Because if it doesn't, then it will very probably have performance issues (Vulkan and DirectX don't officially exist, and OpenGL is somewhat deprecated on MacOS). So that's why I think it would be great for Mac users to know if a game does NOT have Metal support on a game article (without having to go to the article source to check if someone actually filled it). I think it would not add unnecessary clutter to make APIs marked as "false" visible to visitors. Especially because most (if not all) of the time, if an API is not supported then it is not even marked as false (at least on the few articles i checked). So the only time it would really be visible, is when it is important to know it's not available (for the Metal API for example). I hope I made myself clear enough and that I'm not too insisting on this, and if you still think it's wrong I will gladly read your opinion on this matter. Thank you for removing the "support" part of Metal and Mantle by the way 🙂

I've dropped the "support" part of both Metal and Mantle (precursor to Vulkan). Note that the parameters remain unchanged so they'll still be called "metal support" and "mantle support". This hits the nail on the head -- all of the render APIs are handled the same right now: if you set an API to "false" or "unknown" it'll be hidden from the page to minimize the amount of unnecessary data that is shown for visitors. This is in contrast with many other templates, yes, but it is correct and works exactly as intended for the API template/table.

That already exists: https://www.pcgamingwiki.com/wiki/List_of_Windows_64-bit_games#Native_support_.2864-bit_only.29

Add a list of 64-bit only games.

wouldn't this be kind of pointless, though? just looking through the editing guide, graphic API support is listed based on what is available for a game, not on what isn't - so if what you're proposing was to be implemented, every single game that doesn't have, say, support for Vulkan would have to be explicitly edited in order to mention that they don't support Vulkan, which (in my opinion) is just more confusing than simply editing a game article in order to explicitly note Vulkan support for a game I will say though - changing the header name to simply "Metal" is a solid idea

这个驱动不能在win11 25h11下运行

Currently, Metal API support in game articles is only displayed if set to true. It should be displayed with a red cross if it set to false, to differentiate with games with unknown Metal support. Also it should be displayed as "Metal" and not "Metal support", like others API : D3D, OpenGL and Vulkan... To test this behavior, check Firewatch game article for game without Metal support and Hollow Knight game article for a game with Metal support.