OA Road MLODs coming soon?

[Synide]

.... you's will be converted to my (easier) way of doing things eventually

Multiply your way (i think someone at BIS probably thought it up before you ) by several seperate mod's + upteen one-off compilations and tell me your way is easy to keep in some semblance of ordered sanity. It's fine & valid to build everything from the root of your P:\ drive using the 'P:\<YourTag>_<YourPBOName>\...' method but once you start building across multiple config.cpp/model.cfg branches it can quickly turn to mustard.

It's difficult enough trying to bug-fix someone's build attempt remotely only to find that binarize has parsed someone's obseqeous config.cpp from some deep folder because they're using P:\ as the root instead of P:\<YourTag>\ as the root.

Don't get me wrong though... For the new people & people who are never intending to work on anything other than there own stuff the BIS preferred build method is fine.
Sorry to jump on the bandwagon Gnat but both build methods have there pros & cons and are appropriate for differing use-case senarios in my opinion.

[.kju [PvPscene]]

Latest tools install + arma2p should be "one click" install and done.
If there are problems, report them to mikero.

[[APS]Gnat]

Fair point Synide, but I'd think a mod the size of I44 would still be fine sitting in P drive. Worst case its several dozen folders.

But its not the name-space so much that raises my interest, it the weird and wounderful method people have to re-arrange their CA config files. I believe it all came about because someone way way back in the beginnings of time had trouble with ladders ..... and their weird reshuffle that fluked a result was how they got around it.
All I say, leave every config.cpp where it depbo's, then just unRap those files, keep both. I've never had a need to dulicate elsewhere .....

[Synide]

Until 1 of your builders drops another folder + config's into P:\ that's completely unrelated to your mod then binarize will parse that too.

That was me mate... I convinced a number of people back in '07 to use this build method primarily because a group of us were building for several different mods and groups of people all at the same time off of our P:\ drives.
It became a nightmare. So, I analyzed the hell of it all and came up with a solution that was actually very manageable, at least from our perspective. The upshot was that you were safe in the knowledge that when your root was 'P:\MOD1\...\' you knew that binarize was only going to go looking for config.cpp's inside the 'P:\MOD1\...\' namespace.
The next day when you were working on 'P:\MOD2\...\' again you were safe from 'config' contamination from 'P:\MOD1'. And, so on.

It wasn't much todo with ladders at all. But, more todo with class inheritance and keeping a sane demarcation between entire ecosystems of config's, similar but subtly different models, scripts & other resource data.
Myself and a number of others were using this method to build and getting great results but most importantly, high reliability and consistency.
In mid 2008 there were soooo many people struggling with build stuff I basically got sick and tied of seeing every 2nd thread in these forums relating to build issues. So I whiped out a document to try and get across a reliable method.

Your weird and wonderful from my point of view is practical and prudent.
While you've never had a need... I and many others have had a need.
I could set it up my way in less than a minute on anyone's machine and with LinkShell it's even easier, ya don't even need to copy anything anywhere.
Bare in mind too that your 'easier' does not necessarily equate to 'better'.
Both our methods have valid uses.

Unfortunately, I guess I'll never be able to convert you to the 'dark-side' of the force -

[[APS]Gnat]

It wasn't much todo with ladders at all. But, more todo with class inheritance and keeping a sane demarcation between entire ecosystems of config's, similar but subtly different models, scripts & other resource data.

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

Unfortunately, I guess I'll never be able to convert you to the 'dark-side' of the force -

lol .... well my "side" is just fine for my small scale 1-man rebellion

[Bushlurker]

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...!!!


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

[[APS]Gnat]

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.

[[APS]Gnat]

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;

[Synide]

- 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.

[[APS]Gnat]

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.