A Possible Community Approach to addon/mod making

[terox 316]

This is basicaly a post to make addon makers aware that their modelling work could be available to a more widespread audience if they approached PBO creation in a slightly different manner

It would solve a lot of "Permission" issues

Allow much more content in mods

and stop redistribution of same name .pbo with differing config values that can occur when a mod is released

The standard addon is released as 1 PBO, containing the model data and a config.

This is a fairly acceptable setup for addition to a communities addon pack.

Where it fails is during the inclusion to a Mod

Quote[/b] ]The problems are

1) Mod required config values often differ from the addon makers values, so they either need to create a new pbo name or edit the original

2) To rename the pbo access to the mlods is needed

For obvious reasons model makers dont allow anyone access to their mlods

End result, model isnt used, reducing content in the mod

3) Alternatively, the mod inherits classes from the original classnames of the addon

End result, the mod editor is filled with unwanted classname vehicles and looks an untidy mess

4) Alternatively, the original PBO has its config either removed or edited, which creates similarly named pbo's with differing content (Not the best solution)

It is not my place to tell addon makers how best to release their addon, but what I can say, is that if you released your addons in 2 parts

addon_model.pbo

addon_config.pbo

This would make your model a lot more available to the community as a whole and would also allow much more content in the mods as well as much speedier creation of mods.

It would reduce a lot of "Asking permission" issues

Would stop redistribution of varying versions of the same .pbo name

From a mod development point of view, you have a much higher chance of getting your work used in a mod, if it comes with seperate configs

All I ask is that you contemplate the bigger picture

Thanks for your time

[ArmaVidz 0]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

[Guest RKSL-Rock]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

[dm 9]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

Seconded.

[ryankaplan 1]

@Armavidz, RockofSL, DM: The topic has almost nothing to do with permission taking. Terox isnt on about using content without permission.

Here is the hypothetical problem for a released addon.

-I want to add jonny's marines to my modification.

-Jonny has released his addon with a single .pbo, which contains both the addon data AND the config.

-Being a modification (and not a collection of addons), i want all the addons i put in the mod to suit the mod, otherwise im going to face problems which include but are not limited to: a very cluttered mission editor, guns that sound nothing like eachother, same men carrying 2 configed types of the same AK, etc.

-I must ask for permission to use jonni's marines. Jonny is a reasonable and normal guy, and wants his addons used as much as possible as he spent all that time and effort on them. Jonny is prepared to five permission.

Now, to achieve what i want to achieve, i have 3 choices:

-------------(1) Edit the JonnyMarines.pbo, take the config out, repbo it, shuv it in the mod and make all the config entries in mymod_cfg.pbo. This leads to the distribution of 2 pbos named JonnyMarines.pbo, with different content in them. This is not ideal for obvious reasons

-------------(2)Get jonny to send the mlods to us, so i can repath them to MymodJonnyMarines.pbo. This has a very high chance of not happening, as jonny doesn't trust me, and for all he knows i might get his model, add a dot and say i made it all.

-------------(3)Get jonny to repath the models to MYmodjonnyMarines.pbo, and then rebinarise them, and then upload them to a private ftp for us. This has a very high chance of not happening, because jonny doesnt know who i am and doesnt care, and doesnt want to waste an hour doing a very boring thing for a mod that may never see the light of day.

So, because i have only one choice in how to add jonnys marines to my mod, i create distribution problems, due to 2 jonnymarines.pbo circulating on the internet.

However, if the addon was released in the way Mr. Terox suggested, This is what happens.

-I ask for permission. Jonny says yes, as he is the same old reasonable man we love to love. We take the JonnyMarines_Model.pbo and delete/dont use the JonnyMarines_cfg.pbo. We create our own Mymod_cfg.pbo, which makes use of the material in JonnyMarines_Model.pbo to my liking without editing any files jonny has created, and without creating another copy of the addon. Jonny hasn't had to waste time on me, or in the unlikely scenario that he did because he is very nice, i did'nt have to waste time on waiting for jonny to send me the repathed mlods. Problem solved, precious time saved.

In the later days of ofp, this was almost standard practice. LSR, SJB, HYK, JAM, all used these for a reason.

I hope you can see into the matter more clearly now. Sorry about any hurrendous grammer and spelling mistakes.

[dm 9]

