Puuk

I had completely forgotten that I even made this. Unfortunately no I don't think I will continue making these. That being said, Roberts Male body doesn't even need one if you are using Oblivion Character Overhaul. Seamless RMv52 is just a single install: https://www.nexusmods.com/oblivion/mods/45864

Thank you, I was aware of GetBipedSlotMask but there was some reason I didn't use it... Probably didn't have the patience to learn how it should be used. I'm quite disinterested in continuing this mod however, so you are free to host your own version if you'd like. Just take any asset rights into consideration.

Sorry for the late reply. I'm glad you managed to solve your issue. Unconventional skeletons were obviously something I had never considered before. Did the racial ability idea work out? If that is the case I could include such edit in the mod itself, if you want.

I haven't done anything with this mod for a while, but IIRC the code had to be implemented that way. Probably because of bugs like what you encountered. There should be an .ini setting which makes the script run more often, so you may want to try that. EDIT: I checked and it seems that I have omited such setting in version 3 for some reason. In that case you can still adjust the fQuestDelay variable in the quest script.

Using the v91b version from SetBody's Nexus page and running these files (http://www.loverslab.com/files/file/253-tgnd-body-replacer/) through it caused an error when handling following cuirasses: daedric, orcish, imperialpalace, imperialwatch, legiondragon: Traceback (most recent call last): File "PythonPortable\App\Scripts\kgtools\seam_mender.py", line 674, in <module> Main() File "PythonPortable\App\Scripts\kgtools\seam_mender.py", line 638, in Main morph_nif = None) File "PythonPortable\App\Scripts\kgtools\seam_mender.py", line 204, in process_nif target_nif = file_util.load_nif(test_file, template = template_nif, settings = c_s, morph_nif = morph_nif, init_nif = True) File "...\Seam Mender\PythonPortable\App\lib\site-packages\kg\file_util.py", line 666, in __init__ self.process_nif(settings, init_mesh, morph_nif) File "...\Seam Mender\PythonPortable\App\lib\site-packages\kg\file_util.py", line 711, in process_nif self.initMeshes(init_mesh) File "...\Seam Mender\PythonPortable\App\lib\site-packages\kg\file_util.py", line 1158, in initMeshes this_mesh = kg.mesh_util.mesh(self, geom, full_init = init_mesh, skel_root = r, idx = idx) File "...\Seam Mender\PythonPortable\App\lib\site-packages\kg\mesh_util.py", line 453, in __init__ self.initNormals() File "...\Seam Mender\PythonPortable\App\lib\site-packages\kg\mesh_util.py", line 673, in initNormals self.recalculateNormals(set = True, nmv = False) TypeError: recalculateNormals() got an unexpected keyword argument 'set' What might be the issue with these files? I'm using SetBody's TGND template and sample settings from the attached jpg, btw.

Ok, I see where you are coming from. I actually wasn't aware that there is damage armor effect.

Well nice to hear I was right about that one after all. Yeah it is great that we already have BA with these kind of issues solved. Getting rid of that unnecessary update however was really important in my book. Don't worry I wasn't fooled. Now that we are talking about this, do you recall if Break Armor cycles through actors when it tries to detect equipment that needs to break? In my approach I used event handlers to detect actors being hit (plus detecting when player enters repair/enchantment menu etc.), which may still be worth implementing here. Cycling scripts have that unfortunate side effect of increasing the chance of stuttering while most of the time achieving nothing. Of course detecting hits isn't a foolproof mechanism on its own (like when a NPC enters the cell), but it can help to drastically reduce the scan frequency to once per few seconds.

