So, my argument isn't with this set of functions (collision_ ones), its with the general attitude of "I want all function built in and if you don't do it, your useless", when it's perfectly possible to write a script for it.
Yes, having a framework lets you have lots built in, but it is impossible to build everything into it, and implying that we will simply ignore you if you ever suggest one is not only under valuing everything we do actually do, but claiming we're too bone ass lazing to bother. Both these things are just wrong, and bitchy. I've implemented loads of common functions that lots of users have asked for, all of which were do-able in GML because, well....LOTS of users asked for it. It's a waste of time and resources to implement an engine level function if only 1 or 2 people want it. Even if 1000 want it, if we have no time to do it due to other considerations no one outside the company will know about, then as long as it can be achieved via GML then you should be fine.
Thanks for clarifying,
@Mike. That is a much more reasonable stance than what it seemed like you were saying a moment ago.
Granted, it's impossible to implement every feature that gets suggested. Over time, though, the highest priority stuff should (one would hope) stabilize to where there's little if any maintenance needed, and at that time you can give attention to lower priority features.
I don't think YYG are lazy, at all, but over the last year+ prior to GMS2 going into public beta, there was a perception on my part as well as others that YYG were not responsive to suggestions. (My most frequent response to Suggestion Box posts seemed to be something along the lines of "This is a good idea but we'll never do it in 1.x, and we're not taking anyone's suggestions at all for 2.x." tied with "This won't be done in 1.x and *maybe* we'll look into it in 2.x.")
Not taking any feature requests forward out of 1.x into 2.x is what really felt painful for me. Understanding that you had your own plans for it, which you weren't at liberty to disclose, it would have been difficult to accept suggestions (or at least publicly acknowledge acceptance) but it created the perception that YYG was not responsive to customer suggestions.
Granted, now that we see 2.x, I'm happy to find that a number of suggestions that I'd made have been added (room inheritance, yay!)
Again, not having a detailed public road map showing YYG's intent for the future of the product also makes it harder for us to know whether you're working on the things we want or not. (We do now once again have a roadmap, but it's still a pretty high level document.)
I trust YYG to know what the most important and urgent things are to work on, but that doesn't mean that judgment shouldn't be challenged sometimes. That's why customers speak up, and why it's good that you hear and take it into consideration.
I will always feel better hearing something like "This is a good idea, and maybe it does belong in the framework at some point, but I don't know that we'll ever be able to get to it. The good news is you can write your own extension, and it may become popular if you put it on the MP and lots of others agree." than "Nope, we're not doing this, and you're lazy for suggesting that we should." Hard "no" responses should be for stuff that are totally infeasible or a bad idea for technical reasons.
I do also think that extremely popular extensions should eventually "graduate" and become rolled into the product, though (and it'd be nice to compensate the author, buying out their asset). That's essentially (more or less) how we got auto tile, right? Originally a forum post by
@Nocturne, eventually a MP asset for 1.x, and now a fully supported feature in 2.0.