Jump to content
Sign in to follow this  
bigshotking

OA Road MLODs coming soon?

Recommended Posts

Can't picture that problem, so I'll just take your word for it.

When I started working for CWR2 and had to install basically the entire mod on my P:\ drive to hook up to their SVN, I ran headlong into precisely the issues Synide's talking about...

Fortunately Mikero patiently explained the whole deal to me.... several times ;)...

In simple terms, when you give BinPBO a "path to project folder" and tell it to "Binarize", it goes to that folder and, as part of the process, it reads/parses the config.cpp it finds there... it also reads/parses any other config.cpp's it finds - in any other subfolder along that path!...

So, for example... if you have a terrain you want to binarize on your P:\root directory - let's say "P:\Island01"... when you launch BinPBO (with "path to project folder" set as P:\) it parses the config it finds in P:\Island01, it also finds P:\CA - which is just full of subfolders - all with config.cpps - so it parses them too!

This is what you want, since therefore your doors 'n ladders will work!

So far - so good...

Let's introduce the potential for errors now.....

Let's say you decide you want an "objects pack" for your "Island01"... You make a new folder on P:\ - called "Island01_obj", but, since you're not ready to work on that stuff yet, you just make up a basic "cfgPatches" config.cpp for it - throw it in the "Island_Obj" folder and go back to working on the island meantime...

Let's say there's also a real dumb mistake in that cfgPatches config you made - something like a "missing };"...

The next time you run BinPBO and tell it to binarise Island01 - BinPBO will throw an error... it'll say there's a problem with the config in P:\Island01_Obj....

But you didn't tell it to binarise Island01_Obj - you're only working with Island01 itself!

It parses every config.cpp - everytime...

Like Synide says, if there's only a few project folders on P:\ - they're all your projects... you're in control - they're all your configs.... you'll probably be OK - most of the time...

Now let's say you decide to use an external objects pack on your terrain... the imaginary "Dougal's Trees" pack...

You unpack the addon to P:\DougalsTrees...

You'd better hope Dougal's config is OK... from now on, every time you tell BinPBO to binarize your Island01, or even Island02 or Island03 - it'll be parsing Dougal's config too - even if you ain't using his trees on your island! - it's on P:\ - it's getting parsed! - every time!

You can see how, when working on larger projects with multiple contributers, this could quickly become unmanageable... especially if those other peoples configs disagree or conflict over classes or inheritance, etc...

One surefire way of limiting which configs BinPBO parses is to have a "Namespace! ;)

If you have something like "P:\CWR2\" - with all the different islands in there, and you tell BinPBO that the "path to project folder" is P:\CWR2 - then it will only parse the config.cpp's it finds in that folder (and any subfolders)...

So - you've successfully limited the scope of BinPBO now... you can have several "namespaces" - I have P:\Bush, P:\CWR2, etc for example.... by pointing BinPBO's "path to project folder" to one or the other of these, I can effectively limit it's scope to just that "family" of project folders...

But! - Now my doors and ladders don't work!!!!! Why????

Because BinPBO is no longer "seeing" P:\CA - where all those doors and ladders configs live!

Now... BinPBO doesn't care about models or textures... it's just reading configs...

So, an easy fix would be..... if you had a little "configs-only" version of CA - inside those "namespace" folders...

Then when you tell BinPBO that the "path to project folder" is, say - P:\Bush... it'll find and parse the project in P:\Bush\Island01, and it'll also find - and parse - all of the configs in P:\Bush\CA !!

Doors and ladders work again...!!! :D

You can just tell I've been hanging out with Mikero a lot lately, can't you... ;)

Still... it's done wonders for my config writing!

B

Edited by Bushlurker

Share this post


Link to post
Share on other sites

Great detail thanks Bush, but its unfortunately past midnight and I'm gunna have to come back and re-read this gem in a dozen or so hours .....

But one thing that comes to mind IMMEDIATELY is ...... you guys aren't using the little tick box called "USE SOURCE PATH" in BinPBO !??

Mines always on, and I've never seen these issues you seem to be talking about.

..... as I said, I gotta re-read and research again.

Share this post


Link to post
Share on other sites

OK .... well after a sleep and a re-read, I'm very curious and I have the following points.

- I've never had the "parsing every config" issues you describe here

- I've never had BinPBO report config errors in anything but the source directory I selected

- I do have every project sitting in the root of P drive, I do not use any "namespaces"

- My "path to project folder" in BinPBO is always the actual individual project folder, not P root.

- The CA folder is also in the root

- I never move or copy a file out of the CA folder

- I have only ever unRap'ed all the configs.bin files in CA, but left both the .bin and .cpp where it was

