.CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6663023

I'm trying to set up a grapple hook feature where the player will left-hold to aim, and then release so a hookshot-like accessory will come flying out until it either enters "oblivion" (aka, outside the screen) or hits a solid object. Once it hits a solid object, Mr Stick will be reeled in as the chain "retracts" (the dots that represent the chain do not move during this process). When he is pulled up to the the Grapple, he should fall slightly and dangle from the Grapple.

Up to this point, I have a relatively bug-free success UP TO the Grapple firing and reeling in MrStick (my character) to wherever the Grapple has attached to.

But that's about the end of much of my progress...

DIRECTIONS:

To fire the Grapple, left-hold the mouse towards the box up on the far right. Release the button and MrStick should fly off, destroying the instances of the pixel chain sprites along the way (simulating a retraction of the chain).

FYI, I have temporarily disabled having the MrStickMain sprite set to the PlayerBox object (which houses the Platform behavior) while I work out this feature. This is sure to result in further problems when I re-engage the "Set To..." event. LOL

PROBLEM 1

After firing the Grapple and it hits a solid object, and upon being fully reeled in to the Grapple, I want MrStick to just kind of "fall" from whatever angle he is at while his hands "clasp" to the Grapple. So I'll pretty much need at least two things, I think: 1) a gravity effect to pull him downward from whichever angle he's at up to being fully reeled in, and 2) a physics hinge point for him to rotate on at the Grapple while gravity is effect on him. He'll stop falling once his angle is that which has him hanging down.

Note that in the Edit Animations for MrStickMain, the image are set to that it looks like he's stretched out horizontally. This is to account for the move forward dt*1000 pixels on line 43 (otherwise he'd fly off to his side! lol).

PROBLEM 2

Note that in Problem 1, I have you fire off at the box on the upper-right, to MrStick's right. Now, before you release the left-mouse button, move the pointer to Mr Stick's left and fire towards the box just above his head. You'll notice that he gets totally flipped over...and even flies away! I cannot account for this.

I've tried applying the Physics behavior to the Mr Stick sprite but I'm not sure which event/action feature to use. Can anyone see what I'm missing and suggest some solutions, please?

Sorry, Xavier, you've just lost 6 years of your life... ;)

I was the third person to download the latest beta of C2 (r122), and I've reloaded the page and double-checked several times to make sure there wasn't some kind of lag in the web site figuring out who did what when. Nope...I'm still the 3rd fastest this time around. I did get the Quick Draw badge...but...I was one of the Lightning guys.

My apologies if this sounds petty. Not my intent. I'm just thinking so long as there is a rep score (which I think is fun...that's why I'm posting this), then I'd like an accurate representation of my badges and score.

(PS - I do understand, last I read about, that the rep system still is getting some kinks worked out. No worries about that.)

BluePhaze - Oh? You've been "watching" me? *chuckles* I didn't realize I'd become that recognizable. Most of my posts have been requests for help...not much in what I can do TO help others yet.

I'm just surprised. I didn't imagine I'd made any impact yet.

BluePhaze - Thank you for that, truly. On one hand, I don't mind so much, but you're right all the same. I have been putting in many hours just struggling with one little aspect of my game project. My time is limited... I appreciate the advice and encouragement.

BluePhaze - *sigh* ...yeeeaaaah...good point. I kinda didn't pay it any mind, but yes, you're very right. I'm still learning C2 as a whole and I didn't realize there would be any issue about loading a beta .capx file onto a stable version.

ghale - Sorry about that. I'll take care of it a.s.a.p. Thank you for trying to take a look. I'll let you know when the stable .capx is up.

.CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6544223

This is nothing more than a test program I worked on in trying to better understand using groups to keep certain actions from happening while other conditions were true.

What I have now works as I intended, and (go figure) a lot less complex than I first worked out.

The aim is simply to press the 1, 2, or 3 keys (keycodes 49-51; if your keyboard has a 10-key number pad, do not use it as they have different keycodes) and the associated group will activate, setting the associated variable to it's related group number. And every tick the active group number will be displayed according to its variable - the others will be reset to their original value at runtime. Nothing to go "Ooooo" and "Aaaah" over.

I wanted to share this to get some feedback on how I might better set this up and other uses for Groups that could extend from what I have here. This is just for general feedback...maybe you've thought of some clever ways to use Groups that I certainly haven't. What kind of problems might arise from using groups to isolate events until they are needed and how might I counter them? What have you encountered?

Also, can someone explain just what "toggle active" for System-->Groups does? I tried using it, but it didn't work as I anticipated, and I can't find any help in the manual. Thanks!

silkc2 - Whooooaaaaa! THAT is way cool. Gonna take me a moment to wrap my head around what's all going on in the event sheet, but that's VERY sweet lookin'! Good job!

ramones - *FACEPALM* I thought I had either deleted that behavior or simply by not USING it in the event sheet it wouldn't be in effect. It's those "little things" that I am not yet aware of that always seem to get me. You're certainly getting major kudos in my end-of-game credits (I'm making a list and checking it twice LOL). As always, I'm very grateful for your help. God bless you, truly!

...*a moment later*... SUCCESS! That did the trick and it looks just like I hoped! :D

silkc2 - You're talking about stuff I'm not yet familiar with (lol), but I'll definitely check out your example and see if I can't employ it later. Thank you for your suggestion. :)

This is a multi-part question...please bear with me.

.CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6541819

QUESTION ONE:

In the .capx event sheet, scroll down to the Mr Stick - Grapple group.

Starting at line 18...

• LINE 18: Object GrappleStaple moves forward at dt*200 pixels
• LINE 19: Every tick, add dt*400 GrappleStapleChainPixelCount (abbv to GSCPCount...hey, it's how I keep track of what the variables are for! LOL)
• LINE 20: 1) When GSCPCount reaches at least 10, create a new instance of the GrappleStapleChain sprite object at the proper angle, 2) reset the GSCPCount variable
• LINE 21: As long as the number of instances of the GrappleStapChain object is more than zero, move the instances forward by dt*1000.

This is what confuses me...

While the Staple object is moving forward at 200 pixels/second...

...a count of 10 per 400/second goes by (I can adjust the "10" value to whatever I want...that'll simply change how often a new Chain sprite object instance is created)...

...but I must have the Chain sprite objects moving at a see of 1000 pixels/second to have them move at the same (or CLOSE TO IT) speed of the Staple object.

If I set the speed of the Chain objects to the same value as in line 18, the Chain objects would seem to trail behind, creating a huge gap between the Chain links and the Staple. Even trying to account for the average 60 ticks/second runtime, this isn't making any sense. Why can't the speed of the Chain and the Staple be the same value in the event sheet?

QUESTION TWO:

You'll notice on line 22, once the Staple object overlaps with the platformSquareBox object, it's supposed to stop the Staple object from moving - I set the movement to zero pixels per second. Back at line 18, one of the two conditions are so long as the Staple object is NOT overlapping with the box may it continue moving. But even after testing that C2 is registering that there is an overlap, which would make line 18 false, the Staple object continues to move forward. What gives? This includes the fact that once there is an overlap the GrappleFire variable is set to "NoFire", which also should prevent the Staple movement. I did have this working just the other day (thanks much to ramones).

Thank you for your help!

ramones - I did notice that (I have a Text object set up to check...). That's okay for now, because the final part of the project for this "grapple hook" will eventually lead to it being destroyed when it hits a solid object...I just haven't gotten to that point yet. Thank you for noting that for me, though. :) You've been extremely helpful!