FrankFamily

You can't import nif in SP, use nifskope or blender + nif plugin or maybe outfit studio to open the nif and export in obj or fbx. Now, what channels, I'm not sure there's a good answer. There's certainly not a single "one size fits all" approach. Skyrim isn't pbr as you say, if you make pbr textures and then load those in skyrim is not going to look good at all. You can: a) Make pbr textures normally and then do some conversion on these to get something that looks good in skyrim. Like, for example, I need the metals darker then maybe I can multiply the metalness onto the albedo at a certain opacity, stuff like that. Lighten/darken stuff, more contrast or whatever. Pbr glossiness could be a starting point for normal map alpha (specular) if you do metalness workflow, otherwise the specular. The metalness map will have some similarities with what you'll want the enviroment mask (_m) to look like (you definitely want to use enviroment mapping in skyrim in metals), since you basically want enviroment mapping in metals. You most definitely want to multiply AO into the texture, potentially even more lighting. There's some baked lighting effects in SP that could be useful. You could do this conversion later in photoshop or less destructively with adjustments directly in SP on top of the layer stack. b) Make textures specifically for skyrim in the first place with the downside that what you see in the viewport won't really match what you'll see ingame so you are a bit "blind". It's basically the same that you'll do in photoshop, just exporting and test ingame as you go. In either case, make a custom export preset that exports exactly what you want, it's super easy to setup and that way you put your specular in normal map channel, suffixes and so on. You need some other software to compress to dds though. Which aproach is better? B is simpler and kind of makes more sense, I'd argue you lose a lot of what SP provides, I do A. In the end you have to be familiar with PBR and Skyrim and find a workflow that works for you. Look at vanilla textures or textures from mods for a guideline of how should stuff look. Some links that could be useful: https://forums.nexusmods.com/index.php?/topic/1188259-bslightingshaderproperty-basics/ https://marmoset.co/posts/pbr-texture-conversion/

Most interesting, what minor issue i'm exaggerating exactly? Furthermore, what minor issue is there to exaggerate? Other than the contradiction you've claimed exists and that I'm not claiming is of any importance or putting much focus on, I'm simply saying it's not actually a contradiction. I'm also curious about what application of semantics has been selective here. The meaning of the word "buggy" doesn't seem to fit that in my opinion. Are we talking about other semantics I'm not aware of? Enlighten me please. I'm just explaining to you why there's no contradiction in those two statements because a software being "buggy" does NOT mean it simply having bugs (which is what would contradict the other statement), but instead having lots of them as pointed out. Meaning you seemed to have missed and meaning that makes the alleged contradiction not a contradiction. Thanks for the idiom btw, didn't knew that one.

Well, being "buggy" doesn't mean simply having bugs, it means having a lot of them, at the very least more than average, so there's no contradiction at all (because a thing can have have bugs but not many and therefore not be buggy). If simply having bugs, even if just a couple, makes a piece software "buggy" then I'm afraid everything is. https://www.merriam-webster.com/dictionary/buggy "Infested with/characterized by/containing many bugs", not simply "containing bugs".

So, to not spread misinformation I figured I could actually test this in the most objective manner I could think of. Here, pretty self explanatory: Â Note this behaviour may only apply to the particulary noisy areas of a texture. Â

A bit late. Well, popular wisdom isn't always 100% correct, it isn't really incorrect either. For most normal maps there will be a significant improvement in saving new normals in bc7 since artifacts in the normal are generally very noticiable. But if the normal map has a lot of information, for example, if you have some sort of very small cloth pattern where practically every pixel is significantly different from its neighbors. I imagine this is your case, lots of variation in the leaves. BC7 preserves that detail in the normal map way better than dxt5 but the alpha channel is worse. I guess in attempting to keep that information in RGB channels better than DXT5 the alpha channel suffers. Both formats end up weighting the same so I suppose there has to be some sort of tradeoff, makes sense. In most cases I'd still use BC7 because DXT5 will destroy the detail in the normal map. If both formats are not good for a particular texture then uncompressed is always an option, albeit a costly one. Normal map's alpha is the specular channel in all assets I have experience with, and they will all have it. In enviromental textures or creatures it might be different. Following vanilla is a good method I'd say.

The alpha channel of a bc7 will sometimes have much more artifacts than dxt5, rgb wil be preserved better though. So, dont use bc7 blindly, compare and decide what looks better ingame.

