E32 Profiles: Difference between revisions

Latest revision as of 08:08, 28 November 2013

@@ Line 5: / Line 5: @@
 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.)
-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.
+==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 profiles
+*loaded from files with .e32 extension containing any number of "<u>profile</u>" entries
-*toggle on/off
+*each profile can be toggled on/off
-*customizable load order
+*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)
-*command line switch <reference name> to enable profiles (additive, but subject to changes by the program)
-*utilizes def parser (Lua in future)
+=== syntax ===
-*"<u>name</u>" { }: two names, "<u>reference</u>" <name> and "<u>proper</u>" <display name>
+*"<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>: (global, duke3d-family, duke3d, nam, ww2gi) (theoretically [duke3d-based, sw, rr, tekwar, whaven-family, whaven, whaven2, corr8]); profiles not matching the current selection of the game tab are simply not shown
+*"<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
-**con (-x)
+**"<u>basedir</u>" (-game_dir)
-**def (-h)
+***Note: This changes the "Custom game content directory" in the startup window. Perhaps it should be a user setting, off-limits to mods.
-**conmodule (-mx)
+**"<u>dir</u>" (-j)
-**defmodule (-mh)
+**"<u>grp</u>"/"<u>zip</u>"/"<u>pk3</u>"/"<u>pk4</u>" (-g)
-**grp/zip/pk3 (-g)
+**"<u>con</u>" (-x)
-**basedir (-game_dir)
+**"<u>def</u>" (-h)
-**dir (-j)
+**"<u>con_module</u>" (-mx)
-**rts (-rts)
+**"<u>def_module</u>" (-mh)
-**map (-map)
+**"<u>rts</u>" (-rts)
-**clipmap (-clipmap)
+**"<u>map</u>" (-map)
-**demo (-d)
+**"<u>clipmap</u>" (-clipmap)
-*if a profile is ever force-disabled due to a conflict, its previous on/off status is never lost
+**"<u>demo</u>" (-d)
-*reference name, .e32 file name as passed to the game (absolute and relative accepted), and on/off parsed to .cfg in load order
-*parse to cfg to allow for non-GUI editing (cross-platform cop-out)
 *"<u>depend</u>" <profile>: the profile (or sub-profile) is disabled if the specified dependency is absent or off
-*all top-level profiles automatically placed in load order immediately below all of their "<u>depend</u>" statements
 *"<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
-*descriptive log output for selections
-==sub-profile-specific features==
+====sub-profile-specific features====
 *displayed indented from the left immediately beneath parent
-*sub-profile "<u>depend</u>" on the parent
+*sub-profile automatically "<u>depend</u>" on the parent
-*by default inherit properties like game and version from parent unless the value is overridden
+*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)
+*"<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==
@@ Line 66: / Line 130: @@
       commands
       {
-          conmodule "conmodule.con"
+          con_module "con_module.con"
-          defmodule "defmodule.def"
+          def_module "def_module.def"
       }
@@ Line 90: / Line 154: @@
           reference "profile1_2"
       }
-      subprofile "profile1"
+      depend "profile1" // note how the first use of depend here makes it a sub-profile
   }
@@ Line 126: / Line 190: @@
       commands
       {
-          conmodule "mymod_specialeffects.con"
+          con_module "mymod_specialeffects.con"
-          defmodule "mymod_new8bitart.def"
+          def_module "mymod_new8bitart.def"
       }
       profile
@@ Line 139: / Line 203: @@
           commands
           {
-              defmodule "mymod_hrp.def"
+              def_module "mymod_hrp.def"
           }
           tie "duke3d_hrp"
@@ Line 161: / Line 225: @@
           dir "vaca_plus"
           grp "vacation.grp"
-          conmodule "Vacation.con"
+          con_module "Vacation.con"
-          defmodule "Vacation.def"
+          def_module "Vacation.def"
       }
@@ Line 174: / Line 238: @@
           commands
           {
-              conmodule "VacaDP.con"
+              con_module "VacaDP.con"
-              defmodule "VacaDP.def"
+              def_module "VacaDP.def"
           }
           tie "dukeplus"
@@ Line 189: / Line 253: @@
           commands
           {
-              conmodule "VacaXXX.con"
+              con_module "VacaXXX.con"
-              defmodule "VacaXXX.def"
+              def_module "VacaXXX.def"
           }
           depend "xxx_pack"
@@ Line 204: / Line 268: @@
           commands
           {
-              defmodule "vacation_hrp.def"
+              def_module "vacation_hrp.def"
           }
@@ Line 219: / Line 283: @@
               commands
               {
-                  defmodule "vacation_hrp_xxx.def"
+                  def_module "vacation_hrp_xxx.def"
               }
               depend "vaca_plus_xxx"
@@ Line 229: / Line 293: @@
 [[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]]