Jump to content
Sign in to follow this  
USSRsniper

Destruct textures

Recommended Posts

I can't make destruct textures to appear on model.

Even changedd paths so its without caps, which some people suggest that it will make difference.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

dammageHalf[] = {"\ca\wheeled\data\hmmwv_glass_CA.paa","\ca\wheeled\data\hmmwv_glassbr1_CA.paa","\ca\wheeled\data\hmmwv_glass_CA.paa","\ca\wheeled\data\hmmwv_glassbr1_CA.paa"};

dammageFull[] = {"\ca\wheeled\data\hmmwv_glass_CA.paa","\ca\wheeled\data\hmmwv_glassbr2_CA.paa","\ca\wheeled\data\hmmwv_glass_CA.paa","\ca\wheeled\data\hmmwv_glassbr2_CA.paa"};

class Damage {

tex[] = {};

mat[] = {"ca\wheeled\data\hmmwv_regular_1.rvmat", "ca\wheeled\data\hmmwv_regular_1.rvmat", "ca\wheeled\data\hmmwv_regular_1_destruct.rvmat", "ca\wheeled\data\hmmwv_hood.rvmat", "ca\wheeled\data\hmmwv_hood.rvmat", "ca\wheeled\data\hmmwv_hood_destruct.rvmat", "ca\wheeled\data\hmmwv_details.rvmat", "ca\wheeled\data\hmmwv_details.rvmat", "ca\wheeled\data\hmmwv_details_destruct.rvmat", "ca\wheeled\data\hmmwv_body.rvmat", "ca\wheeled\data\hmmwv_body.rvmat", "ca\wheeled\data\hmmwv_body_destruct.rvmat", "ca\wheeled\data\hmmwv_regular.rvmat", "ca\wheeled\data\hmmwv_regular.rvmat", "ca\wheeled\data\hmmwv_regular_destruct.rvmat", "ca\wheeled\data\hmmwv_clocks.rvmat", "ca\wheeled\data\hmmwv_clocks.rvmat", "ca\wheeled\data\hmmwv_clocks_destruct.rvmat"};

Here is part of config with damage textures, but i think everything correct and it should work.  If i posted this in wrong section sorry, because i have no idea if its config related or model related.....

Share this post


Link to post
Share on other sites

Used to be able to do the same with old OFP models converted to ArmA ..... but since stopped working.

I suspect its either the 1.08 update or using the new O2 that caused the coding to stop working.

Check my Piper Warrior for how ArmA works now.

Every texture needs a .rvmat, _destruct.rvmat, _co.paa, _nohq.paa and a _smdi.paa

See more details here;

http://www.flashpoint1985.com/cgi-bin....21;st=0

Share this post


Link to post
Share on other sites
Gnat @ Oct. 22 2007,14:21)]Used to be able to do the same with old OFP models converted to ArmA ..... but since stopped working.

I suspect its either the 1.08 update or using the new O2 that caused the coding to stop working.

Check my Piper Warrior for how ArmA works now.

Every texture needs a .rvmat, _destruct.rvmat, _co.paa, _nohq.paa and a _smdi.paa

See more details here;

http://www.flashpoint1985.com/cgi-bin....21;st=0

Thx i think i found whats was the problem, what you said about .rvmat helped me. But how do i get glass breaking effect on windows? is this damagefull and damage half stuff in config? Or i need to add something else to make it work? Because i looked over your config on piper warrior and see nothing related to glass braking...

Share this post


Link to post
Share on other sites

Here is one weird things that i encountered today. When i binirize model with BINPBO, everything binirizes good, config files, .rvmat's, but all destruct .rvmat's don't appear in actual final version of .pbo. And there is absolutely no errors in log about those .rvmat's, nothing.

Share this post


Link to post
Share on other sites

NOTE:

I had to manually add those "missing" files to the BINPBO Temp directory so that they would be included in the final binized PBO

This suggests we are doing something wrong ...... or BIS stuffed up BINPBO ..... take your pick, but either way the Piper Warrior is binized and the damage textures work.

edit: typos

Share this post


Link to post
Share on other sites
Quote[/b] ]When i binirize model with BINPBO, everything binirizes good, config files, .rvmat's, but all destruct .rvmat's don't appear in actual final version of .pbo. And there is absolutely no errors in log about those .rvmat's, nothing.

the same thing with damage textures (like windows) and with pther texctures that re not in the model. Seems to be BIs error to me

