How do I make a bullet more accurate?

0 favourites
  • 13 posts
From the Asset Store
This pack contains 10 types of bullet effects, with different shapes and colors.
  • Hey all,

    Im having an issue with the bullet behaviour. It is spawning correctly and it IS moving towards the mouse co-ordinates but its not accurate... at all. It moves in the general direction of the mouse co-ordinates, but not EXACTLY towards the mouse co-ordinates (which is the desired effect). Instead the bullet is always 50-100 pixels above or below the cursor, depending on its placement on the screen. See the screenshot below:

    [attachment=2:wmi7j8gg][/attachment:wmi7j8gg]

    Am i doing something wrong or is "the general mouse direction" the only way it can move? The following screenshots are of when the bullet being created and the its off-course trajectory:

    [attachment=1:wmi7j8gg][/attachment:wmi7j8gg]

    [attachment=0:wmi7j8gg][/attachment:wmi7j8gg]

    As you can see, its moving in the general direction of the cursor but nowhere near the actual co-ordinates.

    Any help would be hugely appreciated, as always

    Many thanks all,

    moymoymoy

  • Are you using the "Bullet behavior" for the bullet?

    If yes, on event 74 replace the "set angle toward" action with the "set bullet angle of motion" and on the field type: "angle(PlayerArmSprite.ImagePointX(1), PlayerArmSprite.ImagePointY(1), mouse.X, mouse.Y)" (without the quotes).

    Also, you can merge event 74 to 73. Add a "trigger once while true" condition to the event 73 and move the "set bullet angle of motion" action below the "spawn object" action.

  • Ahhh eli0s my hero good to see you man, hows it going?

    But yeah, i am using the bullet behaviour. Ive changed the events as suggested so it now looks as follows:

    [attachment=0:34ne9hoc][/attachment:34ne9hoc]

    Unfortunately im getting the same results

  • In the world of heroes I must be... the amazing slug-man!

    Doing good moymoymoy, thanks for askinng

    Now, this is weird. Is it possible to send me the capx (or a simplified version of it) to take a look..? We must be missing something obvious there, but a closer look will help to trace it down!

  • I'll inbox you the capx for same reasons as before Good to hear you're all good my friend ^_^

    In the meantime if anyone else has suggestions also, I'll be more than happy to try them out

  • You might need to take the layer/parallax into consideration. Look at the Mouse manual page: https://www.scirra.com/manual/114/mouse regarding X("layer"), Y("layer")

  • Ok. I have found the problem, but not a solution. It's the system| layout scale 0.6 that causes the offsetting...

    I must say that I was almost ready to bite my monitor when I realized that I should check the scale factor...

    If you set the layout scale to 1, it works ok. I don't know how to overcome this, I tried the magicCam plugin to see if the scaling from within the plugin uses an other algorithm, but it renders the same results.

    That's why I insist that a real 3d work space is crucial. As it is now, C2 scales everything from 0,0 coordinates, this is causing the offset. Perhaps there is a way around this by using the parallax values of the layers and ass/subtract some offset in relation to the scale, but this is too complicate for me.

    Some hero

  • eli0s That makes sense i guess but then why am i not having that problem with the Yee enemy when it shoots?

    blackhornet Thanks for the suggestion, i had a look/mess around with it but i was getting same results

  • Because it is not on the edge of the layout, thus the scrolling factor isn't so obvious? Also, you are not able to confirm exactly were it shoots, the mouse cursor is much more accurate comparison point to detect the offset.

  • eli0s has just described exactly what I was suggesting is the problem. You've got to get the coordinates all relative to the same layer.

  • blackhornet you are absolutely right!

    moymoymoy i'll send you the file... Thanks to blackhornet it works

  • Thank you both for helping and coming up with a solution

    Im sorry to appear dense however, but is there a chance this could be explained in simpler terms? Ive had a looked at the new capx and i understand the event/actions that are happening but i dont quite get how the difference is made.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It's a bit of a tricky concept, but run the example included. You'll see three squares. The red and yellow are on the same layer (0), blue is on a different layer (1) with parallax of 50,50. The coordinates of each are displayed at the bottom. Use the arrow keys to move the red square.

    If you move the red square a little bit, only the Red coordinates change, as you'd expect. But as you move further right or down, you'll see two things on the Blue coordinates. The first pair never move, as there is no movement being applied to the blue square, but clearly the blue square is moving on the screen. That's because the parallax calculation is coming into play and making the layer that Blue is on appear to move. The second coordinates are the coordinates of the blue square according to layer 0. They move, as they are showing the location of the blue square according to layer 0.

    When you need to calculate locations between two layers, you need to account for this. That is what the CanvasToLayer and LayerToCanvas expressions help with. You convert from the layer to the canvas, which is the global coordinate system, and then back to the layer you care about.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)