eventHandler

Multi-step solution to Bethesda's modding problems: 1. NexusMods add an option for "Bethesda approved/disapproved" on mods. By default, mods are neither tag, and all current policies apply as normal. 2. Allow Bethesda to appoint their own moderators with the sole power of being able to apply a tag to mods "approved" (for mods they officially want to bother supporting) or disapproved (for mods violating their site rules on content). These moderators have an official title on the forums/profiles indicating they are Besthesda appointed and not Nexus moderators (they have no forum moderating power, except the ability to post/control an official Bethesda thread). 3. NexusMods disallowed from removing mods tagged "approved" for any reason without Bethesda first authorizing the removal, since Bethesda has interest in those mods being available. This means legal complaints on "approved" mods have to be handled by Bethesda, but NexusMods can handle any complaints on both untagged and "officially disapproved" mods. This step is to avoid any legal grey area and/or any NexusMods staff interference with Bethesda's official marketing and/or other goals. 4. Make the site by default only show mods that have not been put on Bethesda's blacklist, i.e. mods with no tag or mods tagged approved. The front page has Bethesda markings and clearly indicates you are using the Bethesda censored version. 5. Registered users can enable all mods similar how nsfw mods work now, which most "disapproved" mods will likely be because they are nsfw. There is a lengthy Terms of Service etc that must be checked before doing so, and mods they disapprove of still have a prominent tag somewhere on the mod's page. There is also a footer on every page now that reminds you Bethesda may or may not approve of the content of anything on the site since you are using evil mirror universe version and a button to go to censored land to make them happier. (This all has to be at least a little bit of a nuisance to people wanting uncensored mods or their legal people would never approve). 6. Bethesda redirects their links/creationkit to NexusMods. 7. Bethesda pays NexusMods all of the money they are spending on Bethesda.net ...or they at least cover the bandwidth on mods they haven't blacklisted. Some kind of cloud sharing between Nexus and Bethesda, where mods seamlessly shift from Bethesda to NexusMods servers if they are black listed by Bethesda. So in this limited scenario, the Nexus links always work, but upon blacklisting the mods disappear from Bethesda.net and the bandwidth/space costs go back to Nexus. The average Nexus user will never notice which servers/bandwidth they are getting the mods from, and since the bulk of the mods aren't going to be censored (especially the big overhaul ones that take a lot of bandwidth), Nexus stands to save a lot of money. The problem is that no-doubt Bethesda would try to integrate their pay-for-mods push onto Nexus with their leverage they'd feel they had if Nexus in any way was bound to them. Nexus would definitely need lawyers to work up the exact terms of any deals, and always have redundancy backups of mods so Bethesda can't extort them down the road. Not that any of these ideas are going to happen, but I always plan for the worst in my dreaming.

Press ~ to open the console while looking at the workbench for the settlement, then click on the workbench so there is an id for the workbench on your screen (such as 000a1b2c is the format). Type getav 349 (press enter) and getav 34b (press enter) to see the max number of triangles and draw calls, then type setav 349 <number> (press enter) and setav 34b <number> (press enter) to a value you want, like double the current amount. If you keep increasing it, eventually you will make the settlement have poor performance/lagging depending on your system specs. They set it to default very conservative values though in most cases. This is not a console hack. Using the scrap bug is much more likely to cause issues than updating the appropriate limit variables.

In response to post #31652265. That... sounds like a story I want to know more about... I like the site too, but I can't say its had that level of profound effect on me. Not as far as I know. Maybe I should think on about where I'd be without it, and see if I'm overlooking something. I'm serious here. I want to hear your story, Tony. PM it if you want. For science.

No cell service for me either, so I also wouldn't be able to use two factor on a phone. Usually its optional, but more sites keep trying to get me to add a phone for password recovery. Too many trees for reliable service, I guess they still haven't figured out a way to bounce signals off of bark and leafs. I think the hills don't help. Not even satellite tv signals work. I guess I could build a 100' high beacon to try to amplify the signal, but that seems like a lot of work for two-factor authentication to get to mods.

In response to post #28509024. #28518094 is also a reply to the same post. Oh, good question! I'm glad you raised it. From the technical definition "a non-mod is something that alters your game without modifying, repairing, restoring, or expanding any aspect, content, or functionality of it." Not to be confused with an anti-mod, which removes content from a game. Of course, we all know that for every fundamental mod in the universe, there exists a counterpart anti-mod. Note that the null-mod is the trivial mod equivalent to a .esp with no entries, if using Bethesda games as an example. However, packing 253 of these into a collection can be used to create a fundamental non-mod. If you were to attempt to make the smallest adjustment by adding one more esp, you would create an unstable non-mod which decays quickly into an anti-mod of considerable destructive power. This catastrophic phenomenon can be observed when unleashed as the baleful conflict of two powerful forces, devastating the mighty the engines of the world one seeks to enter, as it struggles to block the exe from loading with the main esm. It just shows how delicate the balance of the natural mod world truly is, and how important we study it further.