@Armavidz, RockofSL, DM: The topic has almost nothing to do with permission taking. Terox isnt on about using content without permission.

Actually, it appears to be a LOT about permissions:

It would solve a lot of "Permission" issues

It would reduce a lot of "Asking permission" issues

The whole idea of his "version" of this pbo system is to remove the need to ask for permission (since the configs are optional, making it easy to repackage the data)

In the later days of ofp, this was almost standard practice. LSR, SJB, HYK, JAM, all used these for a reason.

Yes, and the reason was the configs need updating/fixing a LOT more than the models and textures do. Therefore it was easier, and more sensible to split the configs from the data, so that "patches" could simply redistribute the configs and scripts, rather than the sizeable model and texture files.

Here is the hypothetical problem for a released addon.

-I want to add jonny's marines to my modification.

-Jonny has released his addon with a single .pbo, which contains both the addon data AND the config.

-Being a modification (and not a collection of addons), i want all the addons i put in the mod to suit the mod, otherwise im going to face problems which include but are not limited to: a very cluttered mission editor, guns that sound nothing like eachother, same men carrying 2 configed types of the same AK, etc.

-I must ask for permission to use jonni's marines. Jonny is a reasonable and normal guy, and wants his addons used as much as possible as he spent all that time and effort on them. Jonny is prepared to five permission.

Now, to achieve what i want to achieve, i have 3 choices:

-------------(1) Edit the JonnyMarines.pbo, take the config out, repbo it, shuv it in the mod and make all the config entries in mymod_cfg.pbo. This leads to the distribution of 2 pbos named JonnyMarines.pbo, with different content in them. This is not ideal for obvious reasons

-------------(2)Get jonny to send the mlods to us, so i can repath them to MymodJonnyMarines.pbo. This has a very high chance of not happening, as jonny doesn't trust me, and for all he knows i might get his model, add a dot and say i made it all.

-------------(3)Get jonny to repath the models to MYmodjonnyMarines.pbo, and then rebinarise them, and then upload them to a private ftp for us. This has a very high chance of not happening, because jonny doesnt know who i am and doesnt care, and doesnt want to waste an hour doing a very boring thing for a mod that may never see the light of day.

Wrong wrong wrong.

1 - Why would you ever do that? The "correct" way would be to extract the model and textures, and repath them to your new pbo.

2 - You do NOT need mlod's to repath textures (the first year or so of arma addons - the reskins - should be proof enough for that)

3 - Yes it does, because it is entirely unnecessary.

So, because i have only one choice in how to add jonnys marines to my mod, i create distribution problems, due to 2 jonnymarines.pbo circulating on the internet.

No, you have a LOT more choices than that.

However, if the addon was released in the way Mr. Terox suggested, This is what happens.

-I ask for permission. Jonny says yes, as he is the same old reasonable man we love to love. We take the JonnyMarines_Model.pbo and delete/dont use the JonnyMarines_cfg.pbo. We create our own Mymod_cfg.pbo, which makes use of the material in JonnyMarines_Model.pbo to my liking without editing any files jonny has created, and without creating another copy of the addon. Jonny hasn't had to waste time on me, or in the unlikely scenario that he did because he is very nice, i did'nt have to waste time on waiting for jonny to send me the repathed mlods. Problem solved, precious time saved.

I hope you can see into the matter more clearly now.

The bold parts are the important parts, permission still HAS to be obtained, which is the whole problem a lot of established addon makers are having with this "system". The italic part is entirely unnecessary.

[max power 21]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

Seconded.

Motion carried!

[ryankaplan 1]

Trust me. I know Terox and Terox knows me, and believe it or not, using content without permission is out of the question. By 'permission asking issues' we don't mean 'needing to ask permission'.

By that, we mean that the work involved in getting permission is reduced on both sides.

Quote[/b] ]The italic part is entirely unnecessary.

Why so? Is my time making the modification not as worthy as the mentioned 'jonny's? Should i feel so honoured that he made the addons that i should stop my modding project for 3 weeks when it could be done in 1 day with no loss to either side? (The jonny is an example btw, it hasn't to do with how jonny may feel or react in reality)

Quote[/b] ]The bold parts are the important parts, permission still HAS to be obtained

Yet again, i say using content without permission is out of the question. If i wanted to do that i don't think i'd care much redistrubution problems and would simply edit his pbo to my liking. In any case, In my example, permission was taken as i said "I ask for permission. Jonny says yes".