Share this post


Link to post
Share on other sites

can i just confirm what you are all saying please.

are you saying that if you have a folder that you are going to binarize into a .pbo, which includes a model, .cpp, main textures and main materials and perhaps also destructed materials, and other references to destructed materials is in the .cpp.

in your case are your referenced destruct materials pathnames pointing to rvmat's inside the addon folder or outside of the addon folder?

if your destruct materials are pointing to rvmat's that 'live' somewhere else within your mod or the standard BIS addons - then why would you expect them to be pulled into your addon and squashed along with the rest of your content?

in the case where your destruct materials referenced in your cpp and/or model are pointing to rvmat's that are inside your working addon folder - are you saying they are not getting added when you 'squash' the folder?

Share this post


Link to post
Share on other sites
in the case where your destruct materials referenced in your cpp and/or model are pointing to rvmat's that are inside your working addon folder - are you saying they are not getting added when you 'squash' the folder?

exactly. destruct rvmats are referenced in cpp, but not included by binarizer automatically

Share this post


Link to post
Share on other sites

As Synide has already said, if the referenced rvmats are outside of the actual PBO, lets say part of ArmA already like this example taken from above:

"ca\wheeled\data\hmmwv_regular_1.rvmat"

These will not be packed in your PBO as they are already present in ArmA.

If they are your own rvmats inside your own addon and the path reference in your cpp is correct then all things being equal (even though not much is in this world) they should be packed along with everything else.

Planck

Share this post


Link to post
Share on other sites
Quote[/b] ]If they are your own rvmats inside your own addon and the path reference in your cpp is correct then all things being equal (even though not much is in this world) they should be packed along with everything else.

read my message wink_o.gif they are custom into pbo folder, but they don't packed during binarize

Share this post


Link to post
Share on other sites

i'll test tonight to see if i get the same result... but, another quick question... are your rvmat's that are inside your folder structure (and as such should get 'squashed' as well...) and referenced by your .cpp in rapified format or as text format?

edit: indeed... agreed, there seems to be a definite problem with BinPBO adding either rapified or un-rapified rvmats... sorry, it's not that i didn't believe you or anything... just like to see 'problems' first hand... cheers for the heads up on the 'trap for unwary'...

Share this post


Link to post
Share on other sites

In the options for BinPbo there is field called "List All Files To Copy Directly". *.rvmat is not included in the wildcards by default.

Could that be the problem?

Share this post


Link to post
Share on other sites

possibly, could be as simple as that... but what if you want them rapified....

Share this post


Link to post
Share on other sites
Quote[/b] ] but what if you want them rapified

I dunno, perhaps if you performed a little jig as well?...Surely it can't harm, if you make it energetic and put your heart into it!

It may or may not work, but it’s one more thing to try?

Share this post


Link to post
Share on other sites
In the options for BinPbo there is field called "List All Files To Copy Directly". *.rvmat is not included in the wildcards by default.

Could that be the problem?

That has been the issue for me thus far with the work on my weapons pack. BinPBO wasn't converting any RVMAT files until I added *.rvmat to the list of copied file formats, then everything was copied over perfectly and worked fine. Adding *.rvmat to the "list of files to copy directly" in BinPBO's "options" page, should work fine.

Share this post


Link to post
Share on other sites
That has been the issue for me thus far with the work on my weapons pack. BinPBO wasn't converting any RVMAT files until I added *.rvmat to the list of copied file formats, then everything was copied over perfectly and worked fine. Adding *.rvmat to the "list of files to copy directly" in BinPBO's "options" page, should work fine.

ok, i've had to do a bit more around this area myself the last week so this is what i have found... probably already some of you know this anyway... but, for those that don't...

There a 2 (two) methods by which materials work on models...

a. by specifying all relevant information for 'CfgTextureToMaterial' and 'CfgMaterials' in a config.cpp - this is the old/transition method.

 OR

b. by pointing faces in your model (using O2PE only) to not only the main texture for that face but also a .rvmat material file.

currently, method (b) will not work unless you do not binarize your model. if you choose to leave your model as a P3DM you can successfully utilize the new ArmA method.

if you want to binarize your model (to make it smaller for one thing...) currently i believe you cannot use method (b) and here's why...

1. when Binarize comes across a .rvmat reference in your lovelly P3DM mlod model it currently cannot include this rvmat in the binarized version it tries to produce.

