Break Armor Framework

[movomo]

That's good news. It now seems BA is stable so far.

[gerra6]

That's good news. It now seems BA is stable so far.

 

Stable is good.

 

I haven't received a single bug report since I released 1.08.

[Uriel]

Can't you set it up to not require an ini at all? I thought about something like this: run GetBipedModelPath, replace ".nif" in modelpath string with "01.nif" and run a IsModelPathValid check. If the 01 model exists, chack for other BU stages.

 

Not sure those checks will run fast enough though.

[gregathit]

If you don't have an ini then how would you alert oblivion to which armors are BU ones?

[Uriel]

OnActorEquip event handler, OnHit event handler... RefWalking NPC's in a cell on GetCellChanged to find which armors to check for BU compatibility, then control "GetNumRefs 35" to discover new NPC's.

If it's unreliable or impossible, maybe just leave only one path in the ini along with a number of supported stages. Or detect stages with IsModelPathValid check.

 

Just an idea, maybe gerra6 had tried something like this already.

[gregathit]

OnActorEquip event handler' date=' OnHit event handler... RefWalking NPC's in a cell on GetCellChanged to find which armors to check for BU compatibility, then control "GetNumRefs 35" to discover new NPC's.

If it's unreliable or impossible, maybe just leave only one path in the ini along with a number of supported stages. Or detect stages with IsModelPathValid check.

 

