• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion Better code bookmarks?

MilesThatch

Member
Currently we have the basic code bookmarks which allow you to assign a quick bookmark to any one of the number keys ctrl + Shift + 1 to 9.

I mean, its ok. But to be honest I know that most of us working on a larger project will have a step event on some master objects that is breaking the 4k lines of code by now. 9 bookmarks is really not enough. Not only that, you have to memorize which of the 9 bookmarks belongs to where. So the whole system kida falls apart.

What do you think of a bookmark index tab in the same sense as the index tab of out help manual or the CTRL+T menu. A small tab on the side of the code window which would have the index of all the bookmarks (Infinite bookmarks too, or at least a cap of maybe 200) and the ability to rename the bookmarks names.

I know you can use #region to organize and text search to find specific keywords you could place in the code but as long as we already have the concept of bookmarks to acknowledged the fact that there HAS to be a better solution to the workaround I mentioned, we might as well go all the way, wouldn't you say?

Not that it's an development breaking problem, just that the bookmarks as they are right now represent something I'd see on a windows 98 era software.
 

gnysek

Member
I've made a regions, and there are shortcuts to fold/unfold them (Ctrl+M, Ctrl+U and Ctrl+Enter if I remember correctly?), which seems to be better than bookmarks (even 10-20 regions is still visible on screens without scroll, you can unfold the one you want with Ctrl+Enter and then fold all again).

The only issue is that you cannot fold region pressing Ctrl+Enter on #endregion, only on #region.
 

MilesThatch

Member
Regions still have to be found using the "Search Text" feature and it has a nasty side effect of unfolding all the regions. Or at least ones that match the text so once you start typing the search query, it will unfold any and all regions that contain it even if you're not done typing in the search term. So you basically still stuck with using the search tool.

You see, with game maker 1.4 it was easier because you could have 1 code node for every separate task you want. In 2.0 you only get 1 code window if you chose code project instead of DnD project. And opting in for DnD project mode just so that you'd get that separate code window for each task is an overkill and not the way the DnD system was meant to be used.
 
Last edited by a moderator:

Mike

nobody important
GMC Elder
Use #region and #endregion to "fold" your code.

Code:
#region  Player Movement
  // blah
#endregion

#region  Player Collision
  // blah
#endregion
 

MilesThatch

Member
Use #region and #endregion to "fold" your code.

Code:
#region  Player Movement
  // blah
#endregion

#region  Player Collision
  // blah
#endregion

Yes, thanks Mike. There's still a flaw, as I mentioned in the response, when you have a large amount of code with many regions and sub regions, you have to resort to using the search text tool in the code window, which will unfold many regions in the process.

I mean who would argue that a small tab to the side that lists all the bookmarks by the name is a bad idea? Heck, maybe you could add a special region description like we have with scripts using the @ sign. Maybe like @bk "Movement Code" and that will add that as a bookmark to that tab.
 

Mike

nobody important
GMC Elder
If it's that large, then I humbly suggest you should probably be using multiple scripts.

You should never get to the point where a single script or event is that large. Break it up into multiple scripts, this is just good practice for any programming language - ask any experienced professional coder and you'll get the same answer.
 

MilesThatch

Member
You mean use actual scripts resources to break apart the code? I get your logic, it would be a work-around for now, but in 1.4 we had multiple code nodes that did exactly what you're suggesting here AND you could also still use scripts if you wanted to. One other problem with scripts is that Object specific Variable and Function suggestion won't appear in nested scripts as far as I've tested.
 
If it's that large, then I humbly suggest you should probably be using multiple scripts.

You should never get to the point where a single script or event is that large. Break it up into multiple scripts, this is just good practice for any programming language - ask any experienced professional coder and you'll get the same answer.
There's overhead to calling scripts, right? And I don't want ten thousand scripts making my resource tree and intellisense into a mess.

An experienced coder might tell you to constantly use scripts...if he didn't mind those two problems I mentioned. He might also suggest breaking up large classes into multiple files, which is basically what separating events into multiple blocks used to be.

I just made a topic about this too, Mike. Please think about our suggestions. My productivity should be *higher* in GMS2 than GMS1, not lower! Different people work faster with different ways of organizing and doing things. I hope you'll give these posts some thought. Thanks! =)
 
Last edited:

Mike

nobody important
GMC Elder
It's pretty minimal... and if you're that worried, use YYC and then gml_pragma("forceinline") and that will tell the compiler to INLINE the script.This acts as a hint to the compiler and as such only works with YYC.

