GSTHD DK64 Edition v0.5.2 adds the option for a path hint's goal to be autofilled based on the text provided. If you were to input the text 258dt ash into a path hint textbox, the hint will be created as "AZTEC SHOPS" with the path goals of Key 2/5/8 & Diddy/Tiny phase automatically filled; saving you from dragging 5 images to the path hint. This fill is done in addition to the normal hint text autocomplete feature, and should not affect normal text input. This also does not affect any hint panels that don't have path goals (WoTH, Barren, etc).

These keycodes can be changed in the 'places' file to suit your preferences. The default codes (in dk64_places.json) are listed below:

Keycode	Associated Goal
K	DK Phase
D	Diddy Phase
L	Lanky Phase
T	Tiny Phase
C	Chunky Phase
F	Freeing Kongs
1-8	Keys 1-8
A	Army Dillo 1
O	Dogadon 1
M	Mad Jack
P	Pufftoss
G	Dogadon 2
R	Army Dillo 2
B	King Kutout
U	Krusha "Phase"

This feature is experimental and not finalized: it may change over time with user feedback. If you have any suggestions/complaints about this feature, go hunt down JXJacob and tell him about it.

• Typing a string of 'keycodes', followed by a space, and then whatever your normal hint text would be.
  • ex: 12d 5dt is added as "5DT" with path goals of Key 1/2 & Diddy
• If there is no space in your hint text, it will not attempt to autofill any paths.
  • ex: 5dt is added as "5DT" with no path goals; despite "5dt" containing all valid keycodes
• If there is a space and the first "word" contains a letter that does not line up with a valid keycode, it will leave the text as-is.
  • ex: 12dx 5dt is added as "12DX 5DT" with no path goals; "x" is not a valid keycode, and the text is presented as-in
  • This can be changed in the options menu (see below)

Scouring Hint panels also benefit from this feature. If you type "3 ash" into a dedicated scouring/quantity panel, the hint "Aztec Shops" will be added with the rightmost number autofilled to 3.

By default, this setting is disabled to avoid confusing first-time users.

By default, if the keycode string contains characters that are invalid (ie: not in the 'places' file), the autofill is aborted and the text is presented as-in. This is done so that text that isn't supposed to be keycodes isn't misinterpreted. By enabling this setting, it will ignore any invalid keycodes as long as there is at least one valid keycode in the string.

For example, with this setting enabled

• 12dx 5dt is added as "5DT" with the path goals of Key 1/2 & Diddy; "x" is an invalid code and is ignored, due to 1/2/d being valid
• x 5dt is added as "X 5DT" with no path goals; "x" is an invalid code, but with no valid codes the text is added as-is
• aztec shops is added as "SHOPS" with the path goal of Tiny; "t" in "aztec" is a valid keycode and therefore every other incorrect letter is ignored

In all methods, no change needs to be done for Scouring hints (PanelQuantity) to support the autofill.

This method relies on filling the Path Goal images embedded into each hint.

So long as your PanelWoth contains "PathGoalCount" with a value greater than 0, it will support the path autofill.

With panels with more than one path goals, the goal images will be spread across evenly (or as well as it can) in the order it is written. For example: If the panel has "PathGoalCount": 3 and the text 124dt ash is entered, the "AZTEC SHOPS" hint will autofill as such:

• Key 1 will be placed on Path Goal 1
• Key 2 will be placed on Path Goal 2
• Key 4 will be placed on Path Goal 3
• Diddy will be placed on Path Goal 1, wrapping back around to the start of the goals
• Tiny will be placed on Path Goal 2

AKA: the "2dos layout" method

This method relies on a 1-to-1 mapping of one PanelWoth per set of path Items.

• ie: for each Path Panel, there is a set of associated Items representing the path goals elsewhere on the layout

Each PanelWoth must contain the following:

• A "OuterPathID", which is a string unique to that panel
• "PathGoalCount": 0, otherwise it will attempt to fill the embedded Path Goals
• "NbMaxRows": 1, as each panel is for exactly 1 hint

Each "set" of Items that represent the path goals must contain the following

• "OuterPathID": "<PANELCODE>_<KEYCODE>", where:
  • <PANELCODE> is the unique code for the specific PanelWoth it should be associated with
  • <KEYCODE> is the keycode for the path item ("D" is Diddy, 1-8 are for keys 1-8, etc), IN CAPITAL LETTERS

NOTE: If you change the keycodes in the 'places' file, you will need to change the <KEYCODE> for the respective Item as well

For example, with a Panel with "OuterPathID": "MP1" you would want to set up:

• "OuterPathID": "MP1_D" would be a code for the Diddy phase icon
• "OuterPathID": "MP1_T" would be a code for the Tiny phase icon
• "OuterPathID": "MP1_4" would be a code for the Key 4 icon
• etc

To facilitate slightly less monotony when creating a dozen or more identical items in a layout, ItemGrids support the OuterPathID string and applies them to each item it places. The OuterPathID will be automatically prepended with the number in which it is placed: going left -> right and top -> bottom, starting at 0.

Example: With a grid of 2 columns, 6 rows, and "OuterPathID": "MP_D", the IDs of each Item will be created as such:

0MP_D	1MP_D
2MP_D	3MP_D
4MP_D	5MP_D
6MP_D	7MP_D
8MP_D	9MP_D
10MP_D	11MP_D

Therefore, the PanelWoths would need a OuterPathID of "0MP", "1MP", etc.

This method would rely on one PanelWoth (with multiple rows) that interacts with multiple sets of path Items. Similar to the above 1-to-1 method, but uses a single large panel instead of multiple small ones.

This functionality is currently unsupported, but is planned. Due to how panels handle a hint being deleted (where it reorders all hints, which would cause desyncs with the static image locations), a significant rewrite to the panel behaviour would need to be done. Too significant for a concept that doesn't have an official layout for it. I will get around to it eventually once I figure out how to best tackle it.