RVMat shows in bulldozer but not in game

[eagledude4 3]

EDIT: When I use binpbo to binarize my addons, the rvmats (contained in a separate non-binarized pbo) don't work.

See post #7 for latest info.

Edited August 9, 2013 by eagledude4

[max power 21]

The first thing I would suggest is changing your graphics settings to ascertain the difference.

Then I would suggest posting your rvmat.

[eagledude4 3]

@Max Power: I gave the addon to a friend with different specs and graphic settings and he has the same result.

Edited August 8, 2013 by eagledude4

[shinkicker 5]

Hi Eagledude4,

Did you use BinPBO and if so did you add .rvmat as a file to copy directly and not be binarized. That one got me before. You set it under options...just add ;*.rvmat

[eagledude4 3]

@Shinkicker. I used binpbo, but because I don't include rvmats with the p3d's themselves, (aka in a separate pbo), I don't need to include *.rvmat.

Through some investigation, I have found that the rvmat is not the problem. When I created the pbo unbinarized, the issue does not exist, so I suspect the issue has something to do with the binarization binpbo is doing. I also noticed my shadow lod is different (10x more low poly)

Edited August 9, 2013 by eagledude4

[mikero 79]

@shinkicker you have me curious. I can't think of a single reason why you would need to pass unbinarised rvmat for anything. yes, you can, but I can't see any occasion where you would need to.

[eagledude4 3]

Through some experimentation, I have found that different combinations of checking and unchecking "clear temp folder", and deleting the files in "C:\Users\Jordan\AppData\Local\Temp\ARMAaddons". Fix the issue.

When the p3d's are included in the pbo, a ca and core folder are created in the "ARMAaddons" folder. But after clearing the temp folder and running pbo again, those folders are not created, and the p3d's are not included in the "ARMAaddons\ed_vehicles" addon folder.

The only thing in the log that looks out of the ordinary is this:

w:\C_branch\Poseidon\Arrowhead\El\FileServer\fileServer.cpp(2513) : Assertion failed 'req->RefCounter()==1'

Edited August 9, 2013 by eagledude4

[mikero 79]

welcome to hell. two things about binarise (binpbo)

for crunching time reasons, eg speed of processing, binarise will not re-binarise any already binarised data it finds in temp (of a later date than the source)

eg rvmats already processed at some previous attempt, are not done again on the generally correct assumption they're going to end up the same. Hence you should find 2nd pass attempts much faster than 1st attempts

the drawback is, that binarise cannot (or doesn't) pre-determine what's valid in temp. if it's 'there' it gets packed. so any old no-longer existing source stuff gets packed too

another drawback is it's quite possible to have a source file (be it p3d rvmat, config, pax) that's an earlier date than the temp folder, they, will be ignored no matter what you try and do. so best bet, always use clear temp

the second 'characteristic' of binarise is the instant you add a config, it's gonna go looking for the external addons you've (probably) referenced in that config. It then builds configs and data for THAT addon. hence your apparently strange CaData and other things outside your control.

these extra items are one offs they get built once, by binarise.exe, for ALL your projects

one final 'problem' is that binpbo is too smart for it's own good. specifically, for p3d's: *only* the pax it explicitly refers to ends up in the final pbo. you can have any number of additional pinkElephant.tga's in your source folder, they simply wont be included in the final pbo because NO p3d references them. This despite the fact that they ARE used by your config.cpp for items such as icons and markers.

filebank.exe (the final pbo packer of binbo) examines the *.dep file in the temp file. if the resource aint in it, you don't get it in the pbo. Most people use a 'helper.p3d'. it does nothing more than reference all the tga/pax items that are used only in the config, to get round this issue.

again. Welcome to hell.

Edited August 9, 2013 by Mikero
helper.p3d

[[aps]gnat 28]

Interesting consolidation of most things I knew thanks Mikero.

But that last one I've never noticed, maybe because all my TGAs are usually converted to PAAs long before a final binPBO run.

[eagledude4 3]

Thanks for your lengthy and informative reply, Mikero.

[shinkicker 5]

@shinkicker you have me curious. I can't think of a single reason why you would need to pass unbinarised rvmat for anything. yes, you can, but I can't see any occasion where you would need to.

I always thought binarised rvmats do not work? I must have have been wrong.

[max power 21]

IIRC rvmats become part of the p3d when binned.