View source for E32 Profiles

E32 Profiles: A facilitator for modules and mutators.

This is Hendricks266's working space for designing e32 profiles, the replacement for autoload, mod batch files, etc.

To the editors: Feel free to add content or notes, but please do not delete anything. (MediaWiki does contain a revision history, in any case.)

==Overview==

A profile is a unit describing a modification of some sort. Each profile contains in essence tokens similar in function to the available command-line parameters. Profiles can be mixed and matched by modifying the cfg file once parsed, by passing command-line arguments, or in a GUI interface.

Words formatted like "<u>this</u>" refer to the actual commands used in profiles.

==profile features==
*loaded from files with .e32 extension containing any number of "<u>profile</u>" entries
*each profile can be toggled on/off
*customizable load order to the extent that tree hierarchy and "<u>depend</u>", "<u>conflict</u>", "<u>tie</u>", etc restrict
*utilizes def parser (Lua in future)
*command line switch <reference name> to enable profile entries (additive, but subject to changes by the program)
*if a profile is ever force-disabled due to a conflict, its previous on/off status is never lost
* data stored in .cfg for each profile, allowing non-GUI editing (cross-platform cop-out)
**load order
**reference name
**.e32 file name
**on/off state
*descriptive log output for final selections once game is initiated

===acquisition/loading of .e32 files===

'''This section needs more thought. Any and all input is welcome on the talk page.'''

*all *.e32 in entire subfolder tree of both main directory and any path directories will be parsed
*command line switch <filename> to install *.e32 (add to .cfg for parse)

=== syntax ===
*"<u>name</u>" { }: two names
**"<u>reference</u>" <technical_name>
**"<u>proper</u>" <Display Name>
*"<u>version</u>" <float>: for each mod, mutator, etc (possibly version checker/downloader?)
*"<u>autoload</u>" flag: default on (HRP, music pack) vs. default off (mod)
*"<u>game</u>" <string>: 
**Some method of describing a set of supported EDuke32 games for which a profile can run.
**Profiles not matching the current selection of the game tab are simply not shown.
**An incomplete tree follows. In this example any bullet point can be used and all include any descendants. Naming is inexact and for illustration only.
***global
****'''Ken-BUILD (Test Game)'''
****'''duke3d-based'''
*****''duke3d-family''
******duke3d
*******duke3d shareware
********duke3d shareware v0.99 beta
********duke3d shareware v1.0
********duke3d shareware v1.1
********duke3d shareware v1.3D
*******duke3d registered
********duke3d registered v1.3D
*********duke3d registered v1.3D United States
*********duke3d registered v1.3D South Korea
********duke3d registered v1.4/v1.5
*********duke3d_atomic_dukedc
*********duke3d_atomic_nwinter
*********duke3d_atomic_vacation
******nam-based
*******nam-family
********nam
********napalm
*******ww2gi
*****''redneck-family''
******rr
******rrra
******redneckdeerhuntin
*****''paintbrawl''
****'''sw'''
****'''blood'''
****'''tekwar'''
****'''exhumed-worldwide'''
*****''PowerSlave''
*****''Exhumed''
*****''Seireki 1999: Pharaoh no Fukkatsu''
****'''witchaven-family'''
*****''witchaven''
*****''witchaven2''
****'''corridor8'''
****'''lo7p'''
****'''fate'''
*"<u>commands</u>" { }: contains list of files/data to load
**"<u>basedir</u>" (-game_dir)
***Note: This changes the "Custom game content directory" in the startup window. Perhaps it should be a user setting, off-limits to mods.
**"<u>dir</u>" (-j)
**"<u>grp</u>"/"<u>zip</u>"/"<u>pk3</u>"/"<u>pk4</u>" (-g)
**"<u>con</u>" (-x)
**"<u>def</u>" (-h)
**"<u>con_module</u>" (-mx)
**"<u>def_module</u>" (-mh)
**"<u>rts</u>" (-rts)
**"<u>map</u>" (-map)
**"<u>clipmap</u>" (-clipmap)
**"<u>demo</u>" (-d)
*"<u>depend</u>" <profile>: the profile (or sub-profile) is disabled if the specified dependency is absent or off
*"<u>conflict</u>" <profile>: The profile will automatically turn off if the specified one is turned on. (example: XXX Pack vs. XXX Lite)
*"<u>base</u>" flag: Only one profile with this flag can be on at a time. Useful for non-mutator base mods and TCs.
*"<u>library</u>" flag: indicates that the profile is a mod library intended for reuse and mashups, such as independent monsters; disqualified from autoload and sub-profiles
*"<u>include</u>" <profile>: like a "<u>depend</u>" but specifically for "<u>library</u>" profiles; silent

