Jump to content

Aemony

Administrator
  • Content Count

    261
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by Aemony

  1. GOG's store page does mention the following at the bottom of it: Is this not correct? Does the game actually include the 32-bit executables as well? Also, what form of DRM are we talking about here? Various Crysis entries have been found to include the anti-tamper component of SecuROM still active and enabled, but with the DRM functionalities disabled. Typically speaking PCGamingWiki doesn't per se treat the anti-tamper component of SecuROM as DRM, as it only rears its head when attempting to do stuff like inject third-party DLL files, and otherwise don't enforce any form of copy protection (which differs from Denuvo Anti-Tamper, for example, which has its occasional online connectivity requirement).
  2. In terms of leveraging PCGW, a couple of questions comes to mind: How would this sort of game-specific information be covered? In the game articles themselves or on a separate page? How would we ensure that users are aware that things might've changed after an update and these sorts of arguably more volatile changes might break their game? What would the benefit be of leveraging PCGW's backend? Even if we were to cover this through the web API query endpoint, something have to be run locally to actually perform said queries. If it was decided to leverage PCGW's backend, which one of our various solutions would be best for this sort of things? Typically PCGW actually doesn't really care about the disk space usage of a game all that much because it is prone to differ between users, DLCs, localizations, etc, which means any potential shown "savings" will not be applicable to everyone. Today we, for the most part, merely avoids this headache by merely stating the system requirements, and in the few cases where the system requirements are way wrong we state an approximation of the real value, and then a note about how the system req is wrong. In regards to the third one, it wouldn't really necessarily result in much. An arguably easier solution would be to have whatever local program/script that was thrown together automatically download the latest copy of a GitHub hosted INI file that included all detection algorithms (if any were set up) along with all file/folder rules that were to be removed. In fact, did you know that the 'cleaning tool' CCleaner makes use of an easily configurable "database" of that exact kind? And that an insane custom INI file can be downloaded straight of a GitHub repository that allows users of CCleaner to extend its "cleaning process" to also include a whole ****ton of applications and even games? Take for example its entry on A Hat in Time: [A Hat in Time *] Section=Games Detect=HKCU\Software\Valve\Steam\Apps\253230 FileKey1=%ProgramFiles%\Steam\steamapps\common\HatinTime\HatinTimeGame\Logs|*.* Detect A Hat in Time by checking for the presence of the registry key HKCU\Software\Valve\Steam\Apps\253230. If it is detected, allow the cleaning of all files below %ProgramFiles%\Steam\steamapps\common\HatinTime\HatinTimeGame\Logs. In regards to the fourth bullet point, if one were to leverage the PCGW backend one would have to avoid Semantic MediaWiki entirely. I once set up e.g. the Windows config paths test property in Semantic MediaWiki in an attempt to store and track entered data/save paths and make them queryable and one issue that I never was able to fix was SMW's inability to handle forward slashes (/) properly. 😖 That's why there's only properties for Windows paths -- Linux and macOS paths uses forward slashes which just broke the whole thing because (Semantic) MediaWiki thought they were HTML code or something... 😐 Anyway, a separate program using a separate INI-based database akin to CCleaner currently looks like the better alternative in my eyes.
  3. Currently there is none, but we did bring the discussion up on the Discord a few hours ago though without any conclusion as of now. My own preferred way of doing it is to direct link to the content as much as possible. One example that was linked on the Discord was a link to a Patreon blog post that had the content as the "primary focus" of the linked page, with the donation being a secondary focus of the page (it was only present in the sidebar). This is fine by me, but the latest Coffee-links however is the other way around -- the primary focus is to drive donations with the secondary focus being the patch itself (currently with a broken link). A donation "gateway", if you will, that the user must pass before they're able to get to the content proper. We'll have to wait and see what the discussion brings us to, and after that write a proper policy about these sorts of things.
  4. Thank you, now the download works! 👍
  5. @asabarabi, sadly it seems the forum software can't handle the name of the file you uploaded. Can you remove any special characters etc and ensure the file name is only named using regular Latin characters such as A-z, 0-9, and dots/underscores/dashes, etc ? Then re-upload the file again by using "File Actions -> Upload a new version".
  6. PCGW has a mutual linking relationship with IsThereAnyDeal (see https://www.pcgamingwiki.com/wiki/PCGamingWiki:Partnerships#Mutual_linking_relationships). Because of that, any potential replacement would necessitate a similar linking relationship before it would be implemented, I imagine.
  7. Aemony

    appid bug

    Stale data in the Semantic MediaWiki backend — it happens and usually resolves itself after the game article gets purged or a null edit is performed.
  8. Probably a false positive, though you've to decide yourself whether to 'trust' the file or not. PCGW in general does not guarantee the safety of files, and due to the numbers of false positives occurring in gaming related files -- particularly those created using e.g. Cheat Engine -- we usually don't remove uploaded files either due to "virus detections". See the "Virus detected in PCGamingWiki file" section for a bit of context.
  9. Performance is much more determined by sheer compute performance of the GPU and not the amount of VRAM it has, so basically no answer that involved VRAM would be relevant for such a question — especially for lower end cards. The amount of VRAM is only relevant in a few edge cases where /technically/ the GPU has enough compute power to deliver a higher performance, but it’s being bottlenecks by the lack of VRAM and the constant need to move data in and out of the VRAM. But even proving such a thing is ridiculously hard since it would basically require an identical card but with more VRAM to compare to, with the rest of the system being entirely unchanged. In regards to game benchmark sites, I don’t thinks there’s any worth evaluating. Game performance is heavily affected by basically all major components of a system, from the GPU and CPU and even sometimes down to the PCIe lanes used for the GPU. A “perfect” game benchmark site would basically have to test an insane amount of permutations to cover all bases, which is impossibly expensive. Even more so when factoring in various video quality settings of the game. Most game benchmark sites just seem to (if even that) test minimum and recommended system requirements and then guess whether a certain config might get a better experience or not compared to those.
  10. Also, if this was an actual suggestion to add additional VRAM rows to track actual usage, then sadly, that's basically impossible due to the previously touched upon topics -- most tools nowadays lies to your face about actual VRAM being used by a game, and other games (or tools) might not even have a proper way to look up actual real VRAM usage of a game (for example, Vulkan doesn't have a built-in way of tracking VRAM usage if I remember it correctly, forcing developers to use DirectX's DXGI memory budgets instead to track 'em).
  11. You mean the VRAM usage number in the system requirement section? It's just mirroring the official system requirements, which is based on the QA testing of the developers. It's less about the number itself, and more about whatever amount of VRAM the "minimum" and "recommended" GPU has. Beyond that, most games use _much_ less VRAM than people might assume. Tools such as GPU-Z, RTSS, etc all reports _requested_ VRAM -- not actually used VRAM. And games might request way more VRAM on GPUs with more VRAM than they actually use. For example, a ton of games I've played have barely used more than 3-4 GB of VRAM even in 4K -- I think Watch Dogs 2 and Monster Hunter World were examples of this. That basically means that even going forward, the amount of VRAM that is actually necessary to play a game is vastly less than what many might assume. See the below thread for a good overview of it all: https://www.resetera.com/threads/vram-in-2020-2024-why-10gb-is-enough.280976/
  12. The last part of the recognized virus definition “!ml” suggests the definition was created through machine learning. Basically there is an extremely high chance of it being a false positive. @Rose is otherwise a well-known and recognized ultrawidescreen modder whose patches occasionally runs into AV’s false positives. @cbk@csolutions.no, at the end of the day you yourself have to determine if you put your trust in a stranger online, but for what it’s worth, I personally highly suspect this is a false positive. Of course I can’t say for certain, but then nobody really can unless they created the executable themselves.
  13. Not sure this is possible. From the looks of things, Wikipedia relies on the Extension:ElectronPdfService (partially outdated info) extension that basically installs Chromium (the core of Google Chrome and modern Microsoft Edge browsers) on the servers and then interfaces with it using a Puppeteer library, as described on the Proton page. So it's not some simple or minor extension as one might imagine. As a result, it might not be compatible with PCGW's infrastructure at all since we're using a nonstandard setup that has various limitations that might come into play here.
  14. Don't like all modern browsers feature a "Print to PDF" or "Save as PDF" option in their printing options (Ctrl+P) ? I'm not saying that it's necessarily the solution, but for occasional printing/exporting to PDF it should be an accessible option already.
  15. I used to use BitDefender, and it was great up until the moment when it wasn't. For me, it was how injecting the Advanced Thread Defense module (scans processes I/O operations from within) often caused games and applications to crash -- with no real identifier about what caused the crash. Ubisoft games that were frequently updated in particular often saw major issues with it. It have historically had compatibility issues with other third-party tools such as Special K. It also had a tendency to constantly remind you of its presence, even if it were to notify you weekly about latest threats it prevented (0, every week). So after having used it for like 1-2 years of my 3 years subscription I ended up removing it from my machines one at a time as I noticed that Windows' built-in Defender provided me with basically the same level of protection with higher third-party compatibility and it didn't nag me about its presence. I still like BitDefender, but... nowadays I don't necessarily needs the most advance or in-depth security suite as user action is still the first (and most important) line of defense.
  16. From my understanding WoW is the only officially recognized one. But it might not be accurate since, based on comments I’ve seen from regular app developers, it’s basically just a recompile of most projects that is needed. A list can be created rather easily — it just needs to display pages in the games category that populates the new ARM property to true. Which right now is only WoW. Also, you hit on an important aspect in terms of testing methodology... I don’t have a Mac myself, but I can imagine Apple doesn’t make it necessarily easy to spot whether Rosetta 2 or native is being used. Well, unless you /don’t/ have Rosetta 2 installed at which point (as I understand it) macOS will prompt to install it.
  17. The macOS (ARM) property was implemented as it was because it's not really feasible or easy attempting to implement it into the actual executable table because of the following reasons: The executable table contains horrendous underlying logic that is hard to work with that determines whether to show/hide columns in various scenarios. The column also interacts with variables set elsewhere (e.g. overall OS states set through the infobox, etc) which ends up causing the difficulty to increase exponentially. Each new column added eats into the Notes field's width of all rows, and with us limited to 820px at max for this table (it's the global max-width for all tables) the notes field can get a bit too small in the worst-case scenarios (all columns visible). This is further exacerbated by how all columns technically relies on the same single notes parameter... As you mentioned "ARM" can technically be divided between ARM32 and ARM64 meaning a proper solution would see implementation of both if we want to properly distinguish between the two. I searched around yesterday trying to figure out if Apple's M1 supports apps in ARM32 or only in ARM64, which I sorta failed to come to a conclusion on. Technically the chip seems to support some ARM32 instructions, but I didn't manage to find a conclusive answer to whether macOS allows the use of those instructions or not. Another potential issue that arises is the fact that the row is currently called "macOS (OS X)". macOS 11 Big Sur which the Apple M1 chip requires is not "OS X" any longer (for once Apple actually left the 10 behind!), and so ARM support can be said to not apply for OS X at all. Basically, much like the notes parameter, the name of that row currently jumbles it all together. This could possibly be solved by renaming it to just "macOS" instead, but that's provided there aren't Mac OS "Classic" apps that have the PowerPC property set on them -- and it would still technically be suggesting macOS have PowerPC support... The row would preferably attempt to (more convoluted logic) have different names depending on scenario, so it was called just "Mac OS X" (or OS X) if PPC and Intel 32-bit was the only columns set to true, and "macOS" if Intel 64-bit was set to true, or something... Basically a moving change to attempt to adhere to the actual name of the OS at the time of the game's release. On another note, Apple's renaming of their OS and moving architectures as an PCGW template creator/editor is just... gah! I know the current implementation of macOS (ARM) property isn't perfect -- I called it 'half-assed' multiple times yesterday on the Discord when I implemented it -- but it was the quickest way of adding support for a new important parameter that didn't force me to waste days trying to untangle the whole mess to arrive to a 'proper' solution that worked within the various limitations we have while still handling all different scenarios perfectly. I might revisit the matter eventually, but right now the fact that I'm basically the only one that over the last year or so have been responsible for more in-depth complex changes to the PCGW templates means that unless someone else steps up and finds a working solution, it's all on me... And I'm currently both busy elsewhere but also tired of having another infuriating tangle with MediaWiki and the extensions that implements limited logic-based functionality unto it, as well as the limitations/requirements that PCGW enforces on the whole thing. Eventually, maybe, but I make no promises.
  18. This would just restore the previous status quo: due to lack of clear guidelines we would create scenarios where Audio > Subtitles and Localization > Subtitles didn't match each others -- it would basically restore the previous confusion that we solved by enforcing n/a in the first place. Then we would revisit this issue months/years down the line and most likely reimplementing the same solution (have the guidelines mention to use n/a) to clear the confusion up. Rinse repeat. This ties into the other discussion about adding abbreviations to all rows of the tables clarifying whether the row covers support for something as opposed to a setting for something. Though somewhere down the line I seems to have removed the example I threw together -- probably as a result of the discussion not really going anywhere beyond the initial draft thrown together and separate development requiring my focus and sandbox page elsewhere. The latest example I had thrown together (for the Input table) can be found here: https://www.pcgamingwiki.com/w/index.php?title=User:Aemony/Sandbox&oldid=788170 Anyway, following the above draft, the subtitle row would be abbreviated with something like this: An option is available to control the display of subtitles for spoken dialogue in the game.
  19. The previous post of mine described the solution to achieve such a thing, and then how we would have to go about solving the follow-up consequences of such an approach (with the property being what was used to populate the 'additional devs' in separate lists on the company pages). Implement-wise, Infobox game would basically include a new section above (or within) the current developer section that said something like: {{#vardefine:additional devs|{{{additional devs|}}}}} The above would execute/parse whatever we stuffed into the "additional devs" parameter and store its result in a variable. Then within Infobox game/row/developer we would have an additional section: {{#if: {{#var: additional devs|}} | <!-- lots of code here that would create the one-symbol note template and populate it with the contents of {{#var: additional devs}} --> <!-- finally at the end, we would clear the stored variable to prevent subsequent Infobox game/row/developer rows from also triggering this whole new section of code (which would've added the one-symbol note template to all Developer rows) --> {{#vardefine:additional devs|}} }} It seems that a separate property for these types of "associate" or "additional" developers would be the best, along with a separate list entirely for this sort of contribution on the company pages. It would allow us to eliminate huge rows in the "Games developed" lists such as is featured on e.g. https://www.pcgamingwiki.com/wiki/Company:Ubisoft_Montpellier However it would also mean that we would have a minor question on our hands as to what columns to display in the separate "Games additionally developed" list: Should we display Developer, Publisher, and Engine as in the current "Games developed" list ? (so not list the new "Additional development by" property) Should we display the new property, Publisher, and Engine -- making away with the "main" developers of the game? Should we display Developer, Publisher, and the new property -- making away with the Engine property? Or any other combination of columns... We're limited to 820px in width for these tables if we want to ensure proper display across all possible page mutations as well as a unified column width across all lists featured on a company's page, so that limits us to just 5 columns that we need to pick and choose between accordingly to what we feel is the most relevant to our userbase. And so, woe is me...
  20. I'm... a bit confused about this one -- do you mean that the games should be listed on those companies' pages? If so, then the solution would probably be to add a new parameter to Template:Infobox game that's called e.g. "additional devs = ". I could probably (unless MediaWiki throws a blanket in my face again) code in logic in the templates that would see special handling of Template:Infobox game/row/developer if it were present within an "additional devs = " parameter. Or we could create an entirely new Template:Infobox game/row/associate template or similar. If we were to go for an "additional devs = " parameter, I could then probably add logic that automatically saw its inclusion at the end of the first Template:Infobox game/row/developer present in the article. In the "backend", the additional devs parameter and its contents would technically have to be expanded/parsed before we expanded/parsed the actual developer parameter (this is because I would have to store the results in a MediaWiki variable for later retrieval within the first "Template:Infobox game/row/developer"), which might affect property assignments (associated studios would be populated before the main studio). To solve the property thing, we would have to set up a separate property (perhaps call it Property:Developed by (additional) ?) for these associated studios to get populated in instead. To solve the lists on the company pages, we would either change the current "Games developed" Semantic MediaWiki query to include games which listed the studio in the Property:Developed by (additional) property, or list those games in a separate new list ("Games assisted with development" or however we would phrase the title of the list). ... Ugh...
  21. Just to be clear: based on the editing guide as it is now, this isn't actually incorrect though as n/a is used correctly on that page. The game has no spoken audio -- there's therefor nothing that needs subtitling and so both rows are set as not applicable. PCGW currently defines subtitles as being solely for spoken dialogue and so it simply isn't applicable for non-spoken dialogue (which is handled through the UI flag). I have forgotten the details, but I believe this definition was arrived to because we keep track of the in-game setting of subtitles as well -- it was basically a definition made to get localization and audio tables in line with one another so that we didn't create scenarios where the localization table would say that subtitles were "true" while the audio table (which tracks in-game settings) would say that an in-game setting for subtitles were not applicable as there's no spoken audio that needed subtitles to begin with. It is because they technically track separate things, while (as with everything else) being the result of years of micro-changes etc that have slowly but steadily changed their purpose and use. The audio table rows track whether an in-game setting actually exists for controlling subtitles (for spoken dialogue) or closed captions, whereas the localization table tracks whether a specific language has available subtitles or not. Related properties, but not identical. There's a separate but related discussion about how we can improve the state of the tables, as some rows track "settings available" while others track "feature support" (again: similar, but not identical). "Closed captions" though currently have even less of a counterpart in the localization table, as that row solely tracks whether closed caption descriptions for audio effects etc are available or not in the game. If we were to remove that row we would effectively remove the ability to identify games with additional closed captions available as an accessibility option for hearing-impaired players from those with merely regular subtitles but without closed captions. As I understand it, typically speaking closed captions isn't tied to a single language or so -- if the game have closed captions then it is generally supported by all localized subtitles. Removing the two rows in the Audio table would result in the following: PCGW loses the ability to keep track of how subtitle/closed captions can be controlled through the settings of the game. Whether they can be controlled separately, is always enforced, or not applicable at all (there's no spoken audio that needs subtitling, as per PCGW's current definition). This can, in parts, be counteracted by allowing these various states through the localization table, but then we're attempting to convey separately related but not identical concepts such as subtitles, closed captions, hackable official/fan-made localizations into a single 'hackable, always on, true, false' state. While also instead of making a single change to change the overarching state of subtitle/closed caption related settings, the editor would have to make changes to every single localization row across all languages while also trying to adhere to existing stuff such as version-exclusive localization and whatnot that might be present. PCGW also loses the ability to separate closed caption-enabled titles from merely subtitle-enabled titles. This should be self-explanatory, really, and should be seen as major lose of information for both regular players as well as hearing-impaired players. Welcome to the world of wiki editing and not clearly defined requirements. PCGW is technically the harder one here with our current definitions, whereas Steam/GOG doesn't actually care in terms of how developers label and make use of those parameters, which is why devs can define them however they want which causes examples of basically any combination you can think of. --- Changing over n/a to true / limited is doable but creates scenarios, some of which I touched upon earlier: If we only change it in the localization table and not the audio table we create a situation where localized subtitles can be set to true while audio table subtitles (keeps track of whether an in-game option for controlling subtitles is available etc) can be set to n/a (not applicable, as the game has no spoken audio that needs subtitling). If we change it in both locations PCGW would suddenly state that thousands of games that have no in-game subtitle option (because there's no need for one) suddenly has one, and can be both enabled or disabled (that's what 'true' means in this context after all). This is possibly fixable by enforcing the newer 'always on' state for the audio table in scenarios where no spoken audio exists (though that is sure to create its own share of confusion -- "Why does the row say it's 'always on' when there's no actual subtitles in the game?" ). If we change it in the localization table but then removes the audio table row for subtitles then we lose information whether subtitles are always enforced, limited, or hackable along with notes regarding that option. If we were to also remove the closed caption row in the audio table we'd lose additional information as touched upon earlier. There is no easy solution here as I see it -- localization table and audio table tracks related but ultimately separate things, and PCGW have done almost everything we can to minimize confusion. Any chance implemented would see data get lost in the translation, limit what editors can convey through the current settings, or create confusion elsewhere. I'm not sure which (if any) potential solution I prefer so far over the current status quo, but the potential solution I drift towards would probably be changing the localization table (n/a > true) while removing the subtitles row in the audio table entirely but retaining the closed caption row (I really don't see that row get removed due to its relevance where applicable). We would still lose information, and basically assume users would just have to content with the information exposed by the localization table, but overall the current confusion would be resolved (though new confusion might arrive elsewhere -- can't tell atm) while we would still track closed caption and be able to list games that actually have additional accessibility for hearing-impaired players.
  22. Can you quote the relevant parts of the editing guide you find contradictory? I'm having problems finding just what parts are contradictory of how both handles their respective subtitles row: Editing guide on subtitles in the Audio table: > Applies for games with spoken dialogue. If subtitles are always shown without an option, set this field to always on. For games with no speech or text-only dialogue, set this field to n/a. Editing guide on subtitles in the Localization table: > The subtitles and/or closed captions for the game are localized to this language. More common to find than spoken audio localizations. > If a game has no speech, gibberish for speech (single word remarks fall into this category), nor any closed caption option, set the field to n/a. These are not broken -- they are merely two out of many lists that have yet to be created. This is a minor oversight probably caused by, as everything else, minor changes over the years.
  23. It's because of how HTML works in general -- consecutive spaces are treated as a single one unless there's an element that tells it to treat the inner contents as monospace / terminal-like manner. I've fixed it by specifying two non-breaking spaces instead.
  24. Version 1.0.0

    1,872 downloads

    Description: The mod makes the texture streaming more aggressive. There is also an optional config that also loads high-resolution textures sooner and increases the texture pool from 1 GB to 2 GB. Installation: Simply extract the archive to the game folder. The default config only makes the texture streaming more agressive. If you also want it to load high-resolution textures sooner, browse to \data\globaldb\ and remove tweakables.xml, then rename tweakables_high_quality.xml to tweakables.xml Configs: .\data\globaldb\tweakables.xml makes the texture streaming of the game more agressive. .\data\globaldb\tweakables_high_quality.xml is an optional file that also loads high-resolution textures sooner. Rename the file to tweakables.xml to have it be applied. Additional information: This is an archive that combines two other mods as well as a texture tweak in one archive: Loose Files Loader by reg2k / registrator2000 Link: https://www.nexusmods.com/control/mods/11 Files: .\iphlpapi.dll Tweakables by reg2k / registrator2000 Link: https://www.nexusmods.com/control/mods/14 Files: .\data\globaldb\tweakables.xml Blurry textures fix/streaming tweaks by hallatore Link: https://www.reddit.com/r/controlgame/comments/j0hff1/pc_ultra_graphics_mod_also_fixes_blurry_signs/ Files: .\data\globaldb\tweakables.xml, .\data\globaldb\tweakables_high_quality.xml
  25. The change has been implemented and is live in the editing guide.
×
×
  • Create New...