A Possible Community Approach to addon/mod making

[.kju 3241]

So I hope you guys still have enough energy to start the technical

thread and merge the results in the wiki.

Like Sickboy has done here:

A view on Multiplayer Scripting

Will words be followed by action?

Give yourself a go.

PS: While you are edit it, you might wanna kindly share your

knowledge on this one too:

Model data to judge ingame performance, What data is useful in ArmA?

[terox 316]

Potentially yes, a technical thread may be best suited, but it will probaly veer off at tangents again

seems my line of "Permission issues" was incorrectly inerpretated by some, and yes it really doesnt have much to do with this thread as thats a personal issue between the original creator and the mod team, although it does have some bearing on the complication s of integrating an existing addon into the mod

In my opinion The ideal system needed is:

a) Ability to add a pre existing model to a mod without having to edit any files

b) Define it's characteristics (config settings) in a way that creates equilibrium throughout the mod, this includes altering settings such as:

<ul> * ballistics

* armour values

* classnames, following the mods classname structure

* armament specs

* init events handler

to name but a few

c) The NON inclusion of the original addons characteristics

d) How to credit the initial model creator

For those of you who don't see the issue of having the original addon config available in the mod's mission editor vehicle classes, I can only assume you havent actually been involved in creating the tidy structure of a well laid out mod.

Without going into specifics, it will create a disorganised looking mess and makes available vehicles for the mission structure that are unbalanced, it also creates additional scripting issues which use such functions as the "format command" etc

For example lets say we run a format command for weapons, ammo script and the mod uses the weapon to mag classname distinction of MyTag_M16 and MyTag _M16mag

This isnt really a ideal practical example but may give insight into 1 of many issues

Quote[/b] ]_unit = _this select 0;

_command = format ["%1 addmagazine %2mag" _unit, primaryweapon _unit];

Now the original addon weapon name was "Johnnys_M16A1" and the corresponding magazine name was "Johnnys_M16_20rnd556x45ball"

The script then requires a multitude of

If(******) then{******}; and the whole concept of optimised mod scripting can become far more difficult because the mod has to cater for unwanted classnames that may well not work within the mod.

No matter how well you try to guide the mission maker into using mod only classes, if there is content available in the mod via a 3rd party addon, some will use it.

and what if we simply want to use a very very good sniper model from 1 pack and no other units, will we end up with someother_addon rifleman in our US Marines fireteam carrying some uber elite sniper rifle that is configged to fire a weapon outside our balanced AI engagement ranges

So it's much more effective, far better organised to leave this content out, yes leave it out completely, not scope 1 it, which requires in most cases tampering with the original file. This is something that should be avoided.

Now lets look more closely at permissions

Addon EULA

Comes with the readme, in most cases expressley prohibits the altering of any files.

Often allows the useage of such files without additional permission providing they remain intact

Often comes with an email contact address

If the creator wants to expressley forbid or allow something, this is the place to write it

Asking permission to use it in the mod

At the moment this comes with various levels of requirement

1) use the addon as is

2) Use the addon without the config

3) Export only the model to a mod pbo

99% of the time, the only authorisation that is given, is for request 1

Issues with request 1 has already been stated

Issues with request 2 are

<ul> creation of duplicates of the original and redistribution

additional workload in updating of the mod should the addon maker release a patch or updated version

much more

Issues with 3 are

<ul> Initial creators work is obscured by placing the model in a

MyMod_Vehicles_models.pbo

To be done correctly by the mod team, requires original MLODS and creates possible potential security /unauthorised copying issues for the original creators work

If the initial creator volunteers to create a customised pbo for the mod team (which is unlikely due to the workload involved) This will then have to be redone every time the model is updated by the original creator

The split PBO avoids all of this

<ul>Johnnys_C130_model.pbo remains intact as was intended in its original unedited by anybody, Johnny state

It's available for all to see in the addons folder

It's characteristics can be tweaked edited to whatever extent the mod team need to cope with their requirements

There is only the correct, original version of Johnnys_C130_model.pbo in circulation or the config version

The mods much happier

The addon maker is more assured of credit where credit is due, because his model remains visible for all to see in its original pbo

Updating becomes easier

Potential for unauthorised editing hasnt changed in any way

Mods dont need to sopend days/weeks trying to add their own version of the c130, which allows them time to work on other stuff.

More content becomes available to a wider audience

Less requirement for folks to say "Stuff this, w'ell rip the model off" because all this political mumbo jumbo just gets in the way and delays us for weeks, months

lots and lots more issues that havent been discussed

EULA could simply state

The model can be used without the config for implementation to a mod providing that **********

or if the model maker does not want to reach a wider audience

he can simply state the model can only be used in conjunction with its original config

#or simply contact me via email to discuss authorisations for useage

Only those that want to do right by the initial creator take heed of the EULA,

so any discussion about thieves copying the work makes for little argument in how to best support the legitimate hard working respectful teams with the community that are trying to bring you enhanced gameplay.

<span style='color:blue'>The combined config only affects those who want to use it legitimately and it effects them in a negative way to such an extent it in most cases prevents them from using the great model that Johnny created which is a crying shame because Johnny probably wants them to use it but doesnt want them to have Mlods and hasnt got the time to create a customised version for them</span>

Maybe as an addon maker you should be asking yourselves why you would not want to use a seperate model/config pbo setup rather than an all in one pbo when the seperate file system has proven itself to work well in the past and the all in one system is down right awkward for any team that wants to show the utmost respect to the original creator.

I cannot see a valid reason that hasnt already been argued with

[UNN 0]

Quote[/b] ]Can someone please open a new thread called:

How to improve PBO and config structure?

I would certainly be interested in hearing opinions on version control, that does not undermine the structure of previously made user missions.

Quote[/b] ]Splitting sound files, textures, models, configs, script should be

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

situation.

If someone makes, say a tank addon. Should they have separate addons for the sounds, textures, config, p3d and scripts. Five pbo's for just one addon?

Again thinking of version control. Five addons does seam a bit excessive for one tank?

With regards to the length of time it takes to make a single model, config, textures, scripts, sounds e.t.c verses a fourth party large scale config Mod.

Please take into account that, there is only one large scale config required for a fourth party mod. There may be 30+ individual addons included in that Mod. So in effect, you are saying that a large scale fourth party Mod is the equivalent to, if not more than, the amount of man hour that goes into 30+ addons?

To me, the maths just don’t add up!

[.kju 3241]

Quote[/b] ]version control

Of pbo releases right?

Well overall it depends what you want to achieve in detail

Quote[/b] ]If someone makes, say a tank addon. Should they have separate addons for the sounds, textures, config, p3d and scripts. Five pbo's for just one addon?

Again thinking of version control. Five addons does seam a bit excessive for one tank?

Definitely. Proper version control on the modder side is done via

subversion. Even a local repository is a must IMHO.

Lets take a simple example. You are tweaking any part of your

addon, I would prefer to build only a small part of it rather to

wait to build the complete pack again and again.

Time is too worthy to be wasted here.

Sort of related. A copy and paste from our forum if you don't mind:

Quote[/b] ]Further to the componentised idea, how about embedding a version array into each module which can be retrieved with getArray? The approximate code would be:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// Get the version for this component

_my_version = getArray(configFile >> "CfgPatches" >> "ACE_mymodule" >> "ACE_version"));

// Attempt to fetch the version of a component we interact with

_module_version = getArray(configFile >> "CfgPatches" >> "ACE_module" >> "ACE_version"));

if (count _module_version == 0) exitWith {}; // Module not present

if (_module_version select 0 > _my_version select 0) exitWith {

player globalChat "Incompatible component detected (other module), get a newer version of (this module)";

};

The idea is that we have a major and a minor version. If we break the interface (change a class such that scripts/missions will break), we bump the major number.

This is just an "off the top of my head" idea, so it'll need some finetuning.

and

Quote[/b] ]As my scripting understand is quite limited other should contribute to this topic more preferably,

however I try to give a few (more general) thoughts.

We have think of different levels here. Server admin and end user.

A server admin wants to ensure certain things. Is the checkfile and verifySignature system good enough for his needs or does he need additional tools?

The end user has various desires:

a) Do I have the latest version of (each or xy) ACE (component). Yoma's download tool sounds like the best opinion here.

As the system needs to be KISS (keep it simple and stupid). Any solution which requires too much user interaction will fail.

b) Can I use component X without Y. Or what does component X need.

Here such a system sounds useful to me.

We can fulfill this with good documentation too though.

From my a bit limited scripting understanding the idea here is much more suited for a conditional activation and behavior system.

Like if you have component X active, do this; if not, do that.

Or check if an addon (pbo) is present and have a different behavior based on the check.

In the end we want to have our components as modular as possible.

This means a script compilation added to the mission itself is the most modular one.

We should consider to support even this level - if the additional work is limited enough. For this we need a generic design to support all worlds and a system to have the component behave the way it is desired.

So think of:

a) ace_stamina_sys is inside a mission

b) ace_stamina_sys is single file pbo component without dependencies.

c) ace_stamina_sys has an affect on other components.

d) ace_stamina_sys requires other components / files?.

So for this kind of dynamic interaction we could use such a (from the general idea here enhanced) layer.

[UNN 0]

Quote[/b] ]Of pbo releases right?