Quote[/b] ]2 - You do NOT need mlod's to repath textures (the first year or so of arma addons - the reskins - should be proof enough for that)

That's infact good news. But other than hex editing which has it's limitations according to a friend of mine, how is it done? I'd appreciate it if you elaborated as it would solve all problems mentioned.

[Heatseeker 0]

Whats the point of having mods that redistribute content we might already have (and in the original form too)?

Shouldnt these mods use addon dependencies instead of redistributing already available content?

Im sleepy so i might be missing the picture here .

[dm 9]

Quote[/b] ]The italic part is entirely unnecessary.

Why so? Is my time making the modification not as worthy as the mentioned 'jonny's? Should i feel so honoured that he made the addons that i should stop my modding project for 3 weeks when it could be done in 1 day with no loss to either side? (The jonny is an example btw, it hasn't to do with how jonny may feel or react in reality)

Its unnecessary, because you dont have to use the mlods to repath textures. Sure the hex-editing method has its limitations, but it does mean that things can be done without the need for mlod models.

(It has nothing to do with whether the mod is "worthy" or not, and everything to do with wasting time, effort and energy, when a simpler solution is available)

Quote[/b] ]The bold parts are the important parts, permission still HAS to be obtained

Yet again, i say using content without permission is out of the question. If i wanted to do that i don't think i'd care much redistrubution problems and would simply edit his pbo to my liking. In any case, In my example, permission was taken as i said "I ask for permission. Jonny says yes".

But what happens with your version when someone says no? Or doesnt even get asked for permission? The point is, that this system allows for easier "abuse" of the content (all you need to do is write your own config and pbo it). Since most users dont care where stuff comes from, because they just want the shiny content. By removing the "moral need" to ask for permission (the way this system does: "hay guys, the data pbo still has the original tag, so its a-ok to use without asking the creator") when making the mod, it alienates and upsets the people that put the hard work in to making the 2D and 3D in the first place.

[RN Malboeuf 12]

Quote[/b] ]It is not my place to tell addon makers how best to release their addon, but what I can say, is that if you released your addons in 2 parts

there's another reason for doing this but not permission issues. It's good idea to move configs/scripts (and model) into separate pbo - just cause it can be easily updated without need for player to download all the stuff again. For ex. DKM mod worked in this way while releasing addons

[baddo 0]

One problem is incompatible "total conversion mods" (don't take this term literally) such as possibly upcoming FDF Mod for Arma and Bundeswehr Mod, and maybe others. I don't know if they will be compatible, but how big chances there are for that if both are going to do their own main configuration files.

That's definitely a problem if those kinds of mods can't be used together. I just names two examples, but I'm sure you can bring up other examples which you would like to be able to play together.

[shinRaiden 0]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

Seconded.

Motion carried!

What they said, ibid.

BAS, Combat, MapFact, RHS, WGL, COC, and most of the other successful mod teams used that structure because it works and is the right way to develop content, for reasons that have been well documented elsewhere.

However, the issue of the OP is not one of content development management. I'm not going to point fingers and say thief though. Rather, I give a caution against impulsive impatience, and respect. When you say "I want you to do things MY way to facilitate MY interests for MY addons, and I am going to complain if you don't share MY interests and MY development methods", what's the consistent message there?

I'm not pointing fingers of blame at you, rather I'm raising a cautionary note to all that before we get grumpy and impatient, we need to chill out, take a deep breath, and remember it's just a game.

[ProPilot 0]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

Seconded.

Motion carried!

And again.

[UNN 0]

Quote[/b] ]Here is the hypothetical problem for a released addon.

-I want to add jonny's marines to my modification.

-Jonny has released his addon with a single .pbo, which contains both the addon data AND the config.

-Being a modification (and not a collection of addons), i want all the addons i put in the mod to suit the mod, otherwise im going to face problems which include but are not limited to: a very cluttered mission editor, guns that sound nothing like eachother, same men carrying 2 configed types of the same AK, etc.

-I must ask for permission to use jonni's marines. Jonny is a reasonable and normal guy, and wants his addons used as much as possible as he spent all that time and effort on them. Jonny is prepared to five permission.

Now, to achieve what i want to achieve, i have 3 choices:

Actually you have a fourth choice, which doesn't require any modification to the original pbo:

