matortheeternal

Sounds to me like you just have a corrupt save. There probably isn't an easy fix.

It'd be great if the 200 responses would be documented through swagger so we can know the data format to expect for a successful request without having to actually test the request ourself. I'm happy to help out with adding that if the Nexus Staff don't feel like they don't have time to add it themselves. I must say that this change really makes it feel like Nexus Mods has moved forward in supporting developers of third party tools. It's a great step to take and I wholeheartedly approve. :thumbsup:

Reinstall Mator Smash. Also please use the Nexus Mods mod page instead of this thread in the future. :thumbsup:

I feel like there are other dev tasks that would be more worth spending developer resources on. That said, having some cool merchandise wouldn't be a bad thing. I'm not the biggest fan of Nexus Mods, but I might spring for a shirt if the price was right. EDIT: If there was merchandise that wasn't Nexus-Mods-branded, I would be more likely to purchase it. I think I speak for a number of people when I say it all depends on the design and how strongly it appeals to me.

Honestly, the more I read in this thread the more of a mistake this whole captcha business appears to be.

What about "legitimate" bot accounts? Are they just SoL if the API is insufficient now? This change seems like a monkey patch for a larger problem. There are many ways for you to secure logins without forcing users to respond to a captcha challenge: 1. Throttle login attempts. Don't allow more than, say, 6 attempts per minute. Throttle at whatever rate is sufficient to prevent brute force attacks but not bother users who forgot their password. Maybe set an upper limit on 30 attempts before locking an account and requiring the user to respond to an email to unlock it. This is a fairly standard system. 2. Use IP address and device information to authorize access to the account based on the device the user is accessing the site from. Steam does something similar to this. This basically requires the user to "authorize" a device which has not been used to log into their account before by clicking a link in an email sent to the address associated with their account. 3. Add and encourage the use of two factor authentication. 4. If these are "too difficult or time-consuming to implement" then wash your hands of users who do not understand the basics of password security and ignore recommendations to not use the same password that they use on other sites (assuming this recommendation is made visible whenever a user creates/changes their password). If a user sets themselves up to have their account hijacked that's their problem, not yours. If the aforementioned security concerns go beyond "brute force" or "third party accounts with the same password cracked" then I have to ask what the hell is going on with your login system to create such issues in the first place? Most attacks are fairly easy to protect against - use HTTPS to protect against man-in-the-middle attacks, use an token to prevent against CSRF, use throttles/locks to protect against brute force, and educate users to help them protect themselves against password reuse/weak passwords. The only kind of attack which is difficult to protect against (but rare in the wild, especially with websites) is a timing attack. You can also throttle logins in general, not allowing the same IP address to make more than a certain number of attempts per minute/hour/day, regardless of the account they attempt to log into. Such a throttle can be set at a value that a human is likely to never encounter (e.g. 200 login attempts/day) but would put a serious damper on illegitimate bot activity.

In response to post #60377462. #60378147, #60380477, #60382372, #60393797, #60402592 are all replies on the same post. There are other problems with your proposition. It would weigh new games with very few mods disproportionately heavily. Consider a hypothetical game, we'll call it H, which has only one mod, M, by a single author, A. In this hypothetical scenario, A would receive a lion share of DP because they make the only mod for the game. It simply doesn't make sense to distribute DP equally between each game the Nexus supports.

In response to post #60377462. #60378147, #60380477, #60382372 are all replies on the same post. anyjs: I don't think that makes any sense. DP should be distributed to creators on the Nexus platform based on the impact they have relative to other creators, regardless of the game they're creating content for. DP cannot be weighed against the "quality" of the content as that is not feasible to measure, it can only be weighed against the "impact" of the content, which can be roughly determined the number of unique downloads weighed against the total of all unique downloads on the entire platform (which is the platform's total impact). The only thing I could think of is allowing users to donate into DP pools for specific games. It wouldn't be too great an increase in technical complexity and it would mean someone who only uses Morrowind mods donating into the DP pool won't have 95% of their money going to authors who exclusively create mods for other games.

Looks decent to me, but Gameplay category could probably be a fair bit higher. These are the categories and ordering I put together for Mod Picker: Fixes Resources - Frameworks Gameplay - User Interface Utilities - Ingame Locations Gameplay New Characters Items Audiovisual Character Appearance Utilities - Patchers

Mator Smash is now available on Nexus Mods. Please use the Nexus Mods Mod page for all future discussion. Nexus Mods Mod Page

Sounds like an antivirus is not letting Smash load the plugins.

yes.

Working on it. Not in this iteration of the tool.

You can change them to Smash.All. Their settings were automatically assigned based on bash tags found in their description, but you can ignore this because the way Smash's algorithm works is such that Smash.All (or Bash.All) is the ideal setting to use for all plugins.

The merge redundant plugins feature has been removed.