Colludium's Forum Posts

  • Thanks Ashley - it makes sense to have the option to affix a joint to the CG.

  • Rhindon, maths, trigonometry and engineering physics are my forte - but not when I'm tired LOL - which is why I love C2 because I'm also, it seems, unable to learn how to code effectively (and I've tried - I just don't have the patience / aptitude!).

    Why the square root? What is the meaning of the maths here? LOL

    All I was doing was applying Pythagoras' Theorem to the data from the physics behavior. It's a fancy way of saying that I took the velocityX and velocityY values from the physics behavior and added them together to determine the overall velocity of the object. They can't just be added together, though, they need to be squared before they are added - by taking the square root of that sum it allowed me to work with a pixels per second value, which is easier on my brain, although not strictly necessary. This explanation does a better job than I can to explain how it works, if you're interested!

    Also, what is an "arccosine". Even in my brief time in Trig/Calc in high school, I do not recall ever learning about this.

    The arccosine of an angle is simply the inverse of the cosine of an angle. LOL - I must have been tired when I put that example together - luckily I stopped trying to calculate whatever it is I was thinking of by using that equation. It simply won't work - if the velocityY is zero it will return NaN.... Oh well... I'll go and edit it out of the original - the shame!!

    The correct equation would have been: velocity angle = arccos( velocityX / sqrt(velocityX^2 + velocityY^2) )

  • Everade, Ashley - thanks for the re-education and apologies for the duff report.

  • Problem Description

    When creating a revolute joint around a sprite's imagepoint(x) the physics engine does not always pick the correct place for the joint pivot point.

    Attach a Capx

    [attachment=0:26flhgi7][/attachment:26flhgi7]

    Description of Capx

    The capx contains 2 physics sprites. Instance Sprite is an immovable object with 2 image points: 0 on the left edge and 1 on the right edge. Sprite2 is a movable physics object. On start of layout, one Sprite is picked by UID to create a revolute joint to each of the 2 Sprite2 objects from one of its image points (these are chosen by UID as well). When you run the layout, it is apparent that one of the Sprite objects is not jointed to the correct position of image point 0.

    Steps to Reproduce Bug

    • Run the layout
    • Observe the action of the Sprite2 objects

    Observed Result

    As described above - one instance of Sprite2 appears to be pivot jointed to the center of Sprite rather than to the left edge.

    Expected Result

    The joint should be created to the correct (and not imaginary) image point.

    Affected Browsers

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

    Operating System and Service Pack

    W8.1 x64

    Construct 2 Version ID

    r195 64 bit

  • Great work here - very impressive and worthy of a lot of respect! I hope you make a well-deserved mint out of this venture!!

  • Problem Description

    When picking an instance of a physics object (by Pick by UID) and then disabling collision of that object with another physics object, a different instance also has its collision filtering incorrectly altered.

    Attach a Capx

    [attachment=0:nfsr7853][/attachment:nfsr7853]

    Description of Capx

    There are a few instances of one sprite on screen - all immovable physics objects. There is also another circular 'wheel' object that falls and bounces on the immovable objects. When the wheel Y position exceeds a certain value, one instance of the immovable objects is picked by UID and its collision filter is altered to disable collisions with the wheel. To indicate when this happens and which instance has been picked, the immovable object changes animation frame.

    If you select asm.js and then run in asm.js or box 2d then the problem is not apparent - you have to run this in box 2d without making any physics engine type selections....

    Edit - it seems a bit more fragile than my first assumption here. Sometimes it works... sometimes it doesn't work... The asm.js might be a red herring...

    Steps to Reproduce Bug

    • Run the layout
    • Observe the result

    Observed Result

    The vertical immovable object changes color to indicate that it has been picked for the collision filter change. However, after bouncing on a different instance of the immovable sprite object, the wheel then falls through the 'floor' - a third instance of the immovable sprite - even though it was not picked for collision filter change and it did not have its animation frame altered to indicate such a change.

    Expected Result

    The wheel should be able to collide with all instances of the immovable object that have not been picked by UID to have their collision filtering altered.

    Affected Browsers

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

    Operating System and Service Pack

    W8.1 x64

    Construct 2 Version ID

    r195 x64

  • Thanks mepis - will do. A couple more weeks - perhaps a month max (for itch - maybe a year to infinity for Steam LOL!).

    Here's a screen shot from the new chapter...

  • OK, a quick progress update. I've decided on a theme for the next few levels - which will take the final total up to 60...!! I'll post some screen shots and maybe a video in a few days, once I'm happy with the 'art'.

    The Steam Green Light process wasn't too hard to set up and I'm not getting flamed (too much!) by the voters. Time will tell...

    I expect to have this released on itch.io and, if they will ever approve my developer account, Indie Game Stand as well. I'm also going to look into a demo and a pay version for Kongregate - it's been a while since I've been over there so I'm going to have to do some reading...

    Anyway, enough procrastination, back to drawing rockets...

  • If you're looking for an object to sit on another's imagepoint (like the demo), then I would recommend using something from the master's repository: Rex's Pin to ImagePoint plugin.

  • I've spent the last two years slooooooooowly learning how to do that AND how to program with C2, itself. Anyway, long story short, I appreciate the feedback and the suggestions. I need it so I can try things out and figure out what works for my ultimate goals.

    This is exactly the same boat that I find myself in. I've had a bunch of false starts and only recently found satisfaction with my sketch book project. I enjoy the maths and technical side of working with the c2 editor but it takes so much more to stick with it until everything is done to a good standard.

    More than happy to help!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here you go - try L Race 1 because there are a few obstacles in the way for you to steer around. No forces, only manipulation of the car's velocity to accelerate at the car's angle, to decelerate when not accelerating (you would need to add to this to make it variable to whether or not the car is skidding), and to control the car's angular velocity if it's steering (same deal with respect to whether or not it's skidding). Hope this helps!

    link to file in dropbox

  • —, I didn't mean to come over as if I was flaming the use-physics idea. I think I would also use physics to tackle this, just for the collision behavior between cars. I'll try and put together an example of how I would address the controls etc - either I would not use extra physics objects at all (and just manage the car's velocity and rotation by equations and variables) or, more likely - use a physics action object attached to each of the car's axle points (intuitively easier to manage the car's behavior, but I suspect that controlling skids, understeer and oversteer would be v hard).

  • I would rather see an exponential like interpolation being added.

    Yes! I remain perplexed that c2 doesn't contain a native set of tweening functions / behaviour.

  • I'll ask some questions while I humbly offer my thoughts - I hope this makes sense! Firstly - why use physics - is it to enable car bumping and the like on the track? If so, seems like a good idea to get around the problem of overlapping car sprites etc. I can't think of another reason to use the engine for this type of game.

    I see no point in applying forces to the car's wheels to make the car move. In fact, I see no reason in attaching the wheels as physics objects to the car by using joints - remember, it's a viewed from above racing game, so you can manipulate the main car sprite to achieve the 'being driven' visual effect that you desire without making it too complicated to manage under the hood.

    Also, rather than applying a force to the car, I would manipulate its velocity directly through events. Doing that won't kill the physics behavior but it will allow you more precise control over the car's velocity - like whether it goes where it is pointed, how quickly it rotates and appears to turn etc (so you can make it change direction on a dime or appear to slide - heading and velocity vector not the same, for example).

    I have no idea why it should veer to the left like that in the example - perhaps the wheel positions are not equidistant from the car's center of mass, which causes the gentle apparent turn. I also saw that collisions between the car and the wheels were not disabled, so all sorts of strange joint fighting could be going on between the wheels and the car's body...

    Just my 2 pennies' worth - hope it helps!

  • So - in a fit of crazy optimism, I have entered the game in the Green Light thrash-athon. I think I need to put some more work in - luckily I'm enjoying making it!!