Wait, you also have that if statement in two places, though only one has && vspeed == 0. Whaaaaaat?
Wait, why are you using the default variables? You have, like, no control over them.
Yeah I dunno. It’s giving me a huge headache cause I can’t work with them >_>
That was kinda my point earlier >_>. It seems to me like it’d be a lot easier, albeit more scripting, to get these things done with our own gravity and “solid” detection/collision scripts. However, I suppose we should just work with what we’ve got, and be thankful that DF got something going?
Does this mean my slope detection script, with a little modification, will come in handy after all? 
Really though, my present slope-running code (which doesn’t use that script, again) supports other slopes pretty well.
What do you mean by a GM7 version, DF? I mean, GM7 can import .gm6 files with little-to-no conversion issues, so I don’t think that a separate version would be necessary. For those who can’t run GM6.1, perhaps they could forward the code to you or whoever… ? It seems to me like keeping track of a GM7 version would just be more of a pain.
Edit @ Timmeh: Yeah, there do seem to be some real strange inefficiencies there. The latter of said two if statements seems to be in anticipation of hitting the ground, before Samus actually hits it. That’s my guess anyways, seeing as it’s all in that else which checks for a collision and takes speed into account in doing so. The vspeed == 0, then vspeed = 0 thing though seems just plain silly . It seems to me that he might have pulled this code together - either from different places or in a rush - and forgot to comb over everything after he added some of the later things.
Ehh… The if that anticipates a collision doesn’t quite seem like it’s reliable >.>. It is only a point_collision, after all, rather than checking all of Samus’ bounding box. Perhaps DF has his reasons, and will explain…
I could whip up some scripts to replace everything that’s currently being done with GM’s inner works, but I don’t know if I’ll be allowed to keep hspeed and vspeed, which would be rather nice words to use.
Well, I may now see the reason why DF chose to use GM’s solid and gravity variables (or solid, at least). If you know the ins and outs of GM’s commands/methods, things like slope-running. ARE TOO EASY. >_>
I just trashed about 70% of what I’ve done on slope-running up to this point, traded the non-test code for some of GM’s commands dealing with solid objects, and now have a pretty much perfect slope-running system. I feel like I cheated, sort of, but it’s nice how simple it turned out to be <_<. DF kind of left a little “hint” (maybe unintentionally) as to how to go about doing this with GM’s commands.
… Ridiculous! xD
But yeah, I think I’d still possibly probably prefer custom gravity. Maybe we should see what DF thinks - he did, after all, say not to script anything irrelevant to anything on the goals list.
Hah. Do let me know! Every solution I’ve tried that I was positive should work ended up not because I misunderstood something about GM. 
Well, put simply (and without giving it completely away e.e), I used move_contact_solid and move_outside_solid with discression. He uses them at one point in the free_movement script, which should give you a good idea how you could use them to ease up the process of making slope-running work xP. Until I turned to these functions, I was using while loops and etc., as I’m sure you’ve probably tried as well.
I’ve been trying to use move_contact_solid and move_outside_solid, but it’s not working quite like I’d expect. Currently, if I gained control of vspeed, hspeed, and gravity, I’d have a much easier time of it.
The first one check if samus is standing or running on a floor. If its’ so, set the gravity and vspeed to 0. If you don’t do that, she will fall trough, its a gm oddity…
The second one checks if samus has moved downwards to a floor, as a result of the function place_meeting, if so, set the vspeed and gravity to 0 to prevent she will fall trough, again a gm oddity
The ‘gravity = 1’ code is wrong, it should be ‘gravity = m_gravity’…
The m_gravity variable can’t be a constant, it’s unique to samus. For example, when she is in the water, m_gravity will be 0.5 or something. Let’s say there would be enemies above the water, then they would also have that reduced gravity if it were a constant.
The default variables are handy, if you know how to use them. It allows you to make use of a lot of gm functions, which is an advantage.
Thought it wasn’t compatible, my bad.
You’re right, the vspeed = 0; line can be deleted, it’s a leftover from some old code.
I’ve never gotten trough or got stuck in any wall or ceiling with that script, it’s 100% reliable me thinks. How would you check it?
Yup, that’s why I use gm’s built-in vars and functions.
I don’t see why you would use custom gravity… the gm’s built-in gravity seems to do the job pretty well, never had problems with it.
I suppose for generic platforming they’d do the job, but I’m used to doing crazy stuff with it.
I’d highly prefer that we just went ahead and rewrote GM’s functions for gravity and friction and what have you as a separate script that we can then place wherever we want in the step. The problem is that, right now, the draw event and all of GM’s built in functions are right next to each other. What if I want to place a script before change in position, but after we’ve drawn to the screen?
EDIT: Or before we’ve drawn to the screen, but after change in position. I’m not in which order they go, I just know that they’re together and that frustrates me =P
EDIT2: Also, I’d do gravity differently than you, with a constant gravity of the planet, and then modifications based on whether you’re underwater or whatever. “gravity = GRAVITY - (m_is_underwater * 5)” or something like that. But I see your way now, and I don’t really care either way.
Hmm well, I guess we haven’t really had problems with GM’s gravity so far. You just gotta figure out how to work around it, I suppose.
GM’s functions make it very easy to work with their solid objects, but there’s one big problem with GM’s solid that I think I mentioned earlier: it doesn’t let ANY objects pass through it, regardless of whether or not the object trying to pass through is solid or not. I can’t think of a really good example, but sayy you wanted like a Chozo ghost to be able to go through walls at times. >_> Couldn’t happen. One easy solution for this would be to temporarily set the object’s mask sprite to something completely transparent (so that it has no bounding box), but if we use custom bounding boxes for everything, this might be an issue or more of a pain (but I’m not really sure).
Anyways, this isn’t really a problem right now, so I suppose we shouldn’t worry about it just yet.
Is the slope-running code I sent you sufficient, DF? If so, then let’s move on with the goals . (Or whatever the next step is - debugging?) Or are they really just monthly?
Edit: I suppose I should just upload it, as well, although I wrote a few explanations in the e-mail. Uploaded.
Wait, GM’s collision detection system is BUILT-IN? o_OOOOOOOOOOOOO
That explains a WHOLE LOT about what I was trying to do >_>
Pretty much >_>. This is probably the third time I’ve said this, but GM will not let one object that has a bounding box go through a GM-solid object. Unless of course that object’s speed is greater than the width/length/size of the solid object. This said, one can make their own solid system by simply leaving all solid checkboxes unchecked, and using a parent for all solids. Muchh experience with this xP.
This is one of the major reasons GameMaker is famous.
I’ve been struggling with making a good collision engine since 2002. If what Saber Mage said (about teleporting through objects if the speed is greater than the width of the object being teleported through) is true, GameMaker uses a collision engine similar to my older design. (The newer, superior design uses vectors rather than simply moving an object and checking for collisions in its new position!)
Oh for christ’s sake.
Where do youuu live? <.<
I don’t quite get the point of move_outside_solid if that’s the case. How do you get inside a solid?
Because GM’s collision system isn’t perfect.