Yttermayn's Forum Posts

  • So this seems like a popular and incredibly useful plug-in. I got it installed, but I can't find much in the way of documentation. Is there a page or txt file somewhere that explains the features and usage?

  • Ash10500 Unnatural20, Thanks guys! I think I'll go the route of the tiled background with bullet behavior, and I took note of the choppiness issue in the related thread.

  • Is it even possible? What I'd like to do is have a repeating pattern scroll slowly by along the x axis as a background. I figured a tiled background would be a good start for the repeating pattern. However, the only way I can think of to animate it is to make the boarders of the tiled background object a multiple of the width of the image being tiled, and then slowly move the tile background along and reset it's position after it moves one image width. Hopefully that would preserve the illusion. Is there a better way?

  • Ashley Thanks for the explanation. I did find a workaround though. If you add the custom movement behavior to the Field and accelerate it simultaneously with the Anchor, everything works out. That way I don't have to reinvent the wheel so much.

  • Problem Description

    We have three sprites, "Anchor", "Field", and "Arrow".

    Pin Field to Anchor. Arrow we control through 8-direction movement. If Arrow overlaps Field, Field changes color (by changing animation frame, but that's not important)

    Accelerate Anchor and Arrow identically to the right using custom movement. Get them up to about 1000 pixels/sec to make the effect very obvious. Field stays with anchor perfectly, as does Arrow. Now use 8-direction to move Arrow toward Field. If you approach from the left of Field, Field will change color before Arrow actually overlaps Field! Approach from the right, and Field won't change until well after Arrow has overlapped. It is as if the overlap collision is getting checked after Field has moved on due to the pin.

    Attach a Capx

    Done.

    Description of Capx

    The .capx does exactly what is described above in order to illustrate the bug. It also has walls that demonstrate that pinned solids work correctly in this scenario as long as Arrow has 8-direction listed before Custom movement in it's list of behaviors. (Note that if Custom movement is listed first, you get a solid collision bug similar to the overlap collision bug).

    Steps to Reproduce Bug

    • Step 1 Hold the space bar down to accelerate Anchor(the purple square) and Arrow(the red triangle) to somewhere around 1000 px/s.
    • Step 2 Move Arrow around using arrow keys. Make Arrow overlap Field (the blue-green rectangle) from different directions.
    • Step 3 Observe the results.

    Observed Result

    Overlap condition works as expected when there is no custom movement. Overlap collision detection "lags" behind while the pinned sprite is moving.

    Expected Result

    Overlap collision detection should function the same whether the sprites are moving or not.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (Tries, but shows black screen with HTML5)

    Operating System and Service Pack

    Windows7 64bit Home, SP1

    Construct 2 Version ID

    Release 195 64bit/Steam

  • newt Ok, I just discovered something new: A scale of 1 makes the sprite the size of the *original image*. So if in the editor you shrank a 64x64 sprite down to 32x32 and then at runtime set scale to 1, that sprite would pop back to 64x64. I thought it would go back to the size set in the editor. Live and learn. I think I will do what you suggest, since many of my sprites are not the same size as the original image. Thanks again.

  • newt Oh, I see where you were going. I was thinking of using a variable that simply gets changed anytime the scale gets changed so that there would be some way of reading the current scale. Thanks for explaining that.

  • Somebody Because it's fussing with two expressions instead of one, and there's extra math involved if you want to change size via percentage change, and you have to store two variables to hold the original size data as well. It's just plain clunky. Thank you though. The built in scale system is quite nice, it is simply lacking when you want to read the current scale setting is all. (IMHO)

    newt I don't quite understand your "scale in reverse" comment, please elaborate a little?

    Also:>"A variable is the only way to go, but it also renders the scale action pointless."

    Do you mean the action is pointless because we have a redundant variable? Because you still have to use the set scale action to make the sprite's scale actually change. It's just a hassle to not be able to read an objects current scale, thus the need for a somewhat redundant variable to track the current scale.

  • You can set the scale of an individual sprite, but I want to make a sprite shrink over time by referencing the sprites current scale. However, I do not see any scale expressions listed.

    For example: On Timer"Shrink", set scale to sprite.scale-0.2

    Is this possible, or do I need to maintain a separate variable to track the sprite's current scale?

  • Bump. Anybody know anything about this phenomenon?

  • Is order of behaviors in an objects behavior list supposed to make any difference? If not, then this may be a bug.

    Run the attached capx. The four walls have the solid behavior. They are pinned to a little blue square. The two colored arrows have 8 diretion and custom movement, and the blue square has custom movement. Press space bar to accelerate the walls with the red and green arrows inside it to about 500p/s or more, there is a readout above to show speed. Use the default 8 direction arrow keys to move the red and green arrows around inside the moving box. Notice how when encountering the forward wall, the red arrow behaves as you would expect, but the green seems to encounter the wall early and jitters there. At the back end of the moving box, the red behaves normally, and the green doesn't stop until it's passed partway through the rear wall. It gets worse as speed is increased.

    The only difference between the red and green arrows is that the red has 8 direction behavior listed before custom movement, and green is the opposite order.

    Is this somehow expected behavior, or should I submit it as a bug?

  • brunopalermo Yes, but it doesn't do rotation, and I notice the white square continues to move when the platform changes direction. While that seems to imitate real life inertia, it isn't actually scripted to do that (as far as I can tell) and is therefore an undesirable side effect (due to lag, maybe?).

    To make matters worse: In my game the ship has walls which have solid behavior, and the ship is controlled through custom movement behavior. The player is currently controlled through 8 direction behavior (while I experiment). I got the player to move around on the ship and stay with the ship by applying the same angle and acceleration to the player as I do to the ship. This works pretty good, but all the walls solid behavior lags behind the graphics of the walls while the ship is moving. So even though you see a wall where it's supposed to be, it won't stop you from moving until you are further aft of it (the exact difference depends on how fast the ship is moving).

  • How do I make the player move with another object, yet still be able to move around relative to the object. In other words, what is the best way to let the player walk around on the deck of a moving ship. (the ship may be rotating and accelerating all the while). Don't bother saying to just pin the player to the ship, that doesn't allow player movement)

  • Kali Good point. Thanks!

    Edit:Tried it and yeah, even chaining once makes the pieces lag behind big time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Say you have a vehicle made up of dozens of parts (sprites). You need to pin them all to the sprite that is controlled by the player. Is it easier on the engine to pin groups of parts to "bases" and then pin the bases to the player controlled object, or to pin all parts directly to the player object? Or does it make a difference performance wise?