In my opinion to upgrade tori control system developers should make something work similar to Maya 3d animation but with physics. I just want to say that it would be better to control tori by pulling parts of the body during turns. Watch this video and think about this idea https://youtu.be/XII9aKbVXrg
Why it will upgrade toribash. You will have more precision. You will be able to have more control of your tori. Will be better to play mods. Just will be easier. You will be able to make more moves. I know it hard to make again tori control system but it will give to you more capabilities. I would like to see this system in toribash. Are you agree with my idea?
do it pls, i think we will likely enjoy it quite alot
like i said, i'd probably rather not
not to mention i'm working on like 13 mods right now i don't have time for something i won't be proud of, i won't play, and i doubt other people will find fun
if you want to learn how to do all this yourself i can give you a basic rundown somewhere else. i've been thinking about writing a tutorial on some of this as well anyway
Originally Posted by snake
thats a mess from design standpoint aswell, there should be one system, not a mix of several, and as simple as possible
i'm not even thinking about tb right now
presuming you have a ragdoll fighting game
and presuming that it's turnbased, or structured in some other manner that allows sufficient time to plan and execute moves
and presuming you have some degree of accuracy (either to one decimal place, like my previous example, or twenty-three) in which you can define the velocity of bodyparts across potentially variable number of axis
the interface you use to do COULD be the one you describe, where you select an object or some number of objects, and drag them to their desired location at some point in the near future, or it COULD be slightly similar to tb controls, except with some changes to allow to the new freedom of movement
for clarity, what i said, again:
Originally Posted by ME
imo, this suggestion would work best as an extension of controls similar to the current ones. if a system exists where you're able to define the rate, to a certain accuracy, at which a joint extends or contracts relative to a max velocity, it might be helpful to select a joint and drag it.
also, i dunno why you're trying to force a single interface down our throats. it's like saying toribash shouldn't have both mouse and keyboard controls, only one. the only restriction on the flexibility of the controls should be 1.) whether it's possible 2.) whether there's the time to implement it
all of this is also presuming that the system necessary to allow this is planned or in development
i dunno why you're trying to force a single interface down our throats.
it's like saying toribash shouldn't have both mouse and keyboard controls, only one. the only restriction on the flexibility of the controls should be
i'm all for diversity in control scheme, like mouseless.lua by Daanaado, but this thread is supposedly about IK controls, so i try my very best to convince or shove it down the throats, so people can try it in blender and see for themselves, to actually see the obvious, which is hard when people don't give it a try and instead try to come up with the ways why it's bad, without having an idea what they are talking about, as they never tried it
explore, think out of the box
again, it can't be mouse only interface or keyboard only interface, my point of view is to have as little overhead as possible, and if something can be done the best way with a specific control mechanism - it should be done this way.
like shooters are using mouse for aiming, ofc you can set your keyboard to aim with it too, but err... why?...
Like i said. For me it sounds intresting. Idk why all these guys go on and on about it. Toribash will stil remain the same. Toribash next will be a new game, a different game.
Even if tbn will use same control as toribash i don;t see why a team of volunteers would start to work with devs and make this IK thing a real thing in a different game. Since we already have the base (toribash) to work with. If it is as easy as you guys suggest go ahead and do it
I deleted a bunch of useless posts. No infractions were given out, because this is Suggestions and we'd rather see posts than not. If your post was deleted and you really, really think it wasn't useless, feel free to re-post it.
That said, please keep your posts on the advantages and disadvantages of this system.
Things that we don't care about: How long people have been here. Bowblend may be a beginner and snake may have been here forever but for determining whether or not IK would be a good improvement neither of these points are super relevant
Whether or not the suggestion is good or bad. Note that I'm specifically referring to posts like "No this will ruin everything" and "This will be the best thing since sliced bread". Please present your points of concern or interest instead.
This almost certainly will not be officially implemented before Toribash Next, at the soonest. Thus, this thread should be taken in the context of Toribash Next. Anyone who is feeling particularly enterprising and who is willing to fight with the existing Lua API is free to implement this (it should be possible) for the current version of Toribash. However, comments on the suggestion should be made with Toribash Next in mind.
It is ultimately up to Nabi, particularly hampa, as to whether or not to introduce this into Toribash Next. In particular, this is not a debate to be won. This is an opportunity to present why this change may be good or bad. So even if you disagree immensely with this idea, don't take it out on the other people who like the idea. Post your concerns and post how you think they could be handled while still implementing this suggestion. Post your interests and post how they could be implemented without this suggestion. Consider alternative approaches.
Please keep this thread civilized. Moderation will be a bit harsher from here on out, as this thread has gotten a bit too salty in places already.
Keep in line with the above guidelines and you'll be fine though.
Last edited by suomynona; Jan 9, 2018 at 05:46 PM.
Squad Squad Squad lead?
The standardization of Toribash Squad roles may have gone too far!
would it be fine to have one more thread about variable turnframes or is it gonna be too much debatable threads in a period of time?
it's somewhat in synergy with the IK controls, though it's a separate concept
I don't see the issue with having a thread about variable turnframes, especially if you mean in a user driven sense for multiplayer. It seems pretty off-topic for this thread, so I'd say go for it.
Squad Squad Squad lead?
The standardization of Toribash Squad roles may have gone too far!
hmm so I thought on a way to proper implement this system on Noribash Text. It's still under development though, since I can only imagine this applied to both legs and arms. As an animator, I know, and have seen, IK constraints only applied to "chain members", like arms and legs. But it's possible to apply it on the torso region. The lack of certainty is big, so an answer might only come up tomorrow, after my struggles with blender.
After reading almost all the replies, I guess I kind of understand how snake want this to be. Tell me if I did anything wrong. Here's what I propose, which have as well relationship with turnframes:
*warning: the example is just an animation. I didn't make any working game engine for it.
arms example ►
Ok, so imagine we are at frame 0. There are 4 IK targets on the screen, overlapping respectively both the tori's hands and feet. They're draggable, so you can freely move them around, with the option to constrain them on the 3 axis (X, Y and Z). When you move them, you can see the ghost trying to arrive at the desired location, matching the chosen rotation.
How fast should the ghost moves to the target? I propose some kind of scrollbar where you chose how many frames will it take to reach at the target.
This is adjustable, with a minimum amount of keyframes based on the maximum velocity of the fastest part in the chain. This would avoid reaching far distances inhumanly fast (customizations on mod maker are ok, so we could still have our lighting battles).
Every controller could have its own bar standing right below it.
In the gif above, the ghost takes exactly 50 frames to end its animation. Here's an example with the right hand taking 20 frames until it rests on my IK controller:
As you can see, the right hand takes 20 frames to goes there, then it stands still from now on. Remember, we're still at frame 0, the ghost only shows the supposed movement. Moving on:
*Space pressed, some amount of turnframes pass (let's say, 20, according to certain mod);
*We're now at frame 20
Ayy, that's how it looks. Noticed the right hand is not at where I want? Well, 20 frames has passed and the hand were supposed to finish its movement in 20 frames. All alright. The left hand hasn't seem to be finished though. Now that we're at another pause, let's change the controls again.
I changed the amount of frames taken in both controllers (30 frames each), them dragged them around. If I press space again, more 20 frames will pass and, since they need 30 frames to complete their movement, they won't be able to reach my controller with only one space. If I press space again, more 20 frames will pass and the hands, in middle of the movement, will finish their animation in 10 frames, then rest for more 10 frames, until the next turn begins, so I can re-start the process again.
This process can be replicated for arms and legs. I'm still trying to figure out how I'll make this for the torso. There are common problems and issues with IK constrains in torso, so I'm used to use Forward Kinematics on torso, and IK on everything else.
Noticed, in the last animation, I made them "collide" on purpose? That brings the next subject I'd like to talk. As the name implies, IK or FK deals with movement only, and not with forces. For this system to be proper implemented with Rigid Body Physics game engines, it has to teamwork with dynamics. In the examples above, I only used movement to demonstrate its functionality. I won't talk about much technical stuff, because that's out of my comfort zone. However, for this to works, the movements has to be kind of translated to dynamics (someone said it early, I think it was MariaVirgine), using some parameters such as body part weight and maximum velocity.
Ghost would be able to overlap objs
While the body, not.
*Note: since I said this is just an animation, be aware that dynamics aren't proper settled with IK in the above examples. You may not notice, but, no matter how heavy or the cubes are or how much force they make against my first, they won't stop the hand's animation. This wouldn't be a problem if the movements were translated to dynamics.
Sorry for the sloppy animations.
Credits: Foodeater for the rig
Last edited by cappuccino; Jan 10, 2018 at 03:17 PM.
holy shit mate, this post you made should be pinned!
Originally Posted by cappuccino
Ok, so imagine we are at frame 0. There are 4 IK targets on the screen, overlapping respectively both the tori's hands and feet. They're draggable, so you can freely move them around, with the option to constrain them on the 3 axis (X, Y and Z). When you move them, you can see the ghost trying to arrive at the desired location, matching the chosen rotation.
though i have a suggestion to improve it a bit to make it sligtly more transparent, so the ghost doesn't follow your move as it has in vanilla, but we move the body where we want, and it shows like it is there on end position, and the ghost shows a transition from initial position to the desired position we made
here a quick video to illustrate what i mean, so we move the hand where we want and it appears like it is there physically already and ghost draws from initial position to the desired one
so here are the steps:
1) we move the arm to desired position
the arm moves there physically not the ghost
2) ghost shows a transition from the start position to the end position
3) the movement goes only specific amount of frames, like 50 for example, even if it didn't go all the way to the end position
4) body on the current position, but ghost shows the travel to the last desired position[/s]
thinking about it again, makes me think that it should be like this, for the sake of clarity and transparency of the player, so he knows what exactly he moved and how his desired position will look like, given the current available info
yeah thinking even more about it, i'm convinced that it will greatly benefit and complement the IK control scheme, i'm most confident of it now, no matter if this a striking or grabbing situation
you did absolutely tremendous job mate! really FUCKING GLORIOUS!!!
and about frames, this is an idea i never though of ( the one you shown) though i was thinking about something slightly simplier for the end user, for example, you move one arm, so your turn takes 20 frames in total, and if you move two arms, it's gonna take let's say 50 frames, so the player does not decide how much turns his movement will take in total, but it is dependent on the moves he made,
never thought of controlling the speed of moment before, your idea is pretty novel, that might be something that should be there along IK!
I'm comfortable with the current system.
But I do like the idea of completely changing it to make it easier.
It's true that the game will no longer be about how good you are at controlling the tori.
But it will be more about how creative are you, and how well can you predict your opponent.
It will attract more new players, and let everyone play better than they have before.
If you want the game to stay difficult, that means you have a rigid mind and the only way you can win in this game is by the 10 years of experience you have and the only advantage of knowing how to control the tori.
I want to think more about what to do, than how to do it.