Yann - Forgive me...I'm a tad confused.

Am I cloning my PlayerBox - that which the player actually CONTROLS but is invisible - or am I cloning the MrStick sprite that the player sees when playing the game?

I haven't yet done as you suggested, but I did try editing the origin point on my PlayerBox. APPARENTLY, moving the origin point on the PlayerBox down one pixel seems to have fixed the problem...for the moment. The seemingly random nature of when the collision with the platform sprite makes it difficult to tell.

wretchedshark - THANK YOU! LOL I was trying to figure that out, myself. I knew it had SOMETHING to do with the parallax...go figure I didn't THINK to actually test changing the values. Thank you again!

Yann - *BLINKS* Well, that's news to me. I assumed my PlayerBox sprite was staying uniform in size and not adjusting despite the frames of the MrStick sprite. If that's the case, how do I keep the PlayerBox sprite (or the collision lines, as you said) from resizing? And thank you very much for checking it out for me.

RangerJim - First, I LOVE that you have a Pixar character for your avatar. Second, thank you for also checking it out and confirming what Yann shared.

*bump* My apologies if the bump is too soon as I only posted this yesterday, but it was already on page 4. I was afraid it would get lost with no reply.

coltonrawrr - Here's my .capx of my game I'm testing new things on. It's by no means a finished work. But it should show you what you're looking for. When you look at the Event Sheet, scroll to the bottom to find the "Dr Box Movement" group. That's pretty much what you'll find in the tutorial — showed you.

Also, you can use a global variable to track your enemy's direction, but if you choose to limit it to a local variable (as I did - see the Local static text MrBoxDirection = "left" variable declaration at the start of the group), be sure to set the variable to "static" so it doesn't reset its own value every tick (which would override any changes in direction and keep it going the same way indefinitely). Think of static like electricity: it's always ready to be on the move and change. Non-static resets - or is re-declared - ever new tick.

Does that help? :) Anything we can clarify?

Thank you for the help! :) I got it worked out.

For my situation, I called on the instance count of the object and told it to -1 in order to refer to the actual ID #.

So, if I have five instances (IID #s 0, 1, 2, 3, 4) and want to destroy the last created/existing instance, then -1 gets me to that correct # and destroy it. So far, it's working.

The instructions I gave go like this:

->PlayerBox | On collision with Enemy

-->(sub-event) System | Pick Sprite instance (Sprite.PickedCount-1) => Sprite Destroy

.capx file here: https://www.sugarsync.com/pf/D6025908_4317202_6583129

Hello all!

My current problem rests in a "little" obstruction or...I don't know what it is...that stops Mr Stick (that's the stick man you can control) from moving forward just as he reaches the apex of the two-triangle incline (made of two instances of the platform45Slanted sprite object.

Once the .capx loads, simply start running to the right (A and D to move left and right, W to jump) and once the PlayerBox (the sprite objected that the MrStick image is set to) reaches the top of the first slanted platform instance and apparently collides with the second, it just gets stuck.

This doesn't happen 100% of time and doesn't seem to happen again after the first time (ie: you move away and come back again). I have Dr Box (that's the box with "evil" eyes) running on Simulate Platform movement and I've noticed he occasionally gets stuck, too...usually after Mr Stick is already stuck. But it seems to happen much less with Dr Box.

I have checked the collision polygon settings for BOTH instances of the slanted platform sprite. It's a triangle shape stretched as far as each point can go to their appropriate corners of the sprite. Both sprites on are equal in terms of the Y-axis. Both are the same size.

The ONLY possible explanation I can think of is that there is (I THINK) a pixel-wide space between the two instances. I haven't devised a way to test this or if it's even the actual problem.

Could someone poke around see what they can find, please? Thank you, much!

if you put the enemies into a family you could save the uid of the family

the collision would pick the right enemy a,b or c

How would I put the enemies into a family? What's a "family" in C2 terms?

AlexmosuTSP - UIDs only change in the editor. So if you hard-code an event that says "pick object with UID 5", and do some stuff in the editor, that event might later refer to a different object.

UIDs however are always unique to an object at runtime. So if you retrieve an object's UID and store it in an instance variable, for example, it will always refer to that object.

Can you give me an example of this, please?

My situation is where I'm using instances of a small block sprite to represent a health meter. Every time my character is damaged, an instance of the sprite will be destroyed. How do I initially call for the sprite's UID and store it to an instance variable? Am I to assume you mean an instance variable OF the sprite object, itself?

I've seen some similar posts to my dilemma, but nothing quite seems to answer my problem.

I've set up a simple side-scrolling platform scene and created a small incline sprite with the Solid behavior. I made sure the collision polygon is in place, will full crop of the singular frame.

My character with the Platform behavior moves and jumps as it should on level ground. The odd thing is that, while my character will jump and move just fine while going up the incline, going down is another matter. It will still move correctly while walking, but as I'm going down the incline, any attempts to jump act like it's locked to the platform.

A summary...

Horizontal movement up: Good

Horizontal movement down: Good

Stationary jump: Good

Horizontal movement up + jump: Good

Horizontal movement down + jump: FAIL

I tried to see if somehow creating a "reset" would solve the problem via an "overlap" condition by positioning the character up higher based on its previous elevation (stored to an "old_Y" variable). However, this actually made the problem worse (per my attempt). I find that I don't know how to test if it's actually an overlap preventing the jump or if there's that tiny split second when the character is "falling" from one pixel of the incline down to the next below. Or something else entirely.

Origin points are in place (bottom-center for the character and dead-center for the platform)...if that makes any difference, I don't know.

For the movement controls, I'm using Simulat Platform pressing Jump and the Action Set X to Character.X+CharacterSpeed*dt for the horizontal movement. I'm inclined to think the decimal value of dt is the cause of the problem...but, why on the decline but not the incline?

UPDATE: I changed the horizontal movement to Simulate platform pressing Left/Right and that seems to have solved the problem.

However, from my learning so far, setting movement based on dt can help even during slow PFS rates. Will using the Simulate platform Actions make any difference?

How do you set an instance variable to <varies>. I sorta get how it comes to that, but what circumstances result in <varies> being displayed in the properties bar? Like, if I edited the initial value, how do I get it back to <varies>?