Yeah, we (@RKSL) are looking at introducing smaller components over a period of time, while still keeping each addon stand alone, where possible. So version control of pbo’s gets a little more complicated and we have to go to extra lengths. But I will continue this on the ACES forum, as I've already read the thread you're quoting from, I just didn't have time to add anything there.

Quote[/b] ]Lets take a simple example. You are tweaking any part of your

addon, I would prefer to build only a small part of it rather to

wait to build the complete pack again and again.

Time is too worthy to be wasted here.

I understand about breaking a large MOD like ACES into modules. As Rock said, we are doing the same at RKSL.

But the thread was really about individual addons, which may or may not, eventually end up in larger MODS. It kind of seem a bit over the top to suggest using the same approach for a single unit, released by one addon maker. The time taken to repack a single p3d and small config is minimal to say the least.

Again, five or more pbo's for a large MOD like ACES is fine. But a single addon, I'm not so sure.

[terox 316]

Ref Version Control

This is primarily a requirement of Multiplayer environment and specifically is to ensure that the server and all clients are running the same version of the addon, or even mod.

The easiest way to run this is b y having the init fields run a script which does 2 things

a) has the server run a pv on it's version variable

b) has the client wait on this PV and then compare it to it's own version

c) Run a sidechat/global chat (Not a hint) that confirms the 2 are the same or issues a warning that states there is a mismatch.

The main problem here though, is that when you have say an addon pack with 30 addons thats a hell of a lot of sidechat messages to read.

of course you can merely sidechat only when a mismatch occurs.

I suppose another method could utilise in the pbo filename

However there are complications.

This thread is now going off topic though

[andersson 285]

I see your point Terox. I have worked alot with peoples addons making my own configmods in OFP. I also understand the other views in this thread as its too common that peolpe give credit to wrong persons/modteams. And I know how much work a good addon demands.

Anyway, there is one thing that I cant figure out in your posts. Why do you mention mlods? They have nothing to do with configs. You also wrote about hex-editing models for new texturepaths. If you are doing that, then your proposed system will not change anything about that.

In short, can you explain your comments about mlod and hexediting? It doesnt fit this discussion as I see it.

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

<span style='color:blue'>The combined config only affects those who want to use it legitimately and it effects them in a negative way to such an extent it in most cases prevents them from using the great model that Johnny created which is a crying shame because Johnny probably wants them to use it but doesnt want them to have Mlods and hasnt got the time to create a customised version for them</span>

(OT?. I dont make configmods in the same way anymore. No need to do that in arma. Bridgeaddons/x-over addons/whatever you call them will do the work. I leave all addons untouched but get changed/balanced result in the game. Yes, the editor gets cluttered, some missions.sqm gets corrupted. But I dont mind having the editor cluttered, it reminds me of the addonmakers. Its also easy to fix the mission.sqm or make the mission in vanilla-arma and play it in modded-arma.

I can see that it would be nice to have a nice looking package, but in the end its the gameplay that is the goal isnt it?)

[terox 316]

You also wrote about hex-editing models for new texturepaths. If you are doing that, then your proposed system will not change anything about that.

In short, can you explain your comments about mlod and hexediting? It doesnt fit this discussion as I see it.

I can see that it would be nice to have a nice looking package, but in the end its the gameplay that is the goal isnt it?)

Firstly, we dont repath models to different pbo's, I never said that

Secondly, if there was permission to do this, then the texture path must remain identical (character length) otherwise hex editing doesnt work, so if we had

Johnnys_C130.pbo

and someone wanted to transfer to

MyMod_Veh.pbo,

hexediting would fail

and given permission, we would prefer not to edit any pbo made by a 3rd party, thats just plain bad practice

and thirdly, i've explained why its a really really bad idea to have unwanted vehicle classes that dont conform to the mods structure nor create equilibrium throughout the mod available in the mission editor.

What I dont understand is why this discussion has centred around a permission discussion, it really has very little to do with the technical side of why a split config/model addon is in my opinion a far better approach

The alternative approach makes it more difficult to do things correctly, and by that I mean having been given permission and then implementing the addon.

It seems no matter how I try to explain it, some folks just dont get it and see negative sides to it where no negative sides exist.

[ArmaVidz 0]

It seems no matter how I try to explain it, some folks just dont get it and see negative sides to it where no negative sides exist.

They get it, as do I, however the reluctance that has been aired, I think, is due to saying the structuring and creation of an addon to better suit the inclusion to a mod. Which is where you find fence-post-sitters and people on either side of the fence; violently arguing over people stuffing their works into a mod and the people who just want new stuff.