This is actually interesting, because in the hindsight I feel that that a noice clue is in place when you are fighting. If your mod really solves the annoying bit with cells I'd very gladly switch over to using it. Also thank you for technical description of what the code actually does. I find Oblivion scripting language relatively hard to read (especially multitype multidimensional arrays that are externally accessed by other scripts). I overviewed it just to find out that the EquipMe-command required by BA's solution doesn't have a silent version, so I wanted to try designing around it. Now it probably is the case that my version doesn't handle multiple same base inventory items very well (didn't really got around to test that), so I'm glad to hear this issue has been adressed.

This made me recall some work I did a few moths ago. Back then I was really liking this mod but the sound of my stuff re-equiping every time I change cell irritated me a bit. I looked into the code just to see to see that fixing this woldn't be too easy. With the experience I had gained from doing similar stuff with Oblivion earlier I began to experiment and came to a working solution. It currently is working in most cases, but repairing with a hammer or at smith (don't remember which) causes the mesh to not update properly, and may require restarting the game. Some pros and cons with my approach vs this one: - Break Armor makes a copy of the item it is replacing ands makes target equip it. To do this it must search and guess for the created item's reference in the target's inventory. My silent version equips a dummy object to the actor for a frame while it updates the target item. References are always known. - Break Armor supports all slots and combinations (if I'm correct). My silent versions needs to have new item created for each slot or combination. While this is not too big issue and new items are relatively easy to add, this also means no specific weapon support. - To my version I added a bit simpler way to make items display custom text when breaking in battle. I include an example for Justice123's Kvatch guard model which is one of those I experimented with. However, I must say that novelty quickly ran off. Anyway here it is, take a look if interested. I don't think I will provide any support as I mainly did this for myself. There is a much more featured alternative in the market anyway. One thing worth mentioning is that I had already supported hands+torso+legs+feet slot combinations but had to disable it because having armor change for a frame is enough for you to get disqualified from the arena. Project name is also "Break Armor 2" because I didn't have imagination. Silent Break Armor Functional.7z

The stripping options are in your Lovers with PK.ini and should work with both armor and clothes. There's no skipping forward/backward, just changing position. Actually in progression settings there is a choice to use jump key to advance into the next stage. Also, if you don't want to mess with inis, There should be a spell called something exploits that lets you change everything in-game.

The issue with Blockhead is that only the event with highest priority will be selected. If Setbody decides a target's body and BA the condition of item, you must choose which one you use. For every situation like this you need to have a patch that takes these both things into account somehow, as opposed to some kind of framework that handles all these issues. Nothing I say must be set in stone. When writing that I was thinking more about equipment replacers like EVE. It has a lot of meshes and editing the install path is less work than renaming everything it includes. After all, if you wish to have multiple models of same armor not every mesh can have the same name and be in same folder.

Yes. It was the most simple way to deliver my point across. I do aknowledge that it is not very good idea to do this in practice because this prevent further developement around it. Also something like Tamago is very complicated and not everyone's cup of tea so it wouldn't make sense to have all those scripts running. I guess that the actually best way to do this is to create a framework that handles all the actual mesh swap work and then have other mods attach to it. Maybe follow the Blockhead idea and assing every plugin a priority value that represent the folder structure. For example we have Tamago with the priority value of 10 and BA with 5. We start search from 'meshes\MESS\' folder. Tamago gets applied first and BA second so we try to find the mesh from 'meshes\MESS\tamago-X\ba-Y\', which should now represent the root folder of meshes, only with tamago's X and BA's Y stage applied to them. If we can't find the proper mesh, we forget that BA part and search from 'meshes\MESS\tamago-X\' and so on. Obviously if Tamago isn't active or the target pregnant we ignore it when searching and instead start from 'meshes\MESS\ba-Y'. The challenge here is to have our plugins inform the framework of these X or Y values, which may differ greatly from a mod to mod.

- When detecting a hit an event handler can add item to target's inventory. By attaching a script to this item and waiting just few frames before acting you can effectively monitor only those actors that are important. I used this tactic in my third version of Dynamic Underwear System to vastly reduce the impact it has on game. This most certainly would work with OnHit, I'm not sure if OnMagicEffectScript would require additotal consideration though. - Repairing is something that I completely forgot. While detecting the repair menu is fairly simple with a simple Menumode block, I'm not sure about these 'scripted repairs'. However since this is probably only relevant when considering the PC or followers, I guess it wouldn't be too much to track with a quest script. - OnActorEquip should work. Again I refer to my DUS mod, which does some similar things. Of course it doesn't swap meshes though. I'm not saying that BU should be rewritten to use events. I'm just thinking of a way to unify all these things like SetBody, BU and Tamago. Because they are mainly written to work independently of each other (minus Tamago Setbody I think?), it would require a lot tinkering to make all of them work together. Blockhead could possibly have been the solution for this until that mesh limitation came apparent. While iamnoone has made some good results with such a limited function, I can't but doubt how all these complex systems would work together. Every time I think about this issue I come to the solution that using just one framework for all these things would be best. When our target is about to equip something, one single OnActorEquip would run and check things in this order: 1. Gender? 2. Bodystyle? 3. Pregnant? 4. Broken Armor? Example 1: we have a male target, but there are no male bodystyles in our database (excluding the default one game would use). Don't proceed. Example 2: we have our male target again, but this time there multiple variations of a male body in the database. He will be assigned a random body variant if not already defined via token (probably best solution?). Since males can't be pregnant (unless for some reason someone really wants so and goes ahead to make all meshes etc.), we skip part 3 and look for an appropriate broken version of a mesh. In this case there isn't any, so we back up a little and just go with the body variant of what ever he is going to equip. Example 3: we have a female target, who is pregnant and does have pregnancy meshes for her assigned bodystyle. She is also taken some damage and there is BA version of her equipment present so we proceed to change the mesh. Example 3 probably doesn't happen since there would be too many permutations. Example 2 on the other hand is also unnecessary long process since there are no male BA variants that I'm aware of. This is easily fixed with some ini-settings (like I have 'ignoremaletops' in my DUS) to avoid any unnecessary processing. About the actual mesh swap, I'm not quite sure how this is best implemented. If we can assing mesh path in the OnEquip-event so that it becomes visible I'd go with that. Otherwise I think that we after all should go the Blockhead route and do what iamnoone has achieved here.

Sorry to suddently jump in, but I didn't quite understand why BA needs to constantly monitor nearby actors. Since it just swaps meshes when necessary can't you just use OnHit-event?

That's too bad, but thank you for trying. I hope that the moderators can fix this issue assuming that the author is unable. (Just realized that the actual uploader seems to be xaz who haven't been around for a few months).