(this is of course written in the readme... which i failed to read for a very long time... lol)

so, if you utilize the new method and want to binarize your models then the materials won't work...

Solutions

1. release your model as p3dm and you can use the new method.

2. if you want to binarize...

while working on your model and using Buldozer you can of course make use of the new method...

but when you go to produce your pbo (for use in game) you should remove all reference to .rvmat's in your model.

you should copy and paste all the information from your working rvmat files into a config.cpp and utilize the old/transition method of making CfgTextureToMaterial and CfgMaterials classes.

now when you produce your pbo using BinPBO the model will be binarized and it will read the material information from the config.cpp and include this in the model.p3d.

you do not need the rvmat files to be included in the pbo.

warning: if you specify the materials in a config.cpp AND still have references to the rvmat's on faces in the model you will probably find your materials will not work in game. they do in Buldozer but not in game...

This will, become irrelevant when BIS fix the Binarize.exe tool to correctly process rvmat's.

the issue detailed above is not entirely accurate with respect to damage textures... and is slightly off topic of this thread...

for an account of the issue detailed above interested parties should see the following thread Materials & BinPBO/Binarize... and disregard the above in respect of damage textures...

Share this post


Link to post
Share on other sites

Synide

can't get what yuor post is about sad_o.gif

Method a) is wierd, it was smth horrible temporary solution.

If you define rvmats in the model andd then specify destruct effects in the confgis correctly - it does work. always. with binarized and non-binarized models (just beware binarizer can miss your destuct rvmats - add them manually if so wink_o.gif). I tried it quite long ago - it's working.

I always used

Share this post


Link to post
Share on other sites
Synide

can't get what yuor post is about sad_o.gif

Method a) is wierd, it was smth horrible temporary solution.

If you define rvmats in the model andd then specify destruct effects in the confgis correctly - it does work. always. with binarized and non-binarized models (just beware binarizer can miss your destuct rvmats - add them manually if so wink_o.gif). I tried it quite long ago - it's working.

I always used

Binarize cannot process rvmat's at this time... this is not a disputable point. i know what a materials section inside a odolv40.p3d looks like and the binarize tool fails to produce this when you have rvmat material files specified through the O2PE Face Properties dialog.

i started another thread about this here if you are interested.

Share this post


Link to post
Share on other sites

? ? ? ? .....

1) I am using method (b)

2) I have BinPBO'ed my Piper Warrior

3) The Damage Textures work ingame!

Share this post


Link to post
Share on other sites
Gnat @ Nov. 24 2007,16:14)]? ? ? ? .....

1) I am using method (b)

2) I have BinPBO'ed my Piper Warrior

3) The Damage Textures work ingame!

sorry, to clarify, yes... destruct/damage materials work.

which is the subject of this thread.

as there is only one way to specify desturct materials and that's through the .cpp.

i was referring to something that was related (sort of)... and that's why i started another thread on that subject here... Materials & BinPBO/Binarize...

so as not to confuse this thread...

PS. if you'd been producing a odol'd model in you pbo although you're damage textures would have been working, you're main material would not have been. (the one referenced on the Face Properties in O2PE)

Share this post


Link to post
Share on other sites
Quote[/b] ]PS. if you'd been producing a odol'd model in you pbo although you're damage textures would have been working, you're main material would not have been. (the one referenced on the Face Properties in O2PE)

...

as there is only one way to specify desturct materials and that's through the .cpp.

i can't get it too... I got model with main and damage materials working no matter if model is binarized or not. And damage materials are defined in cpp - there's noother way. just can't see what trouble you are discussing.

Share this post


Link to post
Share on other sites

I'm suspicious that once you open and save a model in the new O2 it can never go back to the old method ..... I still have one addon (Ka-26) where the (a) method still works, but a newer model refuses to work the exact same way.

Share this post


Link to post
Share on other sites

you are wrong... ok, let's say probably biggrin_o.gif I just wasted too lot of time on this engine to be wrong

actually method a) is very old and wierd way that was used only because of tool absence

Share this post


Link to post
Share on other sites
you are wrong

lol ... always amazes me how so many people (non BIS employees) in this forum are SO SURE about how the infinitely complex ArmA engine does and doesn't work when there can be <span style='font-size:11pt;line-height:100%'>100's</span> of variables (known and unknown) at play in each and every aspect of addon making.

But hey, you're probably right.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×