I guess we've learned that: 1) Either males are more likely to fill out surveys on modding sites, or females report themselves as male on said surveys. 2) People over 75 fall into one of these: [a] don't like to take surveys while looking for mods, either decline to answer or lie about age, [c] don't use mods when they play pc games, or [d] still get their mods from dial-up AOL. 3) It's possible up to half of all mod authors don't use mods themselves. 4) Between 53% and 97% of people surveyed claim to browse the site, but only 20% admitted to it. So if people responded honestly about the "Browsing Experience" question, then at minimum 33% responded deceptively on the "Usage" question regarding browsing, and as many as 77%* answered deceptively about it. 5) Possibly as few as 1%** of all forum users are not mod authors. *If the 3% who claimed to only search for a particular mod lied and actual claimed they browse under the "Usage" question, then only 17% of the admitted browsers can be the group of interest, and thus the maximum would be as high as 80% of survey respondents were deceptive. If those 3% did not claim to browse, then the maximum possible is 77%. **That is 1% of all site users, which is actually 1/9th of survey respondents identifying as forum users. So then it would be just over 11% are non-mod authors, if only counting forum users, and still leave almost 90% of forum users as mod authors. Just to avoid arguments, I'm going to explicitly point out this post is humor. I am aware of the flawed assumptions made in both part two and particularly part four (though the main assumption is stated, so the inductive logic that followed is valid if we note that omission is a part of the formal classification of deception in academic communications nomenclature). Part one is valid in this one case, but cannot be extrapolated to a general case based on this small amount of sample data. Part three is actually interesting to consider and entirely possible, though it seems implausible to me. I think part five speaks for itself, through laughter.

Since this is the post that comes up when searching for this topic, and ragnaroklucifer already resurrected it, here are my findings with skse 1.0.7.0.0: By default the #ifdef _PPAPI is commented out now, so you can make your own native functions without defining it (but the interface is still unsupported and subject to change in future releases of skse). To make a native papyrus function you would need at minimum #include "skse/PluginAPI.h" #include "skse/PapyrusArgs.h" #include "skse/PapyrusVM.h" #include "skse/PapyrusNativeFunctions.h"and to copy the corresponding .cpp files to your project (they come with the solution, but only the skse project has them and your plugin project cannot see the code it needs). You also need to copy PapyrusNativeFunctionDef.inl and PapyrusNativeFunctionDef_Base.inl to your project (also in project skse). This way you can avoid a) copying code and/or b) using #include on .cpp files (two bad ideas). The skse solution has 5 projects in it to be clear on the distinction, so don't confuse the overall skse solution and the specific skse project. They are common_vc9, loader_common, skse, skse_loader, and steam_loader. It also comes with a plugin_example project to get you started. You actually only need to build common_vc9 and your plugin to create your plugin dll; you only need the other three projects for reference if you are not forking your own version of skse. MyPlugin.h #pragma once #include "skse/PluginAPI.h" #include "skse/PapyrusArgs.h" #include "skse/PapyrusVM.h" #include "skse/PapyrusNativeFunctions.h" namespace MyPluginNS { bool RegisterFuncs(VMClassRegistry* registry); float DoMathFun(StaticFunctionTag* base, float fIn1, float fIn2); }MyPlugin.cpp #include "MyPlugin.h" namespace MyPluginNS { float DoMathFun(StaticFunctionTag* base, float fArg1, float fArg2) { // your own custom function to be used in papyrus scripts return fArg1 + fArg2; } bool RegisterFuncs(VMClassRegistry* registry) { // register the function with the game // note you need to have the actual function name for the 3rd argument, but I am calling it // "MyPlugin_DoMathFun" for the name it will be used as in papyrus scripts to avoid conflicts // since you can't use the namespace in your scripts like we can in the plugin registry->RegisterFunction( new NativeFunction2 <StaticFunctionTag, float, float, float>("MyPlugin_DoMathFun", "Utility", MyPluginNS::DoMathFun, registry)); // example optional flag you can set registry->SetFunctionFlags("Utility", "MyPlugin_DoMathFun", VMClassRegistry::kFunctionFlag_NoWait); return true; } }main.cpp #include "MyPlugin.h" // here is a global reference to the interface, keeping to the skse style SKSEPapyrusInterface * g_papyrus = NULL; // any other things the plugin does extern "C" { // don't forget the plugin query, skipped here // barebones load if your plugin is only registering papyrus functions, // otherwise add other things to this bool SKSEPlugin_Load(const SKSEInterface * skse) { // you need to get the papyrus interface being used by the main skse dll, // otherwise skse won't know to ever register your functions g_papyrus = (SKSEPapyrusInterface *)skse->QueryInterface(kInterface_Papyrus); // now register the function to register your functions with skse, so skse will // know to add your plugins when it is registering all of its own custom functions bool btest = g_papyrus->Register(MyPluginNS::RegisterFuncs); if (btest) _MESSAGE("Register Succeeded"); //example error check return true; } }; // leaving extern "C"You're not done. You still need to tell papyrus that these functions exist in order to use them in scripts, or they won't compile. So in this case I used the "Utility" class of functions, so I need to open the latest skse copy of Utility.psc and add "MyPlugin_DoMathFun(StaticFunctionTag* base, float fArg1, float fArg2)" to the bottom and then re-compile it and put the .pex in my Data/Scripts folder. MyPlugin.dll needs to go in Data/SKSE/Plugins. Now it should work to call "MyPlugin_DoMathFun(StaticFunctionTag* base, float fArg1, float fArg2)" in your scripts. Anyone using your plugin would need both MyPlugin.dll and your Utility.pex. You should document the functions so that people can recompile the Utility.pex with your function headers anytime skse is update (or to merge with other mods) if you stop supporting the mod. edit: You should probably also make sure g_papyrus isn't null before trying to register your function register callback in the plugin load code. bool btest = false; if (g_papyrus) btest = g_papyrus->Register(MyPluginNS::RegisterFuncs);