====sub-profile-specific features====
*displayed indented from the left immediately beneath parent
*sub-profile automatically "<u>depend</u>" on the parent
*by default, sub-profiles inherit properties like game and version from parent unless the value is overridden
*"<u>tie</u>" <profile>:
**sub-profile is ALWAYS enabled if both its parent and the specified profile are enabled, otherwise never
**has the capability to allow more than one "<u>base</u>" flagged profile to run (the profile with the tie command is loaded after the specified profile)
**the idea is to reconcile compatibility between mutators that may need it
**Always hidden from the GUI unless "verbose mode" is enabled

==implementation strategy==
#write simultaneously the source for parsing the profiles and for evaluating a valid selection state
#write new source file with the mechanics (game-independent)
#add GUI implementations, essentially all about displaying checkboxes and text (all decision making code in #3 not #4)

==def parser syntax examples==

 profile
 {
     name
     {
         proper "Name of Profile"
         reference "profile1"
     }
     version 1.0
     game "global"
     commands
     {
         con_module "con_module.con"
         def_module "def_module.def"
     }
 
     profile
     {
         name
         {
             proper "Sub-Profile"
             reference "profile1_1"
         }
         // etc...
     }
 }
 
 // alternate method of defining sub-profile:
 
 profile
 {
     name
     {
         name "Sub-Profile 2"
         reference "profile1_2"
     }
     depend "profile1" // note how the first use of depend here makes it a sub-profile
 }
 
 // HRP example
 
 profile
 {
     name
     {
         proper "High Resolution Pack"
         reference "duke3d_hrp"
     }
     autoload
     version 6.0
     game "duke3d"
     
     commands
     {
         dir "polymer_hrp"
         zip "duke3d_hrp.zip"
     }
 }
 
 // MyMod Example:
 
 profile
 {
     name
     {
         proper "My Mod"
         reference "mymod"
     }
     version 1.0
     game "duke3d"
     commands
     {
         con_module "mymod_specialeffects.con"
         def_module "mymod_new8bitart.def"
     }
     profile
     {
         name
         {
             proper "My Mod - HRP Extension"
             reference "mymod_hrp"
         }
         // version 1.0 // not necessary due to inheritance
         commands
         {
             def_module "mymod_hrp.def"
         }
         tie "duke3d_hrp"
     }
 }
 
 // Vaca+ Example:
 
 profile
 {
     name
     {
         proper "Duke Caribbean: Life�s A Beach Plus"
         reference "vaca_plus"
     }
     base
     game "duke3d"
     version 4.0
     commands
     {
         dir "vaca_plus"
         grp "vacation.grp"
         con_module "Vacation.con"
         def_module "Vacation.def"
     }
 
     profile
     {
         name
         {
             proper "Caribbean Duke Plus Extension"
             reference "vaca_plus_dp"
         }
         commands
         {
             con_module "VacaDP.con"
             def_module "VacaDP.def"
         }
         tie "dukeplus"
     }
 
     profile
     {
         name
         {
             proper "Caribbean XXX"
             reference "vaca_plus_xxx"
         }
         commands
         {
             con_module "VacaXXX.con"
             def_module "VacaXXX.def"
         }
         depend "xxx_pack"
     }
 
     profile
     {
         name
         {
             proper "Duke Caribbean: Life�s A Beach HRP"
             reference "vaca_plus_hrp"
         }
         commands
         {
             def_module "vacation_hrp.def"
         }
 
         // depend "vaca_plus" // not needed as it is a sub-profile
         tie "duke3d_hrp"
 
         profile
         {
             name
             {
                 proper "Caribbean HRP XXX"
                 reference "vaca_plus_hrp_xxx"
             }
             commands
             {
                 def_module "vacation_hrp_xxx.def"
             }
             depend "vaca_plus_xxx"
         }
     }
 }

==GUI mockup==

[[File:E32_profiles_mockup.png]]

This image is outdated in the following ways:
*Ideally, the Duke Plus Extension and "HRP XXX" would be hidden and transparent to the user because they would be <u>tie</u>d to the mutator for which they are a compatibility layer anyway.

[[Category:Developer's corner]]