Figuring out collision detection using other

[Gimchi]

hows this work because this crap doesnt:
Step Event:
With (ObjectDood)

if place_meeting(x, y, other) && other.variableNum1 = Self.variableNum1

do something or order something whatever


yeah it doesnt work? how do you do general collision detections like using the command other. im trying to order stuff in the Z layer with depth but its having trouble. just how does other work? it doesnt seem to give want to cooperate. (with and without the with)

[Sera]

"other" as a keyword is a bit context sensitive, but the primary two uses that come to mind for it are:

• Collision Events
  
  In an object's collision event, "other" generally refers to the instance being collided with. For example, if enemies have a collision event for colliding with obj_Bullet, other will refer to whichever instance of obj_Bullet triggered the collision. A common result might be something like HP -= other.Power;
  
  
• "with" Statements
  
  Within a with statement, all instructions are performed by each individual instance of the given object, or with a specific instance given. (This is why calling instance_destroy() within a with statement destroys what you're working with, rather than the object that called the with loop.) Within this context, "other" refers to the instance that called the with statement in the first place. This is generally useful for checking variables within controller objects that have some varying outcome within the game, among other things.

As you get progressively more skilled and detail-oriented (AKA "control freakish") with GML, there's a good chance you'll be relying on the Step event more and automatic collisions less, so your exact use of "other" sort of evolves over time. Regardless, understanding how it behaves is always useful.

[darksouls]

Originally posted by Zaron X:

"other" as a keyword is a bit context sensitive, but the primary two uses that come to mind for it are:

• Collision Events
  
  In an object's collision event, "other" generally refers to the instance being collided with. For example, if enemies have a collision event for colliding with obj_Bullet, other will refer to whichever instance of obj_Bullet triggered the collision. A common result might be something like HP -= other.Power;
  
  
• "with" Statements
  
  Within a with statement, all instructions are performed by each individual instance of the given object, or with a specific instance given. (This is why calling instance_destroy() within a with statement destroys what you're working with, rather than the object that called the with loop.) Within this context, "other" refers to the instance that called the with statement in the first place. This is generally useful for checking variables within controller objects that have some varying outcome within the game, among other things.

As you get progressively more skilled and detail-oriented (AKA "control freakish") with GML, there's a good chance you'll be relying on the Step event more and automatic collisions less, so your exact use of "other" sort of evolves over time. Regardless, understanding how it behaves is always useful.

Wow, I am having similar problems. And have decided to copy the OP. But I found out about the "all" constant and it made it work.. yet I do not understand why?

Can you explain to me why this work?

with (all)

If place_meeting(x, y, other) && other.value == self.value

instance_destroy()


It is being called from an object that gets destroyed's step event. I am having trouble, is all referencing everything else? So in this syntax, With everything else, if that everything else has any contact with other = Objecttype that called?? (So Self?) and if the object type that called the with statements value is equal to everything else's value, destroy... everything else.. Hmm this is where I lose track of everything.

[Sera]

"all" refers to just what it says: everything. Each instance in the room, regardless of object type, should react to "with all".

"self" refers strictly to the instance using it; "with self" will accomplish very little, since you'll just be having the instance telling itself to do something, which is default behavior as is. "self" simply holds the functioning instance's id.

Using an object name (ie. "with obj_Bullet") will have the with statement's contents be executed by every instance of the given object. That one's pretty simple.

You can also use the with statement on individual instances, which will generally rely on functions that return instance ids. For example, "with instance_place(x, y, obj_Wall)" would do whatever is instructed to a specific instance of obj_Wall at the given location. You need to be careful with this approach, though, as if an instance isn't found you'll get the keyword "noone," which will result in errors and the game crashing; the best way around this is to first check if there IS an instance at a location before trying to manipulate it.

As for your exact code, it looks like (if I'm reading this right) so long as there is a collision with the calling instance (though I wasn't aware place_meeting() accepted instance ids?? That's cool, I guess) and both instances have the same value, the referred instance gets destroyed. It might be clearer if you work in a manner that makes it clear how things are grouped:

with all {
     if place_meeting(x, y, other) and other.value = value then {
          instance_destroy();
     }
}

Some notes: self.[anything, really] is generally not required; any time you lack a location prefix like "self" or "other" or "obj_FartNoiser", you're working with self by default.

Also, if you're wondering why instance destroy works, within a "with" statement, self stops referring to the object calling "with" and instead becomes the object "with" is manipulating; instance_destroy() only really functions on the object calling it, but since within the "with" statement that becomes the instance being manipulated, that instance is what gets destroyed.

[darksouls]

I will spend some time going over what you said, thank you.

[darksouls]

Ok, I managed to understand what you wrote and even managed to fix my problem, but now I have a new problem, how do you manage depth in drawing orders?

[Sera]

That depends how vital your drawing or execution order is; depth affects the order instances execute in in my experience, not only just the order they draw. Generally, though, this boils down into a couple simple categories:

One, draw order is mostly about visibility in general - think in platformer games - in which case depth as a static number is usually perfectly acceptable, because objects will typically always be within a two dimensional plane with no need to mess with your illusion of depth a ton. Generally you want the player object to have the most visibility, save possibly the scenery so he doesn't visually clip through walls, and then behind that items, enemies, etc. in whatever order serves the gameplay best.

Two, you're making an RPG or some junk and everything is top down, and having feet appear over someone's face is kind of not ideal unless that's just the sort of thing you want to put out there.

In the second case, I usually just have objects set depth to -y in their step events; further towards the bottom (front) of the map usualy results in things appearing in front. You gotta mind bounding boxes for clip-through or whatever, and keep in mind how far into negative numbers your depth gets (doing it view-based may quite honestly be a lot smarter, especially if dealing with larger rooms) so you know what to do with your HUD (though Draw GUI is a helpful aid in this that is new to Studio and alleviates that problem quire a bit).

If you're asking in more general terms, though: lower numbers are drawn first.

That was, uh...

Probably the easier answer.

[darksouls]

No I mean I have two objects with the same depth and one object moves between depths and when equal to that other objects depth it is drawn behind it. I can fix this easily but I was wondering how someone else would approach this draw ordering problem.