Object-specific collision, and NOT conditions?

Hey, everyone.

I'm trying to create a platformer (seems popular) that animates characters based on physics and primitive inverse kinematics. First I made a biped ragdoll, but that was useless, because the physics did not obey my set-force-to-angle commands 100%; the best I got was a limp zombie-looking thing, whose feet fell through the floor, limbs spinning.

Today I realized I needed invisible objects to just nail the jointed biped graphics onto. So I created a player object, and two feet, and am trying to animate them with cycles of "set force towards position" and velocity added to the player body, a la deadeye's kickit.

I'm not really a programmer, just an artist, but like messing with stuff like this. As a result, however, there are a bunch of problems I cannot seem to overcome. For one, the feet are colliding with each other, and that is not what I want. Can I make them pass through each other but still collide with the environment?

Additionally, they tend to drag behind the player. Is there any way to restrict physics movement within a hard radius, dramatically without elasticity? I tried hinge, but it lagged the program horribly. I already have one of the feet set to animate with a force when its position reaches certain coordinates, resulting in forward and backward cycling while the control is held down, but it's difficult to balance masses, forces and everything. And the collisions with pfoot2 are not helping.

Finally... I can't seem to figure out how to add the ? to a condition, like I see in others' projects. <img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /> It would be useful to use in a manner similar to kickit, as well. Is there some secret way?

The short answer is you won't be able to do what you want with the physics object right now. There have been a few suggestions to improve the physics made that would help with that, but they're not yet implemented.

As for the ≠, you right-click on your condition and select "Invert condition."

Yeah, Physics needs more features to achieve what you want, like a 'Disable collisions between objects...' action and such. Unfortunately I have a lot of bugs to fix - and exams this week - and bugs take priority over feature requests, because features tend to introduce bugs again - I need other developers on this project <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> I'll see what I can do.

In an attempt to create my own pseudo-physics platformer without using any of the seemingly buggy movement presets, I seem to have instead created an atomic bomb.

Setting the player object to Always drop by pCenter.Y + pCenter('gravity'), I tried to create a loop that would, over time, add a number to gravity while the detector does not intersect the ground. Not really sure how to use the loops, though... so I set While as a sub to the Always, with the additional condition that detector does not intersect ground. In that event, gravity is increased by 2.

Running the program makes it run but not show, and Construct freeze up strangely. My music even started skipping. So I closed construct, restarted, and it was still messed up. So, reinstall. I didn't actually have to restart: done this a couple times, and all one has to do to successfully reinstall is force the Temp.exe process to end.

So... yeah.

How does one use loops? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

Check out this thread, it should explain a few things:

http://scirra.com/phpBB2/viewtopic.php?t=321

If there are bugs in movements, you should report them so they get fixed. AFAIK the supplied movements work pretty well. I don't intend that most people make their own custom movements, because that defeats the point of ever having movements in the first place. If a movement is not good enough, ask for feature requests or bug fixes. People seem to have an aversion to using the provided movements and I don't like this; if it isn't doing something you want it to, we should work to find a way to make the movement better, rather than in general forcing people to devise their own systems.

Anyways by the sound of it, you have an event like this (note a subevent to 'always' may as well be its own event):

+ While

+ Detector not overlapping ground

: Add 2 to gravity

'While' repeats its actions until the conditions are no longer met. This means if your actions don't do anything that could ever make the conditions false, the while loop will never end and it will run infinitely, hanging the application! Construct isn't yet clever enough to notice when you do this, but I've logged it on the todo list.

Basically in order to make the while loop endable, you need to change the detector's position in the actions so that it is possible that it eventually ends the while loop. Also, to prevent infinite loops, you could try using 'Repeat 10000 times' instead of 'While'. This means if the conditions are never falsified, it will run 10,000 times then continue, so at least the game responds. Note your actions are run 10,000 times in such a case though!

Actually, running it a certain number of times is preferable! That way, there becomes a maximum falling speed. Thanks for the information. My loop seems to have been wrong because it had no ending reassurance, I guess.

There aren't really bugs in movements so much as... conflicts in what I'm trying to do. For example, I had the pCenter a physics object (this is the object that determines the player's location and momentum), and another physics object, pLowBound, below it that dynamically resized according to the animated limb extents. The detector sits below this as well, also keeping accurate width. When pCenter and pLowBound were both physics objects, the addition of width and height adjustment events made the player freeze immovably after a short movement from its spawn location.

By now I've made it so pCenter is the only physics object. For accurate ground collision, its pivot is always set to the bottom of pLowBound. For wall surfaces, when pLowBound collides, I set pCenter's velocity to drop, and if due to extra momentum pLowBound manages break the wall object's edge, and overlap, I gently bounce the player in an opposite direction. Should probably make ground collision similar to what I have for walls, but the actual physics object gravity pulls pLowBound through the ground until pCenter hits it if I only work with its collision, as a non-physics object.

It's still pretty messy, as the physics objects seem to enjoy sinking into one another, but I think by using a single physics object with extra objects attached, I can accomplish what it is I want to do.