R0J0hound's Forum Posts

  • You would only need to round it when you display the number. Another way is to just use whole numbers and convert it to a decimal only when you display it, that way no rounding is needed. I think newt was alluding to that above.

    So instead of:

    Global number num=0

    Every 1 seconds

    --- add 0.2 to num

    --- set text to num

    Do this:

    Global number num=0

    Every 1 seconds

    --- add 2 to num

    --- set text to num/10

  • It's not a bug, it's a limitation of how floating point numbers are stored on a computer and some rounding.

    What happens is 0.2 can't be percisely represented in floating point so numbers are slightly off when doing math. It's much like how 1/3 takes an infinite amount of decimal places in base 10. It happens that 2/10 takes an infinite number of binary bits and floating point only has maybe 50? I forget exactly.

    Look at the accuracy problems section here for more of a read.

    https://en.m.wikipedia.org/wiki/Floating_point

    You probably can find some more explanations by using the forum search on the bugs forum with the keywords floating point.

    All other software that uses floating point numbers experience the same result. The difference sometimes is when putting the number into text they often round the result to say six decimal places instead of the 15 or so seen there.

  • Look in the manual about the mouse plugin. You can use and expression like mouse.x("layer 0") to get the position on that layer. It hAndles parallax, angle, etc...

  • randomly

    I'm unable to see what's amiss. I don't have access to C2 and what you want to do is different enough it's probably easier to start from scratch.

    In regard to the alternate idea in my last post to calculate the impact point exactly: the process is to use algebra to manipulate the first equation into the form ax^2+bx+c=0 and use the quadratic formula to solve for x. Well except it will be time in the equation. Anyways we can disregard that one for now.

    You said the bullet behavior doesn't give X and y velocty. While this is true, you still can convert it over:

    Vx = speed*cos(angleofmotion)

    Vy = speed*sin(angleofmotion)

    You can also convert it the other way

    Angleofmotion = angle(0,0,vx,vy)

    Speed = distance(0,0,vx,vy)

    The most complicated bit of the original example are these three actions:

    add vx*dt to X

    Add gravity*dt to vy

    Add vy*dt to y

    Those change the velocity and position to what they would be after dt seconds. You can replace dt with any duration you like. Next put those actions under a repeat condition and it is done multiple times. So say you repeat 10 times and use 0.1 instead of dt, it'll calculate where the position will be after 10*0.1 or 1second.

    I did skip a step though. Before the repeat you need to set X,y,vx and vy to what the bullet is currently. As a sub-event of the repeat event you can check so see if y is below the ground level, and then stop the loop and place the marker.

    Alternatively you could position a second Sprite at the bullet and move that instead of using Xy variables.

  • statham

    You can still do that as I said.

    Add a new condition:

    System -> pick by comparison

    Select you Sprite as an object type and use the expression Sprite.chipmunk.speed to get the speed.

  • statham

    I purposely didn't add and conditions to compare expressions of the behavior. You should use system-> compare or pick by comparison with the expression to do it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Not really. The errors are passively logged so it's hard to know what causes it. You could try a trial and error approach to run your game for a bit, try some things, close, and see if any errors were logged. Maybe to speed things up you could somehow check when that file is created or modified. That's something outside the scope of C2 but there are ways that can be found with google. With either approach maybe you could narrow down what causes it.

    You could also use a debugger or try recompiling nw.js to stop when those errors occurs so you can check what causes it. Neither sound easy though.

  • randomly

    If you just want to mark the point it hits the ground then you can either just set speed to the bullet's speed or if the ground is flat you can just calculate the impact x directly by taking these two equations and solve for x:

    y = initial_y + initial_y_velocity*time - 0.5*gravity*time^2

    x = initial_x + initial_x_velocity*time

    which would be:

    x= initial_x + 2*initial_x_velocity*initial_y_velocity/gravity

    if the bullet was launched from ground level

  • Ashley

    That makes sense. It would be a nice to have though. I guess I was imagining the ui highlighting the picked instances in a similar way to what happens when you select an instance from the list.

  • If your game doesn't crash they're not fatal errors. I have no idea what causes them.

  • Searching around the net it looks to be related to the chromium browser which nwjs is built upon. That said it appears to be a general error and many cases that cause that error have been fixed in chromium and nwjs updates.

    • Post link icon

    Dropbox is no longer letting you host webpages like that. It only stores files now.

    See here:

    The solution is to use some other service to host a webpage.

  • If the debugger could let you step one event or condition/action at a time and be able to inspect what is being picked then that would probably satisfy the op. Also would it be possible to set break points in triggered events and let you step through that?

    Currently debugging events is something new users have trouble with. More advanced users resort to logging text or visualizing what's picked somehow manually. Debugging more complex events usually requires disabling most of the events and building it up a little at a time while visualizing what's picked. In some cases advanced users can mentally run through the events as they read it to find what's amiss but in most cases it's easier to scrap it and start from scratch.

    Anyways being able to debug events at a finer level would be useful in helping new users with the nuances of the event system and advanced users to identify where their events are failing.

  • You can also add effects to layers or even the layout.

  • With full access to the physics library you can disable gravity for certain objects by applying a force to cancel the acceleration of gravity. However it must be applied before the gravity is applied. In the chipmunk behavior you can do this in the "pre step" trigger.

    For the physics behavior disabling gravity and manually is the way to go. I haven't tried the apply force action for a bit but if it's not possible to not apply a force to the com then you could instead calculate the torque and cancel it out. The formula for that is easily found with Google and the only snag is converting the distances and angles to the units used by the plugin.

    Edit:

    Here's info on converting units for the physics behavior: