A Possible Community Approach to addon/mod making

[klamacz 448]

well, I will use Terox' suggested approach with my addon project. I'm sure I will have PM box full of permission answers and I will be happy to see my addon in big mod. It costs me almost nothing and saves my time during patching bugs and others' time when creating mod.

Do I have always fear unfair people?

Terox, sickboy and others: Thanks for this nice idea

[sickboy 13]

well, I will use Terox' suggested approach with my addon project. I'm sure I will have PM box full of permission answers and I will be happy to see my addon in big mod. It costs me almost nothing and saves my time during patching bugs and others' time when creating mod.

Do I have always fear unfair people?

Terox, sickboy and others: Thanks for this nice idea

That's a great start mate Keep it up!

Don't fear unfair ppl; they should fear you!

[terox 316]

Seems i stirred up a bit of a hornets nest due to misinterpretations of some of my comments.

I've been around the OFP/ARMA scene from day 1 of OFP

I even made an addon

I've run an OFP/ARMA community for some 5 years or so now

Ive been part of mod making teams

Our community is in the process of developing a mod

We dont advertise it, we dont look for any publicity, we dont display W.I.P screenshots, we simply get on with making a mod, developing it as we play it, specifically for our community.

Because we respect the efforts of model makers and other developers we always ask permission for use of 3rd party content, if we dont get it we dont use it.

Now because we dont pursue the limelight, most of the arma community don't know we exist.

So when we approach addon makers those who have never heard of us they regard us as an unknown entity and hesistate to offer us any pemission.

This makes it unbelievably diificult for us to create a mod that has non BIS model content. (We dont have a modelling team as such, we basically have 1 guy and a couple of others who help in that department

If we have these problems, am sure others have too, so on with the reason for this post

I'd like to explain how the proposed system would help Mod teams and even larger comunities that dont make mods but use addon packs

so lets play make believe

For the hypothetical mod, lets say we are looking for a model of a C130 hercules (Big model requiring hours and hours of work)

We have one available, lets call it Johnny's C130

and lets say it is available in only 1 of the two following configurations

1) All In One Johnnys_C130.pbo

2a) Johnnys_C130_config.pbo

2b) Johnnys_C130_model.pbo.

Lets take option 1 first, what do we do

Quote[/b] ]

1) We download the addon, run it in a test mission

a) we look for errors in the rpt file

b) we look for anything, bug wise that would cause instability

Happy with the quality of the model, we then email Johnny, with something like a standard draught letter which explains our intentions

Johnny hardly ever says,

Quote[/b] ]yes and here's the mlods, do with it what you want

.

What he normally says is yes, but you cant edit it in any way.

This ofcourse is no good to a mod, who is trying to standardise all the content, adding init event scripts etc, changing the classname, balancing weapons, armour etc etc.

What can we do, well we can create an inherited class, but that then leaves the original classname in the mission editor, which we dont want. Might not seem like an issue for only 1 vehicle, but when you multiply that by 20 vehicles and all their varients, then it does.

What a morally corrupt mod team could do is rip the addon apart, steal the model, or edit the existing config, why, well because they want the C130 regardless of the wishes of the creator

and alas Freds_C130.pbo is born or a modified version of Johnnys_C130.pbo

Because we wont do that, we simply miss out on using Johnny's C130, which is a crying shame because of the quality of the model and the effort that Johnny has put into it and the enjoyment we would get by using it in our missions

However if Option 2 config is available

Same old email

However this time, Johnny just needs to say yes, or his EULA may even state that the pbo's can be used without any additional permission providing they remain in their original state

There are no issues with the editing of his C130_model.pbo because there is no need to touch it

there are no new versions of the C130_model.pbo being created

No additional unwanted classnames are seen in the mission editor

No Mlods bouncing around the community

and the ability to create whatever config you need

I know this is put simply, but thats how simple it makes adding new content to a mod.

The Mod gets a C130

Johnnys efforts reach a wider audience

Nobody steals, modify's anything because there is no requirement to do so

and no EULA's are being broken, trust remains intact

This at the end of the day is merely a suggested approach.

and as was pointed out by earlier posts, it makes updating the config side of the .pbo much easier, not having to re upload, or add the additional filesize with the model

and If a newer and improved model comes out, it's simply a matter of downloading it and replacing the original model pbo in the addon folder

Because of the way this community is, especlially on the BI forums, let me make it very clear to those guys who like starting flame wars.

I am in NO WAY telling folks how things should be done, at the end of the day its their addon, their effort and their decision.

All i am trying to point out is, there is a different configuration that makes the addon more flexible for use. This is how many addons were configured at the back end of OFP.

This lost experience due to these established development teams disappearance has taken the BI community back to the early days of OFP and the same type of mistakes are being made again, by the new batch of addon makers

Thanks for your time and feedback

[Jackal326 1181]

