Rhindon's Forum Posts

  • .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!

  • ramones - Thought: Would it be perhaps better to set it to GrappleStaple.Count = 1 So not to accidentally have it misfire should there somehow be TWO instances? Or rather to PREVENT two instances?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • ramones - OH! Yeah, I JUST discovered that a second ago...

    I thought C2 might count it because it IS on the OUTSIDE of the layout so I can create new instances of it (see line 14), but I didn't realize that it's not counted AS an instance for the reason you noted. I thinks I gots it now! (Testing...testing...)

  • ramones - Wouldn't it be better to set it to GrappleStale.Count < 1, since there is already such a sprite just outside layout edge? And because I only want it to fire if there are no other sprites of that kind on the layout?

  • ramones - I'll test that and let you know. Your help is greatly appreciated!

  • ramones - Thank you, sir! You confirmed what ArcadEd discovered for me earlier (he's part of a Facebook group I admin).

    I'll work on it, myself, but do you have any suggestions for a fix (in case I can't see the solution...)?

    Thank you, again!

  • Mage213456 - Are you assigning instance variables directly TO the object? I don't mean creating a variable globally in the event sheet, but creating it through the object. Select the sprite/object you want to have the health value instance variable for, then, on the far left of the editor, in the properties bar, look for the instance variable option...that should do the trick for ya.

  • .CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6545687

    When the .capx loads, left-hold the mouse button anywhere on the browser screen (eventually, I may try to limit it to just within the game window. Mr Stick will hold out his hand with a C-shaped object attached (it's supposed to be a staple, like for a stapler).

    Release the mouse button and the staple sprite should fly off to the...er, big BLACK yonder. When the staple is in motion, the GrappleFire variable text should read "Fire". Presently, I have the condition set that it will return to "NoFire" once the sprite is destroyed upon leaving the screen or collides with a solid object (this does not include the DrBox sprite). I have also tested it to set to "NoFire" upon leaving the layout. ...I get the same problem, which I'll detail next.

    Rapidly click the left mouse button so that the staple sprite fires off into space (NOT coliding with any of the boxes in the area). Before long, Mr Stick should get locked into his aiming stance. The GrappleFire variable will say "Fire" and will not reset. Somehow, there is a brief point in the event logic flow that I cannot account for that allows Mr Stick to resume a pre-fire stance even while the staple sprite is still in motion.

    Mr Stick should NOT be able to resume is pre-fire stance UNTIL the Sprite has (1) been destroyed by leaving the window parameters OR (2) collides with a solid object (that part is working fine).

    Possible solutions that I cannot figure out:

    • Testing when the sprite leaves the game's WINDOW parameters
    • Allowing the GrappleFire to reset to "NoFire" only when the Staple sprite has been destroyed

    Can anyone see that "gaping hole" in my event flow that's allowing Mr Stick to get locked into his pre-fire stance (due to the GrappleFire variable)? Thanks!

  • Ashley admitted on the first page that he caved and called it "skeeruh". Case closed. LOL

    I would agree that the "sc" (as in "scissors") might be a silent-C, but then, "scirra" isn't a normal word in any language (certainly not English). THUS, it's quite reasonable to think that the C is a K-sound letter. sKirra.

  • ramones - You win the award for awesome-est helper of the day. Thank you, sir!

  • .CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6502596

    I'm working on the top-down shooter tutorial made by Ashley to see if I could figure out another issue I'm working out (a totally different game).

    I started messing around with some features and discovered you could adjust the "zoom" level by changing the layer scale (in my .capx above, you press A to "zoom in" and D to "zoom out". The zooming works fine, but...

    If you're familiar with Ashley's tutorial, you know that the Player (Hero in my .capx) sprite is supposed to set its angle toward the Mouse X/Y coordinates. When the layer scale (or "zoom") is 1, that works swell. However, changing the zoom levels (up or down) affects the sprite's ability to track the mouse properly...it's tracking, but, oddly. I don't understand why. At least, I have a notion but I can't explain it, let alone figure out a solution.

    I'd definitely like to incorporate a zoom option in future games... Anyone have feedback on what's going on? If so, I may be able to figure out a work-around. Proposed solutions are welcome, of course.

    THANK YOU!