Calling all modders (APB - All Pixel Bulletin)

[Gordon]

Gentlemen (and Kitty, if she's still around),

In light of recent events, I've been asked to try to convene a "Modders Round-table" of sorts to attempt to work out some issues that will hopefully maker our (as well as the various host site web-master's) lives easier. So, I hope you will all chip in and cooperatively we can establish some simple guidelines that make sense and that are a win-win for everyone.

So, I guess the first question is, would people prefer all the discussion to take place here, via e-mail or some other BB/forum?

The second question concerns mod re-use etiquette. I don't think there's any question that plagarism is bad, but there are some grey areas that should probably be ironed out and some sort of code of conduct (like the "Repoman's code) probably couldn't hurt.

The third question concerns coming up with some sort of mod naming convention. Several web-masters have asked me about this, and I think it makes a lot of sense, especially with CM:BB on the horizon as mods will not be interchangeable between CM:BO and CM:BB.

Fourth, I'll be re-architecting/re-issueing the German Uniform RuleSet and creating an Allied Uniform RuleSet that will be part of the release of CMMOS v3.00, so I'd like to gain the participation of all the uniform modders out there so that it can be a complete "package" (note: individual modders will still own and control the mods, we'll just want to coordinate a "name-space" for the mods so that they can all co-exist under a single German and an single Allied RuleSet).

I'm sure other issues will come up that can be discussed.

So, hopefully we'll get a quorum.

Thanks,

Gordon

btw, Tanks a lot - are you interested in issueing a copy of your winter buildings that are CMMOS-enabled? If so, please contact me ("gordonemolek@earhtlink.net").

[Michael Dorosh]

I'd like to see a website with a listing of all available "official" (low numered) CMMOS mods - including file names. I'd be willing to maintain such a site if the info was (spoon) fed to me. Thumbnails of these mods would be a plus - and links to download sites. I would also include known projects in progress also. Each line of the list would have

thumbnail

filenames (for other modders to know not to duplicate)

mod artist's name

resolution

location of download

This is necessary for modders just as much as users (modees?) - no point working on a CMMOS mod called _pzIV_hastyambush if there is already a mod out there in existence, and with that name.

I'm for the other ideas you cited Gordon.

[ 11-15-2001: Message edited by: Michael Dorosh ]</p>

[Gordon]

Michael,

Good points. I'd like to make such a list as "official" as possible, so I nominate Manx and CM:HQ. Actually, the genesis of such a list is already there in the CMMOS section, albeit without all the fancy thumbnails and links in place. But I'm sure Manx will have that all whipped into shape in no time. :eek:

One thing to note, however, is that there's nothing whatsover preventing anyone else from offering, for instance, their own US Black/Olive Drab Shermans as a substitute for my version, provided the issues above are resolved and we can iron things out such that there's no confusion on the gamer's part as to which version he's using. Although I can't imagine why anyone would want to replace any one of my mods. Also, I think the "community" would benefit more from that person working on something that hadn't been covered yet, but there's nothing "illegal" about it.

In fact, I'm still anxiously waiting for someone to step up to the plate and offer to work up a complete set of foliage camouflaged US/UK vehicles. I'd love to add those Rules/Icons to the Commonwealth and US/Free French RuleSets.

Gordon

[Gyrene]

Gordon, a problem with having modders follow a naming convention for CMMOS is that many modders use Macs and CMMOS is not available for the Mac.

In other words - I don't think too many Mac modders even know how CMMOS is supposed to work.

As for mod re-use, I think that getting permission before tweaking a mod is the right thing to do, especially if you plan to release the tweaked mod.

On a naming convention for the files between CMBO & CMBB I think that a "_BO" or "_BB" in the name would suffice. Example - SpringTreeBases_BO.zip, HiResSkies_BB.zip etc.

Gyrene

[Michael Dorosh]

Alright Manx - get on the stick for heaven's sake.

[Gordon]

Gyrene,

I'm still looking for someone to work with on the Mac side to see if we can't get something equivalent to CMMOS for Mac users (even if it's just some extra capabilities added into the existing Mac mod manager(s) that will help solve these sorts of issues.

Yes, something on the order of "_BO"/"_BB" (or the absence of "_BB" means it's a CM:BO mod) is probably sufficient, but the naming convention goes far beyond that, including version information, low/hi res, summer/winter, etc.

Gordon

[Cameroon]

<blockquote>quote:</font><hr>Originally posted by Gordon:

Gyrene,

I'm still looking for someone to work with on the Mac side to see if we can't get something equivalent to CMMOS for Mac users (even if it's just some extra capabilities added into the existing Mac mod manager(s) that will help solve these sorts of issues.

Yes, something on the order of "_BO"/"_BB" (or the absence of "_BB" means it's a CM:BO mod) is probably sufficient, but the naming convention goes far beyond that, including version information, low/hi res, summer/winter, etc.

Gordon<hr></blockquote>

Not to get anyone's hopes up, but I (a Mac developer) have been messing around with creating a CMMOS compatible (not copy) Mac mod manager.

If CM worked in OS X I'd probably already have such a beast out (OS X is soooo much easier to write for than pre-X). Perhaps I'll re-motivate myself Rest assured, I will let the community know about my progress.

Regarding naming conventions, there is at least one important issue to make note of. Mac file names may only be a total of 31 characters (unless you're in OS X but since CM doesn't work there...). File naming conventions should probably take this into account as 13344_1942_winter_camo_bloc_uk.bmp isn't going to work

[Gyrene]

Cameroon, good news on a Mac CMMOS thingie being in the works. Now I'll be able to know what the fuss is about

A naming convention would be nice, but hopefully the file names remain readable or we'll end up with file names that look like aircraft part #'s

Example:

2863_PzIV(GHJ)_VC_BO.zip

2863 = Gordon Molek

PzIV = Panzer IV

(GHJ) = models

V = Variants

C= CMMOS Compliant

BO = CMBO

Crazy huh?

[MikeyD]

For my posted mods I always try to include a line in the documentation saying

"You have my permission to use, distribute, and modify it any way you see fit."

Hell, if you want you can even put it on a CD and sell it as you own, what do I care? Some (most) of the 'mod instutions' though may have very different attitudes regarding their own work.

[Gordon]

Cameroon,

Let me know if you need any help or source code (Borland's C++ Builder). voidhawk's C code to reduce BMPs from hi-res to low-res is also available to integrate into the Mac tool.

Good to know about the name length limit on Mac. I think we're Ok so far. A quick check of my BMP directory yields the longest filenames as:

13230_sno_a_AltRoadwheels.bmp

5011_dieppe_uniform_canadian.bmp

The second of which hasn't been published yet (I believe), so we should be able to adjust.

MikeyD,

Yes, I used to do something similar but have fallen out of the habit lately. Possibly a stock disclaimer, or set of disclaimers (and a standard place to put it) might also be agreed upon.

Is there a lawyer in the house?!?

Gordon

[AndrewTF]

At first I used to add a "do whatever you want" message in the readme's to my mods, but after looking at some of the goofball things people did with them, including "repaints" and and things like appropriating the equipment from my German uniform mods, I've changed my mind. I also think it's common courtesy to at least notify the original mod artist if you intend to use or alter a mod and then distribute it to the public.

I now include a message that asks that they not be redistributed in altered form without my permission.

For the record, if someone at least lets me know that they're doing with my mods I don't make a stink, even if I don't like what they're doing.

[Philippe]

Leaving standardized file names aside for the moment (and only for the moment...I've recently become painfully aware of how important this issue is), I would like to come back to Gordon's second question, mod re-use etiquette. Particularly the grey areas as they apply to creating general editions.

I'm bringing this up for purely selfish reasons. I've been working with Gordon on a CMMOS edition of subdued terrain mods. The first draft is done and awaiting CMMOS 3. I'm now dreading the prospect of chasing down over a hundred permissions for the separate mods that are going into this edition. Now in practise we're probably only looking at a little more than a score of blanket permissions. But there are indeed grey areas.

To make my edition consistant I've had to rename things slightly: several mod authors will be surprised to learn that they've created mods called "Water and Ford". I've also had to take a few editorial liberties. Out of sixteen grass mods that I'm using, few bothered to set up a texture for the background (the low resolution area between the playing area and the horizon controlled by 1503), and several who did did so only occasionaly. To smooth things over I've relied on my own judgement (shudder), picked a tile from the high resolution group that I thought would make a nice background, and voila...a mod etiquette problem. [Yes, the best thing would be to chase each author of a grass mod down and ask him which tile he'd like to use as background, but if I used that approach on everything it would take three years to finish this project].

Similarly, a couple of the Tree mods that I'm using seem to have omitted the overhead view on a couple of the tree tiles. Now most of us play with our nose in the weeds so it doesn't matter that much, but if you do decide to soar like an eagle you may be surprised that your autumn foliage turns green when you fly directly overhead. So the logical thing for an editor to do is to either track down a mod author and wait for him to correct the gaps (and add more delays to the whole project), or to find the closest looking substitutes from all the mods available, use them, and invite the author to fill in the gaps at his leisure. But by doing this we've gone one step farther. Mod author A's overhead of a tree may be showing up in mod author b's trees. [Note that this kind of thing happens all the time anyway with incomplete mods -- installing them doesn't wipe out the entire previous mod, just the parts that are duplicated].

Another issue is what to do about unknown attributions. Anonymous has written some of the greatest music and poetry in several civilizations, and I was really surprised when I discovered that he had tried his hand at modding terrain sets. It is amazing how often people don't write those annoying little text files that tell you what the mod is, or how easy it is for those files to get separated from the mod, especially when it is part of a larger one getting broken up into lots of little pieces. What is the editor's duty to the mod author vis-a-vis attribution ? You go crazy trying to track everything down. What is the editor's duty towards the mod author's notes on a particular mod ? Very different kettle of fish. The edition is, in the end, the editor's work, so the notes (and the selection of mods) are his. Of course, in a good edition it will be screamingly obvious whose Scattered Tree Base you are using. And since the attribution notes won't carry over, you should also make sure that it is screamingly obvious who made the mod from the coding of the bitmap.

And this is another reason why a standardized agreement on coding is important. The code remains long after the notes are lost and forgotten. If you see a Woods Tree Base with a suffix of _ju after the number, you should be able to know at a glance that it was Juju's. Same for _gs and Gunslinger or _JohnS and Tiger. Because Gordon encouraged me to make a section of my edtition for total or near total conversions, I have been forced to come up with standardized names if only to make the global conversion rulesets work. And it can get complicated when Gunnergoz decides to do yet another speckled terrain set.

Finally we come to the question of permissions for an edition. Suppose someone decides to assemble all the mods for field guns and to write CMMOS rulesets for all of them. He doesn't really change anything, just imposes order, makes selections...and makes choices about shared bitmaps. Does he really have to go out to the authors of the mods for permissions ? Probably. Should the mod authors have any control over the editor's editorial discretion ? Probably not. [The concern here is that a mod author might try to impose conditions on the context in which his mod is presented, the context and form of presentation being the domain of the editor]. Should the mod author be allowed to vet his part of an edition before release ? Maybe, depending on how easy it is to set up a vetting process, and whether the author's involvement can contribute to the editorial process. [Vetting shouldn't be about vanity, it should be about improving the edition].

I hope that some of the issues raised in this post help clarify the thornier ones that come into play when you make a mod based on someone else who made a mod based on yet a third person. [i seem to recall that the old Latin Prose Comp book was called Matthew's Bradley's Arnold].

Philippe

"Consistancy is to the life of the intellect as marriage is to the life of emotions, a confession of failure." -- O.W.

[Michael Dorosh]

Far better to incorporate readmes into CMMOS now that there is a window for notes. I had 50 files in my bmp folder called ReadMe.txt, and I usually just deleted them anyway. Who can be bothered, really? Kudos to Gordon for version 3.0

Incidentally, for my unofficial CMMOS mod downloads, I put the mod artist's name right in the option window in parentheses. I figure that is only fair, even if it does clutter things up a bit.

[Scipio]

I wonder how a 'rule set' is made? This sounds very complicated.

About the CMMOS for Mac. I have only limited knowledge in C++, but isn't the sourcecode in princip independent from the platform and can be simply compiled?

[Gordon]

Michael,

For v3.00 there will actually be two ways to include additional information. The first is the "Description" which Rule specific, the second is the "Redits" which is RuleSet specific.

Scipio,

Well, I don't think writing CMMOS RuleSets/Rules is very complicated, but I'm a software engineer by trade and therefore of questionable moral character to judge these sorts of things

Not to mention the fact that I was partially responsible for the original batch file system which resulted in me going crazy enough to write CMMOS

However, that said, I truly believe that creating/enabling a mod for CMMOS is actually quite straight forward, once you get in the right frame of mind. What's that frame of mind? Basically you have to think of, say a uniform mod, as a series of building blocks. Some uniforms share the same pants, some the same tunic and some are identical except for the sleeves which have different unit insignia on them. A CMMOS RuleSet/Rule is just a way of expressing those relation ships. So, continuing with the example, if some crazy fool wanted to create a uniform mod allowing you to represent every single British regiment that served on the western front, they'd need to provide a set of BMPs for the basic uniform and then a whole bunch of different sleeve BMPs, one per regiment, and then "program" CMMOS via a Rule file as to how the user selects each regiment. CMMOS then just copies the appropriate BMPs over the game's run-time BMPs and you're done.

Also, forgot to address your porting question. No, it's not quite that simple because the different operating systems have different interfaces defined to accomplish similar tasks.

Gordon

[ 11-15-2001: Message edited by: Gordon ]</p>

[Scipio]

I didn't mean how it works, I just asked how they are created? Are they created manually? And do you rename each single file manually? I'm just curious. I don't use a mod tool - I change the graphics only if a new mod is available that's better then the one I currently use.

[Darknight (DC)]

<blockquote>quote:</font><hr> Fourth, I'll be re-architecting/re-issueing the German Uniform RuleSet and creating an Allied Uniform RuleSet that will be part of the release of CMMOS v3.00, so I'd like to gain the participation of all the uniform modders out there so that it can be a complete "package" (note: individual modders will still own and control the mods, we'll just want to coordinate a "name-space" for the mods so that they can all co-exist under a single German and an single Allied RuleSet). <hr></blockquote>

Well, I'm in the middle of completing the British unit sleeves for each battalion right now for the HR uniforms (and I'm considering doing the US divisions later, when I complete this). I didn't really worry too much about the naming system when it was just the Canadian units on my HD (I would just use something like:

5012_rcr (where rcr is a short form for Royal Canadian Regt);

or a variant like:

5012_1rcr (where the # stood for the division)

With the British sleeves beginning to accumulate on my HD now, I've been thinking of something like:

5012_cdn_rcr

5012_uk_4ksli

(where in this case, the number stands for the Bn b/c there where no duplicate Bn in the Cdn army in ETO).

If there is some other way that works, I'm happy to implement it.

[Cameroon]

<blockquote>quote:</font><hr>Originally posted by Scipio:

I wonder how a 'rule set' is made? This sounds very complicated.

About the CMMOS for Mac. I have only limited knowledge in C++, but isn't the sourcecode in princip independent from the platform and can be simply compiled?<hr></blockquote>

The ability to transport code between platforms is pretty much dependent upon how much said code makes use of OS specific features/tools.

Probably the only portable portion of code would be that which deals with parsing the rule files, and then only if it's using standard library stuff. None of the GUI code would port and none of the file system code would port. Since CMMOS is mostly a GUI tool for manipulating the file system, there's not a lot of opportunity for porting.

I'd be a software engineer/programmer by trade as well, once someone hires me... stupid slowdown

[Gordon]

Scipio,

Sorry, about misunderstanding your question. Mostly it's just a bunch of text files and BMPs collected into a zip file. I haven't explored creating a CMMOS RuleSet authoring tool yet.

The renaming of BMPs question is being addressed in version 3.00 by inclusion of a tool called "BMP Munge" which handles simple BMP file renaming (and scaling down to low-res sizes) to help mod authors (at least on the PC) assemble the necessary BMPs.

Darknight_Canuck,

The only real issue I see so far is if there have to be different versions of the same sleeve to match different uniforms. Then you'd probably want to adopt something like "_baseUniformModName_Regiment", or some such.

Gordon

[Manx]

<blockquote>quote:</font><hr>Originally posted by Gordon:

Michael,

Good points. I'd like to make such a list as "official" as possible, so I nominate Manx and CM:HQ. Actually, the genesis of such a list is already there in the CMMOS section, albeit without all the fancy thumbnails and links in place. But I'm sure Manx will have that all whipped into shape in no time. :eek:

Gordon<hr></blockquote>

We will do whatever we can to promote CMMOS at CMHQ. At this point in time CMMOS is THE BEST means of distributing (on a PC) Mods that come packed with optional extra's and for switching between different releases. CMHQ is ready and willing!

About Mod Etiquette -- Speaking purely as a CM webmaster, i wish you mod guys would come up with some sort of Code of Practice with regards to getting permission to alter or re-release mods by other designers.

At CMHQ we have recently had to "pull" a mod compilation from the site because of a dispute over just part of the mod being released without the consent of the original author. So, once again our time has been wasted uploading files, taking screenshots and writing reviews. This isn't the first time at CMHQ, or incidentally, at my old site, CMs, that this sort of thing has gone on.

This won't be happening again at CMHQ.

[ 11-15-2001: Message edited by: Manx ]</p>

[Manx]

The idea of a naming scheme is a good one -- so in addition to whats already been suggested above (i.e - me nicking a few ideas), how about something like this.

BOCL1GM_modname.zip

where,

BO/BB = Game Version

C = CMMOS Compatible (left out if not)

L/H = Low/Hi-res

1-X = Mod Version #

GM/GEM = Designers Initials - (Gordon's in this case)

_ = underscore (required)

Mod Name = Err...kept as short as possible, but still understandable

EDIT -- In situations where a mod has been collaborated on by more than one designer, one guy (or gal) takes agreed "responsiblity" for it and the mod uses his/her initials as a point of reference. This would most likely be the person who has done the most work on it i guess. Hosting sites would of course acknowledge ALL those involved as would any readme files etc. etc.

Rare, but, when one mod is split into smaller parts (as in Magua's "Normandy" mod) you add a "1-X" for each part. Left out if not applicable.

so further to the above, and with all options switched on, you end up with somefink like this:

BOCL1GM1_mod.zip (multi-part CMMOS Mod)

or,

BOL1GM_mod.zip (Non-CMMOS, single part)

What do you reckon?

[ 11-15-2001: Message edited by: Manx ]</p>

[Michael Dorosh]

Why are you including .zip in the titles? Does the zip name really matter? I should think the .bmp file names are what is at issue, no?

[Philippe]

Manx's list of the elements needed in standardized mod naming is most certainly a major step in the right direction. I think his ideas should be applauded, as well as the fact that he has had the courage to put a draft of a system out on the table for discussion, but I would like to add a word of caution. A naming system can have a lot of unforseen consequences and needs a lot careful thought before you marry into it.

My own experience with trying to come up with a naming system that works, and then having to live with it in practise landed me in a bit of a pickle. To wit, I ended up having to rename about a thousand files manually (twice !) after I discovered, to my chagrin, that the requirements of what I was trying to do and my own logically elegant naming system were incompatible.

The problem was that I had ten different components of Magua's Normandy mod, for example, and had given them ten different names based on what they were along with some specific identifiers. Well, when you're trying to compare all the different summer wheats or all the brushes or all the marshes, no problem. The ruleset and whatever you've done to the file list at that point take care of all the particulars.

The fun starts when Gordon suggests (ever so gently) that you need to invoke all the different parts of Magua's Normandy terrain mods at once. I don't believe there's a way in the current version to do this unless they all have the same basic extensions. In other words, as it stands ruleset xyz can call up all the terrain mods that end in _nor, and it won't call up the building _nor mods because ruleset xyz doesn't mention buildings in its list of applicable files from the filelists. If each of Magua's Normandy mods has an identifier that is different (apart from the number), CMMOS won't recognize that they are all Magua Normandy mods, and you won't get an application of all the different but related mods. And it gets worse when you have someone like Gunnergoz who has made several mods that have shared features. (You either use options or have several differently named versions of the same bmp).

Now understand that my own problem was relatively simple. My mods were set up so that there was only one layer of extensions and no options to worry about. I leave it to those who have tried writing multi-option rulesets (i.e. multiple layers of extensions that have to be read in a certain order, multiple nationalities with\out areal panels, camouflage, shared AA guns, whatever) to comment on what works and what doesn't. The one thing that I ask the writers of the Uniform and Armoured Vehicle rulesets to remember is that CMMOS gives us the theoretical capability to invoke, for example, all the 9th Panzer division mods at one go, provided you label the mods the right way and write the rulesets correctly.

The point is you have to design the extensions so that it will be possible to create a ruleset that can do what you want it to. If you design it incorrectly, when it comes time to write that ruleset for all the ... (fill in the blank)mods, if you didn't plan ahead you end up re-writing the extensions until they end up being something your ruleset can invoke. Now Gordon tells me that he has a nifty new program to speed the renaming, but let me assure you, it's not an exercise you want to engage in, with or without crutches.

Now, to cut to the chase, what do I think will work and what am I worried about? The extensions need to be as simple as possible. And even that is probably too complicated. The bmp number already identifies a mod for what it is part of, so you don't have to label it a marsh or a kartoflnwerfer or whathaveyou. Remember, a lot of the work gets done in the filelists and rulesets. I also don't see the need to clutter up a name with CMMOS compatible or non-CMMOS compatible. Something either has extensions that can be invoked in a ruleset or it doesn't.

As for the BO versus BB issue, my first suggestion would be to use CM1 and CM2 nomenclature (on the offchance that there is CM3, CM4, and an IPO). Secondly, I would try to dispense with CM1/BO nomenclature altogether, unless Gordon thinks that the CMMOS will get confused by the extra layering that might crop up in CM2, CM3 and CM4 mod titles. (Actually, if there are no extensions used there is no layering, just messy labels...)

What I think needs to be done now is to come up with an official list of CMMOS names (e.g. _gs = Gunslinger, _gg = Gunnergoz, _dd = DD, _nor = Magua's Normandy terrain set, _gk = Gary Kump, etc.). This would be somewhat like (shudder) a domain name registry. But the point is that it would be a guide for people to create non-official rulesets for non-CMMOS mods, as well as a guide for modders in naming their work. (And yes, I'm aware that there's an extra dimension here that I'm missing because my rulesets have only had to cope with one layer and notes).

So I hereby nominate Manx, as the best man standing, for Official Registrar (title to be enhanced upon request). If he agrees we should all send him our currently used lists of extensions so that he can sort through them, make whatever changes are necessary, and post the official versions wherever he thinks appropriate. But I also think that it is imperative that Gordon have major input into this process since he knows best what will work in CMMOS as it stands, and only he knows what CMMOS will look like in the future.

Philippe

"Consistancy is the hobgoblin of little minds". -- O.W.

[Gordon]

<blockquote>quote:</font><hr>Originally posted by Manx:

[QB]BOCL1GM1_mod.zip (multi-part CMMOS Mod)

or,

BOL1GM_mod.zip (Non-CMMOS, single part)

What do you reckon?

QB]<hr></blockquote>

I reckon we just reached the bottom of Gyrene's "Aircraft Parts" slippery slope.

Your suggestion certainly has many of the elements that I was looking for, it just might be a little too cryptic for mere mortals (like me).

Just to throw it out to get shot full of holes, the format that I had recently settled on (which doesn't necessarily include all of the items discussed was):

GEM_Camo_M4s_v2.0_CMMOS_hr.zip

So you've got the author's initial "GEM", the what the hell's the mod about "Camo_M4s", the version "v2.0", the format "CMMOS", and high res "hr". Is it that much better or worse than what you're proposing? Not sure, I'm probably just more used to seeing this format.

The other key issue to think about in regards to a naming format is what's the primary sort "key" that user's want to have? Is it the author? Hi-res vs lo-res? The vehicle/terrain/etc.-type? The season? CM:BO vs CM:BB? Whatever that "key" is, I believe that's what you want to have as the first component of the name.

Gordon

[Gordon]

Michael and Philippe,

Don't necessarily want to speak for Manx here, but it appears he's talking about the MOD naming convention and not the BMP naming convention.

Philippe raises many good points concerning the BMP naming convention you select being "enough rope to shoot yourself in the foot with" if not thought out carefully (and believe me, I've done a lot of thinking on this stuff).

Don't worry about 9th Pz, I believe we've got it covered.

Gordon