Feature: Add mid-note read capability to Array notes similar to

[suspect15]

Issue: Array notes calculate the offset and show it at the top of the tooltip, but they do not hide unreferenced data the same way AddAddress note tooltips do.

Array note tooltip:

AddAddress note tooltip:

Array notes continue to be very useful, especially with advanced consoles. Currently, a significant disadvantage to using them is usability for future maintainers. With a large array note, the tooltip would be quite unwieldy.

Truncated large array note tooltip:

Request - add similar mid-note read functionality that strips out unreferenced data for array notes similar to how AddAddress handles mid-note reads. Additionally, having Array notes

[Jamiras]

What you're describing is a structure, not an array. Most pointers point to a structure, so we annotate them accordingly:

[32-bit] pointer to struct
+0x00 = [32-bit] first field
+0x04 = [32-bit] second field
+0x08 = [32-bit] third field
1=third field enum value
2=third field enum value
3=third field enum value
+0x0C = [32-bit] fourth field

You're essentially asking for a non-pointed at structure:

[16-bytes] struct
+0x00 = [32-bit] first field
+0x04 = [32-bit] second field
+0x08 = [32-bit] third field
1=third field enum value
2=third field enum value
3=third field enum value
+0x0C = [32-bit] fourth field

[Jamiras]

An array is when an element is repeated multiple times. An array of 8 bytes is just 8 single-byte values. An array of 10 32-bit values is 40 bytes, where every fourth byte starts a new 32-bit value. An array of structs is just repeated structured data.

Continuing with my example above, this is how I plan to support arrays of structs (eventually):

[10x16 bytes] array description 
+0x00 = [32-bit] first field
+0x04 = [32-bit] second field
+0x08 = [32-bit] third field
1=third field enum value
2=third field enum value
3=third field enum value
+0x0C = [32-bit] fourth field

That would annotate 160 bytes of data, where every 16th byte is first field, then the 4th byte after that is second field, etc. So, if the note were at $001000, a reference at $001028 would get decoded to:

0x001028 (0x001000[2] + 8)
[32-bit] third field
1=third field enum value
2=third field enum value
3=third field enum value

I'm still trying to come up with the best way to annotate the path. The illustration is showing my current preference.

• 0x001000[2] + 8 - array at $1000, index 2, offset 8
• 0x001000 + 0x20 + 8 - array at $1000, 20 bytes in to element, offset 8
• 0x001000 + 0x28 | element 2 of array description, offset 8 - fully explicit using note header "array description"

[suspect15]

I appreciate the clarification on the terminology. I'll close this discussion since it's already something you are tracking. Thanks for the thorough response.