Feedback Improving local asset importing

[JeffJ]

As we know, the very missed feature of being able to import our own local asset packages will be returning at some point in the future.

This had me thinking, that this is a good opportunity to improve it rather than just re-implementing it.
One area where I personally wanted it to be better in GMS1 was the fact that if I made updates to my module, then I had to manually re-import some or all of the new resources.

What if there was a better way to more dynamically reference the changes to an external module used within a project? What if you could somehow "link" an external module to a project and commit changes from the module to one or more "linked" projects?

Any ideas or thoughts? I personally find that making these external modules and libraries are an amazing way of saving time and coding with flexibility and scalability in mind. I can't wait to have this feature back in GMS2, but it could be even better, and the time to make these suggestions is now, rather then when it's already made.

My thinking is to take whatever thoughts and feedback is made here, make an official suggestion ticket, and link to this thread.

 

[GMWolf]

How about git submodule support?
I guess GM would need to change a little too, like having heirarchical project structures.

 

[Homunculus]

I'd definitely love to see some improvements on the asset import process. Speaking primarily from a marketplace point of view, right now those are the main areas I hope to see improved:

• Namespacing: being sure that importing an asset into an existing project would not cause any conflict with the current resources would be great. It's also beneficial to keep big projects better organized
• Submodules: Not so sure I'm using the same definition as @GMWolf or @JeffJ for this, but I'd love to be able to "split" the core of a library from the optional content like demo code or snippets or plugins that are there just to help the final user getting a hang of how everything works or extend the main functionalites. Right now I have to explicitly instruct the user on what to import as a base and what to import only to look at as an example to get started.
• Refactoring: Updating an asset package sometimes means changing or removing scripts and resources. As long as those changes affect only a few internal references in the package itself it's not a problem, but most of the time when updating an asset in an existing project, there's a lot of references that require refactoring, and right now there are no tools for that except the find and replace functionality.

I understand that the points above probably are not easy to implement, I can see why refactoring could be problem due to GML syntax and how game maker works in general, but I still hope to see some changes in the future in this regard.

 

[GMWolf]

Namespacing should be a breeze to implement.
But I have the feeling that YYG currently gives no ****s about GML, and that the code they are working with is anything but robust. (Evident by many features which should naturally fall out of a well specified language, but that GML does not have, e.g. Chained accessors)

 

[Homunculus]

@GMWolf I understand where you come from and you are not alone, this has been discussed over and over now, but I think the goal of this topic is to collect some feedback, not to start a rant about the current state of the program. When there's a problem (and you want to solve it), you need start talking about the possible solutions in a productive way.

 

[True Valhalla]

While this isn't quite what you're talking about, I really wish this asset import functionality was built into GMS2 by default. That specific extension doesn't support Mac