Position_meeting with instance?

[Schwee]

Been at this long enough so I'm reaching out. I'm sure its stupid and obvious...

Creating inventory slots:

for(var i=0; i<obj_ctrl.inventory_size; i++;) {
    slots[i] = instance_create_layer(curr_x, curr_y, "Inventory_slots", obj_inv_slot);

Checking if slot is selected via mouse click:

for(var i=0; i < array_length_1d(slots); i++) {
    var slot = slots[i];
    if (
        mouse_check_button_pressed(mb_left) &&
        position_meeting(mouse_x, mouse_y, slot)
    ) {

I've pretty much narrowed down the error down to the position_meeting check. GM documentation says position_meeting SHOULD accept this 'slot' but it does not seem to register. I have tried slot.id as well. Is there something else I am missing?

 

[spoonsinbunnies]

place meeting moves the object calling it and checks for a collision then moves back, so if a controller is using this without a sprite it will never be true, check for that.

 

[Schwee]

Well I am using position meeting but that does answer my question either way...I don't have any sprite set for the object I am looking at, and thus no collision mask. Thanks!

 

[nesrocks]

Instead of position_meeting, try using point_in_rectangle. Because position_meeting will move the object running the code to the specified position and checking for collision with the object, but if you're on a controller object that doesn't make sense, especially if it has no sprite.

 

[TheouAegis]

Instead of position_meeting, try using point_in_rectangle. Because position_meeting will move the object running the code to the specified position and checking for collision with the object, but if you're on a controller object that doesn't make sense, especially if it has no sprite.

place_meeting() virtually moves instances. position_meeting() is just a boolean collision_point().

 

[nesrocks]

Oh yeah, you're right. I'm sleepy!

I can't see the error, so to narrow down stuff, try putting this code in the draw event and see if it draws the circle at the top left corner when you mouse over the object that is supposed to be slot[0]:

if position_meeting(mouse_x, mouse_y, slot[0]) draw_circle(10,10,10,false);

 

[FrostyCat]

Each instance of obj_inv_slot must have a collision mask in order to be registered by position_meeting(), and that usually comes from its assigned sprite. Is that left unset? Remember: Things that are just drawn don't count for collisions.

Also, for those of you who suggested place_meeting(), you need to read this article: What's the difference: Collision functions

 

[NightFrost]

I'm not entirely sure why'd you want inventory as a bunch of instances. I'd see it primarily as data with some draw loop to visualize. On a single-row inventory the click position would then be mouse x minus inventory area's left edge, then div with inventory slot pixel width. On a multi-row inventory, if your data is 2D grid you do the same with y, but if it is an array or list you multiply this y-position by number of slots per row and add to x-position.

 

[ParodyKnaveBob]

Well I am using position meeting but that does answer my question either way...I don't have any sprite set for the object I am looking at, and thus no collision mask. Thanks!

Since you found the problem already, it'll be nice to hear how you solve it. Planning to give the object a mask? (Which, even if you super don't want to assign a sprite and need to draw something manually, you can always assign a transparent box just for collision purposes -- a little trick I do all the time, and handy because you can scale the box to any size you need. Also, instead of transparent, it can be some arbitrary marker that you just don't allow to auto-draw.) Some other plan?

Regards, $:^ J

 

[RefresherTowel]

For inventory/UI work, I almost always use point_in_* functions. Of course, I also don't use instances within my UI work, I'm always simply drawing it from a controller object, so there's that.

 

[Schwee]

@ParodyKnaveBob I solved it doing exactly that. I may end up changing this technique down the line but this will suffice for now so I can continue working with and testing other functionality. There's a few posts mentioning just drawing the inventory without an instance and I imagine that is the smarter way to go about it for scale.

 

[ParodyKnaveBob]

It really does depend, re: smarter way. I've seen many a GM expert over the years say they used to get more and more into data-fying everything, removing object resources from their trees and handling everything through controllers, and then see various benefits to just using GM's own built-in stuff anyway and move back to using object instances for things. $:^ J After all, you clearly have not hardcoded your inventory, but rather soft-coded a slot object that can handle whatever instances of information (and existence) you wanna put there, thus hey, good job -- plus (within reason), "if it works, it works," right? $;^ b

Just for example, in the past, I created a whole menu-constructing system which I was going to put on the Marketplace (until I batted major life curveballs) that handled all kinds of data in all kinds of ways -- but if I wanted, I could simply instance_create() some menu option into the room that allowed for easy GUI and pleasant UX. No shame in mixing and matching! (Like the difference between HTML and CSS, ha ha ha ha.)