The split pbo setup, (i.e. one pbo with models and textures, and one with the config), is not only a good idea for the reasons Terox has suggested previously in this thread, but there is another side I couldn't see mentioned here. The simple fact that having the config file(s) seperate to the model/textures also helps updating, to a degree anyway. Like Terox, I am not saying "This is how you WILL make your addons!", I am simply saying, that if you release an addon, and then after release find a small bug in the config that was missed during testing, its a lot easier to release a 5kb v1.01 update that fixes the mistake that its present in just the config pbo than it is to release a ~50mb that would result in a single pbo file being re-released.

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

^ quoted for clarity and context.

I think some people are misunderstanding what others are saying.

For myself I understand the idea behind the separate PBOs. We, UNN and I have previously used this method for our OFP stuff. I don’t even object to it in principle. The thing that concerns me is that this method makes the unauthorized (ie no permission) use of the addon easier. I know BIS have now taken a stance on this but there are still people who aren’t willing to follow the community’s rules.

We are happy to support other mod teams that respect the rules and our work and ask permission but you have to understand that it’s the small minority that will ruin it for the rest of the community and ignore the rules. Personally I see this ‘proposal’ as very large open window that makes that easier. I can just see several people in this community saying “yes I used your addons/models but I’m not asking permission because I’m using my own configâ€. And before someone pipes up and says “Bullshit/Bollocks/tosh/hogwash/balderdash/twaddle/piffle†etc. It’s already happened, both in OFP and ArmA.

I’ll repeat what UNN has already said,.I see no reason why creating an extra config.pbo is such a problem for Terox and co. If a mod team wants to “standardize the addon config values†and not affect the models then they will have far better results just creating their own Terox_config.pbo than editing and repackaging the entire addon just as he says. I really don’t get why it’s such an issue unless you are changing the models. Just inherit from the original class, leave the original addon intact and make your own config based mod - which is what I understand is what Terox wants to do. Where’s the issue?

[dm 9]

I think some people are misunderstanding what others are saying.

For myself I understand the idea behind the separate PBOs. We, UNN and I have previously used this method for our OFP stuff. I don’t even object to it in principle. The thing that concerns me is that this method makes the unauthorized (ie no permission) use of the addon easier. I know BIS have now taken a stance on this but there are still people who aren’t willing to follow the community’s rules.

We are happy to support other mod teams that respect the rules and our work and ask permission but you have to understand that it’s the small minority that will ruin it for the rest of the community and ignore the rules. Personally I see this ‘proposal’ as very large open window that makes that easier. I can just see several people in this community saying “yes I used your addons/models but I’m not asking permission because I’m using my own configâ€. And before someone pipes up and says “Bullshit/Bollocks/tosh/hogwash/balderdash/twaddle/piffle†etc. It’s already happened, both in OFP and ArmA.

I’ll repeat what UNN has already said,.I see no reason why creating an extra config.pbo is such a problem for Terox and co. If a mod team wants to “standardize the addon config values†and not affect the models then they will have far better results just creating their own Terox_config.pbo than editing and repackaging the entire addon just as he says. I really don’t get why it’s such an issue unless you are changing the models. Just inherit from the original class, leave the original addon intact and make your own config based mod - which is what I understand is what Terox wants to do. Where’s the issue?

Amen to that.

I think a lot of people instantly got hung up on the "zomg they are being eliteist because they dont want to share" idea, rather than seeing the real reason for the reluctancy behind it.

Just like you, and others have said, we all see that its a good system, but as always, there are good sides and bad sides to it. Until the community, as a whole and as minorities, can learn to respect the hard work of everyone - modellers, config writers, scripters, 2d artists, mission makers - this "open source" style of "permission free" addon sharing is going to be shunned by those who have been burnt before.

Its all well and good claiming "but the pbo isnt changed", but for these 4th party mods, the data is either auto-installed with an exe, or installed once in one big go and never looked at again. The 4th party part ("zomg ubercool group addon number 23423523 BY PERSON X") is the part which is seen ingame, so the credit is naturally passed onto Person X. Until this can be resolved, you will see a portion of the addon making community not wish to "contribute" to such a system.

[ryankaplan 1]

RockofSL;

Basicly all the points you make in your arguments have been counter-answered very successfully by sickboy, and you are repeating yourself in a circle that has already been catered for with long strenaous posts which I don't wish to repeat when you can scroll up.

However, there is one thing i fail to understand. How does the dual-pbo system make it use content without permission? If i wished to use your content without permission, it would not make my job of taking your content and calling it mine any less easier or difficult if you have it in a single pbo. It would however make it harder for the people who wish to make a respectful mod like me to implement it in their mod by a truckload. The dual-pbos system we're on about will still be binarised. You will still need to ask permission to use it. If some idiot does not wish to ask permission, well, we can't anything about it, just like the situation is right now.

