Belthan

Yeah, same thing with the mobster glasses. That's "Plan B" if I can't get acceptable results with a single mesh. Unfortunately, that would require completely reworking the mesh because the "cutout" currently doesn't correspond with any vertices (it's all done with the texture). And editing meshes with the new NIF format is a major hassle compared to the old FO3/FNV format. And I have at least a dozen other outfits with the same issue. [sigh]

The gaps in the commonwealth shorts mesh top are completely transparent and the strands are completely opaque, which means they're probably still constrained by materials treating the alpha channel as binary. Works fine for fairly broad mesh and fishnet, but not for sheer fabric like chiffon. The butterfly cutout in my Little Black Dress Is supposed to be filled with black chiffon, which is partially see-through. The alpha channel in the _d.dds file is 70% for the cutout and opaque everywhere else. When the NIF has a BSLightingShaderProperty and a proper BGSM file, the cutout looks like an empty gap. With the same _d.dds file, a NIF with a BSEffectShaderProperty, and a proper BGEM file, the cutout is partially transparent (not quite as dark as it should be, but that's easy to fix). However, the BGEM file ignores the specular map (_s.dds), so it uses an environment map with an environment mask (_m.dds) instead. It's better than being completely matte black, but it looks like crap compared to the BGSM version, which does use the specular map (plus the lack of a specular map means it doesn't look shiny when wet). Maybe a picture is worth a thousand words: https://drive.google.com/file/d/0By98Y3-7IeHYcTJHLWozRkNTR3M/view?usp=sharing

I'm not aware of one. The victim could potentially be in a large number of factions, so even if a function like that existed it would have to return a list of factions. This is a klunky workaround, but you could use GetInFaction in a script with an if and as many elseifs as you need to cover victim's likely factions. if victimREF.GetInFaction faction1 sendassaultalarm victimREF faction1 elseif victimREF.GetInFaction faction2 sendassaultalarm victimREF faction2 ... endif

After further investigation, NiAlphaProperty was a red herring - it is completely superfluous in FO4 (unlike FO3 & FNV where it was absolutely required to enable transparency). If the alpha channel in the dds and the alpha settings in the BGSM or BGEM are correct, you can remove NiAlphaProperty from the NIF and you will still get transparency. The good news is that you can get partial transparency by using BSEffectShaderProperty instead of BSLightingShaderProperty. 1) Create a dds file with desired transparency 2) Create a BGEM file, or copy one like Materials\Clothes\Mobsters\Glasses.BGEM and tweak it to your liking (most importantly, on the Effect tab, set the Base Texture to your partially transparent dds file). 3) In NifSkope, if your object has a NiAlphaProperty, remove it. 4) Insert a BSEffectShaderProperty. 5) In the new BSEffectShaderProperty, change Name to your BGEM file (e.g. Materials\Belthan\LBD.BGEM). 6) In BSSubIndexTriShape->BS Properties change the first entry to the index of your new BSEffectShaderProperty, and change the second entry to None. 7) Remove Branch on the now-unused BSLightingShaderProperty The bad news is that the Effect tab doesn't allow you to specify a specular map, and since you are linking to the BGEM from a BSEffectShaderProperty the specular map on the Material tab has no effect. This is fine for visors and such, but it sucks for things like lace and sheer cloth. I might be able to work around it with a subtle environment map to simulate the missing specular map, but geez... it's like they thought the only partially transparent material in the universe is glass. I mean, either allow a Material to render a partially transparent alpha channel without a binary black/white threshold (which you could do in freaking Oblivion, for crying out loud), or allow a specular map on an effect. It's not rocket science. And if anybody does figure out how to achieve partial transparency with a material, I'll apologize for the rant :smile:

Yes, and one might assume that would work with a reasonable combination of blending flags in the nif's NiAlphaProperty. It doesn't, which is why I'm going through the time-consuming process of testing unreasonable combinations.

Awesome, thanks!

