
    .(  script(                        core) .
    .( version(                        01r4) .
    .(  author(                       daedo) .
    .(   email(         cosmith@mix-net.net) .
    .(     www(  http://daedo.hypermart.net) .


    .( about  ) .
    . this is a very simple cosmetics script i wrote out of curiosity and
      interest in learning bx scripting. core is 100% clean code style and
      0% bloat. if you are looking for elite talkers and nasty coding, look
      elsewhere. if you are looking for nice clean code and a rich set of
      features, then core may be for you. it has a ton of formats and a
      very customizable format system. core also contains all the basic
      cosmetics functions like theme and tsave. a few online resource
      commands are included: download, inic, and dict. start with chelp, 
      config, format, and theme. if you have any ideas, questions, bugs,
      fixes, or want to submit a theme or format, email me at 
      cosmith@mix-net.net or find me on efnet as daedo.

    .( dcs    ) .
    . core is based on a philosophy/standard of scripting i developed called
      dynamic core scripting. i am in no way trying to claim that nobody has
      ever coded a script in this fashion, but if they have, none of the
      popular scripts these days reflect that. dcs is a very simple way of
      coding a script which allows for extremely easy customization and 
      addition of code by the author or any user providing instant
      integration of the new code. dcs is present in core in three different
      areas: formats, modules, and the ansi startup graphics. the basic idea
      behind dynamic core scripting is that the core of the script, ie the
      initialization script, the help system, the format system, etc, is 
      scripted with very little "hard coded" code, in that no actual file
      names are used, rather the script checks for new files; the help
      system topics and entries are not hard coded, rather they are dynamic
      according to what commands are available; the format system has no
      hard coded formats or ways of displaying formats, rather it relies
      upon actual seperate format files for display and loading. this
      allows, as previously mentioned, the ease for both the author and user
      of being able to add reletively any new code and have that new code
      instantly recognized and integrated by the script. although this may
      sound a bit long winded, the results are well worth it. here are some
      examples of how dcs is put to use in core:

      formats: if i or any user decided to add more formats to core, it can
      be done with extreme ease. with the directory/file structure for the
      formats in core, if one wanted to add another join format, and there
      were already ten formats in ~/core/formats/join, all that would have
      to be done is to create a new file called "join11" which contained the
      proper fsets for the new join format. core will then automatically 
      recognize and use this new format in the /format and /rformat (selects
      random formats for all types) commands. the only exception is the 
      status bar format. this requires the creation of a second file, 
      sbardemo(num), which contains three simple fsets for the display of 
      an example status bar used by /format.

      modules: if i or any user decided to add more modules to core, this
      too could be done with extreme ease. the module loading alias and
      stubbing aliases in the initialization script does not use hard coded 
      module or alias names, rather they load all of the *.m module files 
      in ~/core/modules and parse all modules for aliases to stub. the help
      system is also designed around dcs, with no hard coded topics or
      entries. instead, present in every module file is the use of the 
      /addhelp command, which adds a new help topic and entry which will be
      used by /chelp. the format for addhelp is simple:

      eval addhelp command&command syntax&description

      ie:

      eval addhelp join&join [channel]&joins a new channel.

      the config system is also designed with a dynamic core, with no hard
      coded toggles or settings. instead, present in every modules which 
      contains a new configurable option is the use of the /addconf command,
      which adds new config entries use by /config. the format for addconf,
      similar to addhelp, is as follows:

      addconf -[s|t] two letter abreviation&command description&variable 
              which holds the toggle's value&alias for setting the toggle

      ie:

      addconf -s as&auto save settings&autosave&autosave

      in the above example, as you can see when you type /config, "as" is 
      used as the toggle's abreviation, "auto save settings" is used to
      describe the toggle, $autosave is the variable which holds the value
      of the toggle, and /autosave is the alias that sets the toggle.
      the -s/-t flags are used to designate whether the config entry is a
      switch (-s), meaning something with a value of on/off or anything 3 
      characters or less, or has a text (-t) value, such as the default
      away message, which can be up to 32 characters long after which the
      value is truncated.

      to compliment the /addconf command there is the /addset command, which
      allows you to define your own user configurable variables and
      toggles that will be loaded at startup and saved with /csave along
      a default value for those variables. this syntax is:

      addset variable&default settings

      ie:

      addset autoaway&on

      this rather self explanitory example loads the variable $autoaway on
      startup with a default value of "on" and saves it's value on /csave.

      thus, any new modules which use these commands to update /chelp /config 
      and /csave will automatically be integrated into the script.

      start up ansi: this is a small detail, yet another instance in which 
      dynamic core scripting adds an ease of customizability. core, on
      startup, plays a random start up graphic. the way in which this
      alias is coded allows new files to be added to the ~/core/ansi/
      directory of the format core.(num) which will then automatically
      be used in the startup ansi.

      the main goal i have with dynamic core scripting is creating a script
      where anyone can add any new block of code to the script without
      having to actually alter the script's code, thus allowing users to 
      easily create there own modules, formats, themes, start up ansi, etc 
      for core. dcs also makes the actual script coding much easier for the
      author. once the dynamic core has been coded, it will automatically 
      use and integrate any code written from then on without having to ever
      touch the core code again. believe me, it's well worth it.

      okay, i'm off my soap box, i have no life, take what you will from
      that little rant.

    .(module system).
    .any module added needs three entries at the top of it:

	:short description
        :module/base
        :depencies

     the first entry should be a short (less than 20 chars) description of
     your module. the second entry will almost always be ":module" because
     i'm the only person that write base code for core =]. the third entry
     lists the modules that your module needs to work. ie, if it uses
     /addhelp, you need to have help.m in the entry. if it uses /addconf
     you need config.m in the entry. and example heading would be:

        :example core addon
	:module
	:help.m config.m

     "why must i do this?" because this makes your module compatible with 
     core's module system, allowing it to be loaded and unloaded with 
     /rmmod and /insmod and listed with /lsmod. have fun.

    .( greets ) .
    . mexis     : one sexy fuck.
    . ip        : provided me with many nights of masturbatory relief
    . butane    : why do you put up with all my questions?
    . chutz     : got me started back in the day
    . adrock    : your ansi makes me wet
    . gandalph  : i tried
    . frog      : mad graphics skills
    . xix       : hump my leg any time big boy
    . moogled   : you know you started all this right?
    . saber     : pheer his 10 minute while fried html
    . pawt      : my saq is bigger than yours!@#
    . grimmy    : hi!@#
    . tricky    : style style style...web page logo and formats.
    . xw        : flipme.to and a fellow backwoods mainer.
    . slack3r   : da hookup man.
    . sphere    : anski boy.
    . sapporo   : support, ideas, slick fuck
    . lindex    : endured questions, stubbing, thanks mang.
    . crippled  : hi
    . shiftee   : helped me get started...
    . RoboHak   : great help...
    . fudd      : your elite skankin border and great script page
    . WhiteDrgn : dalnet.m, bout time someone realized...
    . Lord_Devi : bugs, ai.m, vhost.m, newk.m, yes, it can be done.

    .(   eof   ).