Jump to content

Break Undies armors.

Nightwynd

By Nightwynd,
in Oblivion Adult Mods

Recommended Posts

rad87

rad87

Posted
Posted

 

In-game enchant I mean. Nah' date=' this IS a problem for me because I want to make BreakUndies work for vanilla armors. People WILL enchant vanilla armors but if it doesn't break anymore after enchanting what's good of vanilla BU??

 

Besides, it should work according to the readme.txt.

 

また、BreakUndies装備にエンチャントを付与した場合にも引き続き動作する

ようになりました。

Moreover, it came to operate continuously when enchant was given to the BreakUndies equipment.

 

As it says loudly and clearly.

 

Thats probably google translated. You can't trust google translate to preserve meaning when translating from an exotic language. That might even mean that the script breaks and start to loop when the armor is getting an enchant

Link to comment

DeadSomething

DeadSomething

Posted
Posted

 

In-game enchant I mean. Nah' date=' this IS a problem for me because I want to make BreakUndies work for vanilla armors. People WILL enchant vanilla armors but if it doesn't break anymore after enchanting what's good of vanilla BU??

 

Besides, it should work according to the readme.txt.

 

また、BreakUndies装備にエンチャントを付与した場合にも引き続き動作する

ようになりました。

Moreover, it came to operate continuously when enchant was given to the BreakUndies equipment.

 

As it says loudly and clearly.

 

Thats probably google translated. You can't trust google translate to preserve meaning when translating from an exotic language. That might even mean that the script breaks and start to loop when the armor is getting an enchant

 

definitely my thought on that line.

 

but if enchanting breaks the BU scripts, there's either no point in enchanting anymore, or no point in vanilla BU for anyone who wants to enchant. so there has to be a way to fix that bug.

maybe there's a way to change the scripts to not refer to the formID, but to where the mesh was loaded from.

that way it would also work for any new armors automatically and for all form-IDs which use the armor-mesh. - that could make ti work even for bodymeshes :D

Link to comment
movomo

movomo

Posted
Posted

 

 

 

In-game enchant I mean. Nah' date=' this IS a problem for me because I want to make BreakUndies work for vanilla armors. People WILL enchant vanilla armors but if it doesn't break anymore after enchanting what's good of vanilla BU??

 

Besides, it should work according to the readme.txt.

 

また、BreakUndies装備にエンチャントを付与した場合にも引き続き動作する

ようになりました。

Moreover, it came to operate continuously when enchant was given to the BreakUndies equipment.

 

As it says loudly and clearly.

 

 

 

Thats probably google translated. You can't trust google translate to preserve meaning when translating from an exotic language. That might even mean that the script breaks and start to loop when the armor is getting an enchant

 

Well, I suspect too that google translater was used for English readme. But actually, Japanese is easier than English for me :cool: It reads clearly,

 

Now BreakUndies also works on enchanted equipments.

by my translation.

 

It isn't mentioning whether enchanted equipments means CS enchantment or in-game enchantment.

Hmm..........is this the author's trap card??

Link to comment
gregathit

gregathit

Posted
Posted

The google machine translation of that line is:

 

"Also, I will continue to work even if you grant the enchanted equipment BreakUndies Is now."

 

Which means jack shit to me. Context is harder than fucking hell to gather, as Japanese moves word order all over the place. However, logic does tell us that any enchantment given 'in-game' changes the formid and that alone will cause BU to stop working as it can't find the armor anymore. Perhaps something can be done in the scripts that can't be done via the ini.

 

Long story short, warn folks to not enchant the armor 'in game', as it will cause the armors to stop breaking. Now if you add enchantments via the CS, then no problem. An alternative might be to add one enchanted set for each armor (keep it from being too OP but powerful enough to keep folks happy).

Link to comment
movomo

movomo

Posted
Posted

The google machine translation of that line is:

 

"Also' date=' I will continue to work even if you grant the enchanted equipment BreakUndies Is now."

 

