prideslayer Posted June 2, 2013 Posted June 2, 2013 As requested in the SexoutNG Beta thread, here's one just for discussing issues with SSR vs. SCR. No download thread, as for the forseeable future, SSR will be 'shipping' with SexoutNG Core and not be a standalone download.
prideslayer Posted June 2, 2013 Author Posted June 2, 2013 What plugins? This is a thread for modders, not for players. I will update the title.
BruceWayne Posted June 2, 2013 Posted June 2, 2013 Could you elaborate what you don't want to see in SCR/SSR anymore, as far as resources go? My only concern would be, if the current armor collection remains in there or if you want it to go in the long run, as evidenced by your first iteration of SSR. While I wouldn't have a problem with that per se, I'd need to find a different solution regarding custom armors, that I currently use or plan to use. As said before, my only additions to SSR would be custom (unplayable) races and NPCs/NPC templates in order to fix the horrible white skin bug. My plugin uses SCR's debug mode enabler for the lack of a MCM menu or some simpler implementation as well. Since I'm not the only one using that functionality, that'd be a feature that I'd like to see remain. If only to help unexperienced users to gain easy access to this feature for the sake of bugtesting or the fact that debugmode remains enabled in between savegames.
prideslayer Posted June 2, 2013 Author Posted June 2, 2013 I have four guiding principles for SSR that I will stick to as much as is possible/practical. 1. Do not modify vanilla records, any of them. 2. No always-running scripts. 3. Actually likely or requested to be 'borrowed'. Re #1: SCR is modifying worldspace, 2-3 cells, addiction/withrdrawl lists, dialog, some NPCs, armors, and so on. I understand there are reasons for some of this, but no reason is a good reason for a 'core mod' that, basically, everything that uses sexout also uses. #2 I'm not as versed on, I just SAW a ton of gamemode and quest scripts and people are complaining of lag/stuttering issues while using SCR. Almost every script in there relates to pregnancy and pregnant body swapping -- pregnancy is an ESM, and those scripts belong there. #3 is a potentially touchy point, but it's the only way to keep the bloat down initially. First off, all the pregnant clothing variants SHOULD be moved from SSR into the Pregnancy ESM. They are not 'shared' in the sense that no other mod is adding effects to them, swapping them around, or otherwise using them at all. They aren't a 'shared' resource, they're a pregnancy resource. Second, NPCs and Races, I will only want to add if there is some actual demand by modders to share an NPC you've created in your mod so they can use it in theirs. So far the few NPCs that showed up in SCR were not used by any other mods. There is, of course, another solution to the face texture problems -- make your mod an ESM. ------------ I have no problem with the 'debug mode' thing I don't think, though I have no ever looked at or used it, so I don't know what it was doing or was there for. If it's just for you to enable/disable debugPrint's in your own mod, you can do that easily enough from the console without having to add any MCM options. It's one line: "SetDebugMode 1 xx" where XX is your mod's index in the load order, in decimal.
BruceWayne Posted June 2, 2013 Posted June 2, 2013 *snip* Okay, that makes sense. The MCM toggle could be set to a number, which, if selected, enabled the debugmode for the mod that has that number set in their init script. I'm well aware of the setdebugmode command. Though, as mentioned, it has the drawback of not persisting between saves and has to be toggled every time the game is restarted, which can be very inconvenient for excessive testing. I'm not sure, what argument there'd be against holding the races and NPCs though. As is, SSR and SCR hold a lot of references to armors, that are only useful, if 1) you have the resources installed, 2) have mods that distibute them. Also it has the nice side effect that it can massively reduce the amount of plugins needed. We recently found out about the plugin limit, which amounts to ~150 plugins give or take, for the most common configurations and the game using more than two cores. What am I trying to say? If it's not harmful, as in not violating any of the 3 rules you've layed out and to which I agree and can subscribe to - there is no reason to not put it there. It would only be basic references with no attachment to the gameworld, no factions, no AI, no scripts, no nothing, but the base form. Only because it's not shared at the moment, doesn't mean it won't be shared in the future, for whatever purpose. I don't see any other reason, besides the face bug, for my plugin to be a master. It being a master would require additional load order instructions, which will lead from "load order doesn't matter" to complains like "My game doesn't start; I didn't read instructions; BOSS doesn't work; it's my first day on the internet; my brain hurts; etc.", as you might imagine.
prideslayer Posted June 2, 2013 Author Posted June 2, 2013 There are a few reasons I don't want to just include 'stuff' for the sake of including 'stuff'. First, there is actually a limit to how much 'stuff' you can have, nevermind the mod limit. Hal has already run into it himself -- too many 'things' in the data dir, and random meshes/textures start just.. not getting loaded. My suggestion to him was to try and put all the SCR stuff in a BSA and see if the limit affects BSA loaded assets as well, or if it's strictly a data dir thing. Right now we don't know which. If it affects both, it's a compelling reason to not just "cram as much crap as we can imagine into this." Second, there is a lot of "stuff" in there as you said, but *most* of that is going to go away -- because most of it is pregnancy meshes and textures, which rightly belong in the pregnancy ESM. The fact that there's a lot of stuff there that doesn't belong or doesn't need to be there isn't a good reason to keep adding more stuff that doesn't belong. Two wrongs, etc. Finally, I just don't subscribe to the "If there's no reason to not put it in, put it in" mentality you alluded to.. My philosophy is if there's no reason TO put it in -- don't. NPCs are a special case, and I will include them provided they modify no vanilla records, and don't have dialog or anything else I am under constant pressure to fix or modify for the NPCs creator. If a simple nonplayable race will do to fix the texture issues, with the NPC actually created in your ESP, that would be better. The fourth rule (which I missed in the last post) is simply that everything included in SSR should work. This means, if I can avoid it, I do not want to include records for items that reference meshes/textures that do not exist unless you have some 3rd party thing installed. I realize this will somewhat empty out the sexout store initially, but to be honest, I would rather an item get removed from the store than be sold there only to make the wearer invisible due to a missing mesh. Modders are going to end up using them in their mods without noticing (or telling) end users that their mod also requires some add-on clothing item from wherever as well. I will draw the line at the extremely lore-unfriendly stuff, even if we have meshes. I'm not going to put the starfox race back in, no matter how many people ask for it or how loudly, as a for-example.
DoctaSax Posted June 2, 2013 Posted June 2, 2013 Debug mode, the way Hal went about it, also allowed to have more than one debugmode being run at the same time. It's a handshake deal, of course. I requested #20 so that I just need to slide debug1/2/3 in SCR's MCM to 20 to have it on for mine, without needing to provide a toggle in my own mod to cut out console spam when it's not needed. We can also set another slider to something else, detecting interference between mods if necessary, that way. It's one of those little things that end up pretty useful. About esming for npc's/races: there's no reason to add LO headaches in a family of mods that's been spared of that so far. Outside of a central resource mod and, optionally, pregnancy, that's all the masters a sexout mod really should need beyond NG itself. If Bruce'd like an npc or race added to avoid esming his own stuff and you get to cut out the stuff people don't use, everybody should be happy that way. ----------- Let's talk formlists. I'd need some, not all. I think it's faster to just say what should be kept. At the moment the following appearance formlists (SexoutSLClothAppear+) are used by Clothing Eval, CheckMeOut, sofo & Lust: ArmorSkimpy (CMO)Dominant (CMO, SOFO)ExposedCrotch (CMO, Lust)ExposedNipple (CMO, Lust)FactionBoomer, BoS, Chairmen, Enclave, FiendOrRaider, Followers, GreatKhan, Kings, Legion, NCR, Omertas, PowdergGanger, VaultDweller, WGSFormalClassy (CMO)GayMaleHighRadResistanceHomely (CMO, SOFO)HotPants (SOFO)LesbianLingerie (SOFO, Lust)MaidUniformMechanicNonPowerArmorPretty (CMO, SOFO)Prostitute (CMO, SOFO)Ragged (CMO, SOFO)Science (CMO)SchoolUniformShortSkirt (SOFO)ShowCleavage (SOFO)Sexy (CMO,SOFO)Slutty (CMO, SOFO)SwimwearSubmissive (SOFO)TightFit (SOFO) The ones without further specification are in the clothing eval system, but not used in another mod yet (I think, someone correct me if that's not true). I'd still keep them around though, if only because they're referenced in clothing eval. None of those have to be pre-filled either, it's exactly the point (I did look into using the faction ones to apply vanilla's faction clothing system to whichever piece of clothing you'd like - but it was needlessly complicated what Obsidian did with that & I really wanted to write story instead. Still think it'd be nice someday to figure all that out. Things like radiation, science etc were about maybe applying an actor effect bumping some stats or giving some resistance if you wore anything in that. Looking smarter making you a bit smarter, that sort of thing. Was also toying with the idea of having people drown if they didn't use swimwear while swimming - but detecting that isn't all that easy, as Hal's pointed out a few times.) Outside of the appearance range: SexoutSLOutfitVaultSuitTorn: if you keep the non-preg 'raw' torn armors in (meshes in an SCS pack I think), I don't need this list or the others that look similar for that clothes swapping thingie in the 2 scenes I use it in, if I used my own version of that again. If I get around to adding pregnancy as a master, I can add the preg variants of that to the functionality through there. There are some lists that should be needed to maintain the armor resource part of what'd be kept. SexoutSFLGloves+ for the respective armor addons (gloves), lists with "repair" in them so that they can be repaired by something. I get that it's a pain to have resources in external mods, not so sure what could be kept that isn't - it's the way the whole thing was set up from the start - avoiding needing permission from the modeler/texturer even. You just tell people to download that elsewhere. Maybe meshes & textures that are made here at least, could still have a place for formIDs in SSR. SexoutSLActorDataIsReserved: iirc, the standard exemption list for random NPC approach mods like hookups & BR. Lust mentions it too but doesn't quite respect it completely (yet).SexoutSLActorDataIsSterile & IsInfertile: exemption list for pregnancy M/F, basicallySexoutSLActorDataCannotGetDisease: same for diseases, I guessMaybe these should be kept. It's not unlikely that a modder wants no preg/disease functionality for a particular npc while leaving it open to the user for any other npc's. That shouldn't take a dependency on a pregnancy or disease mod - which would give users the wrong idea. As far as I'm concerned, if preg-related lists move to pregnancy, and anything else were cut, that'd be alright - formlistwise.
prideslayer Posted June 2, 2013 Author Posted June 2, 2013 Debug mode, the way Hal went about it, also allowed to have more than one debugmode being run at the same time.This is already true. How do you think Sexout and SCR can independently toggle debugmode? DebugPrint prints to the console only if the mod calling it is in debugmode. SetDebugMode takes a mod index as an optional param. Without it, it toggles debugmode just for the mod making the call. Any mod can toggle its own debug mode with just 2 (quest var) or 3 (nx var) lines of code, not counting any code required to expose it via MCM, and that setting will persist in saves. I'm not saying the SCR debug mode isn't useful, or that I won't reimplement it in SSR, just that it's not doing anything that is difficult to do in your own mods. About esming for npc's/races: ...I'm happy to do it given the restrictions outlined : No modifications to vanilla assets, and no dialog. If putting the textured race in the SSR ESM, and the NPC(s) actually using it in the ESP, I would much prefer that option. Let's talk formlists. I'd need some, not all. I think it's faster to just say what should be kept.I can and probably will keep them all. Their contents will certainly change, though, because some of them are referencing things that are going to be removed from SSR. Some will simply be moving to the pregnancy ESM (like all the pregnant armors), in which case, Hal will need to script up adding them to the appropriate SSR formlists. SCES should continue to function just fine, provided it's only using the formlists in SSR, and not relying on any scripting. (...but it was needlessly complicated what Obsidian did with that & I really wanted to write story instead...)I really want to write story as well! Unfortunately how I spend my modding time is mostly dictated by y'all... When it's not, it's dictated by my own frustration, e.g. with SCR. SexoutSLOutfitVaultSuitTorn: if you keep the non-preg 'raw' torn armors in (meshes in an SCS pack I think), I don't need this list or the others that look similar for that clothes swapping thingie in the 2 scenes I use it in, if I used my own version of that again. If I get around to adding pregnancy as a master, I can add the preg variants of that to the functionality through there.Hal and I discussed this. My opinion is that the code to *do* the swapping does not need to be in SSR. The lists can be, but only if they are generic and easily used by multiple mods/swap-systems. If they are specific to pregnancy and only pregnancy can reliably use them, then that's where they belong. If they're specific to the damaged-clothes mod and only it can use them, same thing. Ideally there should be a single clothing swapping "system" that both pregnancy and the damage thing can plug into, along with other similar mods, that can mediate such things. IMHO this system has no place in SSR. SexoutSLActorDataIsSterile & IsInfertile: exemption list for pregnancy M/F, basically SexoutSLActorDataCannotGetDisease: same for diseases, I guess Maybe these should be kept. It's not unlikely that a modder wants no preg/disease functionality for a particular npc while leaving it open to the user for any other npc's. That shouldn't take a dependency on a pregnancy or disease mod - which would give users the wrong idea. I hate that these and others are prepopulated with vanilla NPCs. Who is Hal (or me, or any one modder) to decide that Old Lady Gibson is infertile, etc? They are still in SSR right now because I said I'd leave the lists alone in this version, and I have, but I will likely empty them out. They are also open to 'abuse': I have a reputation as something of an asshole, deserved, but what if I were an even *bigger* asshole? I have not, and will not, try to push my play style, kinks, or anti-kinks off on anyone else. That said, I don't find pregnancy or STDs attractive, sexy, whatever you want to call it. So imagine if in my mod, I added all the NPCs in it, and the player, to the infertile and other lists? There would be massive backlash, and rightly so, from players who want to experience those things and have them affect the player. This is why I am so insistent that, wherever possible, the lists be populated by individual mods and not be prepopulated by SSR or any other important 'core' master file.
Halstrom Posted June 3, 2013 Posted June 3, 2013 I'm not saying the SCR debug mode isn't useful, or that I won't reimplement it in SSR, just that it's not doing anything that is difficult to do in your own mods Hal and I discussed this. My opinion is that the code to *do* the swapping does not need to be in SSR. The lists can be, but only if they are generic and easily used by multiple mods/swap-systems. If they are specific to pregnancy and only pregnancy can reliably use them, then that's where they belong. If they're specific to the damaged-clothes mod and only it can use them, same thing. Ideally there should be a single clothing swapping "system" that both pregnancy and the damage thing can plug into, along with other similar mods, that can mediate such things. IMHO this system has no place in SSR. I hate that these and others are prepopulated with vanilla NPCs. Who is Hal (or me, or any one modder) to decide that Old Lady Gibson is infertile, etc? They are still in SSR right now because I said I'd leave the lists alone in this version, and I have, but I will likely empty them out. Well the debug mode was added for the newer & smaller modders so we didn't end up with 50 MCM menus to search through possibly overloading MCM and they didn't have to go through the trauma of becoming a MCM expert for a debugging option on simple mod. It also allows simple instructions for modders to give novice users to get debugging feedback when bug hunting What is in SCR now is a trial of a new system meant to replace the Pregnancy one eventually, but I still have to look through Prideslayers suggestions on another way to do oufit / bodyswapping, hopefully someone else will write an ESM to do it, but I doubt it., I can probably split it off into another esm later, after I clear everything else off my plate, as no one seems to be interested in making Damaged/Pregnant meshes other than Evilrunner, I'd say there's no rush, and what outfits we have now are probably all there will be for a while. Yeah, I did a lot of formlists wrong, I pre-populated those lists on request a long time ago before I knew how to do it by script and basically sorted all the old aged people into them, someone asked to add them into the banned for sex list too, but I drew the line there. So far no one asked for it to be an option, if they had I would have done it, it's easy enough for me to just copy the formlist into Pregnancy and then have a script add them on a MCM setting, I'll add that to the list.
ChancellorKremlin Posted June 3, 2013 Posted June 3, 2013 There's just a few things I picked up on this conversation which I thought I'd comment on: There are a few reasons I don't want to just include 'stuff' for the sake of including 'stuff'.Finally, I just don't subscribe to the "If there's no reason to not put it in, put it in" mentality you alluded to.. My philosophy is if there's no reason TO put it in -- don't. NPCs are a special case, and I will include them provided they modify no vanilla records, and don't have dialog or anything else I am under constant pressure to fix or modify for the NPCs creator. If a simple nonplayable race will do to fix the texture issues, with the NPC actually created in your ESP, that would be better. My take on this is though, there are reasons to keep certain things in, otherwise people wouldn't be requesting them to. I totally agree that NPC's (as for most if not everything else in SSR) shouldn't modify vanilla records or have scripts attached that don't perform some highly useful and shared function, but NPC's doesn't fall under that category. As far as NPC's are concerned though, with the above conditions - keeping them in both to avoid the neck seam/wrong head issue and avoiding having to make an esp into a master are perfectly valid reasons, so long as say you don't bump into them in townsville while wandering around without even having the required esp installed. As a shared resource/library, I think this is one of the directions we should be working towards. The fourth rule (which I missed in the last post) is simply that everything included in SSR should work. This means, if I can avoid it, I do not want to include records for items that reference meshes/textures that do not exist unless you have some 3rd party thing installed.I realize this will somewhat empty out the sexout store initially, but to be honest, I would rather an item get removed from the store than be sold there only to make the wearer invisible due to a missing mesh. Modders are going to end up using them in their mods without noticing (or telling) end users that their mod also requires some add-on clothing item from wherever as well. I'm going to come out and say we should keep textures/meshes for most if not all armours in SSR. As has already been said, it is incredibly useful for not having to load 10-15 ESP's when loading just one will do - for those of us using lots of mods, hitting the plugin limit happens rather soon and I can't say enough how much having one library/resource take care of that. Secondly, things are only not going to work if for whatever reason, the texture/mesh gets called in game, which anybody just using SSR should never ever have to notice. You're only ever going to run into that problem if you have Store installed, and then its entirely on you if you decided to follow through with the requirements or not - if you didn't, and can't see stuff, that is on you and not on SCR/SSR. Lastly on this point, there are tons of clothing in there in one form or another which I and other modders have earmarked for future uses. Seeing as those plugins will likely rely on SSR anyway, I don't see the point in removing meshes/textures which you won't even see anyway unless using a third party Sexout plugin that references them. I also can't think of one modder that "ended up using stuff in their mods without telling end user that their mod requries some add-on clothing" with what we have so far and I have no reason to believe that will ever be the case. I will draw the line at the extremely lore-unfriendly stuff, even if we have meshes. I'm not going to put the starfox race back in, no matter how many people ask for it or how loudly, as a for-example. This I can more or less agree with. There is a lot of stuff in SCR I wouldn't ever use, but that's not to say some people won't find a use for it. Here, I'm talking about clothing specifically (not races) like mantis, ghost, stuff like that. There is also a certain irony in you saying elsewhere you don't want to force your own choices in people (ie by putting everyone on an infertile list) while "drawing the line" at lore-unfriendly stuff. That is forcing a gameplay preference on us through the use of a library/shared resource plugin everbody knows we're going to have to use. As a library, and not a vehicle for gameplay preferences, even though I don't ever use mantis/ghost stuff, I think it should be there. Removing them just puts us into a slippery slope about what to keep/take away and where we draw the line - ie, because I/you/lore doesn't like it, etc. As I've already said, if you don't like it, you won't ever see it unless you play a plugin that puts it into the game. And that's how it should be. About esming for npc's/races: there's no reason to add LO headaches in a family of mods that's been spared of that so far. Outside of a central resource mod and, optionally, pregnancy, that's all the masters a sexout mod really should need beyond NG itself. If Bruce'd like an npc or race added to avoid esming his own stuff and you get to cut out the stuff people don't use, everybody should be happy that way. Again, I agree. If there's a good reason not to have to turn an esp into an esm, for as silly a reason as just to avoid a head/body mismatch, then that's what we should do. No need to create unnecessary headaches for people which we have thus far avoided. SexoutSLActorDataIsSterile & IsInfertile: exemption list for pregnancy M/F, basicallySexoutSLActorDataCannotGetDisease: same for diseases, I guessMaybe these should be kept. It's not unlikely that a modder wants no preg/disease functionality for a particular npc while leaving it open to the user for any other npc's. That shouldn't take a dependency on a pregnancy or disease mod - which would give users the wrong idea. I think there's a definite benefit in this if say, you only need one or two functions from an esm like Pregnancy but not the whole shebang. It seems kind of senseless to have to make a plugin reliant on another esm for the sake of say two lines of code. The added benefit, too, is that I get to see what aspect of the esm you're referencing (here pregnancy) without having to have that esm installed and potentially majorly disrupting my gameplay. For example, in theory - there could be one or two functions I like in pregnancy, and 50 I dislike. If your esp is using those two functions, there would be no reason for me to have to have the whole thing installed just to have access to something I *only* want while playing your esp. In that sense, I think we need to consider some leeway with certain vars, scripts and functions that might be useful to modders without having to use the entirety of another esm. That's the whole point of a shared library/resource, making things easily available for other modders. I'm not saying the SCR debug mode isn't useful, or that I won't reimplement it in SSR, just that it's not doing anything that is difficult to do in your own mods. As a frequent bugtester, I have to say the MCM toggles are a godsend! I honestly can't think of a reason to get rid of it. It works perfectly fine as it is. It causes no hassle whatsoever. It is INCREDIBLY useful for both modders and bugtesters alike. And it's already there. Saying it isn't difficult to put into your own mods may be true, but why make people go through that extra work? It's there, it works, its unobtrusive, and its incredibly useful. Especially if we consider that, rather than having one submenu we would have to have half a dozen for plugins that have no other reason to have an MCM menu other than for the debug tool. Given that MCM gets buggy itself with the mods submenus you have loaded into it, taking this function out of SSR is not only unnecessary but counterproductive. To sum up, this is what I think we should have in SSR.: NPC's that don't alter vanilla content/add anything to the game by themselves Clothing/armour/apparel textures/meshes with no scripts and same conditions as above The MCM debugging toggle Leeway for minor scripts, functions and variables from other ESM's which would otherwise require users to have the entire esm activated with potentially unwelcome and detrimental effects on gameplay. These would be inactive unless a third party plugin (obviously the one requesting the code stay in) activates it and would otherwise not alter/modify gameplay in SSR alone in no way, shape or form. My two cents.
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 puts us into a slippery slope about what to keep/take away and where we draw the lineThe only reason there is any kind of "slippery slope" is because I'm trying to compromise. In my opinion, the only armors that belong in SSR are the ones that are: 1. Complete and working. and 2. Actually have some chance of being used by multiple mods, or already are. That is "where I draw the line." It's not enough to make some people happy, so I'm attempting to compromise. If the attempt fails, so be it. Being that SCR still exists, is functional, and works for just about everyone -- I see no reason to compromise further. Those who won't see the logic in what I'm trying to do despite having explained it several times probably won't no matter how many times I repeat myself. Obviously, nobody *has* to switch. Anyone that finds the direction I take SSR unacceptable is welcome to ignore it and continue to use SCR for their mods. I'm sure Hal would appreciate it if they would help him clean it up, his time is very limited. If the end result is that only the mods I have modified to use SSR (Tryouts/WG and Sewerslave) end up using it, I will take them back out behind the woodshed to remove SSR as a dependency, and then remove SSR entirely. It really will not be that difficult. It seems kind of senseless to have to make a plugin reliant on another esm for the sake of say two lines of code.This is, in fact, what the majority of mods using SCR are doing. Usually it's not even two lines. It's one formlist, or one quest var. In that sense, I think we need to consider some leeway with certain vars, scripts and functions that might be useful to modders without having to use the entirety of another esm. That's the whole point of a shared library/resource, making things easily available for other modders.Yes, that was the whole point. A place to put resources *shared* between mods. Not a warehouse of every possible thing that *no* mods use but that someday one might want to use. A for the quest vars and so on, they're still there. I won't add new ones. NX vars should be used for that sort of communication. They can be set and checked by any mod, on any reference, without any of the mods using it having one another as masters. int preglevel if IsModLoaded "SexoutPregnancy.esm" set preglevel to someref.NX_GetEVFl "Sexout:Pregnancy:Preglevel" else set preglevel to -1 endif Look ma, no quest vars, no load order issues, no mod depending upon another mod. And it's already there. Saying it isn't difficult to put into your own mods may be true, but why make people go through that extra work? It's thereI'm not saying I will not do the work to add it back in, but you're missing a crucial point here in the difficulty comparison: It's in SCR, it's *not* in SSR -- it was gutted, with every other script. Sure, it makes debugging other mods easier. I do *not* want to have to debug SSR, that is something that should *never* happen. This is one reason I am going to keep it extremely light on scripts/effects/etc, and have none (except perhaps, this *one*) that are running in Menumode/Gamemode. Bugs in SCR are what "fucked up" my game and sent me down into the rabbithole, where I saw just how badly screwed up it is. SSR is my solution. Nobody has to use it if they don't want to. I'll say that just once more.. Nobody has to use it if they don't want to. SCR is still there.
BruceWayne Posted June 3, 2013 Posted June 3, 2013 About esming for npc's/races: ...I'm happy to do it given the restrictions outlined : No modifications to vanilla assets, and no dialog. If putting the textured race in the SSR ESM, and the NPC(s) actually using it in the ESP, I would much prefer that option. I haven't been asking for anything else. As for the solution of just putting races in there and the NPCs remaining only in the .esp, I'm afraid that doesn't work. I went ahead and tried that out by copying the african-american race as a custom race and putting it into SSR. NPCs using that race still had their normal face, but the skin was still bright white. On the other hand, If I put the NPCs in the .esm with vanilla races, they still remain their correct colors, even if I overwrite them in the .esp or assign them different races(!) afterwards.
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 I kinda thought that was going to be the case, but I had to try! If you still have that version laying around, what happens if a 'base' NPC is defined in an ESM, and a new NPC is decended from it in the ESP? If you make a new NPC, set the actorbase to something like CGPresetAfricanAmericanM01 and tick the "use model/animation" and "use traits" boxes, does that one still end up with a white body if saved to an esp?
BruceWayne Posted June 3, 2013 Posted June 3, 2013 Just tried, I took my test-NPC, whose base is stored in SSR and working as it should, and the bug remains if it just inherits model/animation and traits or any other things for that matter. Edit:
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 Ok, thanks for looking into it. Bummer that it works that way.
ChancellorKremlin Posted June 3, 2013 Posted June 3, 2013 The only reason there is any kind of "slippery slope" is because I'm trying to compromise. In my opinion, the only armors that belong in SSR are the ones that are: 1. Complete and working. and 2. Actually have some chance of being used by multiple mods, or already are. All the armours that are referenced by store are "complete and working". And quite a few of them are used by different mods too. The only ones I'd make an exclusion for are "pregnancy related" because given that they have a common theme (pregnancy) that should be the plugin they go into. This is, in fact, what the majority of mods using SCR are doing. Usually it's not even two lines. It's one formlist, or one quest var. Yes, but they're all referencing SCR, not a bunch of other plugins. Yes, that was the whole point. A place to put resources *shared* between mods. Not a warehouse of every possible thing that *no* mods use but that someday one might want to use. Again, this isn't an all or nothing approach. I'm not saying leave everything in now am I? I'm saying keep NPC's which mods use, armours and little more. I don't see how I'm asking for a warehouse. I'm not saying I will not do the work to add it back in, but you're missing a crucial point here in the difficulty comparison: It's in SCR, it's *not* in SSR -- it was gutted, with every other script. You asked what we wanted in/out - I told you - how am I to know you already did away with it? But anyway, if you're saying you wouldn't mind adding it back in, then you'll have no problems from me. Sure, it makes debugging other mods easier. I do *not* want to have to debug SSR, that is something that should *never* happen. Being that SCR still exists, is functional, and works for just about everyone -- I see no reason to compromise further. Those who won't see the logic in what I'm trying to do despite having explained it several times probably won't no matter how many times I repeat myself. Obviously, nobody *has* to switch. Anyone that finds the direction I take SSR unacceptable is welcome to ignore it and continue to use SCR for their mods. I'm sure Hal would appreciate it if they would help him clean it up, his time is very limited. SSR is my solution. Nobody has to use it if they don't want to. I'll say that just once more.. Nobody has to use it if they don't want to. SCR is still there. The only problem I have with these statements is that - unless you plan on doing updates for two versions of Sexout, one which works perfectly fine with SCR as is or however Hal finishes up with it, and one for SSR, then switching to SSR isn't going to be optional at all if we want to continue having access to updated versions of Sexout, which we all obviously do. Given that your new version of Sexout works with SSR but not SCR, and that is the version you will release future updates for, SSR will very much be what we have to use, one way or another. In sum, I think nobody here is asking for a warehouse of stuff or even anything pregnancy related. We're asking for NPC's, MCM debugging function, non-preg related armours meshes/textures. That's it.
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 All the armours that are referenced by store are "complete and working".Last I checked, this was not the case, but it's been a while. The last time I used the store, if I didn't have some of the option armors installed, one or two of the vendors had missing meshes because they were wearing items from the store, and most of them were selling items referenced in SCR that also did not have meshes. If this has been fixed, great, though I don't understand how it could be -- unless the store now only sells vanilla armors, pregnant/torn meshes, and the few toys we have full meshes for. What tells the store it's "ok" to sell something? How does it know if the meshes and textures are present or not? I'm saying keep NPC's which mods useRight now in SCR (or at least in the last version I downloaded, that SSR is based off of) there are 40 NPCs. 29 of them are pregnant NPCs or Offspring and belong in Pregnancy. Three are sewerslave NPCs ahat sewerslave does not actually use any more. One is the broken/incomplete NPC that I beleive Hal has removed from the latest SCR. That's 33 of the 40. The remaining 7 are: - 1 is the "Sex Doctor" aka "SexoutSSexDoctor, a pregnancy/drugs/std/whatever thing. - 3 are "thorn performers" - 1 is "Melisa Bayley" aka "SexoutSNPCRapersRapeSlave" -- no idea what this is. - 1 is the Starfox/Krystal NPC. - 1 is "Private John O'Donoghue" aka "0SexoutS0NCRSewerNCRTrooperGun1". As far as I know, none of these 7 are used anywhere except internally within SCR itself, or within pregnancy. If you (the royal you) are the 'owner' of one of these NPCs and are actually using them in your mod, let me know. I would rather not have NPCs to SSR because there is no point to them. They, thus far, are certainly not a "shared" resource -- All of them present are used by 0..1 mods, never 2+. The only reason I'm hearing to put them in is so the mod using them does not have to become an ESM, which strikes me as a very weak reason. There is nothing 'wrong' with a mod being an ESM. We're talking about bloating the library to add a resource that will decidedly not be shared, all to avoid turning what.. one? two? ESPs into ESMs? , armours and little more. I don't see how I'm asking for a warehouse.I've said the armors can stay, provided they modify no vanilla records, and that they work. You asked what we wanted in/out - I told you - how am I to know you already did away with it?I've said, repeatedly, that every running script from SCR is gone in SSR, and all that remains of them are the vars -- as I don't know which ones mods are actually using vs. which they aren't. That includes the scripts that make MCM "go." SSR has no MCM menu at present. Another way would be to have tried it before suggesting changes. But anyway, if you're saying you wouldn't mind adding it back in, then you'll have no problems from me.I would mind, but not so much that I won't do it, if the demand is great. If there are lots of mods using it and most/all their authors want it to stay, I will add it back in. I won't be adding 'more' support to it for new mods though. Given that your new version of Sexout works with SSR but not SCR, and that is the version you will release future updates for, SSR will very much be what we have to use, one way or another.This simply does not make any sense. Sexout does not use SCR or SSR (how could it?), nor does it care if they are installed or not. It has no 'compatability' stuff for SCR, or anything like that. Maybe I'm not getting your meaning, but I do not intend to maintain two versions of Sexout certainly, and the single version I do maintain will work fine with SCR, SSR, Neither, or Both -- just as it always has. Lastly, You asked what we wanted in/outSure. I've heard some things, and now I'm asking for justifications for them. Problem?
ChancellorKremlin Posted June 3, 2013 Posted June 3, 2013 Last I checked, this was not the case, but it's been a while. The last time I used the store, if I didn't have some of the option armors installed, one or two of the vendors had missing meshes because they were wearing items from the store, and most of them were selling items referenced in SCR that also did not have meshes. If this has been fixed, great, though I don't understand how it could be -- unless the store now only sells vanilla armors, pregnant/torn meshes, and the few toys we have full meshes for. What tells the store it's "ok" to sell something? How does it know if the meshes and textures are present or not? Like I said elsehwhere, yes, they rely on 3rd party plugins. But you're only ever going to notice those items missing if you install Store, and then don't follow through on the requirements - which at this time, is SCR. The advantage is having on ESM acting as a library for sets of armour and not having to install every single esp in order to see them - like a library, which is what it is - a repository of sorts. Right now in SCR (or at least in the last version I downloaded, that SSR is based off of) there are 40 NPCs. 29 of them are pregnant NPCs or Offspring and belong in Pregnancy. Three are sewerslave NPCs ahat sewerslave does not actually use any more. One is the broken/incomplete NPC that I beleive Hal has removed from the latest SCR. That's 33 of the 40. The remaining 7 are: - 1 is the "Sex Doctor" aka "SexoutSSexDoctor, a pregnancy/drugs/std/whatever thing. - 3 are "thorn performers" - 1 is "Melisa Bayley" aka "SexoutSNPCRapersRapeSlave" -- no idea what this is. - 1 is the Starfox/Krystal NPC. - 1 is "Private John O'Donoghue" aka "0SexoutS0NCRSewerNCRTrooperGun1". As far as I know, none of these 7 are used anywhere except internally within SCR itself, or within pregnancy. If you (the royal you) are the 'owner' of one of these NPCs and are actually using them in your mod, let me know. I would rather not have NPCs to SSR because there is no point to them. They, thus far, are certainly not a "shared" resource -- All of them present are used by 0..1 mods, never 2+. OK, I don't think I've expressed myself well enough here. When I mean "NPC's" I literally mean one that are in use right now and only there for the reason of avoiding a body/head conflict. If all of those referenced above aren't being used and don't look like they are going to be used, get rid of them. The pregnant related ones definitely belong in pregnancy. What I want is to draw the line in the sand here and now, so in the future someone can actually come up to you and say "Hey, Pride, I want to avoid the head/body mismatch. Can I include this raw NPC?" and not have him blown off. The only reason I'm hearing to put them in is so the mod using them does not have to become an ESM, which strikes me as a very weak reason. There is nothing 'wrong' with a mod being an ESM. We're talking about bloating the library to add a resource that will decidedly not be shared, all to avoid turning what.. one? two? ESPs into ESMs? There is no bloat. How many requests have you received so far from people asking you to keep NPC's in because of a mismatch? Seems like a perfectly valid reason to me, SSR is a resource plugin, have it in there. Otherwise, we're eventually going to end up with a handful of ESP's become ESM's for no other reason than to avoid that problem, which is really silly when it can easily be solved this way. I've said the armors can stay, provided they modify no vanilla records, and that they work. While I want to say "yay!" to this, I'm guessing - seeing what you wrote above - you mean only the armours inherent to Sexout, like Loogie's stuff and some other variations, as opposed to say, half the stuff Store relies on? Another way would be to have tried it before suggesting changes. ... or you could have asked us what to cut before going ahead and asking questions later. I would mind, but not so much that I won't do it, if the demand is great. If there are lots of mods using it and most/all their authors want it to stay, I will add it back in. I won't be adding 'more' support to it for new mods though. I'll let individual authors take care of that then. But say a few want it to remain and you put it back in - why deprive that function to future modders? Maybe I'm not getting your meaning, but I do not intend to maintain two versions of Sexout certainly, and the single version I do maintain will work fine with SCR, SSR, Neither, or Both -- just as it always has. Great! Sure. I've heard some things, and now I'm asking for justifications for them. Problem? Attitude could do with some adjustment, but other than that - we're golden!
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 which is what it is - a repository of sorts.For *sexout* resources, not every other mod people want to include from the nexus or wherever else. A standalone "all the random junk.esp" could hold the items and just add them to the SCR formlists and cause them to show up in the store. Hell the store itself could do it, which is probably what should be happening. OK, I don't think I've expressed myself well enough here. When I mean "NPC's" I literally mean one that are in use right now and only there for the reason of avoiding a body/head conflict. If all of those referenced above aren't being used and don't look like they are going to be used, get rid of them. The pregnant related ones definitely belong in pregnancy.I don't think *any* of them are being used right now, that's why I asked.What I want is to draw the line in the sand here and now, so in the future someone can actually come up to you and say "Hey, Pride, I want to avoid the head/body mismatch. Can I include this raw NPC?" and not have him blown off.I think I've made it clear that is exactly what I intend to do unless there is a very compelling reason not to. Making every player and modder pay the price, and me do the work of adding the NPC to SSR, to support a single mod so that author does not have to take 30 seconds to make it an ESM and another 5 seconds writing load order instructions... does not make sense. I have never been talking about adding new NPCs, that is not something I ever intend to do. I am talking strictly about those already in SCR/SSR and in use by other mods. How many requests have you received so far from people asking you to keep NPC's in because of a mismatch?Zero. Bruce has one that is not working as an ESP, but as far as I know, that one is not currently in SCR or SSR.Otherwise, we're eventually going to end up with a handful of ESP's become ESM'sSo what? While I want to say "yay!" to this, I'm guessing - seeing what you wrote above - you mean only the armours inherent to Sexout, like Loogie's stuff and some other variations, as opposed to say, half the stuff Store relies on?I mean exactly what I said. Armors that work. Armors that will show up in game if I, as a modder, use one on an NPC or give to the player in my SSR-reliant-mod, without me installing anything else except the SCR data pack (or SSR BSA if that is working properly). I'll let individual authors take care of that then. But say a few want it to remain and you put it back in - why deprive that function to future modders?Because it does not belong there, convenient as it may be. Attitude could do with some adjustment, but other than that - we're golden! My attitude would be better if people were not operating under mistaken assumptions that I have either not alluded to, or have outright denied. - No mod is required, or even requested, to switch to SSR. Do it if you *want* to and find it useful *the way it is* or with minor changes. - SSR and SCR can live together, side by side, with no problems, as far as I know. That first point, some people seem to be getting a little thick on. I haven't asked anyone to switch. I have not recommended that anyone switch. I, honestly, do not care if anyone switches. In fact, if nobody does, it makes my life considerably easier, as should be obvious by now
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 Jiminey christmas CK, why am I even listening to you and letting you try to push my buttons to begin with. Last I checked, you haven't made any sexout mods -- SCR dependant or otherwise.
ChancellorKremlin Posted June 3, 2013 Posted June 3, 2013 - SSR and SCR can live together, side by side, with no problems, as far as I know. If that really is the case, and will continue to remain so in the future, then I'm perfectly happy. Perhaps I should be talking with Hal about what to include in SCR rather than with you about what not to include In any case, you and other modders can do as you wish. I don't even know why I'm complaining - it's not like I have anything that relies on SCR/SSR anyway. EDIT: Seems like we think alike, though it sounds a lot less douchy when I say it.
prideslayer Posted June 3, 2013 Author Posted June 3, 2013 - SSR and SCR can live together, side by side, with no problems, as far as I know. If that really is the case, and will continue to remain so in the future, then I'm perfectly happy. Perhaps I should be talking with Hal about what to include in SCR rather than with you about what not to include That is the entire reason for the SSR beta download in the NG Beta thread -- for people to test first with SSR and the SSR using mods alone, then to test with them alongside SCR and SCR using mods. I forsee no "real" problems. However much you feel I need an attitude adjustment, understand that compared to what's running through my head, I am keeping a remarkably civil facade up. I am pissed about what's happened to SCR, and pissed about the impact it has on my game when I just sit down to play/playtest. As it stands right now, I personally refuse to use it, or any mod relying on it. That is unlikely to change for several months, even if I were to idiotically assume that all the changes I want made to it are made. However upset you think other modders are or may get at me for what I'm doing with SSR, understand that I am already upset, because SCR has done exactly that to Sexout, a mod I have put as much work into as anyone else has into any of theirs. I will admit, on this subject, my fuse has run quite short.
ChancellorKremlin Posted June 3, 2013 Posted June 3, 2013 You don't need to explain yourself Pride, I've made my final thoughts on the matter clear in my previous post. Where this progresses from here is entirely up to you and the other modders.
BruceWayne Posted June 3, 2013 Posted June 3, 2013 Easy fellas. While I don't want to go as far as saying I'm pissed about SCR, I certainly noticed the impact it has and was "irritated" about things it included as well. Given that I don't use any of the script-related mods like Pregnancy or something where the drugs, STDs or what-have-you would have their use, something like SSR is a good and welcome alternative. I'm hoping that my incessant questioning doesn't get confused with me demanding stuff and causing unnecessary grief. If it gets in there, I'm happy and would include it myself with no work required by anyone else. If it's not, I can live with that as well, seeing as I'm not doing it already with SCR and I can turn my plugin into an .esm with very little effort on my part. The face-skin-mismatch is a problem that has been at the back of my head for quite some time and I thought this was the easiest solution for this particular problem. Maybe it is, but maybe it is not the best possible solution. So whatever will be the case, I can and will live with it.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now