inkBot's Forum Posts

  • Oh yeah, I misread your post, you were completely right on the typo there.

  • Change this condition

    + player1_MSK: is on ground

    to this

    + player1_MSK: [negated] is jumping

    + player1_MSK: [negated] is falling

    "is on ground" sets the vars to zero when jumping because is seems that the object is still considered on the ground at the beginning of the jump.

    Ah, should've known. But this raises a question. This sort of makes the 'on ground' condition pointless. Why does it exist?

    Over to the other thing you mentioned. It's actually not a typo at all.

    What I wanted to do was to have the events that change your facing in one group and the controls for facing left in one group and facing right in another. If you face left then the group for facing right is disabled and vice versa, and when you're in the air the group with the events that changes your facing itself is disabled.

    I knew that it bounces and have been trying to solve it (the everything gets set to 0 kind of got in the way)... .But strangely it only bounces when you try to jump from player 2's left side to its right side. Jump from right to left seems to work nicely.

  • I thought of another thing I would like to see. It would be nice to be able to see Event Groups in the debugger, and if they are enabled or not. I think it would be useful for those of us who use groups a lot.

  • I just put in doubleJump yesterday. Must have missed that. I changed it so that it's 'equal to 0' now.

    However, there's still a problem. After I made the change I checked again with debugger and the variables do change as they are supposed to now (well, sort of. It's still a bit iffy...), but they still reset to 0 almost instantly for no apparent reason because the 'is on ground' event is the only one that sets them to 0. Unless I'm missing something.

    New cap: http://www.box.net/shared/4qtnahjoke

  • I'm working on getting a fighting game working and it's (or was) moving along nicely, but I've hit a snag.

    I have four variables which I use for jumping: jumpForward, jumpBackward, jumpStanding and doubleJump

    The idea is that if any of them, except doubleJump, is equal to 1, the player input is ignored and the player is moved forward, backward or not at all (depending which variable is at 1) until the character either jumps again or lands on ground, at which point the variables are set to 0.

    Here's the problem, the variables are always set to 0. I've checked with the debugger and they don't change at all. Or if they do, they turn back to 0 too fast for it to be seen. This is not supposed to be and I can't seem to find any events that does this, aside from the 'on ground' event.

    Here's the cap

    http://www.box.net/shared/fxbi0mm7p8

    The problem is in the 'testlevel' layout.

  • why don't you just import a collision mask as well as the sprite itself? or do you mean you are painting the sprite inside construct? While this is possible i guess there are better/faster solutions around, i always thought of it more of a dummy solution to create some testcases or something, nothing too complex.

    Constructs default collision mask uses the same image as the sprite, until you change it. There is to my knowledge no way to import collision masks (Constructs own collision masks that is. Not those created manually by users, using one sprite as a collision mask for another) separately from sprites. For people who use the built in collision mask, being able to see the sprite (preferrably transparent) while collision mask mode is on in the image editor, would make it much easier to get the collision mask the way you want it.

    As far as what I use for creating my sprites, I use Graphics Gale, and have so for the better part of some 6 years now.

  • The persist files are a known issue and I'm sure Ash (or someone) is trying to fix it for 1.0.

    In the meantime, I've found that if you've got a persist file keeping your cap from opening, deleting the persist file allows you to open the cap again (though i don't know what implications deleting the persists has, as I'm not privvy to the inner workings of Construct)

  • It doesn't crash for me either, even when trying your cap. =/

    Though I did get another duplicate of the sprite on the layout when I made a new angle. However, it disappeared a soon as I did anything and it only happened once.

  • I'm glad people are liking the suggestions so far =)

    I like this proposal, despite of it's overwhelming redness >_<

    Hmmm, you're right. There needs to be more red! =P

    ... I would suggest something that looks almost the same but it's not: being able to fire an event, which can be used in the event sheets to do the good stuff you can doo in event sheets. This would allow complex interaction with animations right off the bat!

    It seems opinions are split on the call functions feature, which I was expecting. What I mainly wanted to suggest with the call function feature was added functionality, rather than a specific set in stone feature. Figuring out what that funcitonality would be is the point of this thread, among other things.

    I'm definately in favour of these suggestions! (even though I can't see any of those images )

    Strange, I've never heard of anyone having problems seeing images from Photobucket before. Are you viewing from school or some other form of public computer? Those often block imagehosts on their systems.

    I also like the radial animation angle viewer, if it wasn't limited to 32 directions but rather had more of a vector type layout, I think it would be really powerful.

    I understand advocating the radial selector for reasons pertaining beginner frienliness, but if we're talking power and efficiency, the radial selector loses. Every time. What we have now gives us access to 360 degrees worth of angles, with shortcuts to the eight main directions when you create a new angle. You can not have any more angles than that. Though I admit, it would make more sense to me if the 0 degree angle was up and not right, then you could imagine the angles like a clock. The radial selector also took up a lot of unnecessary space.

    Creating many animations directions in Construct at the moment really IS a hassle (especially importing them, see my thread here http://www.scirra.com/forum/viewtopic.php?f=17&t=5477 and take note of the importing animations suggestion)

    I looked at it before and looked agagin at it now. It's an interesting idea, but I'm not sure of how practical it would be.

    What you're doing is essentially cutting away one part of the process (creating angles for your animations) and replacing it with another one (prepping your animations to be imported in this manner), and I don't think you would really save any time or work with it.

    If the idea is to limit the time spent on creating animation angles, there exist features aimed towards that in Construct. The mirror/flip animation toggleboxes in the property view. Of course, if you have different animations altogether for left/right, then it's a different thing. But, I think the time you would spend on prepping your animations in this manner would be fairly similar to the time spent creating new angles.

  • Not too sure about the call function from frame, but the rest looks nice.

    I think it could be immensely useful. What about it are you unsure about?

    Noticed it looks like you have a keyframe/timeline bar under the animation preview... would be sweet if one could actually drag it with the mouse.

    That was the general idea. Sorry if it didn't really get conveyed properly.

    A couple things...

    Are we keeping sub animations? If we do it would be nice to see some expressions targeted at those.

    I see no reason to get rid of sub-animations. Even though I don't use them much myself.

  • Not too long ago there was a thread suggesting a change in the design of the animation editor (or rather, a throwback to TGF). That thread and the recent threads about what should or shouldn't be in Construct 2 made me think about the animation editor a bit, and I came up with some ideas that I think could improve the animation editor. But before we get to that let's take a look at the current one.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_now.png">

    First things first. I like this editor, it's reasonably compact and does what it needs to quite well. The TGF radial... thing, was good, but it took up quite a lot of space for, let's face it, relatively low functionality.

    The animation list in Constructs current editor is better in my opinion. The tree-structural approach to listing the animations allows for a better overview while not using up too much space.

    The frames list is also good, but not great. It, again, does what it needs to. But not much more than that, and if you have a very long animation, things get unruly fast.

    Which brings me to the properties view. This is, in my opinion, the weak link in the animation editor. Most importantly, it's all the way over on the other side of the screen (which admittedly can be changed, but I think most people keep it as it is by default because of convenience. At least I do) while not really showing that much infromation.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_props_now.png">

    And last, something everyone wants, animation preview. As it is now we have to preview the entire layout to see if the animation looks right. Add to that that we have to jump from one side of the screen to the other to make changes. I think it's clear that it could be improved.

    So here's my suggestion.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_idea.png">

    First, we have an Animation Preview at the top, with a convenient progress bar and a box showing the current frame, as well as some buttons which we'll get to later.

    Second is the Frames List. Here is where changes to the old start (I'd call the preview an 'addition' rather than a change).

    Instead of showing our frames as icons we have a list, with three columns. The first columns is "Frame", which I think is fairly self-explanatory. Next we have "Speed", this is in fact speed from the properties view. So instead of going to the propertes view to change the speed of a frame, we can do it here.

    Last is something new. This idea I got from Unitys Animation View. "Function" would allow us to call a function from a frame in an animation. In my example the function is to play a sound, this could be used to play sounds of different footsteps (left/right, stone ground/wooden floor, etc) when a character walks, but it could be virtually anything.

    Below the Frames List we have the Animations List. This, too, incorporates the functionalities from the property view into the animation editor instead. So we could now set the speed of animation and if it loops from here instead. (Note that the names themselves of the animations in the Animation List does not represent how I think it should look. I think the way it looks now is great, I'm merely suggesting added functionality.)

    In my example the "Tags" functionality is not present, but I'd imagine it could be included in a similar fashion.

    And last, here's a short legend of the different buttons/icons.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_previewanimation.png">

    Play animation - Plays the animation in the Animation Preview window (animation is resized to fit if it's bigger than the preview window)

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_previewinwindow.png">

    Preview in window - Opens a window showing the animation in 1:1. Usefull for larger animations/characters.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_pausepreview.png">

    Pause animation - Pauses the animation in the preview. The frame in the preveiw will be the one that is selected either via the progress bar or the Frames List.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_loop.png">

    Loop? - When ticked, the animation loops.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_repeatnumber.png">

    Repeat # - The number of times to repeat (if not looping).

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_repeatto.png">

    Repeat to - The frame number to go back to when the animation ends.

    <img src="http://i79.photobucket.com/albums/j135/mr_norris/animation_editor_pingpong.png">

    Ping-Pong? - When ticked, reverses the animation on end.

    So, there are my ideas for the animation editor, I'm interested to see what you guys think. I started a new thread instead of posting in the "Most Wanted" thread because I think it could be discussed in detail of how to improve the editor for 2.0 instead of just saying that we want it improved.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The simplest way to do this would be to simply give your player sprite two platform behaviours, set them up for player 1 and 2, and a private variable to keep track of which player is allowed control, then change the variable whenever you need.

    If the variable is "1" you deactivate platform behaviour for player 2 and vice versa.

    Here's a cap, should be fairly self-explanatory.

    http://www.box.net/shared/y9rvdedlzv

  • Here's something I'd like to see (maybe even in 1.0?)

    Having the sprite be visible while you're working on the collision mask.

  • Ashley explained why in the first post.

  • Madster do you think you could make an example of the way you suggested? I fiddled about trying to do it and got nowhere. I'm going to go ahead and use my own solution, but I think yours would be much more efficient.