Problems with porting events from Classic

  • LATEST UPDATE: The below problems are more or less out of the way mainly because of r86, except for number (2), for a particular reason.

    I've isolated the angle problem that this engine is having, to TWO main possible factors. It can only be one or the other, not both, I presume.

    a) The anglelerp(a, b, x) expression. It's supposed to replace the RotateAngle() expression from Classic, but I have a feeling it's not working right. I'm gonna ask Ashley about it via PM.

    b) The collision detection system might not be working properly in this instance, though I can't see how it would cause spontaneous and virtually random changes in angle.

    ------

    I've been trying to port a Sonic engine someone else made from Construct Classic to Construct 2, but there's been a few issues that has halted progress. Three main issues:

    (1) I'm pretty sure the "While" condition is completely redundant, but if not, how do you create a work-around for them?

    (2) Construct 2 doesn't have the "RotateAngle" expression, resulting in the player unable to rotate properly.

    <img src="http://dl.dropbox.com/u/919275/Screenshots/AOD/RotateAngleExpression.png" border="0">

    (3) Construct 2 doesn't have the "Sign" expression... Whatever the hell that is.

    <img src="http://dl.dropbox.com/u/919275/Screenshots/AOD/SignExpression.png" border="0">

    I'll provide the caps here:

    Classic .cap (Version r2, requires the MagiCam and Slgor's input system plugins.)

    Construct 2 .capx, release 86, requires Standard license (requires the Function Plugin)

    Go to the "Player_Code" event sheet on both, and open up two groups:

    • Motion Management -> Tools (Whole group, for (1) and (2), I'm going to replace the "Parameter" function with a variable to get around the "Else" problem)
    • Movement Routines -> Movement (look at the "Calculate Sub-Step" events for (3))

    If anyone has any idea on how to work around these issues, I'd be grateful.

  • (1) While loop

    To do a while loop do a for loop with a insane amount of loop and stop it once "what would be the while condition" is false

    (2) RotateAngle() ? what does that do?

    (3) Sign()

    sign(negative number) = -1

    sign(positive number) = 1

    sign(0) = 0

    What I usually do instead of sign(number) is either

    number/abs(number)

    but you have to check that number isn't equal to 0

    or

    cos(angle(0,0,number,0))

  • 1) Hmm. Insane amount of loop, huh? How much do you reccomend?

    2) RotateAngle() comes out as "RotateAngle(Start, End, Step)" when you pick it out from system expressions, so I assume it's meant to 'rotate' the value from start to end, using the "step" parameter for how much per step. Of course, this obviously means having to re-work the event.

    3) Ah, I see, now. Though, I'm not sure what the bottom one does exactly.

  • 1) well that doesn really matter, as long as you're sure you get the work done but you can always do a

    repeat 10000000000 times

    As long as you stop it when the condition becomes false you just need to be greater than the greatest possible loop you need.

    2) Yeah it looks like C2's angleLerp although I didn't know there were this action in CC

    3) haha the bottom one it a little trigo trick, really simple actually

    if number is positive the angle(0,0,number,0) is just a flat 0 degree angle (imagine a line between (0,0) and (number,0)

    and cos(0) = 1

    if number is negative, it's a 180 degree angle

    and cos(180) = -1

    if number = 0... hmmmm now that I think about it you might get 0 and then cos(0) = 1 so it won't be exactly the same as the sign() function but hehe... it might not be a problem.

  • 1) Ah, so you mean like this, or am I getting it wrong? Because I'm causing my game to freeze when I try this method:

    <img src="http://dl.dropbox.com/u/919275/Screenshots/AOD/WhileLoop.png" border="0" />

    2) Yeah, I just checked out angleLerp and it does pretty much the same thing, it seems, haha. Must go by a different name. It works, however, so, yeah.

    3) Oh, yeah, I see what you mean, and it seems to be making a huge difference so far.

  • your [invert] collision = 1 isn't inside the loop so yeah you are running the full iterations congrats :D

    Also [invert] collision = 1 is the same as collision not equal to 1... there's the operator... Well as it's the same it's not an issue, just wonder what is better practice.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Well, shoving it inside the loop doesn't seem to have any discernible effect either, but I decided to lower the 'repeat' count to 1000, which makes it run much faster for the time being.

    edit: Nevermind, there's still a problem with full iterations.

  • You need to re-structure your events so that "collision=0" is also a sub-event of the loop.

    +------+------------------+
    |System| Repeat 1000 times|
    +-+----+------------------+
      +------+----------------+
    --|player| collision = 0  | Actions...
      +-+----+----------------+
        +---------------------+
      +------+----------------+
    --|player| collision != 0 | System  | Stop loop
      +-+----+----------------+
        +---------------------+
  • Tried that, it doesn't seem to work.

  • To implement "while", try this plugin.

  • Alright, update. The .capx has been updated, with:

    • Input fixed properly, thanks to a fellow over at Sonic Fan Games HQ.
    • Animations are fixed up and ready to go, though animation speeds do need tweaking, such as running.

    Currently, the main issues are stemming from moving on slopes (and possibly on edges). It may be a collision issue, I'm not sure. I sincerely doubt collision polygons are the reason.

  • Once again, .capx updated, and I have a status report. There is one major problem - when the player's angle is not perfectly at 0 and moving on a horizontal plane, the player's angle fluctuates to ridiculous degrees, which a friend and I discovered using a debug thing we rigged up.

    In the "Calculate Player Angle" section, in the original .cap, there's this:

    <img src="http://dl.dropbox.com/u/919275/Screenshots/AOD/CalculateAngleClassic.png" border="0" />

    In C2:

    <img src="http://dl.dropbox.com/u/919275/Screenshots/AOD/CalculateAngleC2.png" border="0" />

    Note the function at the bottom - it's using an "Else" under a function, and a function within a function is pretty much impossible in C2 because of the way the Function plugin works, so... I had to substitute a variable in there to replace both the function and the else, and use an action to reset the variable after the "function" is completed, which, logically, should function perfectly.

    However, turns out it doesn't. I tried the same work-around in the Classic .cap. The results were... Enlightening. It prevents Sonic from rolling while moving in both engines, but it doesn't cause the angle to go haywire in Classic.

    So, two questions: Is there a better workaround, and is there anything else I'm doing wrong here?

  • About function:

    1. event with green arrow can not be put under other event anymore, you could try to put "start of layout" under other event.

    2. what is "else" for function? One of my solution is when you try to call a function by name string, but there is no compared name, so there is no function be called.

    Put "Function xxx not be called" in event is strange. For example,

    + on function "f1"

    + Function "f1" not be called

    + on function "f2"

    + Function "f2" not be called

    + on function "f3"

    + Function "f3" not be called

    If you call "f1", it will trigger event:on function "f1", and event:Function "f2" not be called, event:Function "f3" not be called

    Do you think it really you need?

  • I do think I'll need an "else" for the function, yes, at the very least. Placing a function inside a function, as I said in the function topic, may not actually be at all necessary, and should logically be unnecessary in my opinion.

  • ALRIGHT. I've isolated the angle problem to TWO main possible factors. It can only be one or the other, not both, I presume.

    a) The anglelerp(a, b, x) expression. It's supposed to replace the RotateAngle() expression from Classic, but I have a feeling it's not working right. I'm gonna ask Ashley about it via PM.

    b) The collision detection system might not be working properly in this instance, though I can't see how it would cause spontaneous and virtually random changes in angle.

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