"+=" should be "+= 1" "int pt_1[n][o]" is not something that is going to work in papyrus, you can't have a multidiemsional array (you can fake it with a one dimensional one for many use cases) But I'm not too sure what you want to do there in order to tell you what aproach is good for papyrus.

Well, if you ask me, Oblivion did not have bugs at all. It's most likely not true but I played it when it came out, only on ps3 before I new mods were a thing and I don't remember it as a buggy game at all, I don't remember any bug whatsoever. So those bugs I found were irrelevant enough for me to still have a great time with it. Its one of my favourite games. Skyrim I've played less and in a different, more modding-centric, mindset but I'd still say its a great game without any mod. Its very easy once one starts making mods to fall into inflating one's importance and becoming exceedingly arrogant. Users are often overly enthusiastic and say all sorts of silly stuff like "you are the best; bethesda should learn from you or hire you; I cant play the game without this mod". Believing all that is easy, seeing the truth is a bit harder but I'd recommend trying. I'll also say that I was surprised to see no mods in op's profile given the abundance of "we"s in the post. Lastly, everytime someone throws a statement like the one I the title I wonder why the think hundreds of people should lose their jobs because this someone didn't like the product the company is selling. Or evenbecause the product is objectively bad. Don't like it, don't buy it, right? Nope... ITS MAKING BAD GAMES IT HAS TO DIE, YOU CANNOT RELEASE A GAME THAT I DONT LIKE.

I'm not familiar with skin textures in particular, but I extracted vanilla and all seem to have just rgb, no alpha channels. So all DXT1, if anything you may want to leave the normal map uncompressed to avoid artifacts, the size will be MUCH larger though, and if you are starting from vanilla normal maps that are compressed there's not much gain in doing it if the existing artifacts aren't removed. Check here if you aren't familiar with channels in PS: https://helpx.adobe.com/photoshop/using/channel-basics.html In all of these you should only see RGB, no alpha. It's possible you have an all-white unused alpha in them depending on formats the were saved previously, if so, just remove it before saving. As said, looking at vanilla it doesn't seem like any of these will use alpha channel for anything. So DXT5 will only double the size by introducing an all-white alpha channel for no benefit at all.

So the previous with the 1060 was at 1080p I assume, and with a 1070ti in 1440p you are getting slightly worse performance, correct? Well, 1440p is a lot more pixels than 1080p, almost twice as many in fact. 1920x1080 = 2 million, 1440x2560 = 3,6 million. Is a 1070ti 170% more powerful than a 1060? I don't think so. Seems to be about 60% from a quick google. Not that things are this simple but maybe the impact in performance it's just what one would expect from going from 1080 to 1440.

You'll want DXT1(aka BC1) for images with only 3 channels (R,G,B) like diffuses without transparency, and DXT5(BC3) for those thatt have alpha channel. Generally you want mipmaps, yes.

Wait, no, GetEquippedShield gives you armor (the form, not the particular instance) you don't need getbaseobject's at all. Going off your last version, what about this: Scriptname _AceTestingScript extends ActiveMagicEffect Enchantment Property MyEnchantment Auto Armor BaseShield Event OnEffectStart(Actor akCaster, Actor akTarget) BaseShield = Game.GetPlayer().GetEquippedShield() WornObject.SetEnchantment(Game.GetPlayer(), 0, 0x00000200, MyEnchantment, 1000) Game.GetPlayer().UnequipItemEX(EquippedShield, 2, False) ;you said this refreshed the enchantment EndEvent Event OnEffectFinish(Actor akCaster, Actor akTarget) Game.GetPlayer().RemoveItem(BaseShield, 1) Game.GetPlayer().Additem(BaseShield, 1) ;this is wrong is the player has multiple instances of this shield, it might not remove the enchanted one. EndEvent

This line is wrong: Game.GetPlayer().GetBaseObject() as Armor the player is not armor so it results in none. Equippedshield.GetBaseObject() as Armor is what I think you wanted to do. Definitely not objref as you have in the comment. why the while instead of running that oneffectfinish?

What I meant is that in the script of a magic effect within an armor enchantment (which should extend activemagiceffect) you receive events from the activemagiceffect like oneffectstart and you also receive events from the player this magic effect is affecting (in armor the one wearing it) like OnHit, OnObjectEquipped, etc. So it's a bit weird that you said you have attached to the enchantment an script extending object reference, an enchantment is not an obect reference, with OnContainerChanged and OnEquipped events that wouldn't be received in the enchantment. No idea how you could remove it, this is an area I haven't experimented with. Perhaps make a blank enchantment and set that at the end? Maybe you can pass none as the enchantment and that removes it, can't tell.

