Higor
07-11-2012, 11:01 PM
Given that Siege is a mod that continues to update, adding fixed Siege-only features to maps results harder than usual.
We're not talking about a package that gets patched in an incremental fashion but instead of many different versions/releases that run on the same maps.
The problem here is package dependancy, if we add a Siege specific feature into a map, this map will need to run this specific version of Siege, unless we overlap various Siege package with matching class names in an ugly way (see: Monsterhunt2).
In order to solve this, Siege should be a two-part package set, following these mechanics:
1). Main package: contains functionality and variable media, loaded as gametype determines the core gameplay features, may be replaced upon upgrades.
2). Construction package: contains map specific features, with zero code dependency, old versions remain for already built maps to use, upgrades to be used within new maps.
Example:
2 Maps:
- Map1, uses XC_Siege_r1
- Map2, uses XC_Siege_r2 (has extra features compared to r1)
2 Servers
- Server1, uses SiegeUltimate
- Server2, uses a Players vs Monster variant (let's call it SiegeCoop)
When Server1 runs Map1 it will load XC_Siege_r1 and SiegeUltimate, when it cycles to Map2 it will load XC_Siege_r2 and SiegeUltimate.
When Server2 runs Map1 it will load XC_Siege_r1 and SiegeCoop, when it cycles to Map2 it will load XC_Siege_r2 and SiegeCoop.
Why this?
Even newest Siege packages contain old objects like ZoneInfos and map specific messages.
This means that there was intention to build Siege specific maps with these features but became impossible as branching and updates came, solving this would have taken a similar approach as Monsterhunt.
Putting these objects in a separate package will make Siege specific maps with Siege only features possible across versions and branches.
Notes:
- In order to make the Fixed package system more versatile, it should only be code based to make file transfers immediate.
- Not generating code dependancy requires the Fixed package to interpret known, but not referenced objects on the main package, having access to their features.
- The Fixed package will be upgraded when necessary, and older maps don't need to load the new versions.
- Fixed packages are separated by version names and all coexist on both client and server ends, for obvious reasons a map won't be able to load both at the same time.
- Fixed packages are not ServerPackages, the loading the map itself will make the servers send said packages.
Things I've already added into a test package:
- XC_CleanPath (NavigationPoint)
Does not spawn RU cristals in this place.
Triggerable, ON and OFF states per trigger.
- XC_TelePath (NavigationPoint)
Allows bots to use player made teleporters.
- XC_sgB_Trigger (Triggers)
Detects visible (type can be specified) buildings in specified radius, team is optional, triggers and untriggers events.
We're not talking about a package that gets patched in an incremental fashion but instead of many different versions/releases that run on the same maps.
The problem here is package dependancy, if we add a Siege specific feature into a map, this map will need to run this specific version of Siege, unless we overlap various Siege package with matching class names in an ugly way (see: Monsterhunt2).
In order to solve this, Siege should be a two-part package set, following these mechanics:
1). Main package: contains functionality and variable media, loaded as gametype determines the core gameplay features, may be replaced upon upgrades.
2). Construction package: contains map specific features, with zero code dependency, old versions remain for already built maps to use, upgrades to be used within new maps.
Example:
2 Maps:
- Map1, uses XC_Siege_r1
- Map2, uses XC_Siege_r2 (has extra features compared to r1)
2 Servers
- Server1, uses SiegeUltimate
- Server2, uses a Players vs Monster variant (let's call it SiegeCoop)
When Server1 runs Map1 it will load XC_Siege_r1 and SiegeUltimate, when it cycles to Map2 it will load XC_Siege_r2 and SiegeUltimate.
When Server2 runs Map1 it will load XC_Siege_r1 and SiegeCoop, when it cycles to Map2 it will load XC_Siege_r2 and SiegeCoop.
Why this?
Even newest Siege packages contain old objects like ZoneInfos and map specific messages.
This means that there was intention to build Siege specific maps with these features but became impossible as branching and updates came, solving this would have taken a similar approach as Monsterhunt.
Putting these objects in a separate package will make Siege specific maps with Siege only features possible across versions and branches.
Notes:
- In order to make the Fixed package system more versatile, it should only be code based to make file transfers immediate.
- Not generating code dependancy requires the Fixed package to interpret known, but not referenced objects on the main package, having access to their features.
- The Fixed package will be upgraded when necessary, and older maps don't need to load the new versions.
- Fixed packages are separated by version names and all coexist on both client and server ends, for obvious reasons a map won't be able to load both at the same time.
- Fixed packages are not ServerPackages, the loading the map itself will make the servers send said packages.
Things I've already added into a test package:
- XC_CleanPath (NavigationPoint)
Does not spawn RU cristals in this place.
Triggerable, ON and OFF states per trigger.
- XC_TelePath (NavigationPoint)
Allows bots to use player made teleporters.
- XC_sgB_Trigger (Triggers)
Detects visible (type can be specified) buildings in specified radius, team is optional, triggers and untriggers events.