Which means jack shit to me. Context is harder than fucking hell to gather, as Japanese moves word order all over the place. However, logic does tell us that any enchantment given 'in-game' changes the formid and that alone will cause BU to stop working as it can't find the armor anymore. Perhaps something can be done in the scripts that can't be done via the ini.

 

Long story short, warn folks to not enchant the armor 'in game', as it will cause the armors to stop breaking. Now if you add enchantments via the CS, then no problem. An alternative might be to add one enchanted set for each armor (keep it from being too OP but powerful enough to keep folks happy).

[/quote']

 

Darn, then I'll do a jury rig. I'll add some no slot items to make folks can enchant their equipments. Also will atach script to them to keep them from being overpowered by equipping infinite enchanted items.

Link to comment
rad87

rad87

Posted
Posted

The google machine translation of that line is:

 

"Also' date=' I will continue to work even if you grant the enchanted equipment BreakUndies Is now."

 

Which means jack shit to me. Context is harder than fucking hell to gather, as Japanese moves word order all over the place. However, logic does tell us that any enchantment given 'in-game' changes the formid and that alone will cause BU to stop working as it can't find the armor anymore. Perhaps something can be done in the scripts that can't be done via the ini.

 

Long story short, warn folks to not enchant the armor 'in game', as it will cause the armors to stop breaking. Now if you add enchantments via the CS, then no problem. An alternative might be to add one enchanted set for each armor (keep it from being too OP but powerful enough to keep folks happy).

[/quote']

 

Wouldn't it be possible to catch the enchantment before it assigns a new ID to the armor, get to know the new ID and coppy the BU data from the old one to the new one?

Link to comment
gerra6

gerra6

Posted
Posted

Wouldn't it be possible to catch the enchantment before it assigns a new ID to the armor' date=' get to know the new ID and coppy the BU data from the old one to the new one?

[/quote']

 

That would be a major pain to code.

 

The first big problem is that enchantment doesn't actually change the item, it makes a copy of it. So you can't merely watch for something to change it.

 

But let's say that you found a way to catch whenever any items with the appropriate editor ids were copied and managed to build a big ugly array that links the original editor id to the copy, you'd still have a problem the moment the script swapped the armor models.

 

The second the script swapped models, you'd lose all of your enchantments. (note, I'm making the assumption that the BU script swaps clothing items rather than model paths)

 

Now, it may be possible to rebuild the entire BU framework from scratch to swap model paths for items rather than swap the items themselves. Of course, you'd probably then need to do some fancy trickery to get Oblivion to re-render the clothing item with the new path (ordinarily this is done when a scene loads).

 

Could it be done? Dunno. Want to code it?

Link to comment
rad87

rad87

Posted
Posted

Wouldn't it be possible to catch the enchantment before it assigns a new ID to the armor' date=' get to know the new ID and coppy the BU data from the old one to the new one?

[/quote']

 

That would be a major pain to code.

 

The first big problem is that enchantment doesn't actually change the item, it makes a copy of it. So you can't merely watch for something to change it.

 

But let's say that you found a way to catch whenever any items with the appropriate editor ids were copied and managed to build a big ugly array that links the original editor id to the copy, you'd still have a problem the moment the script swapped the armor models.

 

The second the script swapped models, you'd lose all of your enchantments. (note, I'm making the assumption that the BU script swaps clothing items rather than model paths)

 

Now, it may be possible to rebuild the entire BU framework from scratch to swap model paths for items rather than swap the items themselves. Of course, you'd probably then need to do some fancy trickery to get Oblivion to re-render the clothing item with the new path (ordinarily this is done when a scene loads).

 

Could it be done? Dunno. Want to code it?

 

Well it actually change the model paths. and to re-render it it de-equips it and re-equip it. at least thats what it looks like in the game

Link to comment
movomo

movomo

Posted
Posted

Could it be done?

 

By Ysmir's beard, no one knows. I'm making a crude workaround for this enchantment issue. If someone cleverer than me kindly code for us we'd be happy a lot, but for now I'll use no slot item.

 

I made 2 no slot item (one for cuirass, the other for greaves) and attached script to prevent from duplicated equipping.

Link to comment
gerra6

gerra6

Posted
Posted

Well it actually change the model paths. and to re-render it it de-equips it and re-equip it. at least thats what it looks like in the game

 

I just peeked at the ini file and it looks like it's building a big array of model paths. So it looks like you're right. I'm a bit surprised that it wouldn't change the models for all armors of that type in the game.

 

Unless I miss my guess, I'd bet that the BU framework already replaces the base item with a BU item. If so, that reduces the problem down to the original issue: How would you be able to detect any and all enchantment events?

 

I'm sure it could be done. Hell, there might even be a simple API call (or whatever the CS calls it) that you could use to keep track of those events. On the other hand, it could be a hideously complex bucket of agony.

Link to comment
gregathit

gregathit

Posted
Posted

Yes, it does use model paths but ONLY because it is referenced by the armors formID number, so you are right back to needing to figure out a way around the formID problem. If the formID isn't by-passed some way then the model paths are invalidated with any formID change.

 

Excerpt from BU.ini example I have in the bottom spoiler of the 1st post to clarify\illustrate:

 

 

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b1.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b2.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b3.nif"

SetStage aaBUDataIni 10

set aaBUData.ID to GetFormFromMod "R18PN - Lingeries.esp" "00C929"

SetStage aaBUDataIni 30

 

As you can see the green are the folders with the path leading to the actual .nif file (in this case Lowbody1.nif being the first armor that the form ID is based on) and then lists the other three .nif files that are to be used by this armor as it breaks. In this case with there being 4 armor parts then you will have a 25% break between stages. In other words stages one of the break (when the armor will update to the second listed .nif file) will occur when the armor has taken about 75% damage. If there are more stages or less then this number moves about accordingly. The red is the name of the esp file that contains the base armor that is listed in line one (Lowbody1.nif) and that you looked up the form ID for. The yellow is the last 6 digits of the form ID you looked up earlier. NOTE: DO NOT include the first 2 digits and the reason why is that will change as the mod is moved up or down in your load order. The first two digits are always a function of load order. Since you have the mods esp name in the BU ini you don't need the load order info as it already knows where to look. :D

C. Save your modified BreakUndies.ini and exit notepad and you are ready to fire up oblivion and test out your new armor!

 

 

It is the yellow item that is throwing a monkey wrench in the works. Perhaps one of you guys can think of a way around this but I sure as hell can't figure anything out unless you can 'block' the enchantment from changing the formID somehow.......:(

Link to comment
gerra6

gerra6

Posted
Posted

Yes' date=' it does use model paths but ONLY because it is referenced by the armors formID number, so you are right back to needing to figure out a way around the formID problem. If the formID isn't by-passed some way then the model paths are invalidated with any formID change.

 

Excerpt from BU.ini example I have in the bottom spoiler of the 1st post to clarify\illustrate:

 

 

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b1.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b2.nif"

SetStage aaBUDataIni 10

set aaBUData.DATA to sv_Construct "R18PN\Lingerie\GarterBelt\1\Lowbody1b3.nif"

SetStage aaBUDataIni 10

set aaBUData.ID to GetFormFromMod "R18PN - Lingeries.esp" "00C929"

SetStage aaBUDataIni 30

 

As you can see the green are the folders with the path leading to the actual .nif file (in this case Lowbody1.nif being the first armor that the form ID is based on) and then lists the other three .nif files that are to be used by this armor as it breaks. In this case with there being 4 armor parts then you will have a 25% break between stages. In other words stages one of the break (when the armor will update to the second listed .nif file) will occur when the armor has taken about 75% damage. If there are more stages or less then this number moves about accordingly. The red is the name of the esp file that contains the base armor that is listed in line one (Lowbody1.nif) and that you looked up the form ID for. The yellow is the last 6 digits of the form ID you looked up earlier. NOTE: DO NOT include the first 2 digits and the reason why is that will change as the mod is moved up or down in your load order. The first two digits are always a function of load order. Since you have the mods esp name in the BU ini you don't need the load order info as it already knows where to look. :D

C. Save your modified BreakUndies.ini and exit notepad and you are ready to fire up oblivion and test out your new armor!

 

 

It is the yellow item that is throwing a monkey wrench in the works. Perhaps one of you guys can think of a way around this but I sure as hell can't figure anything out unless you can 'block' the enchantment from changing the formID somehow.......:(

 

Sure, but it appears to be swapping out models on a single item, rather than replacing one item with another.

 

If that's the case (and I haven't looked) then there is still a formID problem, but it is much more straightforward.

 

If I were writing the plugin, here's what I would try.

 

First...and this is the big problem that I don't know the solution to, write a gamemode script that captures the pre and post editor ID for any enchant item events.

Second...hijack the pre-existing BU array (I assume it's a generated array). Do a lookup using the old editor ID. If the ID is found, grab the model paths. Next, add a new entry that combines the new editor ID and the model paths.

 

The second part is nice and straightforward. The first...ugh. No clue.

 

*edit*

 

OK, this function call could probably do the trick. http://cs.elderscrolls.com/index.php/GetLastEnchantedItem if it is combined with some sort of inventory checker.

 

Then there is the OnEnchant call, IsClonedForm function

 

And of course, some sort of persistent quest variable array would be needed to store the item ID pairs.

 

fun

Link to comment
rad87

rad87

Posted
Posted

Well it actually change the model paths. and to re-render it it de-equips it and re-equip it. at least thats what it looks like in the game

 

I just peeked at the ini file and it looks like it's building a big array of model paths. So it looks like you're right. I'm a bit surprised that it wouldn't change the models for all armors of that type in the game.

 

Unless I miss my guess' date=' I'd bet that the BU framework already replaces the base item with a BU item. If so, that reduces the problem down to the original issue: How would you be able to detect any and all enchantment events?

 

I'm sure it could be done. Hell, there might even be a simple API call (or whatever the CS calls it) that you could use to keep track of those events. On the other hand, it could be a hideously complex bucket of agony.

[/quote']

 

well i'm thinking about overriding the original enchanting script and adding BU friendliness

 

*edit* quick look at oblivion.esm and all I could find was EnchantingStationScript 

Begin OnActivate

if isActionRef player == 1
	showEnchantment
endif

End

doesn't seem like much help. now I can only think of making a list of player inventory prior to showEnchantment, making the one after that, comparing both and if they are different checking if it was BU item that was enchanted and if so coppying bu stuff from the old one to the new one

Link to comment
gerra6

gerra6

Posted
Posted

 

End[/code] doesn't seem like much help. now I can only think of making a list of player inventory prior to showEnchantment' date=' making the one after that, comparing both and if they are different checking if it was BU item that was enchanted and if so coppying bu stuff from the old one to the new one

[/quote']

 

The truth is, you probably don't want to modify any of the Oblivion.esm scripts anyways. Too much room for conflicts with other mods.

 

It's always best to make a mod as self-contained as possible. The three functions available in OBSE (see my last post) combined with a gamemode script and an inventory checker should be able to get you the pre and post formid's of any items as they are enchanted.

 

http://obse.silverlock.org/obse_command_doc.html

 

The way I'd probably do it is to create a persistent quest variable (ideally an array) so it will be stored in the savegame file. Then, whenever the game is loaded, wait for the BU scripts to initialize and then add your dynamic entries to the BU core array (the one that is generated from the ini file entries).

Link to comment
rad87

rad87

Posted
Posted

 

End[/code] doesn't seem like much help. now I can only think of making a list of player inventory prior to showEnchantment' date=' making the one after that, comparing both and if they are different checking if it was BU item that was enchanted and if so coppying bu stuff from the old one to the new one

[/quote']

 

The truth is, you probably don't want to modify any of the Oblivion.esm scripts anyways. Too much room for conflicts with other mods.

 

It's always best to make a mod as self-contained as possible. The three functions available in OBSE (see my last post) combined with a gamemode script and an inventory checker should be able to get you the pre and post formid's of any items as they are enchanted.

 

http://obse.silverlock.org/obse_command_doc.html

 

The way I'd probably do it is to create a persistent quest variable (ideally an array) so it will be stored in the savegame file. Then, whenever the game is loaded, wait for the BU scripts to initialize and then add your dynamic entries to the BU core array (the one that is generated from the ini file entries).

 

or if there was a way to make BU completely mesh based that would be even better, for example no need to define multiple entries for the armors that share the same mesh

Link to comment
gerra6

gerra6

Posted
Posted

 

End[/code] doesn't seem like much help. now I can only think of making a list of player inventory prior to showEnchantment' date=' making the one after that, comparing both and if they are different checking if it was BU item that was enchanted and if so coppying bu stuff from the old one to the new one

[/quote']

 

The truth is, you probably don't want to modify any of the Oblivion.esm scripts anyways. Too much room for conflicts with other mods.

 

It's always best to make a mod as self-contained as possible. The three functions available in OBSE (see my last post) combined with a gamemode script and an inventory checker should be able to get you the pre and post formid's of any items as they are enchanted.

 

http://obse.silverlock.org/obse_command_doc.html

 

The way I'd probably do it is to create a persistent quest variable (ideally an array) so it will be stored in the savegame file. Then, whenever the game is loaded, wait for the BU scripts to initialize and then add your dynamic entries to the BU core array (the one that is generated from the ini file entries).

 

or if there was a way to make BU completely mesh based that would be even better, for example no need to define multiple entries for the armors that share the same mesh

 

Sure. Actually, that might be easier.

 

One way to do that is have a script that checks the inventory of every character whenever the cell is loaded, game is loaded, or if the inventory changes and determines if any of the equipment uses a BU compatible mesh.

 

I've never used it, but GetBipedModelPath might do the trick.

 

If it works, it would remove the need for hardcoded editor id's altogether. The script would still need to know the editor id's to function, but it could gather them dynamically from the local items.

 

*edit* I should mention that this method might entail a substantial overhead cost. It would be extremely important to find the most efficient approach to comparing string values in arrays within Oblivion.

Link to comment
rad87

rad87

Posted
Posted

I'm looking through BU Framework scripts to find a cause of the problem with armors with enchant after the game starts and I found something that looks strange to me in the aaBUCmnFncV2. There is an array called param. param[1] is used as a bit flag. In all places where it appears only bits 1 and 2 are used except the very end where bit 3 is zeroed. The rest of the script sets param[1]'s bits 1 or 2 to either 1 or 0 so zeroing bit 3 at the end seems really strange to me. Isn't this an error in the script?

 

*edit* don't mind that. bit 3 is actually set in the aaBUObjSC script

Link to comment
  • 2 weeks later...
gerra6

gerra6

Posted
Posted

The new Break Armor Framework 1.05a has been released.

 

This is an entirely mesh based replacement for the Break Undies system that allows break events to work for player enchanted items, dynamic items, stock items, or any mods at all.

 

As long as the mesh path matches with one of the entries in the Break_Armor.ini (or BreakUndies.ini, or BreakUndies_Stock.ini) it will automatically swap armor meshes as they are damaged, or clothing meshes as the NPC takes health and/or fatigue damage.

Link to comment
DeadSomething

DeadSomething

Posted
Posted

The new Break Armor Framework 1.05a has been released.

 

This is an entirely mesh based replacement for the Break Undies system that allows break events to work for player enchanted items' date=' dynamic items, stock items, or any mods at all.

 

As long as the mesh path matches with one of the entries in the Break_Armor.ini (or BreakUndies.ini, or BreakUndies_Stock.ini) it will automatically swap armors meshes as they are damaged, or clothing meshes as the NPC takes health and/or fatigue damage.

[/quote']

 

thanks :) i hope it works the same way as i thought.

it will definitely be an improvement :)

Link to comment
  • 5 weeks later...

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.

View Community Rules

Help Support LoversLab

×
×
  • 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