konjak's Forum Posts

  • Sorry, I just sound like an ass when I talk, I love how you actually get things done compared to Clickteam (who like to delete posts or close threads that have suggestions in them).

    I just found it a bit strange a choice to merge animation direction and angle after having used MMF for so long...

    Thanks again!

    Ps. If it really takes 20 minutes, man you're quick! Don't you have to add conditions and actions relating to animation direction and object angle seperately?

  • I heard of it and thought it sounded promising on The Daily Click, I think, but I didn't mind it much then because I didn't think it would be up to par yet since it was very early on.

    Recently I was reminded of it and it being v.0.98 I decided to switch to it!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That would be awesome! Thanks for the consideration!

  • I think there's a misunderstanding here as to our point. Of course games NEED sprites to be able to change DIRECTIONS.

    The thing is Dustin and I are confused as to why changing animation direction has to be linked to rotating the sprite itself.

    Look at MMF2, you have animations and animation directions. These are SEPERATE from the "set angle" action in the program. This is very useful and I really think setting the angle and the physical animation direction images shouldn't be linked as it is limiting and makes you create many more animations than you should need just to STOP Construct to change to my image of my character looking down instead of right because I wanted a rotating effect without changing the actual image of the character.

    <img src="http://www.konjak.org/angle.png">

    In this example image I show what I'd like to be possible. Animation direction is a seperate thing, and then setting the angle is another, shown here where the images of the animation directions have both been rotated 45 degrees clockwise (in an ugly way), but the angling is leaving the images alone, not try to flip them once they reach 180 degrees.

  • Well, yes, I said that was a possible way AROUND it, but why need a way around it? Could I get an example of a use for how the setup is now?

    If you have a picture for ever 360 degrees you don't need the rotation to begin with. If you almost have one for every picture you might as well use rotation because you're not gonna get a much cleaner image. And even if you do have one for nearly every direction a seperate animation angle command isn't exactly harder to handle, plus it lets you have both rotation and animation angle at once with comfort.

    Also, how do you retrieve the transparent color in the image editor? It would be nice and comfortable.

  • I agree, angles should not have to do with animation angles. That should be seperate actions and conditions.

    It's pretty much only a hindrance this way. The only way around it that I can see is to make seperate animations for each direction you want if you intend to have rotation. Say, if I have a picture of a fist turned right, I might want it to rotate full 360s to punch a face. But I would also like it to be able to do this in the other direction, and I add a mirrored frame to the 180 angle, but then I am screwed for the rotation to look good as the fist will constantly flip every 180 degrees no matter the inital direction.

  • Sorry, seems solved by turning off Grab Layout which I had on...

  • Thing is if I put it on a non-scrolling layer I just get a permanent white box...

    If I can't get it to work right now I'll put up a file.

  • I seem to be the only one experiencing this after searching these fourms, but whenever my screen doesn't scroll in my application the Canvas Object I have covering the visible playfield becomes a solid white. It feels like I may have missed something, maybe some setting, as nobody else seems to share this problem.

    Anyone have any tips for poor and lost me?

    Great and promising program though!