plat move

ty for all your help

Try this on for size.

http://www.filedropper.com/lolfighter

There are a couple problems I don't have time to fix, but at least it will get you started.

Known issues:

-Landing a jump while moving up causes a hang. This is a bug and should be reported.

-I don't know a good way of making a ceiling that doesn't allow creeping.

Have fun!

ty really appreciate it

Allow me to see if I can explain this to your liking. I'm terrible at these things, so let me know if I leave something out...

The detector method here is really only used in a visual sense. In fact, there is only one detector and its sole purpose is to create the base XY of the character sprite. Many 2D games use this to create seamless detection (similarly, SMB1 used 8x8 box math). In modern game engines with advanced collision detection (Contruct's per-pixel) it nearly becomes a necessity as animation frames cause the intended surfaces to constantly change. The character sprite is then placed on top of it and does not affect the world movement collisions. The times when character sprite collision is useful is, say, when the player encounters an enemy or dodges a bullet.

This system is helpful in the type of game you wish to create if only because you wish to add jumping. If your character sprite was the sole arbiter of world collisions, jumping would interact with the world and cause a number of game-breaking troubles. So I give the detector a 4-direction movement, which directly controls its associated character sprite. I then give the character sprite a gimped platform movement to allow jumping. This is what programmers call 'overloading,' but I guess we're using the term rather loosely here.

Which brings us to your first question:

[quote:a8wlgodc]"Sprite[Platform].VectorY equal to 0" Why/Where?

Because we are using two movement behaviors and forcing one to be directed by the other, we run into a few immediate problems. First, both are controlled by the player's input. Second, the platform movement will forever be "falling" even as it is repositioned each frame. Because all we want the platform movement for is its jumping ability, we must then turn all other functions OFF. This is done not only in the behavior's default variables, but also selectively at run time. And here's why.

We are already always setting the character's X coordinate to the detector's X to mirror its left/right movement. We also need to mirror its Y, but not when jumping. Therefore my solution is to turn the platform movement's gravity on and off.

//WHILE THE GRAVITY IS TURNED OFF (player not jumping), MIRROR THE DETECTOR'S VERTICAL MOTION.
System: 0 Sprite[Platform].Gravity Equal to 0

The Detector's Y (vertical) coordinate is less than (above, since 0 is at the top of the screen) the Box's hotspot (Y); So, reset Detector's Y to Box's hotspot PLUS (lowered by) half of its height (the remaining distance between the hotspot in the middle and its own bottom edge).[/code:a8wlgodc]

It is a quick and dirty implementation to show the basic concept.  I'm sure somebody here can provide a more elegant approach to it.

So, does that help you at all?  Did I leave anything out?

Thats well explained Daddy.

ty

Your time to answer questions will come. Dont hurry. It will be sooner then you think now. Just keep asking. And realize that you are asking our questions and those from people that did't make a "log in name".

I understand where this confusion is coming from. The application properties, among other things, does seem kinda hidden away now that I think about it. At least compared to MMF where most things are menu-driven, Construct may be a little daunting at first as it often requires the user physically navigate to an option whilst not providing a traditional means of finding it (This has been my complaint about "Ribbon" systems also seen in Office products recently).

I guess the best advice I can give is don't be afraid to explore.

compared to MMF where most things are menu-driven, Construct may be a little daunting at first as it often requires the user physically navigate to an option whilst not providing a traditional means of finding it (This has been my complaint about "Ribbon" systems also seen in Office products recently).

As far as I can tell, the "ribbon" pretty much is a menu (with illustrations). Now if only it knew to get out of the way when you're not using it, and supported [Alt]+[letter] keyboard navigation ...

Drop down menu just 2 pixels on the left of the home menu.

Minimize ribbon.

ty for taking time to help

If you mix an object that has platform movement with another object without platform movement in the same family, the system-level actions regarding platform movement will not be accessible from that family. Because events for families affect all objects within, only the controls shared by all objects are usable.

ty

ty for helping out

OK,

You can not use Behaviors properties in expressions trough a Family. Lets accept that at this moment as a fact. Ashley added Behavior tabs to the Family's in the condition and action wizards.

Maybe he overlooked the expressions. Or he has no plans to.

But,

Besides the fact that you can not do it the way u try, i wonder about the "why".

Why would you want to move 3 objects as they are "player objects" ? You bring yourself in deep problems in that .cap. Because, well, how to explain ?

1/

You want conditions that are made to be a flow condition to act as a pick condition.

Flow conditions are true or false. When true they execute there sub events and actions. When false they dont.

Pick conditions pick a group of objects (can be a family), filter according the condition, and pass the filtered object(s) to the sub events and actions.

What u have there,

System: Sprite[Platform].VectorY Equal to 0

is comparing 2 values, when the comparison is true, the action will run.

Thats what it is designed for.

So the action

Blue Set gravity to 0

Will set all Blue's gravity's to zero. ALL Blues ! When the comparison is true.

You can see that if you delete the other 2 "Blue Set gravity to 0" actions.

So even if you could access the behaviors properties trough a Family, your events dont do what you seem to expect.

Of course, if the action directly addressed the object "sprite" then it would work, because there is no need for a pick event then.

But since you insist to work with a group of objects, represented by there Family, you need a pick event. The correct pick event here would be :

Blue: compare a behavior propertie. Close to the conditions we have already as there are:

Blue: compare x position ... Blue: compare private variable ... etc

Now well, we dont have that condition (yet).

So its the same problem. Yes is exactly the same problem. Moment we have the condition, expressions will be available too.

You understand ?

2/

You have 3 instances of the same object Detector. You have 3 totally different objects.

They way you snap there X's to each other works more by incident then by design, or good coding.

Just duplicate one of the faces, as clone or as instance, dont matter. If you do as clone, dont forget to bring it in the family blue.

And before you run it, try to predict what will happen.

You see ?

3/ why promote 3 objects to "player objects" ?

4/ i would make you a .cap with a nice work around. But, in my learn curve, i did not reach the Platform yet. Because in my eyes, what use is it to not understand the events completely and dig my ass in the behaviors. So i dont understand the platform behaviour yet. I am sorry.

But i am sure, if you understand what i just told you, you will see the light and come up with a solid solution.

Although, just theoretical, i dont see practical use in 3 player objects.

j0h