Modders, modding guidelines - please read

[Juju]

First of all, thanks for all your efforts (can't have enough mods), but I do have a few gripes with most of the mods released so far.

ATM there are, say, 60 mods available. In a year there will be hundreds, and recognizing which is which and what does what on our hard drives will be a lot harder to track. It's just a request, but it would be nice if all modders could stick to a couple of, let's call them guidelines.

When you release a mod, please:

- Provide a readme detailing the contents of the mod and what it does/doesn't do.

- Provide screenshots, if at all possible with before/after shots. But please also keep them at an acceptable size. 5MB screenshots for a 20kb mod are just excessive.

- Don't include elements not advertized in the mod. For example, if the main goal of your mod is changing doodads, and you also include any non-doodad elements, please mention that in the readme. It's incredibly irritating seeing some things change and not know which mod is responsible.

- When it's done: Please don't keep updating multiple versions of the same mod. We've been waiting for this game for years. We can wait a couple of weeks for a complete and finished version. This is also something the mod hosting sites will definitely appreciate.

- Repack your mods and give the .BRZ a unique name, including your own name, if possible. Loose files in the Z folder produce a lot of clutter. It's also harder for us users to switch out mods that cover the same elements if we can't instantly recognize them by name/description.

Sorry if I'm being a grump about this, but doing it this way would make me, and many others I'm sure, a happy modslut!

Thanks in advance,

Juju

[Sequoia]

Thanks JuJu, this is good advice. Regarding when it's done however, one problem of a modder is lack of beta testers and sometimes one does not catch things until others comment on it once it has gone public. Perhaps we can start a mod tester recruiting list in this modders forum.

[Vein]

- Provide a readme detailing the contents of the mod and what it does/doesn't do. - See below

- Provide screenshots, if at all possible with before/after shots. But please also keep them at an acceptable size. 5MB screenshots for a 20kb mod are just excessive. - That all depends on what the pictures show. A picture is worth a thousand words so by doing this step it avoids the need to include a read me detailing the contents of the mod and what it does/doesn't do. Over 1.5mb is excessive however.

- Don't include elements not advertized in the mod. For example, if the main goal of your mod is changing doodads, and you also include any non-doodad elements, please mention that in the readme. It's incredibly irritating seeing some things change and not know which mod is responsible. - This one is my fault. But when I left the loading bar mod in my sound mod it was an accident. I can't update it though because I would hate to break the next rule

- When it's done: Please don't keep updating multiple versions of the same mod. We've been waiting for this game for years. We can wait a couple of weeks for a complete and finished version. This is also something the mod hosting sites will definitely appreciate. - There is nothing more tedious than having to re-upload something because you idiotically put the patches on the wrong arm. YOU may be willing to wait for an update but if I didn't do it straight away it simply wouldn't get done at all. My aim is to mod the game till I am happy with it and then to leave well enough alone. I could always not bother updating though. No skin off my nose.

- Repack your mods and give the .BRZ a unique name, including your own name, if possible. Loose files in the Z folder produce a lot of clutter. It's also harder for us users to switch out mods that cover the same elements if we can't instantly recognize them by name/description. - You can very easily do this yourself by dropping the folders into the INPUT folder in Rezpack in the Tools folder and clicking Rexpack.exe. The modder could easily do it but if they didn't, and you want their mod, now you can do it yourself

Generally good advice though.

[Juju]

Thanks JuJu, this is good advice. Regarding when it's done however, one problem of a modder is lack of beta testers and sometimes one does not catch things until others comment on it once it has gone public. Perhaps we can start a mod tester recruiting list in this modders forum.

When I used to mod for CMx1 I had a few dedicated testers. Couldn't have done it without them, I'll tell ya.. I've also teamed up with modders who did similar mods to mine and test each other's work.

[Juju]

- When it's done: Please don't keep updating multiple versions of the same mod. We've been waiting for this game for years. We can wait a couple of weeks for a complete and finished version. This is also something the mod hosting sites will definitely appreciate. - There is nothing more tedious than having to re-upload something because you idiotically put the patches on the wrong arm. YOU may be willing to wait for an update but if I didn't do it straight away it simply wouldn't get done at all. My aim is to mod the game till I am happy with it and then to leave well enough alone. I could always not bother updating though. No skin off my nose.

What I meant was I would have been happy to wait for the final V3 version. That's where those testers I mentioned in my previous post come in. Ask around, I'll guarantee you there will be plenty guys willing to test your mods. My experience is that their input is invaluable and it has certainly contributed to the quality of my own old CMx1 mods.

[mjkerner]

I have a suggestion for the Repository, if BFC is reading this...could we sort them by date? Already after only one week, the alphabetical sort means we have to go through 6 somewhat slow-loading pages. No prob now, but what will that be like a year from now?

[Hellmann]

First of all, thanks for all your efforts (can't have enough mods), but I do have a few gripes with most of the mods released so far.

I respect your opinion, Juju, but I don't agree with everything you're saying. Please let me explain why.

In the extremely rare cases I feel a good mod needs a photo and readme which doesn't already have them, then I'll just take a quick screenshot in Fraps and type a couple of words in a text file. It's hardly a hassle. Most of the mods I've seen already have readme's though. The one's that don't are usually because the filename says everything about the mod as it is. If not, rename it! What more do you need to know? So long as you store your mods logically on your HDD, there shouldn't be a problem.

You're right about one thing though; I did indeed notice one of the mods by a certain mod-god (hehe he knows who he is) that had a different 'loading bar' not previously advertised, but I actually liked it and considered it a nice bonus! It's not as if I had to use it if I didn't want to, is it? Just extract it and delete the .bmp files if you don't like it, surely? And as for loose files in the Z folder... what does that mean? All my mods are in their own folders inside my Z folder, nothing is "loose" and I can see exactly what's what. You do know that you can have all your mod files in their own separate folders under the Z hierarchy? Or didn't you know?

Another thing, I usually extract any .brz I download with RezExplode so that I can see exactly what's inside a mod before I use it. Don't you? If I'm happy with what I see, then I'll leave it as the default .brz to minimize fragmentation. Otherwise I edit it and repack. I prefer it if the mod isn't packed as a .brz, but as it's such a trivial thing and only takes a few seconds to extract and examine it, I don't care either way. Why does it matter to you? There's nothing stopping you from renaming the mod folders to whatever you like, and there's nothing stopping you from repacking it as a .brz yourself... or is there? I'm pretty sure the manual or 'Mod Tools Readme.txt' explains how to do this.

And why shouldn't we update our own mods whenever we like? Firstly, we don't get paid for it, so what right do you have to complain? When anyone is kind enough to share a mod or update it, I'm always grateful WHENEVER it is, considering they might never release a mod ever again. Secondly, if the person hosting our mods seriously doesn't like frequent updates, they should BAN the "offending" modder(s) to prevent them from doing so - if it's actually that much of an issue to them.

Lastly, and I know I'm not the only modder who thinks this; it's nit-picking unnecessary gripes that can and do put modders off from sharing mods with the public. Remember those talented modders we lost in the past? Frankly, I've found that it's better to share the mods I make only with friends and people who can appreciate my work, than have to put up with the hassle of sharing them publicly. Not saying you're guilty of it my friend, but I'm tired of those ungrateful lazy souls who love nitpicking and complaining about the most trivial, obvious, inane mind-numbing things. You say, "In a year there will be hundreds" [of mods]. Really? Carry on with the "complaints department", and there might be less than you think!

[Juju]

I have a suggestion for the Repository, if BFC is reading this...could we sort them by date? Already after only one week, the alphabetical sort means we have to go through 6 somewhat slow-loading pages. No prob now, but what will that be like a year from now?

But you already can. I do it all the time. Click on 'submit date.'

[Juju]

I respect your opinion, Juju,

It's not an opinion, it's simply a request. It's about presentation, about quality.

I was going to include a more in-depth answer to all your questions, but after reading your last paragraph I don't think I'll bother.

And if you don't know why, well, that's exactly my point.

[sawomi]

I advice to follow Juju suggestions, your mod will get more used in the long run (if it is good enough), at least when the mod-manager arrives.

Defenitly include a read-me, the text you can also use for a advertisement-post:

Some example by myself (not CMBN):

http://www.battlefront.com/community/showthread.php?t=93280

http://ww.battlefront.com/community/showthread.php?p=1207463

[lookeylou]

Maybe post the points per objective. So you as the commander can make a decision on which VPs to go after or hold if you are short on combat effective units or running out of time. I hate the "surprise" on the result page

Also if the design of a map is made around achieving a goal, don't make a secondary objective more points than the primary.

[mjkerner]

Thanks juju...I just didn't notice, or if I did, my mind must have registered it as something for the mod submiter! I thought it was a strange oversite....

[Johnny Canuck]

I agree with Juju's points.

To me, there's nothing worse than scenarios/mods without adequate documentation, that contain spelling mistakes, or ones in which I have to perform the equivalent of 'recompiling the kernel'.

Mods may need to be updated, and should have version numbers. Either way, there should be some reasonable testing performed by other members before being published as a finished scenario/mod.

And yes, a decent repository with multiple sorts/filters and a rating system would be excellent.

[Mord]

Well...as far as my stuff goes, I do everything stated, already.

LOL...I keep seeing all these references to readmes....I've put one in every mod but I still end up having to explain stuff...so it's a damned if you do damned if you don't.

Mord.

P.S. Hey, Juju...you plan on throwing your modding hat in the ring for CMBN?

[Juju]

P.S. Hey, Juju...you plan on throwing your modding hat in the ring for CMBN?

Not yet. Almost all of it looks good enough stock. Buildings are just too much work. But if and when, I might take a swing at a set of bridges.

[wyseman76]

I think these points are pretty manageable as a modder. I will say that it is almost impossible to avoid updated versions though, do to the ever increasing variables in more complex mods. We all overlook something now and then, but I do see your point, in reducing excessive updates.