Jump to content

Recommended Posts

View File

BreakArmor Framework 1.10f

 

Break Armor 1.10 improves performance, adds Break Weapon support, and fixes all known bugs and incompatibilities.

 

Break Armor 1.10f resolves the reported problems with OBSE save game bloat and incorporates a fix to the way that Break Clothing calculates health.

 

What is Break Armor?

 

Break Armor is an entirely new approach to the Break Undies system that allows breakable meshes to be used on any and all compatible clothing and armors.

 

The framework has the ability to automatically detect Break Armor, Break Weapon, and Break Clothing compatible meshes without the need for external ini files. This greatly simplifies the process of adding additional Breakable meshes to your game.

 

Break Armor uses mesh paths, and mesh paths alone to determine whether or not a particular piece of armor is Break Armor compatible. This means that all that is required to make a piece of existing armor Break Armor compatible are meshes for each desired break state.

All that you need to do is place appropriately named meshes in the appropriate folders, and the Break Armor framework will automatically detect them and start swapping meshes.

 

That's all it takes.

 

Features:

 

1. Break Armor can potentially work on any existing armor, clothing, or weapons. All that is required are the meshes.

 

2. Break Armor is fully compatible with user-enchanted armor and clothing, dynamically generated armor and clothing, etc. All that matters are which meshes the items use.

 

3. Modders Resource: Break Armor features a custom callback function that will report the current break status and coverage of any items worn by the passed NPC.

 

4. BreakArmor can also be used without extra ini files. Break Armor has the ability to detect and load appropriately named BreakArmor compatible meshes with no external ini files. This works for clothing and weapons as well.

 

5. BreakArmor can process BreakUndies style ini files, if desired (optional).

 

Recommended Mods (Perhaps even Required):

Because what's the point of Break Armor if you don't have anything to break?

 

Break Armor for Vanilla Armors

 

BU Armors Compilation

 

Installation

 

 

 

Copy BreakArmor.esp into your Oblivion/Data folder.

Copy Break_Armor.ini into your Oblivion/Data/ini folder

 

Optional:

 

LoversBreakArmor.esp

This enables armor destruction for BreakArmor compatible meshes in Lovers. Note: This plugin is still a bit crude. I'l probably update it with something a bit more elegant in the future.

 

BU_Disabler.esp

This disables break undies scripts. This allows you to use armor from esps that have BreakUndies.esm as a master. Note, BreakArmor should be loaded after BU_Disabler.

 

 

Modding with BreakArmor

 

 

 

 

BreakArmor is fully compatible with all Break Undies style meshes. To ensure backwards compatibility with Break Undies meshes, Break Undies 2.x style ini files can be read and processed by BreakArmor.

 

However, BreakArmor can also function without Break Undies ini files.

 

Whenever a new piece of armor is detected, BreakArmor will check the mesh's folder for BreakArmor compatible meshes. It then looks for a very specific pattern in the name _ba#.nif

 

Assume that the base clothing mesh is called "clothingmeshname.nif"

Rename the break meshes to match the following pattern so that the folder looks like this:

 

clothingmeshname.nif

clothingmeshname_ba1.nif

clothingmeshname_ba2.nif

...

clothingmeshname_ba#.nif

 

clothingmeshname.nif is the base unbroken mesh (the one listed in the esp/esm that loads the clothing). clothingmeshname_ba1.nif is the first broken state, clothingmeshname_ba#.nif is the most broken state.

 

And that is all that is required to ensure compatibility with BreakArmor 1.10

 

However, if you would rather use BreakUndies ini files, simply append the appropriate RunBatchScript entry to the end of the Break_Armor.ini file. Note: BreakArmor automatically processes any or all of BreakUndies.ini, BreakUndies_Stock.ini, and Break_Armor.ini if present

 

To add Break Armor, Break Weapon, or Break Clothing capability to an existing armor (stock or from any mod)

 

1. Create a unique mesh for each break state. Note: There is no hard limit to the number of meshes that Break Armor can utilize for a given piece of armor.

