########################################################################################
# 			       Purpose of this file
########################################################################################

This File describes global scripting rules for Etheria developers.

########################################################################################
#     The Golden Rule....
########################################################################################

---> NEVER (EVER!) UPLOAD CODE, WHICH DOES NOT COMPILE!
     --------------------------------------------------
     Explanation: Etheria automatically syncs it's script base with CVS on a daily 
                  basis. A single compiler error, can thus prevent the shard from 
                  updating properly, possibly resulting on a complete crash of our
                  gameworld. Thus always compile your code BEFORE uploading it to CVS
                  and make sure, that it is free of errors and warnings.

########################################################################################
#     Further Script Rules....
########################################################################################

---> Donot use capital letters in filenames.
     ---------------------------------------
     Explanation: Etheria Shard runs on a unix Server. As opposed to windows, Unix
                  systems are case-sensitive. A script that runs on windows, may thus
                  encounter problems on the productive shard if cases donot match.
                  Even worse though, you may have both a "Readme.Txt" and a 
                  "readme.txt" on a unix server within the same sub-directory. For 
                  any dev working on windows though, downloading these files, they will
                  overwrite each other. 
                  In order to avoid such conflicts in the first place, never use 
                  capital letters in your file names!

---> Never use include statements in include files.
     -----------------------------------------------
     Explanation: POL095 is not able to handle double includes within a script. Thus if
                  you have two includes, both pointing to a same, third one, then you 
                  will have all functions double, and your compile will fail. 
                  Thus, if your include file is based on further includes, merely list
                  these as a comment in your file header. The actual include statement
                  can then be placed in the .src file itself.

---> Always put Etheria specific, global cfgfiles into the '<pkg>/cfgfile' subfolder.
     --------------------------------------------------------------------------------
     Explanation: While pol specific cfgfiles (e.g. the itemdesc.cfg) are always kept 
                  in your pkg' mainfolder, etheria specific cfgfiles are less known,
                  and should thus be kept in a seperate folder to simplify overview 
                  of what is a local package cfgfile only and what is a shared but 
                  Etheria specific cfgfile used in conjunction with other packages.
                  
                  These cfgfiles are known so far:
                        - igniteables.cfg       /pkg/abilities/igniting
                        - smithing.cfg          /pkg/crafts/smithing
                        
---> Always add documentation in a /docu subfolder to your package!
     ---------------------------------------------------------------
     Explanation: When other scriptes interfere with your package, it is important for
                  them to know, how to interact with your package. It is thus 
                  recommended, that you at least document all itemdesc entries specific
                  to your package, all cprops stored on items and characters as well as
                  any custom cfg files made available to other packages.
                  Even if things still seem logic and self explaining to you now, this 
                  may no longer be the case in a few years time... but even then, you 
                  may want to know what your scripts are doing. (I'll not mention that
                  additionally you should add plenty of commentary to the scripts 
                  themselves.. that's just way too basic a thing to do.)