@Doco: not sure if this is really a solution, but you can check the result of the file_open commands: if they're negative gm couldn't open them.
Wow, the manual needs an update, I've been using GM for 7 years and I didn't know that...
But I will have to stick to my policy about "undocumented" features. Either put it in the manual or get rid of it.
I see both the above issues as being related to my reported "bug/gripe" that the manual needs some heavy editing in some places. I thought
the negative return on file_* was documented somewhere, (and originally cited the above quotes to help out and show where the manual says it,) but I just scoured sections like What's New, Files, and other places (including using the search) and came up empty-handed. On these kinds of "undocumented features," I'm totally with GameGeisha's policy of document-or-unfeature.
This reflects a significant issue in GM, not a physical bug but a conceptual one: designing advanced features with too much focus on accessibility to novice users who don't know what they're doing, so much as to decrease the usability of the advanced features as a whole.
Surface handling is not novice territory, there no need to make it too accessible as to cripple it with "intuitive" side effects.
I'm inclined to agree here, too, that on already advanced
features, it's certainly
nice to have a novice easy way to go about it (like the cookie-cutter "effect" particle functions), but unexpected results shouldn't be a conscious decision.However,
understand making the 0,1,2 quick fix for a .1 minor version. In the future, though, in connection to what GG opined, it'd be nice if this were better fixed in the next major version (9) if feasible (probably leaving the 2 option as a duplicate for 0 for backwards compatiblity--but marked as deprecated and removed in the next major version (10)).
Yeah not sure if this is a bug or not, but it would be nice if YYG fixed objects with too much speed going through walls and stuff like that.
Firstly, YYG aren't the ones behind GM.
Secondly, that's not a bug. If you increase the x/y value by too much, chances are the object will "jump over" any walls there might be (especially if they are thin). There's nothing the GM developers can do about this.
Or instead you could just limit the speed. But... it might be confusing to beginners, that's why i'd like to see it fixed.
1. YYG are working on it now--pore over this forum and read Mike Dailly's posts.
2. Confusing to beginners? One of the very first official tutorials spells this out very plainly. It's not a GM bug, it's a programmer bug. One of the best programmed games ever (EarthBound
for the Super NES, 1995,) suffered from this bug--although it pretty much requires tool assistance to actually exploit it (using the walk-speed-increasing Skip Sandwich to "walk over" a rare wall due to simply being too fast to collide with the small wall (big enough to stop normal human players heheh)).
And lastly, I remembered a vicious
bug last night, but alas, I've already posted a realistic gripe. $:^ |
I hope this scattered reply helps (someone somehow),
[P.S. I have no idea why the forum is glitching that extra quote-box-text thing at the end of my post there. Hm.]
Edited by ParodyKnaveBob, 09 March 2011 - 02:58 AM.