About the naming convention: the prepended 'K' denotes something extended/in addition to regular sections, in a CHK file/StarCraft map, be it a section, string, etc.
Why a prepended 'K'?
Current extended sections:
KSTR - Extended String
KTRG - Extended Trigger Struct
KTGP - Trigger Grouping
KTRG - Extended Trigger Data
Title: KTRG
Size: at least 4 bytes
Format:
VersionNum - 4 bytes
(the rest of the format depends on VersionNum, see below)
Version 1
Version 2
KTGP - Trigger Groups
Title: KTGP
Size: at least 4 bytes
Format:
VersionNum - 4 bytes
(the rest of the format depends on VersionNum, see below)
Version 1
TRIG Changes
An entry is needed in the existing trig struct to prevent easily losing extended data when using programs that don't acknowledge it. Notice that within the existing trigger struct, a byte is allocated to denote whether a trigger executes for a given player, and many of these players are never used anyway (though some mappers use them as a primitive form of documentation/storage/templates).
So, within the existing TRIG struct we can define the following:
- possibleExtendedData = the 4-byte number given by a triggers execution bytes for playerId 22-25 (Unknown(23-26) in SCMDraft)
- if (possibleExtendedData&0xFEFEFEFE) > 0 then the bytes are used as extended data by mapping programs and therefore...
- extendedTrigDataIndex = (possibleExtendedData&0x00FFFFFF), which you can use to get the extended trigger data from the KTRG section.
- groupedWithPlayerId22 = (possibleExtendedData&0x10000000)
- groupedWithPlayerId23 = (possibleExtendedData&0x20000000)
- groupedWithPlayerId24 = (possibleExtendedData&0x40000000)
- groupedWithPlayerId25 = (possibleExtendedData&0x80000000)
- if (possibleExtendedData&0xFEFEFEFE) == 0 then the bytes are not used by mapping programs and should be treated as regular players.
It's setup this way to ensure that the players (ID:22-25) can still be used by the mapper (even though they don't run in SC) without editors thinking there is extended data; as well as allowing these players to be used by the mapper when a trigger uses extended data (though I don't necessarily know why you'd want to). Consequently extendedTrigStruct indexes 0, 1, 256, 257, 65536, 65537, 65792 and 65793 are never used; and extendedTrigStruct indexes have a hard max of 0x00FFFFFF (well above the maximum amount of triggers you can have).
Closing Notes
- Indexes to extended trigger data contained by triggers should be considered the most valid, if the extended trigger data has the wrong trigger number, update it.
- Indexes to groups contained by extended trigger data should be considered the most valid, if a group has the wrong trigger number(s), update it/them (though these should be kept up to date by any editor using these extended sections).
- Groups should show up under all players they execute for
- Top level groups should show at a level equal to, or in an area separate from executing players.
- Executing players are special groups, and may not be contained inside other groups
- Triggers may only belong to one group (not counting executing players)
- Groups may contain triggers and/or more groups
- Groups may not contain groups within their parent tree
- In the future, groups may be generated from "templates", and the options you used to generate it will be saved (for example you may have used the following parameters to generate addition triggers: lhs="Cave", rhs="Cantina") so you can easily change them; this will require another section definition.
These are not yet in use, shout out any issues/things that should be included
Post has been edited 10 time(s), last time on Oct 22 2015, 3:40 am by jjf28.
TheNitesWhoSay - Clan Aura - github
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.