Snake Man 407 Posted October 8, 2009 (edited) Chernarus has its textures placed on two different pbo's. chernarus.pbo - WRP. pboprefix: ca\chernarus chernarus_Data.pbo - Close textures, terrain UI image, Scenes\ and Scripts\ dirs. pboprefix: ca\chernarus\data chernarus_Data_Layers.pbo - Satellite layer textures. pboprefix: ca\chernarus\data\layers This setup works fine ingame because $PBOPREFIX$ allows us to place the content into whatever dir and specify how engine sees the path. However, it doesn't work in Visitor 3 (at least in my test), as it cannot find the textures. When you develop the terrain in the v3 PEW file, do you have to keep the textures in the data\layers directories, or is there any way to define them like in the chernarus example? See also PMC Editing Wiki: BIS Terrain Analysis. Edited July 19, 2012 by Snake Man Share this post Link to post Share on other sites
beton 2 Posted October 8, 2009 Hi, i don´t know too much about that but wasn´t it the same with the plants? We have 5 different pbo´s but for use in Visitor we have to put them alltogether in in one directory with 5 subdirectories. I think Visitor looks for the textures as defined in the layers config and places them like it is set up in the preferences of the project. But why would you like to change that as long as it works? Beton Share this post Link to post Share on other sites
.kju 3245 Posted October 8, 2009 Did you extract the files exactly according to the prefix? Screenshot please. Share this post Link to post Share on other sites
Snake Man 407 Posted October 8, 2009 But why would you like to change that as long as it works? I want to split my normal "TAG_MyTerrain.pbo" setup into the same style separate pbo setup as Chernarus. Close textures in data\ for one pbo, satellite layer textures into data\layers pbo. Why? Well because I have more than one terrain that would need the same close textures and it would be wasted space to duplicate those on additional WRP pbos. Did you extract the files exactly according to the prefix? No, there is only one directory just like Chernarus ie "TAG_MyTerrain_Data" and another one is for layers like "TAG_MyTerrain_Data_Layers". But yeah I guess I need to keep the development setup on sub dirs like "TAG_MyTerrain\data\layers" for Visitor 3 to find the textures... unless someone knows a method how to get v3 to see the $PBOPREFIX$? Share this post Link to post Share on other sites
.kju 3245 Posted October 9, 2009 Yep. That is your problem. You need a setup exactly according to the prefix. So BI had them all in one folder tree during development and only split them to different pbos for the release. Just use different prefix for each type in the first place: myTag\W_Name\ myTag\T_Name\ myTag\C_Name\ Share this post Link to post Share on other sites
Snake Man 407 Posted October 9, 2009 Damn, additional work when using this setup. Or do you guys know some batch file method to use files otherwise under binpbo control to just click one .bat which would "compile", binarize and pack a pbo's for me using this 3-pbo setup? I mean if I must manually split the pbo's up even when testing in my development setup... it will cause huge amount of uncertainty (did I goof up my splitting this time, is all the new files splitted, did I missed anything etc) in development and release moments. In a compromise... heck with the additional megabytes in the final release, it might be just well worth to duplicate the data\ texture contents on all the WRP's that share the same textures. Yes it means literally hundreds of megs in my case, but ... thats the only way to be 100% sure everything runs smoothly. Or am I wrong? Share this post Link to post Share on other sites
.kju 3245 Posted October 9, 2009 MoveObject does easily repath files (pew also supported from what I recall). You can use junctions for on level at least: http://dev-heaven.net/wiki/20/Virtual_folders_and_files To avoid messing up your work space, use a local git/svn repos. That way you can always easily diff and revert to any version. Share this post Link to post Share on other sites