Just an idea, maybe [b']gerra6[/b] had tried something like this already.

 

Ah, well ... most of that is way over my head. However, I wonder if trying to have scripting do that sort of thing would generate an unnecessary CPU load?

[gerra6]

OnActorEquip event handler' date=' OnHit event handler... RefWalking NPC's in a cell on GetCellChanged to find which armors to check for BU compatibility, then control "GetNumRefs 35" to discover new NPC's.

If it's unreliable or impossible, maybe just leave only one path in the ini along with a number of supported stages. Or detect stages with IsModelPathValid check.

 

Just an idea, maybe [b']gerra6[/b] had tried something like this already.

 

That's not the problem at all. I already scan the qeuipped inventory of every NPC (One NPC per frame that doesn't already include a breakArmor swap event...each breakarmor event gets exclusive access to the tool for two frames).

 

Prior to that, when the ini is loaded, I already check the file paths to ensure that every file included in the ini actually exists before I add a particular mesh to the core BreakArmor array.

 

The problem is that I have no way to know in advance which armors should be breakarmor compatible, what the naming conventions of the breaks will be, or even if all of the pieces will end up in the same folder.

 

An ini file solves that problem by allowing modders to tell BreakArmor exactly which meshes go with what. And that's all it really does in addition to user-customizeable settings.

 

Now, I should probably mention that the BreakArmor ini file *only* gathers mesh paths (and messages, if included), not the actual objectids. So if you're just asking me to remove the itemid requirement from BreakUndies, that was the entire point of this project.

[Uriel]

Yep, i've seen that change to a paths instead of itemid's. My idea was to use a single naming convention for all BU meshes. That'll help keep all those meshes in a strict order, make editing, debugging them simplier.

Also i think that ini's are what made previous BU systems unpopular. Learning the ini stuff was over the head/not worth the time for a most part of players, nearly all others were too lazy/bored to write the ini's, and those who wrote them encountered bugs they were not able to fix.

With this system ini's are simplier, but they are still required.

 

I just realised FileExists command should be better then IsModelPathValid.

 

However' date=' I wonder if trying to have scripting do that sort of thing would generate an unnecessary CPU load?[/quote']

I tried scripting a new RHHS engine, and found that scripts are running pretty damn smooth even when they're doing A BUNCH of unintended stuff i were not able to foresee. xD

I now think not the scripts are slowing the game down but what they do to the game. You can run a giant loop nearly instantly if it's only manipulates the data. But those scripts that constantly do something with the rendered objects will be much slower.

 

 

BTW, is there an ini for the Gregathit's BU packs somewhere?

[movomo]

Yep' date=' i've seen that change to a paths instead of itemid's. My idea was to use a single naming convention for all BU meshes. That'll help keep all those meshes in a strict order, make editing, debugging them simplier.

Also i think that ini's are what made previous BU systems unpopular. Learning the ini stuff was over the head/not worth the time for a most part of players, nearly all others were too lazy/bored to write the ini's, and those who wrote them encountered bugs they were not able to fix.

With this system ini's are simplier, but they are still required.

 

...

 

BTW, is there an ini for the Gregathit's BU packs somewhere?

 

Unified BU naming convention would be a great idea. There are 2 minor problem though,

The first one is that someone should change every single BU meshes name to one pattern. Well, they are not 'plenti', probably this one won't be a huge pain.

The second, we should make sure that no other armors share the same naming pattern as BU ones.

If gerra6 can make BA not to use ini at all. without much cpu load, wow.

 

&

 

You can use Greg's BU pack ini without modification. If you don't like those unnecessary lines, just use notepad's replace all or something and coment out all of them.

[gerra6]

Yep' date=' i've seen that change to a paths instead of itemid's. My idea was to use a single naming convention for all BU meshes. That'll help keep all those meshes in a strict order, make editing, debugging them simplier.

Also i think that ini's are what made previous BU systems unpopular. Learning the ini stuff was over the head/not worth the time for a most part of players, nearly all others were too lazy/bored to write the ini's, and those who wrote them encountered bugs they were not able to fix.

With this system ini's are simplier, but they are still required.

 

[/quote']

 

I think I'm missing something. What is so complicated about copying an ini file into an ini folder? Why is that a huge barrier?

 

If you're talking about manually modifying ini files, I've taken steps to ensure that only modders *need* to modify the ini files.

 

As mentioned on the first page, the base BreakArmor package scans for and accepts three ini files, which in turn gives you access to all armors in Gregathit's package as well as Movomo's stock replacer package.

 

I just realised FileExists command should be better then IsModelPathValid.

 

That's what I use:

 

Begin Function {}

let filePath := "Data\Meshes\" + $aaBUData.DATA
if FileExists $filePath
	ar_Append aaBACycle.arr_TempFilePath aaBUData.DATA
	let aaBACycle.FileCheckArray[$aaBUData.DATA] := 1
else
	let aaBACycle.FileCheckArray[$aaBUData.DATA] := 0
endif

sv_Destruct filePath, aaBUData.DATA
End

 

That is the function that processes any mesh paths from the ini file. It's pretty straightforward. Before it adds an mesh to the temporary group array' date=' it checks for a valid file.

 

Once a script sets the quest stage to 30, all entries in the arr_TempFilePath array are added as a single array group into the primary array.

 

However' date=' I wonder if trying to have scripting do that sort of thing would generate an unnecessary CPU load?[/quote']

I tried scripting a new RHHS engine, and found that scripts are running pretty damn smooth even when they're doing A BUNCH of unintended stuff i were not able to foresee. xD

 

I now think not the scripts are slowing the game down but what they do to the game. You can run a giant loop nearly instantly if it's only manipulates the data. But those scripts that constantly do something with the rendered objects will be much slower.

 

Take a look at the first few pages of this thread. The 1.00 to 1.02 releases really didn't hammer the CPU that much, but some folks experienced tremendous lag when they ran the early revisions of BreakArmor.

 

It doesn't take much for Oblivion to hit a brick wall of performance. There are simply too many mods out there that hog system resources in unpredictable fashion. I learned the hard way that I could not assume that my mod would be free to hog the CPU whenever it wanted to.

 

That's why the current version of BreakArmor is designed specifically to minimize CPU load. The fact that the mesh swaps are almost instantaneous with this new system is just a nice bonus.

 

BTW' date=' is there an ini for the Gregathit's BU packs somewhere?

 

Yep. The one in the pack should work fine. BreakArmor was designed from the ground up to be backwards compatible with all known BreakUndies ini files.

 

I'll think about what you've said, but I keep running into the same two obstacles.

 

The first is that I will not sacrifice backwards compatibility with BreakUndies for any reason.

 

The second is that I will need a damn good reason to increase the CPU load of this mod. Trust me...no matter how well this stuff runs on your computer, all it takes is a few sloppy mods and performance dies.

 

Now, there is an onLoad file scan that I've planned for my next release (which I have not actually started working on). It will be a modders resource that automatically scans the ini folder for esp specific BreakArmor ini files. It's basically a modders resource addition.

 

Lets say someone creates a new BreakUndies/BreakArmor collection of meshes for a mod called HeavyMetalArmor.esp. During the onLoad initialization, BreakArmor will check the ini file for BA_HeavyMetalArmor.ini and if present, will process it.

 

No special editing of any pre-existing ini files would be required to add new armor collections to BreakArmor

 

What do you think? Would that help address your concerns?

[gerra6]

If gerra6 can make BA not to use ini at all. without much cpu load' date=' wow.

[/quote']

 

I honestly don't know.

 

Here's the problem. Right now, BreakArmor (like many other mods) does a ton of initialization and other resource intensive processing work immediately after the game is loaded.

 

This gives me the opportunity to build a nice big array that stores all of the known file paths without needing to worry about an in-game performance hit. Whenever I scan an NPC for the first time, I check their armor paths against the keys in that array and either categorize their equipment as BA compatible or not. From then on, the scan more or less ignores the non BA compatible items (sort of).

 

Here's the code that cycles through the NPC inventory:

 

 

scn aaBAEqCheck

array_var arr_eq
array_var arr_eqRef

string_var NPCKey

ref currentNPC
ref BaseObject
ref InventoryObject
ref tempInventoryObject

short meGender
short eqKey
short IOKey

Begin function {currentNPC}
if IsFormValid currentNPC == 0
	return
endif

let NPCKey := GetRawFormIDString currentNPC
let meGender := currentNPC.GetIsSex female

;Cycle through all equipped items on passed NPC
;First get equipped objects
Let arr_eq := currentNPC.GetEquippedItems
let eqKey := 0
while eqKey < (ar_Size arr_eq)
	let BaseObject := arr_eq[eqKey]
	let eqKey += 1
	;Check for Armor or Clothing
	;print "Test 1"
	if eval (aaBACycle.BreakClothing)
		if eval (!(IsClothing BaseObject) && !(IsArmor BaseObject))
			continue
		endif
	elseif eval !(IsArmor BaseObject)
		continue
	endif 
	;print "Test 2"		
	if eval ((ar_find BaseObject aaBACycle.NPCStateArray[NPCKey]["NoBAEquip"]) >= 0)
		;Item is not BreakArmor compatible
		continue
	endif

	let arr_eqRef := currentNPC.GetInvRefsForItem BaseObject
	let IOKey := 0
	while IOKey < ( ar_size arr_eqRef )
		let tempInventoryObject := arr_eqRef[iOKey]
		if ( 1 == tempInventoryObject.isequipped )
			let InventoryObject := tempInventoryObject
			break
		endif
		let IOKey += 1
	loop

	if eval !( InventoryObject )
		break
	endif

	if eval ((ar_find BaseObject aaBACycle.NPCStateArray[NPCKey]["BAEquip"]) >= 0)
		;Item is BreakArmor compatible
		;print "aaBAEqCheck Current Health " + $InventoryObject.getcurrenthealth
		call aaBAEQStatus currentNPC InventoryObject BaseObject
		continue
	else	
		;print "First Time Set-Up" + $currentNPC + "  " + $InventoryObject
		call aaBABuildEqArray currentNPC InventoryObject BaseObject
		continue
	endif
loop
sv_Destruct NPCKey
End

 

 

This alternate system would require me to build that big array dynamically. The first time an NPC is scanned in a session I would need to run a check on x variations of every single piece of armor and clothing that they are wearing. For any that are BreakArmor compatible, I would then need to build unique array entries for their equipment.

 

Would this work? Probably. But it is going to entail a performance hit the first time an NPC is scanned.

 

There is also the problem of false positives. We would need to decide on a naming convention that no one else has ever used for anything else.

 

And, of course, I would still need an ini file to store user customizeable options.

 

So, if you folks really want this, I'll consider it. But I don't like it.

[gregathit]

Well, I don't understand the need myself. There is no real barrier to individuals entering armors into an ini anymore. The ini that Gerra6 has pared things down to is really just a simple file path listing of where the meshes are. The ini for my pack is a bit more complex, but still just a listing of file paths so oblivion can find the meshes it needs.

 

Now the scripting that one "used" to have do with the BU 1.2 system inside the esp files was a royal pain in the butt and I could understand folks not understanding it. This is a whole different story anymore. I think folks can quite easily list out mesh paths if they want to add an armor to the ini file, especially now with the new system.

 

Personally, I would not sacrifice any more CPU load than what is absolutely necessary.

[movomo]

Sure, if this new system requires more system resource and kills backward compatiblity, it's not 'necessary' thing.

 

Although I partly agree with Uriel's suggestion (BreakUndies thread was full of questions about BU ini edits!), It shouldn't be a serious problem anymore. One thing made folks confused was that they should open the esp with CS or Tes4edit or whatever and figure out armor formids, now it's gone. hopefully, no special instruction needed on how to use explorer or notepad.

[ShiaNekoChan]

Part of the problem before was that there was no established Breakundies armor maker etiquette.

 

If I were going to make a breakundies armor then I'd include the formID in the readme (or maybe even the whole breakundies entry) so people wouldn't have to go through all the trouble to add it. x_x

 

Anyway, I think it could go either way. It's more user-friendly if it's without an ini all together and definitely doable, but at the same time, it's a lot easier for users now that they don't have to include a formID.

[gerra6]

Well...it's done.

 

I've taken a few steps in an attempt to minimize the performance hit, we'll see if it's enough.

 

The 1.09 experimental version performs an intentionally *very* simple check to determine whether or not BreakUndies or BreakArmor meshes are present. It appends numbers to the end of the file name. The moment it doesn't find a match, it stops. This is by design...the fewer checks it needs to perform, the better. For testing purposes, I used the current naming convention used in the BU stock replacer project.

 

This means that for BreakUndies and BreakArmor meshes to work without an ini file they need to follow a very specific pattern.

 

The first mesh should have no number.

 

meshname.nif

 

Each break mesh should appear as follows:

 

meshname1.nif

meshname2.nif

meshname3.nif

...

meshname99.nif

to whatever number of meshes are included in the package.

 

I've tested it out, and it appears to work. Please take a look and let me know what you guys think.

 

Now...I would *suggest* that we decide on a more distinctive naming convention for ini-less breakarmor meshes. Something a bit less likely to result in false positives...maybe meshname_ba1.nif or something like that. It doesn't really matter. I'd just like to avoid having the tool start swapping out someone's horns (or whatever) because they named them horn.nif, horn1.nif etc.

 

But in order to minimize the performance hit, I intend to only support a single naming convention once this is out of the experimental phase. So let's make it a good one.

 

Off to sleep.

[Uriel]

meshname_ba1.nif

Should be enough, imo. I doubt there's anything that will accidentally repeat this naming.

I'll run a "*_ba*.nif" search on my garbage collection to see if there are any matches.

 

It might be useful to have some kind of a test spell. My idea here is to run armor detection when player casts a test spell, but a little different detection: if "*_ba[n].nif" is not present, check for "*_ba[n+1].nif", and, if it is present, display a message about a missing "*_ba[n].nif". It'll help detecting misnamed .nif's.

[Nephenee13]

Honestly, I think the INI-less version is a terrible idea.

 

Seriously, why make gerra go through the hassle of coding a less efficient, more resource intensive, less flexible version when the existing one worked perfectly goddamn well to begin with?

[gregathit]

Honestly' date=' I think the INI-less version is a terrible idea.

 

Seriously, why make gerra go through the hassle of coding a less efficient, more resource intensive, less flexible version when the existing one worked perfectly goddamn well to begin with?

[/quote']

 

I agree. Not to mention introducing possible bugs and instability. But hey, I will just stick with version 1.08 myself so it doesn't matter much to me.

[Nephenee13]

Not to mention that even if multiple versions of the same INI file are distributed, Wrye Bash would be able to merge the automatically.

 

This is a solution searching for a problem.

 

Efficiency is good! Lets not make things less efficient!

[Uriel]

That was just my idea, i was not making someone do it.

I believe Gerra did that because i'm not the only one who think ini's are bad.

[gerra6]

The main reason I did it...it was an interesting idea that was easy to code. I was also curious to find out how big a performance hit it would actually cause. My instincts after the fiasco that was the pre 1.05 version of BA is to do everything I can to minimize CPU load, hence my resistance to the idea.

 

But the although BreakArmor is intended to run every frame (which is why the armor swaps are so fast), it is specifically designed to do an incredibly small amount of processing. In each frame it does only one of three things...process a Single NPC, Initiate a BreakArmor armor swap event, or finalize a BreakArmor armor swap event.

 

Of those, the only really resource intensive action is the first time equipped inventory check of a single NPC. Once that first time check is completed, subsequent checks of that same NPC use the information BreakArmor has already gathered about their equipment to minimize any performance hit (it just checks for new equipment or damage (or NPC Health/Fatigue for clothing) for BreakArmor compatible equipment)

 

So, the hit is entirely contained in the first time check. On my tests on my modding box, it's not really noticeable. But...and this is a big but...I 1.00 to 1.02 performed great on that box too.

 

Allright. I should also add, the 1.09 version still checks for and processes external ini files. The difference is that, in addition to checking for external ini files it also checks for breakarmor filenames. We're not losing any backwards compatibility with this, just making it potentially easier to add new armors to BreakArmor.

 

The really nice thing about this is that different modders from different sites can all create armors for BreakArmor 1.09 with no coordination required from anyone (unlike ini file management which requires a certain amount of cooperation)...all a user would have to do is drop their meshes in the correct folders.

 

So please let me know how well it works for everyone and we'll decide whether or not this particular experiment should continue. Me, after coding it and testing it out, I kind of like it. But that might just be protectiveness towards code I've written.

[Nephenee13]

i'm not the only one who think ini's are bad.

 

Well, this is a silly opinion to have.

[gerra6]

i'm not the only one who think ini's are bad.

 

Well' date=' this is a silly opinion to have.

[/quote']

 

I really like ini files for storing user-customizeable settings. Just take a look at the absurdity that is the ini file system I created for the Autosetbody Reloaded project.

 

However, In the case of BreakUndies/BreakArmor, there is one thing I really don't like. Since the ini files need to contain all of the mesh paths for all of the breakable armors, and any modder can create breakable meshes, an end-user who downloads breakarmor and then starts grabbing BreakArmor/BreakUndies meshes from different places will need to manually merge the different ini files.

 

That's a headache that, the more I think about it, I would like to avoid, if it can be done without negatively impacting performance.

[Uriel]

Efficiency is good! Lets not make things less efficient!

Effeciency? Is it efficient to write update and track the file, when it can be done by a script?

Well' date=' this is a silly opinion to have.[/quote']

I don't mean all the ini's. I mean this case. And i explained why.

[gerra6]

Efficiency is good! Lets not make things less efficient!

Effeciency? Is it efficient to write update and track the file' date=' when it can be done by a script?

Well, this is a silly opinion to have.

I don't mean all the ini's. I mean this case. And i explained why.

 

The question ultimately comes down to how well does 1.09 run when compared with 1.08.

 

If the performance, in real world use, is just as good as 1.08, then I'll release a 1.10 version that will support meshes that were either loaded via ini files or discovered via the meshname_ba#.nif naming convention. Because greater flexibility is usually a good thing.

 

If the 1.09 performance is degraded compared to 1.08, then the 1.10 release won't include that feature.

 

So folks, rather than argue this in theory, if you're willing to test this out, please do.

 

And let me know how well the 1.09 experimental release performs.

 

Thanks a ton.

 

In the meantime, I am off to finish the Beta version of my automated BB weightpainting script. Look for a release in the Modders Resources thread sometime later today.