Candescence's Forum Posts

  • Hey, I'm trying to do something like this in C2:

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

    Problem is, functions can't be called within functions. And the lack of an "else" condition means it's impossible to check whether a function is NOT being called, due to the nature of how the plugin works. Trying to replace the function with a variable work-around doesn't, well, work, or at least not very well.

    Would it be possible to implement a solution to these issues?

  • 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?

  • 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.

  • Tried that, it doesn't seem to work.

  • 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.

  • 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.

  • 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.

  • 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.

  • Tested, pretty much perfect on my Win 7 laptop, except for that odd alpha thing going on with certain objects, but otherwise, pretty much perfect.

    I'm eager to see this properly implemented as an export!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, to actually save stuff, like changes to tiles, and whatnot. Probably the only file format to hold data like that would work with HTML5, it's not like we're gonna be using ini files. :p

    Arrays for storing tile data during runtime, XMLs for saving them. That works.

  • Well, that's fascinating. That being said, I imagine it would require two main things: Arrays/XML files, and being able to save arrays/XMLs. And C2 can only do arrays, but not save them. So... Yeah. A bit of a problem.

  • For those who haven't played Terraria,

    It doesn't show things like air pockets, but still.

    Long story short, I can imagine doing something like this could be somewhat complex, especially without "Offset Collision" conditions that Classic has. And I personally am not sure where to start with something like this, though I would really like to be able to create proper fluid dynamics, even if they're blocky fluids.

    So, yeah. Any ideas? I imagine some of you smart fellows might take this request as a challenge, heh.

    Edit: Hell, if any of you guys somehow take it one step further and do proper fluid dynamics like in that "Where's my water?" game on the iOS, that would be awesome as well. I'm really curious as to how those developers managed to pull it off. Probably asking a bit much, but, one can hope. <img src="smileys/smiley36.gif" border="0" align="middle">

  • Oh, yeah, it does. That's why I suggested it. <img src="smileys/smiley4.gif" border="0" align="middle" /> Lemme list the features that are in the Classic version but not in this one...

    General Features:

    • Predictive aiming
    • Being able to have a list of objects as targets
    • A reload timer to make it easier to allow for a short amount of time between bullets
    • Targeting options: "Follow first in range", or "Always the nearest".

    Behaviour settings:

    • Reload time
    • Target Method (Two options: "Follow first in range", or "Always the nearest")
    • Turret Rotation toggle
    • Predictive aiming toggle
    • Bullet Speed (Used for predictive aiming)

    Conditions:

    • Is always picking nearest
    • Is always picking first in range
    • Is using predictive aim
    • On Shoot

    Actions:

    • Acquire Target
    • Add Object to target
    • Clear targets (clear the whole list, not just one target)
    • Set Base Object
    • Unaquire Target
    • Set Activated
    • Set Range
    • Set Reload Time
    • Set Rotation Enabled
    • Set target method
    • Set use predictive aim

  • Mind you, there are some features in the Classic version of the behavior that isn't in this plugin. Maybe you could work on implementing those. Predictive aiming, especially, that would be extremely handy for, say, tower defense games.

  • You guys might wanna actually check out the cap before you go making suggestions. It's a pure event-driven system that utilizes quite a few sensors.

    For reference, I'm gonna toss up my own version of that cap that's a WIP of trying to implement individual working players, complete with picking. My method for picking may not be entirely sound, however, though it does seem to work on my end.

    dl.dropbox.com/u/919275/SonicConstructMultiReDo.cap