2. Add those meshes to the folder where the original nif is stored. The meshes MUST be named in the correct manner that indicates the order of breakage, as detailed above. (mesh_ba1.nif, mesh_ba2.nif etc)

 

That's it. The next time the game is loaded, BreakArmor will automatically start swapping meshes based on Armor Health (for Armor) or NPC Health/Fatigue (for Clothing).

 

 

Requirements:

 

 

1. OBSE v.20 or higher

2. Armor and/or clothing that is available in-game. The BreakArmor framework doesn't know or care how the armor got in-game, all that it cares about is finding meshes that it recognizes.

3. Optional: An ini file that loads the meshes you want to use. Note: It looks for any of the following: Break_Armor.ini, BreakUndies.ini, BreakUndies_Stock.ini

 


  • Submitter
  • Submitted
    02/07/2013
  • Category
  • Requires

 

Link to comment

BreakArmor is supposed to read all three of Break_Armor.ini, BreakUndies.ini, BreakUndies_Stock.ini. Then you'd better remove stock entries from Break_Armor.ini aren't you? I'll handle them, no sweat.

 

Ah, and how's that multislot bug going? Fixed?

 

Uh oh, glad to see it's gone now. :3

Link to comment

Actually you might need to change "Recommended" to "REQUIRED" for the two mods. I assume that you will get either a CTD or console spam if you don't have those two mods installed as the ini check is run. Or am I wrong on this?

 

