Re: [Warzone-dev] Organization Proposals

2008-12-06 Thread Kreuvf
Hi there,
I added a section on colours to that proposal. Please have a look and tell me
what you think of this.

http://wiki.wz2100.net/Organization_Proposal#Colour_support

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] Organization Proposals

2008-11-20 Thread Giel van Schijndel
Kamaze schreef:
 Kreuvf schrieb:
 And to me the syntax looks a bit crufty (but I guess it is like that
 because you have a parser at hand for that).

 Uhm, thats normal JSON-Syntax. That was something I had in my mind,
 because it supports various datatypes and nesting, as well as arrays. It
 is just less-bloated than XML, but for most of my proposals a simple
 *.ini could do the job as well, right. INI's would probably easier to
 handle for the users as well.

I like the added versatility we get by using JSON. It's not that much
more complex than an INI-style configuration file. In addition when
using JSON we have the option of extending to executable config files
later on (i.e. JavaScript). Although from that point of view using Lua
is probably a better idea (which just happens to have a syntax more
similar to INI for some cases).

So considering that we're about to use Lua anyway I suggest to use that
for config files instead of JSON.

 And what could be done about plagiarism? People taking mods of
another person
 and then just rebranding it? I'd really like to have that problem
addressed.

 I think this is impossible, unless we create some kind of DRM system.

We have no direct influence over other people's actions, nor do we have
responsibility for them. So I suggest that we don't take responsibility
for this problem.

As for DRM, that wouldn't work either, it would only make it slightly
more difficult. I.e. we would have to set up a central authority to
credit original authors. That authority would probably end up being
us. So in the end it would only create a situation where those who are
best at manipulating us will end up getting credit for works. I'd rather
not go there.

---
My own comments

As for the directory structure:
That structure simply won't work on GNU/Linux distros. Please take a
look at the structure we currently use on GNU/Linux [1], [2], [3] and [4].

 * All game data is moved into the /data folder. Music, Fonts, FMVs,
   Locales are in their own folders, since they aren't updated
   frequently. This folder is reserved only for official files, so
   no mods should drop something here.

That's no change really, that's a description of the current situation.

 * Documents and documentation will be found in /docs instead of
   loose in the root directory.

Aside from a few files like AUTHORS, COPYING, README, etc. that's the
case already, and for these files I'd like to keep it that way.

 * The /mods folder stays the same, but gets an additional sub
   folder. Mods are categorized into 3 categories: Global for mods
   which are for both, single player and multi player. Single- or multi
   player/skirmish-only mods. The /mods/gametype/autoload folder is
   intended for mod packages which should be auto-loaded. However, Giel
   said that he wants to get rid of these folders, so there is a
   configuration file /mods/mods.cfg where auto loading can be
   defined or a certain loading order for mod-stacking.

Yes, I think we should specify autoloading of mods in a configuration
file. The /autoload/ directory is just a quick hack to achieve
autoloading behaviour for non-standard (i.e. not base.wz or mp.wz) mods.

Additionally I would actually like to get rid of the distinction between
single and multi player mods. I'd rather have global mods and
campaign mods (i.e. mods that add a new campaign or modify change the
story of existing campaigns).

 * new folder called /tools. A reserved folder for tools (surprise!)
   which can/will be shipped with future releases. Like an launching
   app, scripts or a map editor.

I don't think we should ship development tools in the same source
tarball or binaries as Warzone itself.

 * The normal config file has been renamed to config.cfg
 ... snip ...

Adding an extension is fine with me.

 * The multiplay folder has been renamed to cache. Since
   AIvolution stores some cache files there, this directory could be
   used as a caching-directory for all kind of mods. (Whats about
   customized SQLite databases as well, when the props-files are
   replaced?)

You do realize that what AIvolution stores is *not* cache data right?
And modified stats are *definitly* not cache. Cache is precalculated
data that has been stored to speed up loading or skip a computation
phase.

 * /multiplay/custommaps has been moved and renamed to /maps. A
   simple folder where people can drop custom map files. It could also be
   used as storage for automatic downloaded maps. (from other players,
   for example)

Maps already reside in /maps... (Although /multiplay/custommaps exists
as well, removal of that might be an option).

 * Added a /mods folder, which has exactly the same structure like in
   the application dir. This should be used for user- and automatically
   downloaded mods. In the case of conflicts, the mods in the user
   directory should always override the global mods.

We currently have /mods/global which is not that much different.

 * /screendumps becomes