I haven't seen it personally, and I'm talking out my ass here, but due to some hostility I've seen in the community in the last year, an assumption of mine is that some mod teams 'hound' the addon makers or 'become hostile' to addon makers if permission is not given, or the mod team goes ahead and does the modification, be it with configs or other, then either posts in the addon makers thread, or 'guilts' an addon maker in giving permission because the team did all the work - and then asked. This in my view, would account for alot of protectiveness over their works and mod team/addon maker relationships. Not to mention the lack of an 'in your face' approach to the credits situation. I think that's what is needed - but that's just my 'feelings' and 'opinion.'

The only real way to judge whether if it is needed or not is to get the collective vote on 'graphical credits' (or whichever delivery method we're talking about here) and then have the community adhere to this 'mod standard practice.' Sounds totalitarian in my opinion but is overdue for these dude's hard work.

The problem you've run into Terox, is that you proposed a method of change to addon development, while stating that the said creation method would allow for easier inclusion to a mod - which then touches on the stigmatism of 'ripoff my addon' and 'lump my hard work in with other stuff.' Regardless of the benefits, you'll meet fierce opposition.

Your addon creation ideas are fine. But you won't find any 'buyers' here while mentioning 'inclusion to a mod' without adding a note and process for 'additional crediting' because mods are kinda...faceless in my opinion. I think others have the same frame of mind as well. Yeah it's in the credits in the readme, personally, I don't think it's enough.

Anyway dude, don't sweat it. You just hit a touchy subject.

[dm 9]

Secondly, if there was permission to do this, then the texture path must remain identical (character length) otherwise hex editing doesnt work, so if we had

Johnnys_C130.pbo

and someone wanted to transfer to

MyMod_Veh.pbo,

hexediting would fail

So, you can just use a "padding" folder to fix it anyway?

Johnnys_C130.pbo

with a folder structure

Johnnys_C130\texturename.paa

to

MyMod_Veh.pbo

with a folder structure

MyMod\data\0\texturename.paa

and thirdly, i've explained why its a really really bad idea to have unwanted vehicle classes that dont conform to the mods structure nor create equilibrium throughout the mod available in the mission editor.

And many people here have explained over and over and over just how EASY it is to overwrite a classname in your mod's config. I'll do it again for you now:

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

class Johnnys_c130: Plane

{

config data;

};

Becomes (in the mod's config, not in johnny's)

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

class Johnnys_c130: Plane

{

scope = 1;

};

There, problem solved, no mess, no fuss, no worries. Just hides Johnnys version and all is well.

What I dont understand is why this discussion has centred around a permission discussion...

Because your whole first post was all about

It would solve a lot of "Permission" issues

It would reduce a lot of "Asking permission" issues

How is that NOT about permissions?

The point is, you're basically saying I dont think your config is very good, infact its rubbish, so I want to throw it away and replace it with my own. How do you think that makes the original creator feel? Surely it takes the original creator just as long to write their config as it does for you to write the config section for it in the mod? What justifies the extra work or the different structure other than the fact it makes it easier to include in config mods? (simply because you dont have to edit the class to hide it, you just dont include the pbo). You can argue the patching/version/release issues, but at the end of the day, it is just as likely that the model needs fixes as well as the config or scripts, so do you suggest seperating those out too? Hell, the original sounds might not be up to scratch, so why not put them in a seperate pbo? Like UNN said, for a full mod, sure that would be feasable. But for a single vehicle? Thats crazy. And do you not think that the original creator may have found the right sounds for it, even if they dont sound "great" or "amazing"? That they may have written the right ammo or armour variables? It seems very much like a "My config mod is so good, why arent you appreciating the fact that I'm using your model (which actually saves me the time and effort of making it) to display it in my wonderful mod which will be perfect."

(Which actually you are saying, ref:

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

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

)

You're asking the original creators to do things differently/do more work to make it easier for you to "rip off" for your mod, and you're surprised that some people dont like it?

Clarification: I use the term "rip off" as a generic term, since some mods do try to make it clear where content comes from, others do not. I also use it to highlight the fact that without this 3rd party work, 4th party config mods would be impossible.

[andersson 285]

@Terox:

I think you read my post in the wrong way. I did say that I do understand what you mean and the benefits with that system.

But you didnt answer my questions. As I understand, this is about an alternative way of placing the config? So why your comments about mlods? I asked if you could clarify that to me as I cant understand that.

My question is not an attack against you or anything like that, it is an honest question.

Firstly, we dont repath models to different pbo's, I never said that

I never said that you did repath models, and that is why I asked about why you mentioned hexediting. But I read the thread once more and I did misread it, I understand what you mean now. Sorry for that misunderstanding.

[terox 316]

NP Andersson

and thanks ArmaVidz, you explanation was great

as for DM, dont try putting words in my mouth, since when did i say anything like the comments you made about my opinion of addon configs.

with that i leave the discussion

Thanks for all your input

[.kju 3241]

lovely..