Sprite Editor: Allow multiple custom origin points/hitboxes on a sprite

[iampremo]

Description

Basically what I'm thinking is just the ability to add as many origins to a sprite as you want. The first origin or maybe just a specified origin would be designated as the actual origin of a sprite as we know today where it can rotate, scale, move, spawn, etc around that point. Though you would have the ability to drag in multiple origins that don't necessarily do anything by themselves, but you can reference them in code and it will fetch their position, and hopefully it'd just be a simple x and y fetch and the x and y would obviously follow the sprite and object perfectly as origins do now, which is also complicated to do manually as you have to calculate rotation and scaling and all sorts of stuff.

For example, you have a gun that is attached to the player from the 1st origin that's placed on the butt stock, though you could add an origin on the end of the barrel of the gun and use instance_create_depth(Origin[1].x or sprite_origin_get_x(spr_Gun,"Barrel"), etc., 0, obj_Bullet) and it would spawn a bullet at the designated barrel origin.

In animation, the origins could just possibly carry on for each frame, but you would have the ability to have custom origins for each frame as well? Though that might be an entirely different function or feature, but it'd be nice to see custom origins for each frame as well.

Personally it would be amazing to have points on guns designated for attachments like scopes on top of the gun or points where the bullet leave or points where the hands grab, and currently that is a lot of manual work or work making tools to actually get these points. There's also just a lot more possibilities, like making enemy spawn points on a sprite that'd be the map, making hitbox points or rectangles by connecting 4 origins.

Benefit:

This change would be simple but streamline the process of making particle points, attachment points, rotation points, spawn points, etc, extremely easily without losing any versatility or complexity.

[WangleLine]

Yes!!! I've requested something like this in the past too - It'd be cool if we could also add multiple bounding boxes as well, because in my games the collision hitbox and the "which parts I want to apply damage" boxes are different almost always

[adamrpippin]

The multiple bounding boxes would be a huge time saver for me, along with the multiple anchor points!

[KormexGit]

Another nice addition would be if you could optionally set a direction value for each point, which would be useful for things like spawning projectiles at the tip of a weapon that isn't pointing straight forward

[ThomazDiniz]

YES! This would help making things like hats, shooting from specific points of weapons, making easier bone animations and better hitboxes. Seems like a lot for the ide, but it would help me a lot. =)

[Talkashie]

This would be a huge time-saver to have! I am currently trying to figure out how to place an object based on its 0,0 origin while rotating it around its center. Having multiple origin points would make this trivial. Without this feature, it requires some math that I, unfortunately, don't quite understand.

[BrittleLizard]

It's a little disheartening to see every suggestion for additional collision masks closed and redirected to this, as I feel like the comments here don't go into a lot of detail on the issue, and they're solutions to very different problems. In my experience, most use cases for multiple origin points can be solved pretty easily with code, whereas hitbox/hurtbox implementation is always either obscenely tedious or incredibly slow.

Just wanted to throw in my two cents that only allowing for one collision mask per sprite is by far one of GameMaker's biggest weaknesses right now. As my projects get more complicated or I want to delve into certain genres like beat-em-ups, implementing custom hitboxes and hurtboxes is an annoyance that never seems to get less frustrating to deal with.

My idea for implementation is similar to the way Animation Curve assets can hold multiple curves. Sprites should be forced to have a single collision mask by default so as to not complicate the basic collision functions, but they should allow for additional masks to be created. New functions could be introduced for checking collisions using these additional masks, or the existing collision functions could take two more optional arguments. (Which mask to use in the calling instance, and which mask to check for collisions with in the colliding instance.)

Really hoping to see development on this front.