Check the log, Self.GetBaseObject() is most likely failing if that object is in inventory, self will be an invalid reference then, unless the item is persistent which I'm not sure you'd want it to be. In any case you said this was in the enchantment's magic effect? Those events won't be received there. They would have to be in the armor form which is the item that changes container and is equipped. The enchantment runs on the player so you get events from the player actor not the item it belongs to.

The first function is in the armor script, the other in the wornobject script. You'll need to either import WornObject and call normally or WornObject.SetEnchantment(etc) In the same manner that you do Game.GetPlayer() and not just GetPlayer() Event won't give you a compiler error since you'd be declaring it, but it would never be received because it's not an event. So: Scriptname _AceTestingScript extends ActiveMagicEffect Enchantment Property MyEnchantment Auto Event OnEffectStart(Actor akCaster, Actor akTarget) WornObject.SetEnchantment(Game.GetPlayer(), 0, 0x00000200, MyEnchantment) EndEvent

It's function not event, I haven't used those functions but I guess you'd pass something like this: SetEnchantment(Game.GetPlayer(), 0, 0x00000200, myenchantment, maxCharge) or instead of the hexadecimal value accessing the property on the armor script, kslotmask39. I don't see why you couldn't just write the number as I did above though.

Shaders for weapon might be somewhat different? I'd try with a shader from an armor piece to make sure. I don't think there's a function for setting enchantment on an object reference because obtaining the object reference will be a problem when the item is in inventory. They give a "XX form in YY container" or something like that, not an objref you can use. You could however use the functions here in the wornobject script: https://www.creationkit.com/index.php?title=WornObject_Script here is how the slot masks work: https://www.creationkit.com/index.php?title=Slot_Masks_-_Armor Those should work on the specific item you have equipped and not the form, without required a proper reference to it.

It's fairly straightforward. You have the constant magic effect that goes into the armor enchantment, around the top right of the magic effect window you can link a perk. The perk will be added while the effect is active. In that perk you use the "Apply Combat Hit Spell" entry (adds effect to target when you succesfully hit him with a melee weapon and whatever conditions you have are met). Point it to a contact fire and forget magic effect with fire or whatever (edit: actually you point it to a spell containing said magic effect). Add condition that the armor piece is equipped to be safe in case it isn't properly removed, optionally add other conditions to make it more interesting like only on power attacking or sneaking, stuff like that. You can condition different perk entries (and therefore effects) to different directions of power attacks which is pretty cool but I can't recall the specifics of that. I believe this has the potential to conflict with other perks using that entry point in that only one spell will be applied to the target in a hit, if all have a few conditions this shouldn't be a problem.

I'm not sure about this but shouldn't it work directly? that magic effect archetype runs on self adding the enchantment to the weapons if they don't have any, correct? There's no difference between a self casted magic effect and an armor enchantment in that regard so I don't see why it wouldn't work. If you want to make an armor piece add effects to melee weapons there's also the perk entry point apply combat something. I've used that in armor to add fire damage to weapons in addition of their enchantment. https://www.creationkit.com/index.php?title=Perk_Entry_Point

Great read! Mistake at the end on the author's name btw.

In response to post #65123986. False, I do listen. I, however, am not your slave and, last time I checked, it was my mod. The best I can do is encourage you to learn yourself how to do the changes you want to done, for private use of course. Good luck!

Yeah, send me the scene, if you can save it as a previous version in "Save As" that would be great. Not sure if it will let you go as back as 2013. If not then just send me that I also have 2018 installed but I'm used to 2013.

Indeed don't select everything but instead skin wrap one by one the pieces. That would explain the instancing error. In the process I explained you wouldn't export it in that pose but instead animate it back to the vanilla pose (to be safe here I'd duplicate and collapse one skin modifier so the underlying geometry is fixed to the vanilla pose, then untick and retick "always deform" on the remaining skin modifier so that it updates properly, going by memory but something like that is what I did) so that the armor is now in skyrim pose and then proceed normally from there. That error isn't very informative, ahrd to tell. If you want you could send me the max file and I could give it a look. That's 3dmax 2013?

Perhaps it was italics and not bold, I could be misremembering that, if it's an instance do make it unique. Not sure what you have going on in there, I'd play with the bones around there and see what effect that has.