(4)Create your own config for the mod and inherit all the required classes from the original pbo. Modify the inherited classes to conform to whatever standards you want. Its even possible to prevent the original units from appearing in the editor while the new MOD is installed, so no worries about clutter in the mission editor.

Unless you want to physically change the p3d or textures, then this method is the least problematic. As it allows you to use content from authors who may have left the community, without breaching any copyrights.

Inheritance, is not something an addon maker should object to on it’s own. Nobody expects to ask permission to use third party addons in a mission? But when your packaging someone elses addons into your own mod, there is a danger that people will assume you created all the content. So at the very least you should seek approval from the original authors.

Don’t get me wrong. I’m all for a modular approach to the content of pbo’s. But it should be done to aid the design and support of addons. Not to facilitate large, fourth party, collective mods.

[Jahve 0]

Honestly, I don't think the real issue is distribution or inclusion, I do believe the real issue is exclusion of respect and acknowledgement to the addon maker.

It's a seems a good idea to develop addons in the manner you stated however until some people learn a little respect for these fellas' hard work - the whole basis for your argument is in my humble opinion - moot.

Agreed

Seconded.

Motion carried!

And again.

quoted, re-quoted, re-re-quoted and quoted again, this topic deserves its own graphic and theme music.

But I second the carried motion! It wont work.

[mr burns 131]

..this topic deserves its own graphic and theme music.

[Maddmatt 1]

Actually you have a fourth choice, which doesn't require any modification to the original pbo:

(4)Create your own config for the mod and inherit all the required classes from the original pbo. Modify the inherited classes to conform to whatever standards you want. Its even possible to prevent the original units from appearing in the editor while the new MOD is installed, so no worries about clutter in the mission editor.

Unless you want to physically change the p3d or textures, then this method is the least problematic. As it allows you to use content from authors who may have left the community, without breaching any copyrights.

Inheritance, is not something an addon maker should object to on it’s own. Nobody expects to ask permission to use third party addons in a mission? But when your packaging someone elses addons into your own mod, there is a danger that people will assume you created all the content. So at the very least you should seek approval from the original authors.

Don’t get me wrong. I’m all for a modular approach to the content of pbo’s. But it should be done to aid the design and support of addons. Not to facilitate large, fourth party, collective mods.

There's the solution. No need to modify the original addons at all

[sickboy 13]

Actually you have a fourth choice, which doesn't require any modification to the original pbo:

(4)Create your own config for the mod and inherit all the required classes from the original pbo. Modify the inherited classes to conform to whatever standards you want. Its even possible to prevent the original units from appearing in the editor while the new MOD is installed, so no worries about clutter in the mission editor.

Unless you want to physically change the p3d or textures, then this method is the least problematic. As it allows you to use content from authors who may have left the community, without breaching any copyrights.

Inheritance, is not something an addon maker should object to on it’s own. Nobody expects to ask permission to use third party addons in a mission? But when your packaging someone elses addons into your own mod, there is a danger that people will assume you created all the content. So at the very least you should seek approval from the original authors.

Don’t get me wrong. I’m all for a modular approach to the content of pbo’s. But it should be done to aid the design and support of addons. Not to facilitate large, fourth party, collective mods.

There's the solution. No need to modify the original addons at all

Means the editor is less cluttered, but:

[*] The classes still exist; I would think it's better that classes which you dont use or don't need, don't exist at all?

