Jump to content

E32 Profiles

From EDukeWiki

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 "this" refer to the actual commands used in profiles.

profile features

  • loaded from files with .e32 extension containing any number of "profile" entries
  • each profile can be toggled on/off
  • customizable load order to the extent that tree hierarchy and "depend", "conflict", "tie", 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

  • "name" { }: two names
    • "reference" <technical_name>
    • "proper" <Display Name>
  • "version" <float>: for each mod, mutator, etc (possibly version checker/downloader?)
  • "autoload" flag: default on (HRP, music pack) vs. default off (mod)
  • "game" <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
  • "commands" { }: contains list of files/data to load
    • "basedir" (-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.
    • "dir" (-j)
    • "grp"/"zip"/"pk3"/"pk4" (-g)
    • "con" (-x)
    • "def" (-h)
    • "con_module" (-mx)
    • "def_module" (-mh)
    • "rts" (-rts)
    • "map" (-map)
    • "clipmap" (-clipmap)
    • "demo" (-d)
  • "depend" <profile>: the profile (or sub-profile) is disabled if the specified dependency is absent or off
  • "conflict" <profile>: The profile will automatically turn off if the specified one is turned on. (example: XXX Pack vs. XXX Lite)
  • "base" flag: Only one profile with this flag can be on at a time. Useful for non-mutator base mods and TCs.
  • "library" flag: indicates that the profile is a mod library intended for reuse and mashups, such as independent monsters; disqualified from autoload and sub-profiles
  • "include" <profile>: like a "depend" but specifically for "library" profiles; silent

sub-profile-specific features

  • displayed indented from the left immediately beneath parent
  • sub-profile automatically "depend" on the parent
  • by default, sub-profiles inherit properties like game and version from parent unless the value is overridden
  • "tie" <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 "base" 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

  1. write simultaneously the source for parsing the profiles and for evaluating a valid selection state
  2. write new source file with the mechanics (game-independent)
  3. 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

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 tied to the mutator for which they are a compatibility layer anyway.
Retrieved from "https://wiki.eduke32.com/w/index.php?title=E32_Profiles&oldid=11731"