- Apart from the very first time I installed the ArmA1 tools, I have never had a door or ladder problem

- If I use a BIS object on a terrain, I simply reference the P3D, the tools do everything else.

- If I reference User addon; a) DePbo it into P drive root b) unRap config(s) c) reference same way as BIS objects

- I don't ever recall BinPBO protesting (warnings or otherwise) about about "Dougal's Trees" (example) bad config

- Inheritance works fine. "Class Plane; Class MyPlane : Plane {....." works fine

- Might be unrelated, but in cfgpatches I've found my "requiredAddons[]" can be blank and the game will never protest unless the actual required addons (BIS or otherwise) aren't present at game load time.

OK, so much smarter people than me have been playing with this longer than I have (probably cuz I've rarely had to experient to fix) so I'm quite happy with you guys blowing holes in my setup .... but right this minute I've got this little feeling that I got lucky and I got it right ......

My setup;

BinPBO_setup.jpg

PDrive.jpg

Share this post


Link to post
Share on other sites
Gnat;2091039']

- I've never had the "parsing every config" issues you describe here

In your example images your building 'P:\usec_b1b'.

binarize.exe will go looking for a config.cpp in this folder. It will then go looking in all subfolders of P:\usec_b1b for config.cpp's. It will then step UP to P:\ and go looking for a config.cpp. It will then go looking in every subfolder of P:\ for config.cpp's.

...but right this minute I've got this little feeling that I got lucky and I got it right ......

There's nothing wrong with your setup Gnat. In fact I used to build exactly the same way as you and sometimes on the rare occassion I still do. Your 'method' has nothing todo with luck mate. It's the intended default method of building that BIS provided for you by way of the implementation that BinPBO exposes.

The point is, YOU are managing your own build drive WELL. It's when you start working across multiple sets of 'similar' but subtly different entire config systems with multiple people that things CAN (but not always) go awry.

The objective of using a P:\GNT\ namespace is to lessen these issues.

Finally... just for a second... have a think about 'P:\ca'. What is it Gnat? It's a MOD it's BIS's default MOD. Nothing more nothing less. It's all their created content nicely apportioned off from the rest of the branches of content on there internal P:\ drives. Which for lack of a better term well call a 'namespace'.

The 'ca' namespace.

If you extract a BIS .pbo what do you get? a pboprefix of 'ca\weapons', 'ca\weapons2', 'ca\tracked', 'ca\chernarus'... etc., etc.

You don't get 'ca_weapons', 'ca_weapons2', 'ca_chernarus' do you?

Let's also consider that there are alot of config's in the 'ca' namespace. How many would there be in the VBS2 namespace or any other they may have on there development drives? I surmise alot.

Perhaps they might even look something like...

P:\ca\...

P:\vbs2\...

P:\toh\...

P:\cc\...

The objective of the method of building whereby you drop a 'ShellLink junction' of P:\ca into your own P:\GNT is to lessen the possibility of issues and to emulate the setup that BIS themselves use.

Edited by Synide

Share this post


Link to post
Share on other sites
It will then go looking in all subfolders of P:\usec_b1b for config.cpp's. It will then step UP to P:\ and go looking for a config.cpp. It will then go looking in every subfolder of P:\ for config.cpp's.

Sorry Synide, but I see absolutely no evidence that it looks up out of the assigned folder.

All logs, all live displays on BinPBO, the processing time, all show not 1 hint that its looking anywhere else but inside usec_b1b

Further, if what your saying were true, does this process typically manifest errors from configs that lay outside the project directory (Up) ?

Bush suggests it does.

I have many broken configs "Upwards", but none are reported as errors as I BinPBO a project.

As for the namespace, I understand your point, and examples, but my reason for entering into the debate is somewhat because thats being looked at as a cure for a disease, a disease that I'm suggest doesn't actually exist when the right "stuff" is done.

Share this post


Link to post
Share on other sites

Firstly I'd just like to say what a refreshing change it is to see knowledgable and informed people enjoying a techie discussion without lost tempers or rancour :)

Whenever this whole namespace discussion comes up, I often mention Gnat as an example of how the standard "P:\Root" approach is perfectly valid, and you never fail to take it with good grace and contribute your own point of view... A gentleman indeed!

Anyhow... on with the discussion!

Since I have a classic example of this topic lurking in my CWR2 setup I thought I'd induce the error and take a few screeenies to illustrate.... here goes.....

Firstly... CWR2....

CWR2 is HUGE! Seriously.. there's a lot of data - a lot of addons....

To avoid there being - literally - over 200 separate "addon folders" on P:\ - just like BIS do, they're in a "namespace"... it looks like this.....

P_cwr2.jpg

Each of these subfolders may have as many as 30 or more individual addons within it - each with their own config...

Fortunately, I'm not responsible for keeping track of this whole thing! (Wolle & Mikero do that ;)), the only thing I need concern myself with is the "CWR2_Islands" subfolder..... let's look inside there next.....

islandsFolder.jpg

First thing to notice is the curiously named "Error Island"... that's not it's real name of course... it's actually an as-yet-unreleased "surprise" extra terrain who's name I would have had to change anyway for this screenshot, but it's also one which does have a dumb error in its config.cpp...

OK... Let's set up to Binarize "cwr2_eden" - the main Everon island file... here's my BinPBO setup.....

cwr2_binPBO.jpg

All pretty straightforward...

The two important paths are the "Addon Source Directory" - the actual addon we're binarizing... that's pointing - correctly - at P:\cwr2\cwr2_islands\cwr2_eden...

...and the "Path to Project Folder", which is pointing at the "namespace" - P:\CWR2

.... everything else looks fine.... Let's Binarize!

But!..... what's this??? an Error???

Error.jpg

... worse still - it's an error inside the "Error Island" folder!

What is BinPBO doing, looking in there at all???

... looking for configs to parse! :D

B

Edited by Bushlurker

Share this post


Link to post
Share on other sites
...but my reason for entering into the debate is somewhat because thats being looked at as a cure for a disease, a disease that I'm suggest doesn't actually exist when the right "stuff" is done.

That's cool... I agree with ya... if the problem isn't presenting itself anymore then I guess I'll just start using your method. At the end of the day as long as it works in game and isn't inefficient does it really matter how it gets there?

Share this post


Link to post
Share on other sites

Nice discussion ,

I only use namespace for terrains and multiple addon sets , there is no use for it if i am making a simple car or something that is standalone and doesnt inherit from anything not already in the Binpbo config .

the way i learned what was happening is to copy and paste your path to temporary folder in explorer whilst binarising , you will see it pulls all the necessary models textures and configs pertaining not only to the thing you binarise but all the required addons and the reuired addons of the required addons, invariably when binarisng a terrain with a bis structure placed you get get almost all subfolders in ca in your temp folder including configs .

the reason the namespace needs all the configs pasted in the namespace is because now its looking for ca content in your new work folder and it only knows and does this because you must change the Path to project folder .

I think people should always use Namespace for uniformity for terrains and ease of error feedback myself , because it levels the playing field , for single standalone addons i think direct to P\folder is good enough.

Edited by Thromp

Share this post


Link to post
Share on other sites

Thanks Bush ;) right back at-ya