[*] The addon CfgPatches is still loaded, which means the original addon will slip into the mission.sqm addons and addonsAuto arrays (or you must preload all addons, which is still unpreferred due to SinglePlayer campaign/mission saving (saves the addons preloaded in savegame array, if you ever remove the addon, say in ryan's example, Johny's Marines are switched out for Marvy's Marines, you have another issue on your hands)

[*] You create dependency on dependency on dependency, e.g:

RHS Marines requires RHS Weap and RHS Naval. The RHS Naval depndency might be normal due to shared textures etc. etc, but what if you do not want to use the RHS_Weap? You don't include it, but now it should give an error when starting up the game: RHS Marines rquires RHS Weap. Even if you overwrite the config or parts of it, afaik.

I personally agree with Terox that seperate config from models/textures is, next to the development reasons, a good way to reduce amount of versions floating around of certain pbo's.

I do not see a negative point here. Only positive points.

It's not easier or harder to rip someone's work, doesn't matter if the config is included in the pbo or in a seperate pbo.

In the end it all comes down to requesting permission and receiving permission, before any work by others will be used and / or included. In both situations this must still happen, but in the situation of seperate config, it adds more flexibility.

Repathing and such are options, but it has it's down side aswell: Creator updates his work; You can go repath again, while otherwise you might only have to update some config parts, or just files. Not a problem when you use 1 addon from 1 creator, but how about 50 or 100, or 200

[UNN 0]

Quote[/b] ]The classes still exist; I would think it's better that classes which you dont use or don't need, don't exist at all?

To use the term better, would mean it was worse if they did exist. I think it's more a case of them not having any noticeable effect either way.

Quote[/b] ]The addon CfgPatches is still loaded, which means the original addon will slip into the mission.sqm addons and addonsAuto arrays (or you must preload all addons, which is still unpreferred due to SinglePlayer campaign/mission saving (saves the addons preloaded in savegame array, if you ever remove the addon, say in ryan's example, Johny's Marines are switched out for Marvy's Marines, you have another issue on your hands)

Can't say I've gone into it in great detail. But some dependencies are only written to the mission.sqs when the addons are created in game. But if you start changing addons in a mission, then you have to expect to do some work. I usually just delete all the dependencies then load the mission into the editor and run it and save. Takes about 1 minute?

Quote[/b] ]You create dependency on dependency on dependency, e.g:

RHS Marines requires RHS Weap and RHS Naval. The RHS Naval depndency might be normal due to shared textures etc. etc, but what if you do not want to use the RHS_Weap? You don't include it, but now it should give an error when starting up the game: RHS Marines rquires RHS Weap. Even if you overwrite the config or parts of it, afaik.

Don't know about RHS addons, but if you’re talking about changing textures, then that’s modifying the p3d. I thought Terox wanted to avoid that?

I can see your point when it comes to weapon packs. If a soldier is configed for a particular weapons pack, that isn't used, it seems like a waste to have to include it? But in that case you could write a null definition within the main config. Just a config.cpp entry that satisfies the addon dependencies. Which would probably just be  a line or two in cfgPatches?

There is a lot addon makers can do, to allow more flexibility with dependencies. Most of the stuff I'm writing can auto detect the presence of particular pbo's and act accordingly.

The bit I added about hiding third party addons was incorrect, it requires addon makers to adopt the sort of thing Q is doing with WGL, so it won't work for old addons. Creating bases class that inherit from the standard classes, allowing you to override things like scope.

There are certainly things addon makers can do to help people further on down the line.

[sickboy 13]

There are certainly things addon makers can do to help people further on down the line.

Quote[/b] ]Can't say I've gone into it in great detail. But some dependencies are only written to the mission.sqs when the addons are created in game. But if you start changing addons in a mission, then you have to expect to do some work.

Terox was talking about a Mod that includes addons by others, but within the mod's own classes. The mission.sqm's will contain the classes like TEROX_MOD_NavalE_Rifleman

so when we change the model of TEROX_MOD_NavalE_Rifleman, we do not have to edit any of the missions... We start our game again and voila, the guy has a new model.

Now I replace all models that come from RHS Naval addon, with 6th Naval addon. Works a charm, but with the suggestions made here, it would require you to edit every single mission to remove the RHS Naval addon dependency and add the 6th Naval addon. (You have to see the bigger picture here. Not your 3 personal missions, not the 10 missions that you received from your friend, but the 200 missions you have on your server!

Quote[/b] ]I usually just delete all the dependencies then load the mission into the editor and run it and save. Takes about 1 minute?

Sure, with 2 addons, not with 10. Also sure with 1 mission, but not with 100! Half of the addons require other addons... so when you empty your mission.sqm addons / addonsAuto arrays, you probably have to manually add a few addons of which no vehicles were used, but f.i. weapons and other kinds.

Quote[/b] ]Don't know about RHS addons, but if you’re talking about changing textures, then that’s modifying the p3d. I thought Terox wanted to avoid that?

No I was merely making an example of a dependency that still might be ok (2 model+texture pbo's that share textures from eachother), and a situation that is not ok (the requirement of a weapon pbo)

Quote[/b] ]I can see your point when it comes to weapon packs. If a soldier is configed for a particular weapons pack, that isn't used, it seems like a waste to have to include it? But in that case you could write a null definition within the main config. Just a config.cpp entry that satisfies the addon dependencies. Which would probably just be a line or two in cfgPatches?

