opusGlass

I agree with what's said in this thread, a limitation on hot files would be good. But personally, I think splitting mods in the first place is an even bigger issue. If a file would've been released as an update / optional file / additional feature of a mod prior to DP, but the author is instead choosing to post it as many separate mods to farm DP, then everyone in the community is worse off (whether or not the author waits a week before posting the split parts). Users have a more inconvenient experience downloading the split content; other quality mods get less visibility which harms both users and authors; and the farmed DP comes out of the pockets of other authors who aren't splitting their mods into the tiniest conceivable fragments. Yes, it's hard to make a black-and-white definition of what constitutes splitting mods, but we all recognize it when we see it. Make this reportable, or find some way to disincentivize it.

In response to post #72143393. #72144508, #72144708, #72144743, #72144783, #72144978, #72145133, #72145678, #72145908, #72146263, #72146413, #72146538, #72146543, #72147408, #72147963 are all replies on the same post. In a perfect world where every mod issue could be fixed by LOOT, dragging load order wouldn't be needed. But in reality, manual load orders are essential for debugging mod conflicts and that's way more cumbersome if LO is strictly rule-based. Not to mention custom LO & patching like Elianora mentioned.

Aren't those Skyrim assets in the screenshots? I guess these are placeholder models?

Hey guys, I'm looking for Level Designers for the next update of Diverse Dragons Collection. Still needed are a lava dungeon, tunnels under Eldergleam Sanctuary, and a cave filled with gold and jewels. If anyone is interested in one or more of these, I can send you more details on the dungeons

In response to post #67827451. Isn't that effectively the same as cashing out via paypal, which is already an option?

It's common for mod authors to end a mod description with a graphic and links to all their other mods, links to personal website, discord, patreon, etc. When this needs to be updated, authors have to make identical changes on every one of their mod pages. In my case, I've let this get out of hand: 32 mods across Skyrim classic and SE all have this identical footer, and every time I publish a new mod I have to add it to the footer of every existing mod. This takes a LONG time. I realize I could just stop doing it, or reduce the number of mods that I put the footer on, but it is nice to have since it promotes my mods to those who are interested, and helps create "brand recognition." It would be great if there were a place on our profile where we could type up a BBCode snippet, then on each of our mod pages put a command that retrieves that snippet and plugs it in when the page loads. That way when we change the original BBCode snippet, each mod page that references it gets automatically updated. It would be nice to have the option to make multiple of these snippets, since for example you might want to plug different code in Skyrim Classic vs Skyrim SE. But I'd certainly settle for just the option to type up 1 referencable BBCode snippet in my profile. Failing the option to plug in BBCode snippets wherever I like on my mod pages, a simpler option would be this: write 1 generic BBCode footer on my profile, which is then automatically appended to all of my mod descriptions.

May the odds be ever in your favor

Comment

comment

I volunteer as tribute

Thanks for everything you've done Vurt. You were the person that really got me hooked on modding with your beautiful Skyrim mods. So in a way, everyone who uses my mods owes you a thanks!

Okay

In response to post #61684642. nvm

Wubbalubbawubdub

Supercallifragilistic expialidocious

In response to post #60909857. #60910697 is also a reply to the same post. Me as well. It really is a great idea, I always wanted to support authors on patreon but I couldn't afford to pay all of them separately, not to mention I wouldn't know how to split it. This is a great solution.

Thank you guys so much for setting this system up! Getting some tangible reward for modding is very reinvigorating, even if it's really just one meal a month. It strikes me as strange that you would want to weight the pool so that non-Bethesda modders get paid more per download. But I'm not going to look a gift horse in the mouth, I'm happy to be receiving anything. Do what you think is best.

I probably should have filed a bug report a long time ago, but my notification settings keep changing themselves. I always disable the email option and use the in-site notifications for everything, but then I'll get an email and check my preferences and some of them have switched to email.

Easy as childbirth

This is great. I too had doubts until I read through the whole page and they were all addressed. I don't expect I will benefit from it much, since I use assets from other authors very often, and they will likely prefer me not to opt-in. But I appreciate that the opportunity exists for many authors! (It also gives me motivation to continue improving my texturing ability, so maybe I can make my own HD base textures instead of needing to borrow from others ;) )

In response to post #54930308. #54930478, #54930773, #54930833, #54930843, #54930848, #54930913, #54931018, #54931133, #54931298, #54931363, #54931473, #54931588, #54932243 are all replies on the same post. I'm sorry Dark0ne, but it seems like you guys are trying to dodge the issue here. Whether or not the underlying mechanism is the same as MO, there is one feature where NMM has never reached the bar. That is the ability to reorder the mod install order. In Mod Organizer, if ModA and ModB both have a copy of the same file and ModB is winning, you can move ModB above ModA and now ModA is winning. In NMM on the other hand, you have to uninstall and reinstall ModA. Additionally, in MO you can uninstall and reinstall ModA without altering the fact that ModB wins the conflict, another necessary function for debugging a mod list. If Tannin has found a way to implement that same functionality with symlinks/hardlinks, then everyone here will be happy. But I haven't seen any confirmation of that, and silence speaks for itself. So far only MO has achieved that vital functionality. That's why everyone keeps harping on about whether or not you're using the same system as MO. If you've achieved that functionality, please let us know, so this can end. Otherwise you will continue to get angry posts from grumpy users who are stuck with a buggy MO2. (And this is really a secondary issue, but I just want to point out that a clean Data folder is an important feature for many mod authors, who need to be able to package their mod files from Data without having to sort through thousands of files to figure out which ones belong to that mod. This isn't a problem for me because I've developed a workflow that doesn't rely on the true Data folder, but a few months ago that would've been a deal breaker for me, and I'm sure it still is for some authors.)