...and the "Path to Project Folder", which is pointing at the "namespace" - P:\CWR2

So there it is!

If you are only binarizing 1 addon/folder at a time, why should this not be P:\CWR2\Island or even P:\Island

I too have had a few major community projects in my P drive ;)

But as I only ever worked on 1 addon (1 folder) at a time, there seemed little point if it wasn't messing up P drive (appearance), as they had naming conventions.

If you Tick "Use source path", little will change, except BinPBO pulling unnessisary configs.

... the reason the namespace needs all the configs pasted in the namespace is because now its looking for ca content in your new work folder

.... and you wouldn't have to do this either .....

That's cool... I agree with ya... if the problem isn't presenting itself anymore then I guess I'll just start using your method. At the end of the day as long as it works in game and isn't inefficient does it really matter how it gets there?

Understand. Hope you guys are not thinking I'm trying to ram this down your necks ......

My aim is to raise awareness of a "method" that new addon makers could be warned away from, for reasons that don't exist/no longer exist.

Improved choices.

Cheers guys

Share this post


Link to post
Share on other sites
Gnat;2092080']Understand. Hope you guys are not thinking I'm trying to ram this down your necks ......

Not at all. Tbh... after thinking about it I probably won't move back to using the P:\<YourPrefix>_<YourAddonName> setup as opposed to the P:\<YourPrefix>\<YourAddonName> method primarily because I like the physical folder demarcation between the different lumps of content and it replicates BIS's own setup.... P:\ca.

...don't exist/no longer exist.

Yesterday I installed the A1 tools package then uninstalled afterwards. It did go looking for config's all over the place... These A2 tools packages no longer do this anywhere near the same extent.

My aim is to raise awareness of a "method" that new addon makers could be warned away from' date=' for reasons that don't exist/no longer exist.

Improved choices.[/quote']

Understand... while I'll agree with you that it's not technically needed anymore you make it sound like it's 'wrong' or a difficult method to setup or use when it's neither.

I'll still use it too 1. keep my P:\ drive tidy and 2. replicate BIS's folder structure. Well just have to agree to disagree as to it's worthiness & setup difficulty.

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  

×