I noticed that. Glad you didn't get banned for it :smile: Anyway, I was following this thread because I have the same problem. I haven't replied before because I don't know how to fix it yet, but maybe sharing the symptoms and what I've tried already will be useful. I also need partial opacity, but the alpha channel in the diffuse dds seems to be all or nothing. That is, if the greyscale in the alpha channel is below a certain level, the texture is completely opaque, otherwise it is completely transparent. Have tried numerous combinations of alpha threshold in the bgsm and the NiAlphaProperty in the nif to no avail. I'm still working on it, and I'll let you know if I figure it out (and hopefully vice versa if you figure it out before I do).

Anyone know if this list ever became the de facto standard for clothing & armor slots? I'm starting to port my mix & match separates from Coito Ergo Sum, and I want to be as compatible as possible with other mods. I know I'm a little late to the party, but my only suggestion to the list as proposed would be to use 33 for boots/shoes because the body mesh is typically part of whatever goes in 33, and in my experience shoes are the item most likely to require edits to the body mesh (to accommodate heels).

Correct - StopQuest BucksQuestCheck at the end of the script means it will only run once (plus changing that script would probably conflict with other mods that do similar expansions and any future updates to New Bison Steve itself, so creating a new script to add your features is definitely the way to go). I'm not familiar with the scripts for New Bison Steve, but it looks like everything else in your examples is prefixed with Bucks* so the compiler error may just be a missing "s" in the ref name (presumably BucksRestEquipREF).

That's the right idea. The more conditions you check in the chatter quest script itself, the less conditions you have to copy & paste between your chatter infos. Something like this. SCN ChatterQuest FLOAT Timer BEGIN GameMode if TheREF.IsInCombat == 0 && TheREF.IsSneaking == 0 // you can also check wait/sandbox command status here if Timer > 120 if GetRandomPercent < 50 TheREF.say [ChatterDialogueLine] endif set Timer to 0 else set Timer to Timer + GetSecondsPassed endif endif ENDThen you can use GetInCell and similar conditions in the infos to enable location-specific chatter.

The main example would be the magazine layout terminals. The first terminal lets you pick an NPC for the cover from a list. The result script for each choice does something like this: set cesModels.CG to AnActualPersistentREFSo far, so good. The next two terminals let you pick additional NPCs to be included in the issue in a similar fashion: set cesModels.FP to AnotherPersistentREF set cesModels.BF to ThirdPersistentREFThe last terminal commits the layout to be printed and calculates bonuses with something like this (simplified for clarity): REF CG REF FP REF BF set CG to cesModels.CG set FP to cesModels.FP set BF to cesModels.BF if CG.GetInFaction Faction1 && FP.GetInFaction Faction1 && BF.GetInFaction Faction1 // do stuff to set theme issue bonus endif if CG.GetInFaction Faction2 && FP.GetInFaction Faction2 && BF.GetInFaction Faction2 // do stuff to adjust theme issue bonus endif // ... and so on // Then calculate total bonus & prepare for printing The last terminal needs to be general purpose because the number of possible combinations for an issue is N*(N-1)*(N-2) where N ~ 90. The first three terminals could set flags to be used by the calculation in the final step, except every time i wanted to tweak the formula or add a bonus category I would have to edit ~270 result scripts (one for each entry on the three selection terminals), and I wasn't aware of the problem with declaring vars in result scripts until you pointed it out.

Thanks for the info! Fortunately, I do almost everything that needs to share vars across scripts with globals or quest variables, but I do have a handful of embedded result scripts (no SCRI) with this kind of construct: REF LocalREF set LocalREF to QuestScript.QuestREF LocalREF.SomeFunction // because QuestScript.QuestREF.SomeFunction won't compile I know it's probably impossible to say for sure, but any idea where that falls on the scale of bad practice? Like, "not great but you can probably get away with it", "might cause intermittent problems", or "change it now before it causes Armageddon"?

I believe the same thing happens even if you set the opposite from parent flag (that is, the child's enable state still only updates when the parent's enable state changes). However, disable & re-enable the parent should force all children to be enabled regardless. So, you would only need to change one line in the quest script when you add new children: BEGIN GameMode if ActualTargetREF.GetDisabled == 0 if MostRecentlyAddedChildREF.GetDisabled // change this with each update ParentREF.disable 0 ParentREF.enable 0 endif endif ENDIf you do it in the OnLoad block of one of the object scripts instead of a quest script, you could probably remove the GetDisabled check on the most recently added child, and therefore the script wouldn't need to change at all when you add features. This would disable & re-enable the parent & all children every time the cell loads, but A) it should all happen in the same frame and B) it will probably happen while the loading screen is still displayed, so there shouldn't be any visible flickering under normal circumstances. BEGIN OnLoad if ActualTargetREF.GetDisabled == 0 ParentREF.disable 0 ParentREF.enable 0 endif END