Just bought TW2+TW1, enhanced editions, for $4.03 on Steam. (Because I already had TW3 with DLC.)

> If you're already recompiling scripts why not use a version function with a "return 8" That is possible, I think it's a toss-up over which is easier. I just decided editing and compiling Papyrus from xEdit was a little more difficult than editing a GlobalVar ;) > But why do you think deleting properties isn't safe? Maybe my info on that is outdated. Pretty sure this page used to say something to the effect of "removing properties causes unpredictable erratic errors." SkyUI still says: and I've seen the same sentiment expressed in forums. But the page now says they will just be removed automatically from the save file, so perhaps that was more of a rumor.

@cdcooley Unfortunately my scripts are somewhat long and can mess things up if the user saves during execution, so don't think swapping scripts will work. And deleting existing properties on a script isn't safe for save files, so I can't alternate between deleting properties and recreating properties on the same script. @DavidJCobb The system is a bit different than you were speculating. I was hoping to avoid going into detail because it's quite complicated, but here's the gist: -Clients install a FrameworkPlugin.esp that contains template versions of all the necessary Forms, the corresponding papyrus scripts with source, and xEdit scripts to incorporate the framework into their mod. -Clients run an "Integrate Framework" xEdit script that (1) copies all of the necessary template Forms from FrameworkPlugin.esp into ClientMod.esp, (2) rename all papyrus scripts uniquely for the mod and recompile them to avoid version conflicts between mods, (3) edit ClientMod.esp's Forms in that mod to refer to their own versions of everything. Since everything has been copied into ClientMod.esp, it doesn't add any dependencies -- users don't need FrameworkPlugin.esp. -Clients run several scripts to build the Forms needed for ClientMod.esp specifically, including the Splicers. Each Splicer has an entirely separate Activator form, with initial values for their accm_SplicerScript properties varying between Splicer forms. (This next part might surprise you but...) There are no ObjectReferences of any of the Splicers. It turns out that the engine stores, runs, and saves scripts for base forms (or at least for Activator base forms) without any need ObjectReferences. Even runtime changes to Properties are saved. Now, because of that last point, your solutions won't quite work, but you actually gave me an idea for how to make it work: -Add a const GlobalVariable "ModVersion." In my script, dynamically save the value of runtime. -On each game load, check if the GlobalVariable is greater than the script-stored value of ModVersion. If so: -For each Splicer, create an ObjectReference in the world. Hopefully, these references will get the plugin value of each property, instead of the base form's current property values. Then, copy the properties from the references back into the base forms. Then, delete the references. It just might work. Thank you!

Ok so first off, this is about a framework that has already been deployed. It's in use by multiple mods so it's too late to redesign it. Answers saying I "should have done it differently" will not be useful. I have a framework that allows MCMs and spell menus to be easily generated for creature mods, using only xEdit scripts. The part of the framework that I'm worried about is the Splicer -- this is a script attached to an Activator that has two paired array parameters, a list of ActorBases and a list of integers (the encounter levels for those actors). A mod can have a potentially unlimited number of Splicers, and they all share the same identical script. The differences between Splicers are determined by the initial values of their properties, as set in the Editor Window/xEdit. This means that when a Splicer needs to be changed during an update, any existing saves will continue using the outdated version of that splicer, since the properties will never be set to their new "initial" value. Since the framework is entirely in xEdit, I can't write a custom papyrus script for each update. I need some general update procedure that can be designed ahead of time without knowing the details of the update, that can be used repeatedly for every update. Some ideas I've found: -Replacing Splicers entirely any time they change, with a "disabler" script to attach to the old splicer that puts it out of use. -Adding a new update script to the Splicer with every update that copies the initial values of its own properties into the Splicer script's properties. I actually could compile these dynamically in xEdit, since they will have identical code other than their name. It would also only work on SKSE systems, which is recommended but not required to use the framework. Both of these techniques would potentially create a lot of "clutter" in the plugin and in the save file (and in the scripts folder for the last technique). Every update would require new script instances to be added and stored in the player's save file for every changed Splicer, and who knows how many Splicers will be changed how many times. Oh and the Splicers are attached to a base form of an Activator, not to instances of a single base form. So I can't delete them when they aren't needed anymore without orphaning scripts in people's save files. So, anyone have any better ideas?