Quote[/b] ][Just like you, and others have said, we all see that its a good system, but as always, there are good sides and bad sides to it. Until the community, as a whole and as minorities, can learn to respect the hard work of everyone - modellers, config writers, scripters, 2d artists, mission makers - this "open source" style of "permission free" addon sharing is going to be shunned by those who have been burnt before./QUOTE]

As yet again, I know the thread may involve long and boring posts but please read the thread. There is no mention of 'Open source, Permission Free' material at all, whatsoever. No mean to be disrespectful, but i feel as though i am replying to the same argument over and over again...

Until the community, as a whole and as minorities....

'The community' is a social construction of ArmA players. 'The community' is not a whole, or one. Just like in any society, there are ones who comply to the rules and there are not and in our case, you can't do much about it other than binarise your creation. We are not asking you to not binarise. I get the impression from you that lately the 'The community' has been thieveing and misbehaving. I don't wish to be put in the same box as the minority who doesn't comply or listen.

Quote[/b] ]Its all well and good claiming "but the pbo isnt changed", but for these 4th party mods, the data is either auto-installed with an exe, or installed once in one big go and never looked at again. The 4th party part ("zomg ubercool group addon number 23423523 BY PERSON X") is the part which is seen ingame, so the credit is naturally passed onto Person X. Until this can be resolved, you will see a portion of the addon making community not wish to "contribute" to such a system.

I don't understand this bit, please clarify.

[dm 9]

However, there is one thing i fail to understand. How does the dual-pbo system make it use content without permission?

... ...

As yet again, I know the thread may involve long and boring posts but please read the thread. There is no mention of 'Open source, Permission Free' material at all, whatsoever. No mean to be disrespectful, but i feel as though i am replying to the same argument over and over again...

The whole premise of this thread and the reasoning behind Terox's suggestion of the dual pbo system is to remove the need to ask the authours permission to use the content. Since, with this "system" the original data pbo (i.e. the one with the models and textures in) will be un-changed, even if it is re-packaged in a 4th party mod, therefore permission to edit it isnt required.

(You can argue until you're blue in the face that you would always ask permission before using something, but the whole opening of this thread hangs around the quotes:

It would solve a lot of "Permission" issues

and

This would make your model a lot more available to the community as a whole

and

It would reduce a lot of "Asking permission" issues

and

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

which suggests to me that Terox wants people to make addons in such a way that it is "easier" to include in his and/or other mods without the need to overwrite/hide or otherwise edit the existing config. And that content should be developed in such a way that permission to use it in such 4th party mods is not required, because clearly the only way to get your addon to the wider community is via a 4th party mod (interpretation of the last quote there).)

The way I see it, is that this system is being pushed here NOT for the advantages it gives when fixing bugs in a release, but more to make it easier for the 4th party modders to pick and choose which models they use without having to bother with the config (and therefore "easier" to re-use).

And yes, I read the thread word for word from the start, and the start is the important bit. (Also, try not to be so condescending, its not very polite or helpful for the cause )

Quote[/b] ]Its all well and good claiming "but the pbo isnt changed", but for these 4th party mods, the data is either auto-installed with an exe, or installed once in one big go and never looked at again. The 4th party part ("zomg ubercool group addon number 23423523 BY PERSON X") is the part which is seen ingame, so the credit is naturally passed onto Person X. Until this can be resolved, you will see a portion of the addon making community not wish to "contribute" to such a system.

I don't understand this bit, please clarify.

Clarification:

The end user doesnt give a crap about what the pbo is named. The end user see's the 4th party mod's logos ingame, and the 4th party mod's website when downloading. Therefore, the end user will, the majority of the time, associate credit for the content to the 4th party mod.

People make addons for 2 reasons:

1. Because they like whatever it is they're making an addon of, thus want it in game.

2. Because it helps their clan/group/whatever with some extra features an functionality.

People release addons for 2 reasons:

1. Becuase they have a feeling of community spirit, or like to share their work.

2. For the kudos. Deny it all you want, but deep down, everyone loves a good ego stroking, and having people go "dude sweet addon!" is part and parcel of that.

[Guest RKSL-Rock]

RockofSL;

Basicly all the points you make in your arguments have been counter-answered very successfully by sickboy, and you are repeating yourself in a circle that has already been catered for with long strenaous posts which I don't wish to repeat when you can scroll up.

Seriously, what part of “repeating for clarity and context†doesn’t make sense?

However, there is one thing i fail to understand. How does the dual-pbo system make it use content without permission?

The point is about recognizable credits. Read on and hopefully you will see what I mean. The concern is that once the model is absorbed in to the “Config based Mod†it will lose its identity (ie made by XXXX Addon Team) and be miss credited with New Config Mod Team’s Creation.

Given how much time the average addon maker spends on addon creation I doubt any of us would be happy with that.

As yet again, I know the thread may involve long and boring posts but please read the thread. There is no mention of 'Open source, Permission Free' material at all, whatsoever. No mean to be disrespectful, but i feel as though i am replying to the same argument over and over again...

