Custom Object Event Labels

[kevinchatham]

After some time using this extension I felt it would be nice to allow a custom label as a fallback for any object event label that fails to generate.

In this case, when the label fails to generate from the file name, I have used fs to read the first line of the file looking for /// @description. The description annotation is replaced with an empty string which leaves the file description as the label. An empty string is a fallback to this resuming default behavior.

Current version:

Patched version:

Example file contents:

/// @description Test

show_debug_message("Hello");

Sorry to not open an issue first, I dug into the code this morning and found the required change was relatively straightforward. It did not take much time. Thanks for the consideration and all of your work on this extension. I really prefer it over the default editor. 🍻

[adam-coster]

Oh, interesting. I like where you're going with this!

A few thoughts:

Missing Event Names

The missing event names are because I have to manually find how all of the file names map onto the event names, so I've only done that for events we currently use. Here's where I've done that:

https://github.com/bscotch/stitch/blob/3053279f24756ede8c219da949efa4094781ecfb/packages/parser/src/lib.objects.ts#L38

So the best way to get support for those missing ones would be to add them to that array and make a PR. I'm trying to have them exactly match the event names from the GameMaker IDE, so that's the main consideration.

Custom event names

This is something I hadn't considered, but I really like the idea. I'd do this a bit differently from how you did so that it would be more opt-in and so that it'd work how everything else does. Something like this:

• Add a new JSDOC tag for this specific purpose. Something like @eventname. That way people won't accidentally rename their events in the tree.
• During the GML parsing step, check for that tag and, if it's found, add its value to a field on the Code class
• Finally, update the tree logic (same place you did) to use that value if it's set.

I'll have to think about it a bit more before doing this, but it seems useful and I don't see any obvious downsides. This is something I'd tackle since it requires updating the parser logic, which is fairly complex.

[adam-coster]

Closed, with details converted into issues:

• https://github.com/bscotch/stitch/issues/212
• https://github.com/bscotch/stitch/issues/211