Here i'll be outlining two more CHK sections as I previously did with KSTR (extended strings). First is KTRG (extended trigger data), the second is KGRP (trigger grouping data), following which i'll go over how the extendedTrigData index is stored in the existing TRIG section.

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.


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)

---

KTGP - Trigger Groups

Title: KTGP
Size: at least 4 bytes
Format:
    VersionNum - 4 bytes
    (the rest of the format depends on VersionNum, see below)

---

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.

I wonder how I didn't notice this earlier. You know, I personally support a bit different approach to triggering via text, but this sounds solid for a GUI version.

I got one concern. Tell me if I'm reading right (format version 1) that TriggerGroupHeader flags groupExpanded and groupHidden store information about current view of triggers (if the group is currently expanded/collapsed/hidden in the editor)? This way, collapsing a few groups without changing data will cause the map to be marked as "changed". Probably putting representation data and the real data in one place isn't best design decision, but frankly speaking I don't know how to make it better.

Yea you're reading that right; personally I prefer to have info about collapses preserved from one day to the next in my code, which is why this is saved. As far as unsaved changes goes, in chkd if an operation is undoable it adds an unsaved change; if it's not undoable I have to explicitly signal the change which I may or may not skip in this case.