Re read Terox’s post and have a think, read between the lines and have a think about how this might be manipulated by that small percentage of the community who consider themselves to be above the community’s rules and courtesy.

We are discussing the idea and the possibilities of Terox’s suggestion that goes beyond what is actually written. Think about what is implied. Frankly it’s not too different from the old/existing situation. Just this method makes it far easier to strip away the actual author's identity.

'The community' is a social construction of ArmA players. 'The community' is not a whole, or one. Just like in any society, there are ones who comply to the rules and there are not and in our case, you can't do much about it other than binarise your creation. We are not asking you to not binarise. I get the impression from you that lately the 'The community' has been thieveing and misbehaving. I don't wish to be put in the same box as the minority who doesn't comply or listen.

Members of this community have been breaking this “social construction’s†rules for a very long time. I see BIS’ recent public announcement as positive thing for the community and finally the ‘protection’ of my own and other people’s work and efforts. We all want credit for the work we do, its human nature. Is it so much to ask for respect and acknowledgement? This idea, while it has its merits also has its downsides. It may make life easier for some “honest†mod makers but it also has the capability to strip the addon makers of their recognition (which is their only payment) if abused. You can just look at the early releases of FFUR to see that. If it wasn’t for a few people complaining some you wouldn’t have seen proper credits and sources listed. Even now large parts of the non addon making community refer to the RHS Hind as the FFUR Hind and various other addons as FFUR's creation. Its been a hard and bitter fight against “theft†and “piracy†in this community. If you want good quality addons there is a price to pay and that price costs very little. Its common courtesy, respect and patience.

Some people are willing to pay it. Other people just don’t give a damn.

I don't understand this bit, please clarify.

DM is referring to the fact that this whole issue revolves around giving the addon makers due credit. By taking the models.pbo only, stripping away their config, tags etc you are removing the original makers identity. The Mod compilers then add their own tags and are seen by the general public as the makers of these addons. It was seen repeatedly in the case of FFUR and lots of other ‘mods’.

[UNN 0]

Quote[/b] ]Basicly all the points you make in your arguments have been counter-answered very successfully by sickboy, and you are repeating yourself in a circle that has already been catered for with long strenaous posts which I don't wish to repeat when you can scroll up.

Actually that’s not exactly true. Although this is a complicated thread to follow, seen as it's running multiple topics:

How can addon design best facilitate large scale fourth party config MODs.

How can addon design best facilitate the addon makers.

Along side those two topics you also have the issues of:

Large scale fourth party config MODS having trouble obtaining permissions and access to use third party addons

Individual addon makers seeing their work being credited to somebody else's MOD

If you look at each individual topic on it's own, then you can see where the conflicts lie.

How can addon design best facilitate large scale fourth party config MODs.

Of course anyone who is interested in, or creates large scale config mods, will see the benefits in Terox's proposal. It makes their life easier and requires them to do less work to produce their config mod. Many of the replies have been centred around "it makes more work for us, so why not do it this way".

While It's not unreasonable to want make the things you enjoy doing, easier and more efficient. It is unfair to expect individual addon makers to shoulder that burden.

How can addon design best facilitate the addon makers.

I can only speak for myself on this topic. But I think breaking down addons into multiple pbo's causes major headaches when it comes to version control. Large scale config Mods do not have to worry about version control, they release their work on mass. Individual addon makers do have to worry about version control. So again, I by default will prefer a method that makes life easier for myself, as an individual addon maker.

Large scale fourth party config MODS having trouble obtaining permissions and access to use third party addons

I think Terox has covered the problems he faces with regards to permissions in his original post? As I've never made a large scale config Mod, I am not going to presume to know the problems involved. So I can't add anything to this.

Individual addon makers seeing thier work being credited to somebody else's MOD

ryankaplan should have been around long enough to notice how someone can be credited with an addon simple because they were the last person to modify the original config.

I've lost track of the threads I've seen were someone, in all innocence, has posted a modified version of an existing addon. Despite the fact that the person releasing the modified addon, repeatdly credits the original addon maker in his initial post. You only have to scroll half way down the page before you find a string of post congratulating the guy who modified the config, for making such a great model.

Like I said, the guy who modified the config never tried to deceive anyone or lay claim to someone else’s work. Only not everyone reads the readme or reads beyond the download url, in the original post.

Some people may think this is a trivial matter, but when you have spent months (perhaps years) working an individual addon. It can be very disappointing to see your efforts being swallowed up by some glitzy ad campaign for the latest config mod.

I think it's safe to say, reading the posts in this thread that:

There is not one solution that works for everyone

So the natural conclusion should be to cooperate in finding some sort of compromise for everyone's requirements. While it might not be the ideal solution for each party, it can't harm to talk in a calm and rational manner, about how we can try to help each other out?