I don't understand this part. With main config, you mean the addon config of the model you use (I guess not, because we don't want to edit this pbo, right?). Otherwise I do not know how you can break the dependency in the following example:

[*] Unit addon, with weapons specified in weapons and magazines array per unit class, and "WeaponAddon" set at cfgPatches requiredAddons

[*] WeaponAddon. Weapons get used by Unit Addon

I would not know a way how I could eliminate the dependency of UnitAddon on WeaponAddon, without editing UnitAddon.

You are right that you can use overwrite configs to change their weapons. Still, because the original addon requires "WeaponAddon", you still must have the WeaponAddon installed, because the weapons/magazines specification per unit, and the requiredAddons setup "WeaponAddon".

In any case, I believe that Terox his solution is the best course of action to follow. It gives ultimate flexibility:

Fourth Party Mod

[*] Can leave the original Config away, and use own config. Less Editor Clutter, own weapons and setup of the units in general. Still, if the user wants to play missions that require the original config, he could choose to install it, even though it will clutter his editor etc. etc.

[*] No editing needed of original pbo's

[*] No copies with different content hanging around

Original Addon

[*] Only have to update the _cfg.pbo for config and scripts, without the need to also send/update a huge models/textures pbo

[*] No copies with different content hanging around

Quote[/b] ]The bit I added about hiding third party addons was incorrect, it requires addon makers to adopt the sort of thing Q is doing with WGL, so it won't work for old addons. Creating bases class that inherit from the standard classes, allowing you to override things like scope.

Not sure what you mean here. AFAIK it is no problem to write an overwrite config that requires the original addon, and will hide the units in editor by using scope = 1;

The same can be done for the original vehicles in the game

[UNN 0]

Quote[/b] ]Terox was talking about a Mod that includes addons by others, but within the mod's own classes. The mission.sqm's will contain the classes like TEROX_MOD_NavalE_Rifleman

so when we change the model of TEROX_MOD_NavalE_Rifleman, we do not have to edit any of the missions... We start our game again and voila, the guy has a new model.

One thing is for sure, at this point in time I don't make missions, so I'm interested in what is required. Only I'm a little confused about the requirements. I'm assuming the missions (in the example you posited) have already been created for the TEROX_MOD* and not the original addon class? So I'm assuming the class names should always remain the same, only the content they point to differs. So Terox (sorry to hijack you as an example) would have ultimate control over the class names, so he can ensure missions made for his large scale config MOD always remain the same. As with any other third party addon MOD? The missions created for the original class names are effectively, out of his control.

I'm assuming large scale fourth party MODS do not use the original class names, but create their own?

Quote[/b] ]Works a charm, but with the suggestions made here, it would require you to edit every single mission to remove the RHS Naval addon dependency and add the 6th Naval addon.

We are talking about text files are'nt we? There are plenty of search and replace programs that could do the job in seconds.

Quote[/b] ]Sure, with 2 addons, not with 10. Also sure with 1 mission, but not with 100! Half of the addons require other addons... so when you empty your mission.sqm addons / addonsAuto arrays, you probably have to manually add a few addons of which no vehicles were used, but f.i. weapons and other kinds.

Again, if it really is common practice to have to edit hundreds of mission per addon, then the process should be automated. Automation should make some of these issues mute.

Quote[/b] ]I don't understand this part. With main config, you mean the addon config of the model you use

In this case I was referring to the the main config as the defining config for the large scale mod in question. Addon dependencies defined in configs look for corresponding entires in cfgPatches. As long as they are present Arma does not care if the actual pbo's exists. So Arma would load fine with a ghost cfgPatchs entry. It would however, crash when you try to create a unit that points to say a p3d that is not present. So the trick to avoid this would be to prevent invalid mission content from being called i.e scope.

Quote[/b] ]Not sure what you mean here. AFAIK it is no problem to write an overwrite config that requires the original addon, and will hide the units in editor by using scope = 1;

AFAIK you can't alter a specific class, but you can alter the immediate class it inherits from. For example you could have a bad config like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank;

class UNN_NewTank : Tank

      {

      \\My stuff goes here

      };

Or a good config like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank;

class UNN_BaseTank : Tank {};

