[FlyingMongoose]

I always looked at an ini as being initialized as the software is loaded (thus the extension .ini), whereas a config doesn't always have to be initialized immediately or on load, or could be loaded later. And I don't mind nitpickyness ;) it's a good thing

But if you think I should ditch the ini directory and say it should go into cfg I will.

Configs has been changed to cfg in the txt file. Also added /cfg/maps/

Oh and I'm going to start a list of benefits for a system like this as well.

Benifits
Cleaner/Easier Distribution
Easier to find files

at the moment can't think of much else but we'll see.

[cybermind]

This is a good idea.

With regards to the ini/cfg thing, they definitely should all go in the same directory. However, I have always gone with the convention that .cfg files should only be used for actual server config files (that can be used with 'exec'), and that .ini or something else should be used for plugin-specific settings files that are loaded and parsed by the plugin. The extension distinction can help against possible confusion as to what to do with the files.

Benifits Cleaner/Easier Distribution Easier to find files

While it's a short list, those 2 items alone are worth quite a lot. From the perspective of new plugins, I cannot see any drawbacks, but to existing plugins, changing over to this structure will be about as confusing as the old MM 1.13 release (that first used the ADS). Authors will have to support the previous system for a short time, or just tell everyone to upgrade.

[FlyingMongoose]

I'd prefer they tell everyone to upgrade...I like beetlesmod functionality...but it's installation is a mess. I guess I'll merge ini and cfg together.

Edit: Done, the ini directory is ditched.

Main reason I REALLY wanted to do this now was because I wanted this standard to be set in place *BEFORE* plugins got out of hand...

More and more plugins are gonna start popping up and without some structure installing and managing them is gonna be a bitch...and some existing plugins already are.

[FlyingMongoose]

So what's everyone think of the latest revision? (I should start putting version numbers on it, lol). Once the revisions are all completely done someone (I could or someone else) should post up a poll asking whether this should be supported by the community, most people like the idea, while some plugin writers won't like to change around their existing plugins the benefits are near overpowering in my opinion. Though I <3 L. Duke for supporting the idea to the fullest and BAILOPAN for also supporting and bringing in his constructive criticism.

[showdax]

The map-specific configuration thing is silly as it's already supported by the engine. I also think the existing metaplugins.ini thing is pretty silly. It'd make more sense to tell people to add "meta load someplugin" to their autoexec.cfg file. The models and sounds directories are going to be useless but that's already been pointed out.

I think it'd be better if metamod had its own directory at the top of the server directory, so you don't have to have multiple copies of the same plugin for different mods, or a mess of symbolic links. Perhaps something like this:

cstrike/
dod/
metamod/
metamod/someplugin
metamod/someplugin/someplugin_i486.so
metamod/someplugin/somepluginsmiscellaneousfile
metamod/otherplugin
metamod/otherplugin/otherplugin_i486.so
metamod/server_i486.so

Then you'd add "meta load someplugin" to cstrike/cfg/autoexec.cfg. You could put server_i486.so in metamod/bin to copy the mod format, but it isn't really a mod so I don't think that applies, and shoving the file one directory deeper is superfluous.

[FlyingMongoose]

Interesting idea...but the engine normally call files from withing the <mod> directory, <mod> = cstrike,dod, etc.

Putting metamod on the same level at cstrike and dod might be pretty hard...unless you want to come up w/ some slightly more complex paths for the gameinfo.txt (which I've had trouble trying to do using the exec function in the server console)... having it all in the addons directory allows you to copy your addons dir over to another server, change the gameinfo.txt and boom you're off. Server's all set up the way you had the first one.

But now that I look the maps config section is somewhat silly, that's gone and this may be the final revision. We'll see ;).

Removed the maps config folder.

[showdax]

Originally Posted by flyingmongoose Interesting idea...but the engine normally call files from withing the <mod> directory, <mod> = cstrike,dod, etc.

That's irrelevant. It works just fine if you do something like "|gameinfo_path|../metamod", but metamod itself would require minor reworking to handle that.

having it all in the addons directory allows you to copy your addons dir over to another server, change the gameinfo.txt and boom you're off. Server's all set up the way you had the first one.

I'm not sure what you mean. How is what I've suggested any harder to transfer around than the current layout? If anything it's simpler because you only have one main directory to deal with, instead of an addons directory for each mod you run.

Also that text file attachment thing is really silly. Just post your ideas directly to the thread.

[FlyingMongoose]

I wrote it out seperately (at least cleaner)

It'd be simpler keeping it within the <mod> directory because the <mod> is the base where most plugins and files are called from in the engine (last I checked)

so you exec server.cfg
it execs
cfg/server.cfg

or

cfg/server.cfg

and the exec /../../addons/metamod/plugin/cfg/whatever.cfg won't work, nor will ../../addons/metamod/plugin/cfg/whatever.cfg

Try it.

Now yes, it is possible to do some reworking to make this work, but this (the way I've stated) is the way that plugins from the original metamod are laid out in, really standardizations should be discussed as they have been and you've been a good contributing factor on the "opposition" of the standardization the way I found it to be easiest in the past, with little "hard" configuration edits and what not. Plus, keeping it within the addons directory from within the <mod> will allow other, non-metamod: source plugins to follow the same standardizations (to a point). Example: Beetlesmod, Xad's plugins, etc. etc. etc.

This debate will go on forever, so how about we agree to disagree when the vote for standardization finally pop's up how about we include your idea in the votes?

[showdax]

Originally Posted by flyingmongoose I wrote it out seperately (at least cleaner) It'd be simpler keeping it within the <mod> directory because the <mod> is the base where most plugins and files are called from in the engine (last I checked)

Okay, so the mod pulls mod-specific files from the mod directory? What does that have to do with metamod? How is it simpler to have seperate installations of the same damn thing for each mod you have?

so you exec server.cfg it execs cfg/server.cfg or cfg/server.cfg and the exec /../../addons/metamod/plugin/cfg/whatever.cfg won't work, nor will ../../addons/metamod/plugin/cfg/whatever.cfg Try it.

You can't "exec" any files outside of the mod's cfg directory anyway, so your idea isn't going to work period. I never suggested cfg files should be outside of the mod directory, but where the files go and what the files are is up to the plugin and isn't necessarily prone to this limitation so it's irrelevant. I think it's pretty obvious that mod-specific configuration files should go in mod/cfg or perhaps mod/cfg/plugin, and non-mod-specific configuration files go in the metamod directory though.

[FlyingMongoose]

Originally Posted by showdax You can't "exec" any files outside of the mod's cfg directory anyway, so your idea isn't going to work period. I never suggested cfg files should be outside of the mod directory, but where the files go and what the files are is up to the plugin and isn't necessarily prone to this limitation so it's irrelevant. I think it's pretty obvious that mod-specific configuration files should go in mod/cfg or perhaps mod/cfg/plugin, and non-mod-specific configuration files go in the metamod directory though.

It's been suggested in my first post, but most plugins have the ability to read .ini files, and it may be possible to work in a metamod execute function based on the <mod> dir, really we gotta wait and see...this is a neverending circle of debate neither of us is going to win, I have my opinion on how it should be done, you have yours.