[-AIF- Kris 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.

Once more

[ArmaVidz 0]

<span style='color:olive'>@ryankaplan</span>

How many times do you see a mod with a splash screen listing all the model maker's names in a awesome way? How many times do you see mods with a cutscene style credits list kinda like what I have at the end of my videos? Never. You see "BlahBlah Mod." - A faceless inclusion worth absolutely...nothing in my humble opinion.

The only way you could ever work around this, so that 'borrowing and adding a new config' will ever be worthwhile for a addon maker, is if they model their name right into the model which shows up in the game. visible somewhere on the model...

This is one of the reasons I actually got into the Arma/video thing...these guys deserve better than their name in a text file, that, for the most part, is skimmed over, or not read at all.

...in my opinion.

[Synide 0]

@UNN... that's a nice read...

How about a small quick 'project team' is setup of some guru individual addons makers and some large scale config modders.

Objective, to produce a small 'crediting' package that can be seamlessly included in large scale config mods. Individual addon creators would include certain config info in there standalone addons that the 'crediting' package (you could even make the addon dependent on the crediting package) could display when appropriate.

Individual addon makers could say, yip you can use my addon in your mod, but only if you're using the 'crediting package'.

And, then have your seperated config for the large scale modders to inherit from or subsume. dunno, just a thought or some similar type of structure.

invariably in communities like this, one ends up with 'best of breed' and 'the cream rises to the top' senario's when it comes to addons and mods.

here's an example...

mod team a - has some of it's own quality stuff, but also includes 15 'best of breed' individual addons.

mod team b - has some of it's own quality stuff.

while both mods are high quality - by virtue of evolution - humans invariably end up gravitating toward Mod Team A's collective effort...

[max power 21]

@UNN... that's a nice read...

How about a small quick 'project team' is setup of some guru individual addons makers and some large scale config modders.

Objective, to produce a small 'crediting' package that can be seamlessly included in large scale config mods. Indiviual addon creators would include certain config info in there standalone addons that the 'crediting' package (you could even make the addon dependent on the crediting package) could display when appropriate.

Individual addon makers could say, yip you can use my addon in your mod, but only if you're using the 'crediting package'.

And, then have your seperated config for the large scale modders to inherit from or subsume. dunno, just a thought or some similar type of structure.

invariably in communities like this, one ends up with 'best of breed' and 'the cream rises to the top' senario's when it comes to addons and mods.

here's an example...

mod team a - has some of it's own quality stuff, but also includes 15 'best of breed' individual addons.

mod team b - has some of it's own quality stuff.

while both mods are high quality - by virtue of evolution - humans invariably end up gravitating toward Mod Team A's collective effort...

That sounds like a solution for some individuals or teams, but not for a whole community. Not that you were implying that it was. A lot of the suggestions and arguments in this thread sound reasonable, but noone can expect the entire modding community to practice under one convention as TOP suggests.

[sickboy 13]

The only thing I will add:

You guys seem to claim that it's not as easy to take your work, if the config is inside the same pbo as the models/textures.

This is completely wrong.

I understand the need for protection, credit where credit is due, etc. etc. But you do not achieve this through keeping your config in your huge pbo!

There are other methods available, and I think it's a discussion for another thread. As it's a whole different discussion. It's a discussion about how to achieve the proper crediting and knowledge to users about who made an addon that might've been included in a fourth party mod.

AFAIK the main reason for Terox requesting the split development method was not to have all kinds of different versions of pbo's hanging around (Yes, he brought up other positives about the method too, but unimportant imho). Users probably downloading the same content over and over, just everytime with another setup due to configs.

We can turn it around; You truelly believe that keeping your config inside your huge addon, will scare mod makers away in including your work in their mod (with request for permission)?

I say NO, because us modders haven't done anything else but this method:

[*] Cool addon comes out

[*] PM Gets sent to ask for permission to include

[*] Permission is given

[*] Addon config is ripped apart and split over Mod config, tweaking and changing values to fit in the mod

[*] Readme is included in the mod package

[*] Proper Credit is given in Mod Readme and changelog

It has been no different in OFP either for me.

Again, the discussion about how to make it more aparant to users, who made this and that addon, is IMHO an entirely different discussion, and applies to any method used to create/distribute addons.

[ArmaVidz 0]

Again, the discussion about how to make it more aparant to users, who made this and that addon, is IMHO an entirely different discussion, and applies to any method used to create/distribute addons.

Exactly, I agree. That sums it up completely.

Objective, to produce a small 'crediting' package that can be seamlessly included in large scale config mods.

Now that's a great idea. EditBecause you know they'll do it anyway...proper kickass credits at least show who did what.

[ShadowY 0]

Luckely we are all stupid and we can`t tell what addons are included

[terox 316]

If someone wanted to go down the disrespectful path of ripping anothers work off, there isn't really a great deal you can do about it apart from perhaps binarising it.

As for the argument that splitting the addon into 2 pbo's will make it easier to copy and resell as ones own work. Think about it, why would it make it any easier, both systems use pbo's, there is no difference in debinarising, hexediting the pbo's in whatever configuration they come in.

What makes a difference is Why they feel the need to do it.

Releasing a pbo in seperate model/config format makes it less likely that they need to edit any of the original work

Firstly they can create their own config.pbo for it without editing or using the original config

secondly, there is now no need to edit the model.pbo to repath the textures, its far easier and much less work to leave it in its original.pbo and plonk it in the addon folder

(This i think is the important factor that will reduce the need for folks to rip addons apart)

As for credits, is not having the orginal johnnys_C130_model.pbo in the addon folder and and an entry in a readme Credit's section enough ?

I can only speak for our team, we dont run any spash screen with any credits for anybody, including ourselves. We dont particulary see the need to print text on screen that says "This mod was made by XXX, YYY, ZZZ otherwise we would be watching the spash screen for quite a while, like the end of movies. Does anyone remember the names of anyone that is posted at the end of a movie during the credits ?

We do have a readme and in that we do post credit where credit is due, which in some eula's is infact a requirement for use

As for the permission issues, most addons come with some form of eula. Most of these eulas give permission to use the pbo's in their original unedited form. If the Eula doesnt give permissions such as that then ofcourse any decent repectable developer would seek permission.

Quite basically if the addon is released in 2 seperate parts, then there is absolutely no need at all to edit either pbo unless you wanted to rip the addon off and resell as your own work, and you aint gonna be able to stop that anyway regardless of how it is packaged

The only way really to punish someone who does that is either take them to court, or publicly flame their mod or their work on the forums and maybe get sites like OFPEC, Arma.info to refuse to distribute it for them

I personally believe that if the eula was written well, the addon was released in 2 parts, then a lot of the issues involved with useage, copying work etc would be reduced considerably and as a community we would see far more content in the mods.

At the end of the day we all love playing ARMA, we all love seeing and using new kit, exploring tweaks inn gameplay thats why we all do this work.

If thats not the reason, then you must be doing it for commercial reasons and thats a whole new ballpark.

By releasing the addon in the way i initially suggested doesnt make it any easier or harder for those intent on stealing the glamour of som ones creativity in any way shape of form

However it makes it much much harder, requiring far greater effort and time for those who respect the initial author and want to do right by them

[Romolus 0]

I honestly don't see the problem here.

If the only intention is to make it easier to reuse addons within the permission given by the original creator, then your suggested system doesn't seem to help much.

Even if someone releases an addon split up into two pbos like you suggested, it's still one released addon. And if you ask this person if you could use his work and he tells you that you can but without changing the addon, then this permission doesn't include just taking and redistributing a part of the addon.

Obviously if someone releases an addon with a config, he wants to have the addon just like that. Including the model, the textures, the config and even the readme or the documentation that comes with the pbos.

So if you really want to honor this permission, you actually have to include the whole package and not just a single file because it fits better with what you want to do.

Same with the addon showing up in the editor.

What's the problem with the original addon showing up in the editor?

If you're creating a config mod that includes other addons, it shouldn't be a problem organizing your units in meaningful categories that show up in the editor without much clutter, so that a mission designer can use just the units of the config mod.

If you're using someone's work and really want to honor it, why not just leave it there in the editor to be seen and played with just like the original creator intended? By hiding it, you also take away some of the credit.

On the other hand, if you really asked and got the permission to take apart the original addon, leave away the original config, readme and whatever comes with the addon that you don't need or want, then what's the effort for just opening the original pbo, altering the config and packing it up again?

The original creator spent months and gave you permission to use his addon and you're really complaining because of those maybe 10 minutes of work you have to do yourself?

You don't even have to change the name of the original pbo and repath the models since as you're changing the configs anyway, you're obviously not interested in the original ones, so there's also no point in making your config mod compatible with the original addon. If you keep your config mod in its own mod folder, there shouldn't be any harm done.

So all in all:

If you get permission to take apart an addon, then the work that needs to be done to integrate addons in your config mod is minimal compared to the effort it took to create the original addons. Not much to complain about in my opinion.

If you don't get permission to take apart an addon, then the suggested system won't help since you're already violating the granted permission by only taking parts of an addon as you please.

[sickboy 13]

Quote[/b] ]The original creator spent months and gave you permission to use his addon and you're really complaining because of those maybe 10 minutes of work you have to do yourself?

Since when did this became a ModCreater vs AddonMaker amount of work contest? The addon maker maybe works his ass of for months on a single project. Well we got news for you; Mod makers work their asses off on their project for months, maybe years too!

What is the objective of a full mod in usual cases:

Creating a harmonious project which includes the work of many many many many others, which is streamlined, made compatible, double features eliminated, and the list goes on...

You could also say that if there was a more general addon template available, and more addon teams would work together on general values, and integratable addons and what not, the whole need for FullMods would deminish pretty quickly.

Also, last time I checked, this wasn't about the time or effort involved because both are quite equal. (Removing config from original pbo, or just leaving the config pbo away)

The main plot was "Not having multiple variants of the same big pbo with the same models, just another config" drifting around the vast areas of sp....ehrr internet. (All that came after that or next to it, was all extra reasons and extra positives, and noted negatives etc.)

On which others started answering "there are 100's of methods to work this out", on which we all replied that those options would make for a lot of work, and had all kinds of other downsides.

Then there is of course the whole debate about visualizing credit for models and addons made by others, but as said, this is a whole different kind of discussion, and if its found important enough I would say create another thread and discuss how this can be improved!

Anyway, if you ask me, we're talking here against a big iron wall.

Drop the words Permissions and small change in development strategy for the better of themselves (yes config+scripts in a seperate pbo is beneficial under most circumstances, even to the original creator! and the whole community, and suddenly everyone looks at you as if ur a Thief, and you're making water burn.

This was my last entry in this thread, unless there's some serious difference in how this is looked at.

[Romolus 0]

Since when did this became a ModCreater vs AddonMaker amount of work contest? The addon maker maybe works his ass of for months on a single project. Well we got news for you; Mod makers work their asses off on their project for months, maybe years too!

No need to get agitated here. With no word I was comparing the amount of work it takes to create mod vs an addon.

What I was comparing is the work it takes to use an addon in your mod and its alternative: To create the addon for your mod yourself.

If no one creates the addons (and spends the time) that you want to use for a config mod in the first place, the only way to create your mod is to create the addons yourself. So by using existing addons you trade in spending months of work for an addon for the few minutes it takes to change the config and pbo the addon. That's the difference I was talking about.

What is the objective of a full mod in usual cases:

Creating a harmonious project which includes the work of many many many many others, which is streamlined, made compatible, double features eliminated, and the list goes on...

You could also say that if there was a more general addon template available, and more addon teams would work together on general values, and integratable addons and what not, the whole need for FullMods would deminish pretty quickly.

Well, if you followed the OFP modding community, you probably know that there were efforts in that area, but most time they failed because people just had different views. If you like it or not, but if someone creates and releases an addon that doesn't work well together with other addons, most time it's because he wanted it to be just like that. There is no obligation to make your work compatible with the work of others.

And there is also no right to do what you please with the work of others just because you spend an equal amount of time for your own work. By using the work of others, you still save the time of doing it yourself, no matter how long you spent on the rest of your project.

Now about having tons of incompatible addons:

Isn't the reason why most people create config mods, because they aren't content with the individual addons they get from other people? So what that actually means is that you come up to someone who has spent quite some time to get an addon exactly how he wants it to be and tell him:

"Hey, I don't really like the whole addon of yours, but I really do like some parts of it. Can I please take the whole thing apart to use it the way I think it should, instead of making the effort and redoing the whole thing myself?"

Can you see how people might get offended by this?

If the original creator thinks your idea is great or if it was only inability that made the addon so incompatible, you probably won't have any problems getting the permission to take it apart.

In that case, I bet that the creator wouldn't even have anything against redistributing an updated version of the original addon, which according to what you just wrote should be even better than just including it in a config mod.

Also, no one really hinders you to create a full mod like FDF or others, with your own models, textures and configs that work beautifully together as a complete pack with a campaign or some missions. All you have to do is to suck it up and spend the time that is needed to get it done.

If you don't want to spend the time, then you have to arrange yourself with others and be prepared to make compromises. Which includes respecting the wishes of the people who you work with.

So even if you just want to talk about making addons compatible with each other or getting rid of multiple versions of an addon, it still boils down to working together with others and therefor getting permission or paying respect.

If you don't want to hear about those things, then you're free to do your own thing without much discussion, like I explained further up. No need for all those things if you do all the work yourself.

Even if the whole community puts up some rules about how addons have to be compatible to each other, there's no real obligation for anyone to follow those rules. If someone likes to do things different, it's their choice, since it's their time they are spending.

Every discussion about how practical it would be if that was different and how all could work nicely together or how much easier it would be for some people is moot since it doesn't even touch the real reason why things are as they are:

People like to do things their way, so deal with it or do it yourself.

[.kju 3245]

Even though many well respected people discussed in here..

Sorry it was no fun to read the whole thread..

Can someone please open a new thread called:

How to improve PBO and config structure?

Let me quote one thing here please:

Quote[/b] ]Special features of the PROPER Mod

Every addon released by the PROPER Mod team has a special structure to allow people analyze our work and learn from it.

Features in detail:

* Simple, feature specific addon.

This means that every logical change is separated into one single pbo to make the changes very clear and easy to understand.

* Advanced inner structure.

Each addon contains a single config.cpp. This file only points to the rest of the content via #include statements. Textures, sounds, config values are separated into various subfolders. Configs are separated into at least into cfgPatches.hpp and Core.hpp.

* Documentation.

The Core.hpp (to be found in the \h subfolder) contains (technical) comments at the top about the changes done by the addon. Sometimes even additional information about config values are described.

* Study and learn.

PROPER Mod addons aim for high (technical) quality and (hopefully) no errors to be found in the ArmA.RPT. So for example more complex topics like working class inheritance and properly updating existing class can be found in our work.

Lets be honest. We have many very talented modders here. Yet

most of them are not into config and pbo editing. You can bet

they would be very happy to get more information

and guidance how to design their addons best.

Splitting sound files, textures, models, configs, script should be

common practice - unfortunately it is NOT. Help to improve the

situation.

Thank you!

As for your discussion about permission etc:

1) Add a readme with copyright information (hey many people

like to have their work used and reused - can you believe that )

2) Add your copyright inside the pbos.

3) Binarize your model.

[sickboy 13]

Q for President

@Romolus:

I still have the feeling as if we're both speaking about 2 different things.

The core of this thread was:

How about we all create the addons with models+textures in a pbo, and the config/scripts in a pbo

The reason was:

Addon Maker

[*] Easier to update just config and or scripts

Mod Maker

[*] Instead of stripping the config from the pbo, and creating another version of the pbo (with exactly the same content, just without the config, because the config parts are sucked up in the main mod's config), we can just leave out the config pbo and as such there is no extra/alternate version of the pbo flying around the net.

Thats the whole thing, nothing more, nothing less.

[*] Permission discussion has nothing to do with this, really, there is _NO_ change whatsoever, it isnt more easy, it isn't more hard! Permissions must be dealth with, every single time.

[*] Amount of work has nothing to do with this. Besides, in the end it is deemed easier for all parties involved

[*] Views and Opinions on how the config(values) should be, has nothing to do with this.

[*] There is no discussion needed about "Maybe the addon maker setup his addon especially this way because he doesnt want it to be compatible with others". Because if he believes so truthfully in his method, he would not give the permission to us to use his work and tweak it to our tastes.

We all know we can make stuff ourselves, and we all know that everyone is different, have their own opinion and views on things; and hell, thats everyone's freedom!

This fact makes it IMHO necessary for guys like me to create full mods that group all the greatest addons together, and make it all compatible to eachother and beautifull working together.

Because for the end user, and especially multiplayer communities, it's a true biohazard out there;

[*] Inconsistent class names, and what if we want to replace TeamA t72 by TeamB t72, You must: edit every mission, change addons/addonsAuto arrays, change classname to new ones. In a universal framework, no mission editing has to be done whatsoever! We replace the used model in the mod's class and voila!

[*] tankA fires 1 shot on tankB and destroys tankB, while tankB must fire 35 shots to destroy tankA, and so on and so on

These are just very simple examples, but the list is endless)

Why o why are we discussing every aspect that has nothing to do with the original idea. And why can't we just share our opinions, views and maybe better ideas on the topic at hand?

Sounds to me like that there are still unresolved issues and frustrations, maybe even dating back to OFP-era. But I dont understand what they have to do with Terox his request. Maybe the other issues and frustrations can be resolved in their own thread?

[Romolus 0]

@Q: Many important things aren't really fun. I agree with you that config info is sparse and that many people would appreciate if they could learn a thing or two. But such a thread might be best opened in the config forum and kept technical right from the start. Unlike this one.

@Sickboy: I don't think we're actually talking about different things, only that you try to put the thread into a more technical tone than it was started in and ignoring the whole rest of the starting post.

The original post had quite a one sided perspective from the point of config mod makers and others just pointed that out.

Obviously the permission thing does have some relevance to the original poster because it is mentioned a few times in the original post. So I can't see how you come up with the idea that it doesn't have anything to do with this thread.

If you read the original post, you might find that the core of it was to explain to addon makers that by separating the config from the model and textures,

their modelling work could be available to a more widespread audience

that

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

and how integrating the config with the model fails

during the inclusion to a Mod

This is what the original post was about and it includes the permission stuff that others commented on and you don't want to talk about.

People pointed out that from an addon maker perspective, the reasons mentioned in the original post might not even seem so fortunate and that's what the whole discussion was about.

So maybe it's the other way round and the technical discussion needs a separate thread like Q suggested?

Also the issues mentioned in the thread are actual issues as Placebo's post in the addon forum shows. Those aren't old grudges from OFP times. Ignoring them and trying to drag such posts onto technical ground doesn't solve them and maybe makes things even worse.

Actually, as I tried to point out, I think those issues are part of the problem with incompatible addons. I doubt that addons are incompatible because their makers didn't know better.

So I think that for someone who tries to make them compatible with a config mod, should take those issues very serious and not just trying to concentrate on technical details.

Even if those discussion aren't fun to read, I really think they are necessary and provide a way to solve things as long as people are open minded and don't just ignore each other.

[sickboy 13]

Okay, then I haven't read Terox his post well enough and made wrong assumptions and conclussions.

I guess it's more about what I believe this was about, which seems to be wrong.

I have very little more to add.