class UNN_NewTank : UNN_BaseTank

      {

      Scope=2;

      \\My stuff goes here

      };

Having the additional layer allows me to override all the inheritance for just my tanks and not all of Arma's default tanks.

So a fourth party mod could define this config, to remove my original tank config from the mission editor menu's, and reduce potential clutter for the new large scale MOD:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank;

class UNN_NewTank;

class UNN_BaseTank : Tank

      {

      Scope=1;

      };

class TEROX_MOD_Tank : UNN_NewTank

      {

      Scope=2;

      \\Terox's stuff goes here

      };

Without that additional layer, you would have to redefine all the classes that inherit from the original Arma class Tank. When realy you are just interested in the classes that inherit from the UNN tank classes.

I'm not sure I have explained this very well. Perhaps Q can confirm this one way or another. From what I have tested so far, you need access to the preceding class layer, to make such changes?

Edit: Modified config examples

[sickboy 13]

Edit: Modified config examples

Quote[/b] ]As with any other third party addon MOD? The missions created for the original class names are effectively, out of his control.

True, this is also not the main concern I think.

Quote[/b] ]I'm assuming large scale fourth party MODS do not use the original class names, but create their own?

In my books; yes.

Quote[/b] ]We are talking about text files are'nt we? There are plenty of search and replace programs that could do the job in seconds. ... Again, if it really is common practice to have to edit hundreds of mission per addon, then the process should be automated. Automation should make some of these issues mute.

That's true, and im fairly confident most already use these. PowerGREP is king, if you ask me. But the point remains the same, it's a bunch of extra work that is simply unnecessary, and I think this was the whole point behind Terox his request.

Sure you can leave addons in tact, sure you can write overwrite configs to hide classes and disable this and that, sure you can edit missions by hand or automated programs, sure sure sure sure

But is it flexible? Is it handy? I think not.

It's either:

[*] Unpbo the addon, remove the config ...

[*] Or simply leave the ***_cfg.pbo config's away ...

...and keep the config entries and needed parameters/settings in your own big config, and voila

All the other solutions with overwrites, hiding, single/auto/mass editing, etc. etc. make a tremendous amount of extra work, on top of the already busy life of such modders (I know, because I am one of those).

I know that renaming, repathing and such are also options. But again a lot of work. Especially with addons that get updated every few weeks or better come out afterwards.

The original request by terox does not have negative points either for addon maker aswell as 4th party mod makers. It only has positive points for both, as described in my previous post.

Why do we have to fight this idea, and come up with long and more work involving 'solutions', while we can just all take the easy way out and all benefit from it one way or the other?

Quote[/b] ]In this case I was referring to the the main config as the defining config for the large scale mod in question. Addon dependencies defined in configs look for corresponding entires in cfgPatches. As long as they are present Arma does not care if the actual pbo's exists. So Arma would load fine with a ghost cfgPatchs entry. It would however, crash when you try to create a unit that points to say a p3d that is not present. So the trick to avoid this would be to prevent invalid mission content from being called i.e scope...

AFAIK you can't alter a specific class, but you can alter the immediate class it inherits from.

You are right that this is a possibility. But again, extra work, and for what?

Anyway, you can overwrite about any class in ArmA. If you create an ovewrite config that hides all west soldiers, then that is possible.

In case of ovewriting the base classes to hide them all, this is possible too, and like with your example, TeroxMod would need to have his own Tank class with scope2 setup to display his tanks only.

The problem is that many addons have setup Scope = 2; on their own in their classes, so to have a water tight system, you would have to include all the classes of vehicles that you wish to hide, and enter Scope = 1 or 0 in each and every one of them.

[UNN 0]

Quote[/b] ]Why do we have to fight this idea, and come up with long and more work involving 'solutions'

I'm not fighting anything, I have no reason to. I was interested in what the perceived problems were. If I don't understand something, or something does not appear to make sense. I can't help but ask questions

[sickboy 13]

Quote[/b] ]Why do we have to fight this idea, and come up with long and more work involving 'solutions'

I'm not fighting anything, I have no reason to. I was interested in what the perceived problems were. If I don't understand something, or something does not appear to make sense. I can't help but ask questions

Don't take that sentence too literally mate. I just meant that most off the posts in this thread throw the idea of the table as if its something negative, and come up with all kinds of 'workarounds' that would get results too, but costs a lot more work.

So I was more speaking in general