Addon Builder Binarize can't find penetration material -> p3d has wrong fire geometry

[x3kj 1247]

As the title say, i'm trying to binarize a tank model.

I get a bunch of these in the log file

Cannot load material file a3\data_f\penetration\armour_plate_23mm.rvmat.
Cannot load material file a3\data_f\penetration\armour_plate_23mm.rvmat
Cannot load material file a3\data_f\penetration\armour_plate_16mm.rvmat.
Cannot load material file a3\data_f\penetration\armour_plate_16mm.rvmat
Cannot load material file a3\data_f\penetration\armour.rvmat.
Cannot load material file a3\data_f\penetration\armour.rvmat
Cannot load material file a3\data_f\penetration\armour_plate_30mm.rvmat.

Ingame if i shoot the model, it emits dirt particles and no shot can penetrate no matter the thickness

If i dont binarize, everything works as expected.

How can i solve this? My addon is in "d:\armamodding\_k40\sourceaddon", is it possible to place the "a3\data_f\penetration\" folder with the unbinarized .rvmat and .bisurf somewhere so AB can find them? I tried putting it in "d:\armamodding\_k40\" but no luck.

[das attorney 858]

It's been a while since I've played about with binarising, but I always had errors with project files outside the P: drive.

[EricJ 759]

Unfortunately the Addon Builder is NOT what anybody would consider reliable. Prior to the patch it was really jacked up and right now alternative means may be a good option:

http://dev.withsix.com/projects/mikero-pbodll/files?sort=created_on%3Adesc%2Cfilename

[.kju 3244]

do you have a correct p drive setup?

[x3kj 1247]

No i dont have a p drive

[.kju 3244]

so how should binarize be able to merge the rvmat into the p3d?

[teacup 2]

Nevermind, I'm talking out of my ass, just checked.

Edited July 16, 2014 by teaCup

[x3kj 1247]

;2731494']so how should binarize be able to merge the rvmat into the p3d?

i was told the toolset works fine without the P drive hack.

How does binarize work in that regard, why does it want to merge a penetration surface material files into the model? I mean, what happens if i change or overwrite materials in "a3\data_f\penetration\" with another addon? If it is merged into the binarized addon, wouldnt that break the dependency? What's the point in using a common material if that is the case? It doesnt make sense to me.

Edited July 16, 2014 by Fennek

[teacup 2]

I binarized my Su-22 addon without a P drive, and penetration materials seem to be working fine: when i shoot the plane surface, i get sparks and not dirt effects, I get metallic sounds, one thing haven't checked is if they let different caliber rounds through or not (like HMG, 30 mm canon rounds, SABOT).

I experienced things similar to what you're describing on the An-2 port I'm attempting. I think it has to do with specific materials, the "armour_plate_XXmm" ones.

One difference that I found between unbinarized and binarized models, is that the latter have references to the BISURF files in them. So it seems binarization does "bake" some of the RVMAT into the model.

[.kju 3244]

by default binarize drops the rvmat as the info is merged into the p3d

exceptions are config referenced rvmat like wounds, damage texture or rvmat from wrps

now if the rvmat is still part of the data arma loads, it might still be able to fall back on that - when the rvmat is not present, you will have issues

however the p3d is not as optimized as it could/should be

as for the exact technical details best refer to mikero/T_D or BI

[x3kj 1247]

I binarized my Su-22 addon without a P drive, and penetration materials seem to be working fine: when i shoot the plane surface, i get sparks and not dirt effects, I get metallic sounds, one thing haven't checked is if they let different caliber rounds through or not (like HMG, 30 mm canon rounds, SABOT).

I experienced things similar to what you're describing on the An-2 port I'm attempting. I think it has to do with specific materials, the "armour_plate_XXmm" ones.

One difference that I found between unbinarized and binarized models, is that the latter have references to the BISURF files in them. So it seems binarization does "bake" some of the RVMAT into the model.

Yes exactly that, if i use armour.rvmat, all is well. If i use any of the materials i get dirt...

If it does pack the rvmat into the model, i could as well just make my own material there ...

Edited July 16, 2014 by Fennek

[mikero 79]

1st things first. As most people will tell you, you are more or less wasting a lot of your creative energy trying to belt addon builder into shape. Use pboProject. If you prefer not to, that's your choice. Some people enjoy self flagellation too.

2) rvmats and bisurfs are baked into the binarised p3d. External ones don't have to be supplied in the pbo. They are ignored except as noted by kju above, and at best merely cause confusion to the engine. pboProject includes binarised rvmat/bisurf source in the pbo, automatically. not because it's used, but just-in-case bis move the goalposts.

3) You need a Pdrive. There's no way round it, over it, or under it. You have a snowball in hell's chance of ever adding 'foreign' files such as a3\any\thing until you create the environment for them to be found and included. A Pdrive is not necessarily 'P:\' nor does it have to be a 'drive:\' at all. What is mandatory however is that all file references sing from the same song sheet. All file references to any\thing must start life from a common path. PboProject makes this easy for you by referring to this as the <workspace>. Most people simply make that <workspace> 'p:\' because it's so much easier to 'understand' where the engine is getting all it's files from.

Basically, you cannot have your files in d:\my\great\addon and use arma files from c:\my documents.They all must sing from the same starting place.

The problem with addon builder and with it's underlying bis binarise, is they ignore many glaring errors and produce a pbo regardless with no message indicating it's faulty. This misleads you to assumed all is'ok'. So you go off chasing your tail looking for errors in anything but the pbo itself.

I think a lot of your misunderstandings about what's going bang will clear up once you understand the need for a common path to every\thing.

Edited July 16, 2014 by Mikero

[EricJ 759]

Actually Addon Builder simply does not work, and when it did work, it gave you an "error=1", forcing me to use PBO Viewer to root out the error, so it didn't for me give me the "A okay" sign" and find out there were more errors, apart for config bin entry errors.

What would be nice Mikero, if PBO Project is better, is to give a good comprehensive install guide for your PBO project since it seems a bit more problematic installing bits and parts when it could probably be best deployed as a full executable. Than rather than having to find X.exe and Y.exe to make Z.exe, in which Addon Builder has an advantage, and also not have to delve into the depths of the Marinara Trench in order to find your program. But even since A3 is all fucked up anyway it's just a moot point since it seems the game doesn't recognize the model.cfg when baked, so it's probably a moot point.

[m1lkm8n 410]

If I remember correctly I think the reason he doesn't have everything as an all in one is because he was against people needing to download large files they don't need to.

But as far as the model cfg not baking thing what exactly do you mean?

I have tons of models I binarized using pboproject and all my animations work fine. I would assume if they were not working my models would have no animations.

[EricJ 759]

I see but given most file sizes of mods I don't see how that could choke bandwidth, but that's his choice regardless.

Anyhoo, It's Addon Builder not so much PBO Project not transferring the animations to the game, or not enabling them where things like iron sights don't flip down when you mount a scope, and magazines still appear when not loaded, the basic stuff. But stuff like muzzle flash works as it should, etc. And since PBO Project depends on so many files without a proper readme even I'm not going to waste any more time on the game until it's fixed, so thanks anyway.

[.kju 3244]

Did you read the readme supplied by PboProject?

[mikero 79]

;2733407']Did you read the readme supplied by PboProject?

Obviously NOT!!!!