A REF whose enable parent is initially disabled only gets enabled when the parent REF's enable state changes. If the parent ref was already enabled before the mod with the child was loaded, the child won't be enabled unless something disables and re-enables the parent. Your best bet is to make one of your new objects the parent of the others, and enable it based on the enable state of the existing REF you would have otherwise made the parent. You can do that in a quest script as shown, or in the OnLoad block of the object itself, if it has a script attached.

NEW SURVEY: Fans of Quo Vagis (FO3) and Coito Ergo Sum (FNV) will be happy to know that A Picture Is Worth 1000 Caps will be back as a side quest in Vidi, Vici, Veni (the third part of the trilogy, coming to Fallout 4 later this year). If you haven't played either of the first two chapters there's way too much to explain here, but A Picture Is Worth 1000 Caps is a side quest to publish a magazine in all three mods (and here's a , but be warned - major spoilers for the first two parts). Anyway, here's your chance to weigh in on the bonus potential of FO4 NPCs for each section of the magazine (female models first, male models next month): https://www.surveymonkey.com/r/VTDRV2Cv

I hereby officially retract every time I grumbled "read the mod description, you idiot" when someone asked a question that was already answered about one of my own mods :) Thanks!

I've had some requests to provide bodyslide files for the CBBE versions of my outfits so they can be easily converted to fit customized CBBE bodies. If anybody can point me to documentation on how to do that, it would be greatly appreciated.

By "scriptlets" do you mean result scripts for stages/terminals/packages/infos etc. as opposed to full quest/object/effect scripts?

The Outfit Studio in bodyslide lets you import obj files, and export FO4-compatible NIF files. The process is pretty straightforward for actual outfits (which I have done). I verified it can convert other types of objects, but I haven't used the technique to make anything other than outfits. You can definitely create and skin a mesh in Blender (or presumably any modeling program), import the obj into Outfit Studio, export as a FO4-compatible NIF, and load that NIF into NifSkope 2.0. Then you can theoretically make whatever adjustments are required to make it a functioning weapon, static, or whatever.

Not until the CK is released (or somebody figures out how to compile scripts without it). After that it should be simple.

To be fair, code reuse is a common practice, and since stripping out and/or renaming legacy resources isn't visible to the user, it's typically viewed as a waste of time and money. After Microsoft spun off OS/2 to IBM and rebranded their own version as NT, it took them ten years to get all the OS/2 references out of the kernel. Not saying it isn't a symptom of laziness, just saying it's not the most egregious symptom :wink: LMAO! Rest assured, once the CK is available there will be mods which add NPCs with depth and quests with mysteries, dilemmas and consequences. (Shameless self-promotion alert: Vidi, Vici, Veni Teaser)

Interesting, thanks for the tip. Fortunately, while I did say I use the technique "all over the place", most of those places are called infrequently (for example, once per each issue of the magazine) so save bloat should be minimal, definitely not anything that runs every frame like the example in that thread.

I'm not aware of any vanilla scripts that work this way, but if you're looking for examples I do it all over the place in Coito Ergo Sum.

Using resources from other mods in your own mod is okay if you have permission from all of the authors whose resources are being used. I'm not a moderator, but I'm pretty sure the restriction you mention is only intended to prevent simple mod compilations. That is: don't download ModA and ModB, make a single zip file that contains both without changing either one in any way, and then upload it as a new mod. However, if you download ModA and ModB, combine them into a single ESP file and a single set of resource folders, AND you have permission from both authors, that would probably be okay because your mod is adding value. Specifically, in that case you would be reducing load order bloat for players who want features from both mods and would otherwise need two ESP files.

I create a dummy quest called GOSUB, and put common functions in the result script for the quest stages. You can then "call" those functions with something like: SetStage GOSUB 50 One nice side effect is that a quest stage result script is guaranteed to run to completion when the stage is set, so you don't need to worry about timing issues.