http://docs2.yoyogames.com/index.ht...4_gml_reference/miscellaneous/gml_pragma.html

"forceinline" - When the function is called with the "forceinline" pragma in a script resource, the YYC will compile the project with the script inline, rather than referenced. This will give a further processing boost, but care must be taken when using it as it will also inflate the final executable file size, especially if the in-lined code is large and/or used in multiple different places, as well as greatly increase the compile time.
 

gnysek

Member
"forceinline" pragma in a script resource, the YYC will compile the project with the script inlin
But it's only for YYC, not for VM (which is "default" export for games). So in most cases this settings wont change anything (especially when testing game which is faster to run on VM).
 
Z

Zeralith

Guest
I feel like Bookmarks could really use another look at, at YoYo Games.

Beyond just "Code" Bookmarks (that MilesThatch is talking about above), Bookmark issues actually extend to "Editors" as well. There are also some Users still unhappy with not having separate Event Code Blocks in GameMaker 2 and some Users also do not like the way Regions are implemented, at the moment (I personally love my Regions now in GameMaker 2!). Having better Bookmarks could really help curb/appease some of these Users further.

Bookmark related things and issues, which I think would be extremely amazing to add/fix, include:
  1. A new Bookmark UI needs to be added to the "Window" Menu. This new UI would show all the Bookmarks that have been added by a User and could look similar to the "Recent Windows" or "Workspace Overview" Windows. Having a UI like this would be even more important if implementing items I listed below.

  2. Bookmarks currently DO NOT save. They don't save with the "Layout" and they don't save with the "Project" either. I know there have been talks between the YoYo Devs to get Bookmarks saving with the "Layout" but I don't think this is good enough. Here's why Bookmarks should save with the "Project" and also Save each Bookmark ALONG WITH the User's YoYo Account Number:

    1. If you are working on your desktop computer and you have a ton of Bookmarks set, but suddenly need to leave... you then Save your Project and Check-in your code to Git. Then you grab your laptop and run out the door. Then you get to StarBucks and decide to Pull from Git and start working again, for like an hour or two. Unfortunately, your Bookmarks DO NOT exist because they WERE NOT Saved with your Project, so you can't continue with your work easily. Saving Bookmarks WITH the Project would be a wonderful addition to actually implement in GameMaker 2, for this exact scenario.

    2. And this is why saving Bookmarks in the Project ALONG WITH the User's YoYo Account Number should be implemented: If you are working on a Team, all the Users on the Team should have their own Bookmarks that are Saved WITHIN the Project, which gets Checked-in to Git. This is also why a new Bookmark UI needs to be added to GameMaker 2, as well. My co-worker Ted might say, "Just look at my Bookmark #3 and you will see where the problem is at." Then I can just open the new Bookmark UI and check the "Show All Bookmarks from Other Users in this Project" Checkbox, to view Ted's Bookmarks.

  3. Some Editors, like the Room Editor, can have a Bookmark set... but there is NO visible Bookmark Icon to show the User what is actually Bookmarked, even though Bookmarks are fully working here. This probably needs to be fixed with actual Icons, but also it would be HELPFUL to have a new Bookmark UI added to the "Window" Menu for this, as well.

Anyway, I know there is a TON of stuff that YoYo Games are working super hard on right now, and I definitely appreciate the software's current state we have right now... but if anyone at YoYo Games thinks these types of situations/scenarios are good nice to haves, they might want to take a deep look at what some of us are asking for.

Thank you!

- Luke
 
Last edited by a moderator:
It's pretty minimal... and if you're that worried, use YYC and then gml_pragma("forceinline") and that will tell the compiler to INLINE the script.This acts as a hint to the compiler and as such only works with YYC.

http://docs2.yoyogames.com/index.html?page=source/_build/3_scripting/4_gml_reference/miscellaneous/gml_pragma.html

"forceinline" - When the function is called with the "forceinline" pragma in a script resource, the YYC will compile the project with the script inline, rather than referenced. This will give a further processing boost, but care must be taken when using it as it will also inflate the final executable file size, especially if the in-lined code is large and/or used in multiple different places, as well as greatly increase the compile time.
I'm more concerned with the organization of my code and being able to quickly navigate my projects honestly, Mike, though the performance was an issue, too. I made another thread here [ https://forum.yoyogames.com/index.p...older-versions-of-gm-or-shaded-regions.44153/ ] that I'd love for you to check out if you have the time. I made a few mockups of what I think would be big quality of life improvements for GMS2. Thanks for your time, as always.
 
Top