OA Road MLODs coming soon?

[Bushlurker]

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



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



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



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



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



B

[Synide]

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

[Thromp]

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.

[[APS]Gnat]

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

[Synide]

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, for reasons that don't exist/no longer exist.
Improved choices.

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.