Ajbael's Forum Posts

  • Your event "Every gun.interval seconds" only makes sense if there is 1 gun instance.

    When there are many guns, this event will not work as you expect. I think it compares "interval" for the first instance only, but it doesn't do picking, that's why all your guns fire at the same time.

    Here is the way to do what you want without the timer:

    This event will pick one or several instances of the gun, only those which satisfy the condition (nextShot<time). Picked guns will fire and a new value will be set to nextShot variable.

    Yeah that's pretty similar to a work around that I am already using. Let me try explaining the problem differently. Let's say the gun needs to cycle out a cartridge before it can fire again. (0: Chambered, 1: Cycling)

    The gun won't fire unless Cycling = 0

    But if Cycling = 1, it will wait Gun.Cycle_Time seconds and then set Cycling to 0 so that the gun can fire again.

    When there are multiple instances of the gun things start going wrong. With even just two guns they will eventually both lock up and I do not understand why. I am trying to understand why things like this are happening, not work around the problems. I can come up with solutions all day long, what I need is understand of why problems like these occur in the first place.

    New .capx with cycling mechanic

    https://drive.google.com/file/d/13RpVWh ... sp=sharing

  • I realize now the title is probably misleading and I would change it but I'm not exactly sure how to concisely word what I am trying to learn about.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Use Timer behavior, it's perfect for this task:

    You can add a sub-event to "On timer" to check if the gun is reloading and only spawn bullet if not reloading.

    Yes that is a perfectly fine work around, but I have plenty of those. What I am looking for is an example of how picking can be used to specify to the system which instance I am referring to.

    The reason for this is because in the game I am actually developing deals with many instance variables as conditions and because I do not have a working example of how to use picking in that situation I have to work around every little detail.

    Please read the whole post.

  • In this capx you can create guns on point by left clicking and destroy them by right clicking.

    Every 0.1 seconds, the firing interval for the gun is set to random(0.1,1.0) The gun will then wait Gun.Interval seconds between each shot fired.

    The result is a gun that fires at constantly changing interval.

    However, when a second gun is introduced, both will be firing at the same changing interval. The desired result is to have them firing at a changing interval that is unique to each instance.

    Introducing the "For each Gun" condition causes only one gun to fire, no matter how many guns are present. (And I do not understand why that is.)

    --------------------------------------------------------------------------------------------------------------------------------------------------------------

    I am having this issue because I do not fully understand how picking works. I understand that there are many ways to work around this without getting into picking, but it is important I learn how to properly employ picking because in the game I am actually developing there are many more instance variables involved than just a changing interval and I can't get the system to understand which instances I am referring to even if they meet the variable conditions.

    For example, guns could have a variable for reloading (0: Reloading, 1: Loaded) and make a condition that the gun can not fire while reloading. Because I don't understand picking, what usually results is that when one gun is reloading, none will fire. Or whatever I am using to trigger the reload may cause only one of the guns to constantly be reloading for all the others while they continue to fire.

    .capx

    https://drive.google.com/file/d/13RpVWh ... sp=sharing

  • What I need help with

    I'm trying to figure out a streamlined technique for creating animations from particle effects.

    What I need it for

    The game I am developing involves spaceships, and I have been using particle effects for thruster exhaust. The effects are gorgeous, but there are a couple problems.

    First of all, the faster the ship moves the more the particle effect spreads out and becomes jumpy. You can see gaps in the flame coming out of the thruster. Additionally, if the ship is moving quickly and makes a sharp turn, the flames come out sideways.

    What I've tried so far

    To solve this, I have been using screen capture video recordings of the particle effects playing, which I then splice into individually cropped frames that I can use to piece together animated gifs. This is a painstakingly slow process, and I don't think it will be realistic for me to continue with it due to the sheer number of special effects I use in my game.

    Other Advantages

    Although I personally have not run into performance issues resulting from high object count particle effects, I anticipate it would become an issue in multiplayer rooms of 2-12 players. If the particle effects were condensed into animations, an effect consisting of any number of objects would effectively become a single object.

    This could be especially useful to me because I love making elaborate, dynamic special effects from particle effects using multiple layers, filters and many, many objects. Many of the special effects I would really like to use for my game are too graphically intense for decent performance, but if I could condense them into animations I could use my creativity to its fullest potential.

  • If I knew what exactly you were trying to accomplish, I could probably offer a better example or alternative. Maybe upload a Capx and some information about what is supposed to be happening with the Mouse/Sprite?

  • There is no way to reduce the speed of the cursor that I am aware of, but I think I know what you need to do.

    Set the cursor to hidden, and create a helper sprite with pin behavior

    On created, pin the helper sprite to the object sprite (Position only)

    Tell the helper sprite set position (Mouse.X,Mouse.Y)

    Then, tell the object sprite to move X pixels per second at angle (HelperSprite.Angle)

    In this way, the object sprite will follow the hidden cursor at the desired speed.

    If you only want to be able to "click" on things that the object sprite is overlapping, you can add that as a condition.

  • [System] On Start of Layout

    [Mouse] Set cursor to None

    [Mouse] Set cursor from Sprite

    This will turn your cursor into the sprite, that way speed will never be an issue.

    Other useful information...

    The sprite can not have dimensions larger than 64*64 to be used as a cursor.

    The sprite set to cursor will appear as it does in the image editor, not as it does in the layout. Therefore, it will not take scaling/rotating into account.

    Also you may wish to include the action "[Sprite] Destroy" following "[Mouse] Set cursor from Sprite" as you will otherwise have a static cursor in your layout which would be an unnecessary object and look odd.

  • Updates (Things I've tried to solve/working around this issue.)

    1. Are changes in the player's velocity not being communicated properly between the peer and host?

    Tried enabling physics for the peer and setup transferable velocity x and y values but this did not change anything.

    2. Is it related to physics?

    Completely removed physics and replaced everything with a custom movement equivalent and got the same result.

    3. Is it related to precision/interpolation of transferable values?

    Tried maxing out precision and experimenting with interpolation, did not produce anything of value.

    4. Did I set something up wrong?

    I edited the "Multiplayer Game" example provided by Scirra so that holding "W" (input: 0,1) would cause the peer to accelerate toward their lookaty, lookatx coordinates. This resulted in the same choppy movement I have been experiencing.

    5. Does the peer need physics/custom movement enabled?

    I tried enabling physics/custom movement for the peer's character, and allowing them to move it alongside input prediction, but it did not change anything.

    Does no one know why this is happening?

  • When connected as a Peer, you will notice that your movement becomes very jagged and jittery while accelerating. Movement will at times also be jagged/jittery while decelerating. I know that this issue is related to changes in the peer's velocity, but I have no idea as to what the actual issue is. I am hoping someone can help me figure out how to remedy this.

    The Capx linked below demonstrates the issue.

    When running the layout, press the “Join” button to join the game. Your ship will automatically rotate toward your cursor, and you can press “W” to accelerate. There is text at the top of the HUD to let you know whether you are the host or a peer.

    https://drive.google.com/file/d/0B9tqOz ... sp=sharing

  • This is the most accurate version i can make with my simple talents.

    https://www.dropbox.com/s/52ic3swmbkd27 ... .capx?dl=0

    The angle is always calculated with the same, non outgrowing, distances.

    When doing this on the parallaxing layer the little errors get bigger when it gets far away from the layout origin.

    The centre of mass is not used. I just can not get it done when using the centre of mass.

    The second to last one actually had the least drift, but I think we might be approaching this all wrong. Even if the drifting is caused by the two forces acting on two different points, this issue doesn't exist when using a bounding box or circle and for that reason I'm pretty sure its a bug.

    So I filled out a bug report, and hopefully it can be fixed before I lose my mind trying to figure out how to get physics objects using collision polygons to move the way they're supposed.

    Thanks again for all your help, I'm going to continue working on this until I find a work around or the bug gets fixed. I've learned some important things about layer coordinates and how the physics engine works through this!

  • Problem Description

    When applying force to a physics object that also uses a collision polygon, the object will not move in the exact direction that it should. How noticeable this drifting effect is depends on the angle you are moving at.

    This is not an issue if the object uses a bounding box or circle for collision detection.

    Attach a Capx

    https://drive.google.com/open?id=0B9tqO ... XBzbGRKOTA

    Description of Capx

    Puts you in control of a ship which will rotate toward the cursor. Hold "W" to apply force in the direction the ship is facing. There is a background grid which will allow you to easily recognize how the ship is moving in relation to its surroundings.

    Steps to Reproduce Bug

    • Step 1 Move in any direction. It is most noticeable when trying to follow a grid line up or down.

    Observed Result

    The ship drifts off course, or follows parallel to the course it should be taking.

    Expected Result

    The ship should move in a straight line toward the cursor, without drifting in either direction. To see how the ship should be moving, change the collision mask to circle or bounding box.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (YES)

    Operating System and Service Pack

    Windows 8.1

    Construct 2 Version ID

    r245

    (This has been an issue in previous versions as well.)

  • Now i understand the problem. I apologize for not getting it earlier.

    The reason for this is that the force is pushes from the center of mass and the rotation takes the origin.

    But lets first go the path that you started. starting from the collision polygon.

    Lets explore the center of mass, see if it drifts.

    https://www.dropbox.com/s/6s7ay6vwoxtqb ... .capx?dl=0

    It does not. It is pretty stable. But it is a little of do inevitable floating point calculations.

    Is that enough to cause a torque when applying a force ?

    https://www.dropbox.com/s/s2kl9qpgilaoo ... .capx?dl=0

    Darn it, yes it does. So in some way, your guts are right.

    Same problem when we use an exact imagepoint ?

    https://www.dropbox.com/s/92uz1kof9rsp7 ... .capx?dl=0

    Nope, not at all. So it kinda a butterfly effect, a little mathematical error that cause big changes.

    I have no idea if it possible to do this better. In real life it is not possible, just less noticeable do the proportions of mass, forces, gravity ..... and so on.

    Question remains, is this the cause of the problem we face.

    https://www.dropbox.com/s/tb85vpfaawclh ... .capx?dl=0

    No, no, i still notice drifting. An that is because the rotation gripes on the origin and the force gripes on an imagepoint that is not the origin. Those forces do not balance out.

    But, we can not rotate an object with the center of mass as origin. Well, in a way we can, just set a torque towards the mouse coordinates on that layer. But then i dont know how to avoid the wobbling, the torque will always overshoot a little.

    So, we have no other chance (but i am not the smartest in here, maybe someone knows how to stop the wobble) then taking the two system apart. The 'system that rotates in tick steps' and the 'physics system'.

    Here goes:

    https://www.dropbox.com/s/8tmehuf4r61tc ... .capx?dl=0

    Hope this explanation satisfies you.

    No worries about the misunderstanding, I really appreciate the input!

    There is still some drifting and wobbling, although certainly much less now.

    Knowing that this issue is a result of the two forces being applied to two different points gives me something I can work with when it comes to problem solving. However I'm not sure why that is an issue when a collision polygon is being used but not an issue when a circle or bounding box is being used.

    Either way I'll get back to you if I ever figure out how to solve this issue completely. Can't help but feel like there must be a simpler way to do this.

    You've given me a lot of information to work with, thank you so much

  • I do not see a collisions setup in that capx. So i do not understand the initial question, still.

    About this capx.

    Besides a few weird things that you do, i see nothing wrong, or i miss something.

    Weird things ? ....

    1 In the physics world there is no such thing as an immediately movement, like you rotate that sprite. That will mess things up, got to do things smoothly. (with respect to time).

    2 You compare to mouse coordinates that are not on the layer that you are moving, due the parallax. Run it in debug, en click 'mouse', watch the coordinates for the layers, you will understand.

    So, if i do those things in a better way .....

    https://www.dropbox.com/s/4sqbnd0bjioqe ... .capx?dl=0

    ..... Do we still have problems ? Do i miss something ?

    There is no collision setup because I'm not having a collision issue. The issue is that whenever I use a Collision Polygon for a Physics object, that object will drift or move at a weird angle while moving.

    It seems like the capx you provided with mouse coordinates relating to the layer the ship is on and replacing immediate turning with velocity based turning did smooth things out a bit, but the issue remains.

    It is most noticeable when trying to follow a straight path while going up or down, the player object will drift along the side of the path you're trying to follow.

  • Well, strip it to the bare bones, and share the .capx.

    https://drive.google.com/open?id=0B9tqO ... mVheVpWUDA