The three ini files should load fine no matter what mods are (or aren't) loaded. It's just grabbing file paths and mesh groups from the other two. They do try to grab formids, so I suppressed console spam for BreakUndies.ini and BreakUndies_Stock.ini. Any initialization console spam or errors *should* be originating from Break_Armor.ini.

 

It's probably worth mentioning that only the BreakArmor ini file is required. The other two will be read if they are present, but won't cause any problems if they are not..

 

The ini processing code checks for duplicate file entries and also for the presence of the meshes themselves. If the mesh has already been processed, subsequent reads of that mesh from any of the ini files are discarded. Similarly, if no mesh if found at the indicated file path, it is discarded.

 

So, what happens if you install BreakArmor and nothing else? Well, nothing.

 

On the other hand, if you grab some of the meshes from either mod and put them in the right place, they will be activated automatically. For anything that is not a vanilla replacer, you'll still need some armor in game that uses the base mesh.

 

Which meshes are BreakArmor enabled or disabled is entirely dependent on whether the meshes are installed and loaded in the ini file.

Link to comment

BreakArmor is supposed to read all three of Break_Armor.ini' date=' BreakUndies.ini, BreakUndies_Stock.ini. Then you'd better remove stock entries from Break_Armor.ini aren't you? I'll handle them, no sweat.

 

[s']Ah, and how's that multislot bug going? Fixed?[/s]

 

Uh oh, glad to see it's gone now. :3

 

The ini processing discards duplicate entries automatically, so overlap shouldn't cause any problems. Basically, the first time an entry is read *and* the file that it points to is found, it generates an array key string. If any subsequent reads have the same key, they are discarded.

Link to comment

This version freezes my game every time my armor needs to switch its mesh. x_x

 

Is there a loop somewhere that could possibly be infinite?

 

Crap. That shouldn't be happening.

 

Does it happen for all armors or just some armors?

 

Does it freeze when NPC's have their armor changed as well? Or is it just when player armor changes?

 

I need to find a way to replicate this error so that I can fix it.

Link to comment

This version freezes my game every time my armor needs to switch its mesh. x_x

 

Is there a loop somewhere that could possibly be infinite?

 

Crap. That shouldn't be happening.

 

Does it happen for all armors or just some armors?

 

Does it freeze when NPC's have their armor changed as well? Or is it just when player armor changes?

 

It seems fine for me. It worked well for player, worked relatively well for my MPC companion. When I say relatively I mean I need more testing..as I want to test in combat situation. oh well. She dies too easily. Too hard to test.

 

====

tested it twice in combat, works fine.

 

@Shia

What armor? If it is vanilla armor, perhaps it's because of bad mesh. I couldn't test all the meshes we worked. Well.. it's likely to cause CTD instead of freezing if that's the case..

Link to comment

I think the problem is related to stacks of armor. I think BU also got a little confused with stacks of armor, too. It didn't crash, but it didn't know which new model to assign to the armor I was currently wearing.

 

Anyway, I've tested the problem out for you and I think I found the cause.

 

In my inventory, I had a stack of 2 leather greaves and another leather greaves, the one I was wearing, outside of that stack, making three.

 

visual aid here: http://img801.imageshack.us/img801/4310/20121126043602.png

 

if I dropped the single one or it broke while I was wearing it, the game crashed.

 

If I dropped the stack of 2 and THEN the single leather greaves, the game did not crash.

 

After I picked back up only one of the leather greaves and wore it, it broke normally and didn't crash if I tried to drop it.

 

I'm not sure what exactly to do about it, but maybe there is a way to seperate the currently worn breakundies armor from a stack so it doesn't confuse or crash BreakArmor Framework?

Link to comment

I think the problem is related to stacks of armor. I think BU also got a little confused with stacks of armor' date=' too. It didn't crash, but it didn't know which new model to assign to the armor I was currently wearing.

 

Anyway, I've tested the problem out for you and I think I found the cause.

 

In my inventory, I had a stack of 2 leather greaves and another leather greaves, the one I was wearing, outside of that stack, making three.

 

visual aid here: http://img801.imageshack.us/img801/4310/20121126043602.png

 

if I dropped the single one or it broke while I was wearing it, the game crashed.

 

If I dropped the stack of 2 and THEN the single leather greaves, the game did not crash.

 

After I picked back up only one of the leather greaves and wore it, it broke normally and didn't crash if I tried to drop it.

 

I'm not sure what exactly to do about it, but maybe there is a way to seperate the currently worn breakundies armor from a stack so it doesn't confuse or crash BreakArmor Framework?

[/quote']

 

OK...that's annoyingly weird. I have a pretty good idea of why that might be happening. I'll need to see what I can come up with.

 

I have an idea that just might do the trick.

 

I clearly need to create a female character to test dynamic inventory management problems

 

I'm going to try disabling the event handler function for the player. I suspect that it is trying to re-equip a piece of armor that you already dropped.

Link to comment

I'm not sure what exactly to do about it' date=' but maybe there is a way to seperate the currently worn breakundies armor from a stack so it doesn't confuse or crash BreakArmor Framework?

[/quote']

 

That is the challenge with a mesh-only framework (I want to avoid modifying the items in any way). I'll see what I can come up with.

Link to comment

Okay great.

 

Also' date=' how's the callback coming along?

 

I hope I can make NX and NXU compatible with this in the next release. ^_^

[/quote']

 

Just let me know what you think will work best. I can add an inventory token or create a custom function callback. Whichever you prefer.

Link to comment

I think an inventory token is the best thing to do. That way' date=' there is much less of a CPU footprint.

 

I did forget to ask, though. Will the token system that corresponds to the GetEquippedObject numbers accommodate for when the lowerbody and upperbody items are seperate?

[/quote']

 

You tell me. How would you like me to set it up?

 

From the CPU footprint standpoint, if we pass the target NPC as a ref, I can just do a quick array lookup to tell you the breakarmor damage statuse of any equipped armors or clothing (the values will already have been calculated and stored). I think that would actually have a lower footprint than an inventory check (although with Oblivion scripts it can be hard to tell).

 

Either way we're cycling through arrays.

Link to comment

hm. Well, since nobody seems interested in making breakundies compatible gloves, helmets, or boots, I still think that the 0 for none, 1 for upper BU equipment only, 2 for lower BU equipment only, and 3 for both is the best format.

 

edit: hm. I see what you're saying.

 

But doesn't BreakArmor check to confirm to check every once in a while if pieces of armor are BU or not? Can't it just give them the appropriate itemcount, then?

 

and then onactorequip or onactorunequip, it can reset the itemcount.

 

edit again: Actually, the lowest footprint would be to only check the modelpath and give the itemcount onactorequip or onactorunequip, if possible.

 

Then again, I'm not too sure. You're the guy who made this new framework, so you might know better than me. XP

Link to comment

hm. Well' date=' since nobody seems interested in making breakundies compatible gloves, helmets, or boots, I still think that the 0 for none, 1 for upper BU equipment only, 2 for lower BU equipment only, and 3 for both is the best format.

[/quote']

 

Sounds good. I'll add that on the next upload. Once I figure out a solution to your crashing problem. For now, It looks like I'm going to fall asleep before I finish my trial solution.

Link to comment

hm. Well' date=' since nobody seems interested in making breakundies compatible gloves, helmets, or boots, I still think that the 0 for none, 1 for upper BU equipment only, 2 for lower BU equipment only, and 3 for both is the best format.

 

edit: hm. I see what you're saying.

 

But doesn't BreakArmor check to confirm to check every once in a while if pieces of armor are BU or not? Can't it just give them the appropriate itemcount, then?

 

and then onactorequip or onactorunequip, it can reset the itemcount.

 

edit again: Actually, the lowest footprint would be to only check the modelpath and give the itemcount onactorequip or onactorunequip, if possible.

 

Then again, I'm not too sure. You're the guy who made this new framework, so you might know better than me. XP

[/quote']

 

OK, I've experimented with a few different approaches and it looks like a callback function creates the least amount of overhead. It also has the advantage of being much more flexible than an inventory token system.

 

I've added a sample esp under the "Modders resources" folder that demonstrates all of the different callback methods available under the callback function.

Link to comment

Awesome! I've been waiting to try this!

 

Unfortunately, I think one of the new functions is creating too much CPU load, though.

 

 

Whenever I'm in battle, my FPS falls to a below playable state. As soon as the battle ends, the FPS goes back to normal.

 

The game has frozen once so far, but not again. It was just after my companion put on a full vanilla breakundies set.

 

edit: The good news is that it's working a little better with stacks of armor now. It can break armor some of the time. It just froze on me, though.

 

I'm guessing it freezes when two or more pieces of armor need to replace their mesh at the same time.

 

I don't know if you use it, but in nudeshy X, there is a chance of this having to happen because of ecchi combat system.

 

It also should be able to update the models of multiple pieces of armor at once if NPC's repair all of their armor at once. I just used MCS extension (or just the companion)'s repair/recharge spell on my companion's armor and the game froze.

 

edit again: Actually, I might be wrong. it just successfully updated the graphics for my companion's armor and then froze when I drew my weapon. hmm...

Link to comment

I think the problem is related to stacks of armor. I think BU also got a little confused with stacks of armor' date=' too. It didn't crash, but it didn't know which new model to assign to the armor I was currently wearing.

 

Anyway, I've tested the problem out for you and I think I found the cause.

 

In my inventory, I had a stack of 2 leather greaves and another leather greaves, the one I was wearing, outside of that stack, making three.

 

visual aid here: http://img801.imageshack.us/img801/4310/20121126043602.png

 

if I dropped the single one or it broke while I was wearing it, the game crashed.

 

If I dropped the stack of 2 and THEN the single leather greaves, the game did not crash.

 

After I picked back up only one of the leather greaves and wore it, it broke normally and didn't crash if I tried to drop it.

 

I'm not sure what exactly to do about it, but maybe there is a way to seperate the currently worn breakundies armor from a stack so it doesn't confuse or crash BreakArmor Framework?

[/quote']

 

What race is the girl in the picture?

Link to comment

A bad news, freeze problem still persists.

 

I'm wearing health 17 leather greaves, and add one more via console. I try to equip new (100) one, the game freezez. (as soon as I enter gamemode)

 

If I drop 17 one before I try to equip 100, it doesn't freeze.

Link to comment

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use