deadeye's Recent Forum Activity

  • There will be one set of pink/orange boxes. This may be where I misinterpreted the purpose of containers -

    you mean that defining the image points and attaching the boxes to them is what will do the job and containers are redundant?

    Yes. Imagine you had a swarm of bees and they each had a separate hitbox. That's what containers are for... to keep track of which bee belongs to which hitbox.

    And if a bee's hitbox gets picked (like with a collision) then you can say "destroy bee" and the proper bee will be destroyed because the container picks it for you.

    [quote:2qn9s3y2]The purpose of the grid is something along the lines of:

    A non player sprite (enemy or wall or whatever) overlaps box 1a. This triggers an event which displays "Enemy in zone 1A!" warning elsewhere on the layout. If that enemy moves to box 2A the warning changes to "Enemy in zone 2A".

    You could do this with instances of the same sprite. Just give each sprite a zone variable and pick and set them according to what their value is. You could even re-use the myPoint variable I made - it has the zone info in it already.

    [quote:2qn9s3y2][quote:2qn9s3y2]http://dl.dropbox.com/u/529356/containers.cap

    Thank you very much ! That appears to do exactly what I was thinking... and a lot more elegantly than the first few drafts I'd knocked together

    No problem, but keep in mind you could simplify it even further now that you know what's up . Here's a quick example of something similar that shows how you can use instances of the same object:

    http://dl.dropbox.com/u/529356/nocontainers.cap

    As you can see, even though they're the same, you can differentiate between them by their variables.

  • Oh, by the way that .cap uses v0.99.82. Sorry I forgot to mention that.

  • Three questions before we begin:

    First, are you having multiple pink squares running around with many groups of orange boxes attached to them? Or do you just have one pink square with one group of orange boxes attached? (If you have just one pink square and one group of orange boxes then you don't need Containers.)

    Second, do all of the little boxes perform the same function, or is there some special reason why you need to have each box be a separate object? (You may be able to make this grid out of many copies of one orange box... but then Containers wouldn't work that way.)

    Third, do all of your orange boxes exist all the time, or will some be destroyed and/or created as the game progresses? (If you need to destroy some of them, then again Containers won't work. All objects in the Container must exist, or none must exist. There is no middle ground.)

    The answers to all of these questions is important, as depending on what they are you may or may not need to use containers in the first place. Please be as detailed about what you intend to do in order to get the best help possible. We can find you an alternate method if need be.

    Now then. I've gone ahead and shown a method here anyway that will allow your contained sprites to work as intended. But like I said, answer those questions just to be safe, you could be saving yourself some trouble:

    http://dl.dropbox.com/u/529356/containers.cap

    What I added:

    1. Image points to your pink sprite. It would need 25 in total, one for each of your orange boxes. I got as far as 2C because I was lazy. Also, I just slapped them on there and didn't bother trying to line them up properly, so that's why they're crooked. Open the pink sprite in the image editor and select the image point tool to see where the image points are located. You will have to add the rest and line them up properly yourself.

    2. I put all the orange boxes into a family (the Blue family).

    3. I gave the Blue family a variable called 'myPoint' and populated that variable with the image point name that each box should line up with. Up to 2C, that is. The others default to the pink sprite hotspot at the center because they have no image point name to match up to.

    Of course all of the orange sprites are contained with each other, and with the pink sprite, but that doesn't mean they will move together. You still have to tell them to set their positions and angles and such. So here's where we do that, and the reason why we've set up all this stuff:

    4. I made the following event to set the placement and angle of each contained object...

    + Always
        -> Blue: Set position to pink sprite at image point Blue.Value('myPoint')
        -> Blue: Set angle to pink sprite angle
    [/code:rg7lpncs]
    
    Since all of the orange sprites are in Blue family, you can just perform all of the actions on Blue at once instead of having several actions for each object.
    
    I've tinted the orange boxes for the group on the left with a red color filter so you can see that the container is separating them properly and the matching ones are lining up only with their contained pink sprite.
  • Whaaaa...

    I have never noticed that action. Very strange! I learned something new today.

    Anyway, it appears that it sets the coordinates according to your desktop and not according to your the game window. So I don't know of a really good method for using that the way you need it.

  • I am trying to make an auto-target, so when i press the button X, the mouse cursor go to a target.

    You can't set the position of the mouse, if that's what you mean. The mouse sets the position of the mouse.

  • HEY, LISTEN! You have two options here.

    1. Post your .cap like I asked earlier so I can see if it's something you're doing wrong or if it's actually a bug or what.

    or

    2. Continue thinking that you can't make Jump Sustain work without even getting any help on the matter.

    It might be messed up! Who knows? NOBODY KNOWS UNTIL YOU POST WHAT YOU'RE DOING ARRRGGHHHHHHHHHHHHHHH!!!! Saying "I just don't think it works" over and over again isn't going to make it work.

    </frustration>

    So... pretty please, with sugar on top, post your .cap

    And if you still don't want to for whatever reason, you can't say I didn't try.

  • I still don't see the need for making your own jump sustain. As I said before it's just a matter of changing the settings until you get it right.

    But whatever, I guess. Carry on...

  • What

  • Which one, stupid or funny?

    I can handle stupid as long as it's also funny.

  • Mr. Wolf, what are your Platform settings? Often it's just a matter of tweaking the settings until you get what feels right.

    Post your .cap if you can.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Holy crap, that's amazing!

    You've really outdone yourself R0J0hound. Awesome work.

  • I can think of several ways to make my own but I have to say I never considered using the Image Manipulator. Seems rather a complicated solution compared to some other methods you could use. Such as:

    + For each sprite ordered by sprite.value('node')
        -> Set waypoint at sprite.x, sprite.y
    [/code:2jovgvy5]
    
    Not to mention the problem of telling which direction you intend for the path to go based on where the next pixel is.
deadeye's avatar

deadeye

Member since 11 Nov, 2007

Twitter
deadeye has 1 followers

Trophy Case

  • Email Verified

Progress

17/44
How to earn trophies