Thanks, Nux, that is kind of what I am looking for. What I meant was that I have been trying for a long time to make the program to do something of that sort and was wondering if there was a good way to approach it. I tried to use geometry to find the correct angles and such but the way game maker uses origins and such made it strange and it was not working.
And physics is very bad to use because then ur game is dependent on the physics engine which could be a bad thing
How game maker presents the objects is completely irrelevant to the problem you are trying to solve. The question in this case isn't really about whether "GM" can do it, but rather a question of how you achieve this in GM. Using the options available for spine are just objectively easier because it means you do not have to program any of the inverse kinematics physics yourself.
The maths is going to be difficult, and it is going to equally involve an understanding of how you would structure such a system in code. The best thing you can do is disconnect yourself from any assumptions you are making about GM and think about the problem purely in terms of mathematics. You have a set of coordinates for each separate body part which you want to manage. You will likely have one body part you are trying to modify and after each modifcation, you would want to apply the inverse kinematic equations to dynamically re-calculate the position of all other body parts, subject to a series of user specified constraints (such as maximum angle of rotation, some form of mass quantifier to control how much movement of one component affects another (i.e if you pull on a bent arm, the arms are very loose and the elbow will straighten out before the torso then gets rotated forward).
In programming terms, it is very common to separate the calculations of what you are trying to achieve from what you are drawing. In this case, objects may not be the best solution unless you are very aware of how all of these interactions play together, and what variables exist to link separate parts together (if anything, objects might be the solution you decide to implement after getting something to initially work, but that's more a result of organisation, rather than the problem itself).
So to start, what you will want is to have a series of coordinates representing the joints between each body part. Body parts would then be drawn based on the positions of these joints. For example, the upper arm position and rotation would be determined by finding the centre and angle between the shoulder and elbow joint, you could then draw a sprite at that central position (allowing for any offset in the origin you have placed to ensure it aligns correctly, though this should really be centered), and you could equally apply the rotation. Similarly, you would repeat the same process for the lower arm except between the elbow and wrist. You could then place the hand purely at the position of the wrist, but offset the origin of the sprite such that it is centered at the base of the hand, rather than in the middle (you can logically think about where you would position the hand relative to the wrist).
Back to the calculations, a "simple" structure for how you would organise such a system would involve you attempting to move one of the coordinates, you would then use equations to move the coordinate as far as it could in the desired direction, whilst equally updating the other coordinates at the same time. Unfortunately, this isn't easy, so i'd stick with what BattleRifle said and just try and do it through spine, because this will be managed for you.
Also, how "dependent" you are on a system that you are using, whether it be physics, or some extension you may be using is entirely at your discretion. You can mix and match systems as much as you like, you just need to be aware of which situations you are using one in, and which ones you are using another in. You can also override the settings of any such system, rather than purely relying everything to be done for you. What I'm getting at is that using GMs physics system does not deny your ability to utilise your own collision code at the same time. For example, if you had an object or grid or something that did not conform to how physics worked, you could equally perform your own collision checks and simply use the physics system for resultant motion once your own collision checks have verified a location is free.
Going forward, try not to think of problems in terms of whether "GM can solve them", but instead reason about what you logically need to achieve, break them down into a series of steps and attempt to create each step one at a time. "GameMaker" will be able to do almost anything you can think of. It's limitation is your ability to actually achieve what you are trying to achieve. Granted, this means some things will be hard, however every hard problem is equally a learning opportunity and often times it is better to try and attempt a problem, and ask questions about the problem itself, rather than the software, given that this is quite clearly a mathematical/programming related issue, not an issue with the software itself.