Take a look at this modified version of your file. The issue was the separation of the on touch end and swipe speed events. In other words, when you started your swipe, if the swipe action didn't end before the swipe speed event was triggered, the system would have to use the TouchFinal from the previous swipe action so results were incorrect.

Event 9 is a repeating event. Every tick when the player is on the platform this event triggers. Since this event repeats every tick, we need to use time to define how far to move. You may already understand this part of the issue but it is important to explain it again so you can see the difference between the 2 events.

Event 10 only happens when the player first lands on the platform. It doesn't need to use time because it isn't a repeating event. After the player has triggered the On Landed event, it will not trigger again until the player either falls or jumps and lands back on the platform.

There is a tutorial for just this kind of thing:

https://www.scirra.com/tutorials/560/sw ... th-inertia

Since the word "better" is subjective in this particular context, the answer is a resounding, "It depends." I know that is not the answer you wanted to read but it is the correct one. If you are more comfortable working with an outside program, it may be better to create it outside then import it. If you like the internal editor and can work with it on your simple graphics, it may be best to use the built in editor. Only you can decide which method is best for you.

Personally, if I am just making a simple shape to use in a mock up or example, I use the internal editor. It is quick and easy to throw together a simple graphic and I don't have to take the time to switch programs. However, if the graphics I am building are going to be used in a real project, I will always use a more powerful image program to create my graphics no matter how simple they are. Even if I think it will stay as a simple box, there is always the chance I may decide sometime in the future to add more detail and I won't want to start from the very beginning. Having the image in a format that supports layers makes alterations much easier in my opinion.

Create a global variable called lastClickedTime and when the mouse is clicked, set it to the system time. Then in your event, add a new condition that says:

lastClickedTime <= time - 10

[attachment=0:1nv86w95][/attachment:1nv86w95]

There is a distance function that takes the x, y value of the first object followed by the x, y value of the second and returns the distance. Use the system's compare two values event and type:

distance(<name of object 1>.X, <name of object 1>.Y, <name of object 2>.X, <name of object 2>.Y)

in the first value and the desired distance in the second.

First, is there a specific feature you have not been able to duplicate in Constructs event system? The only reason to create a plugin is because there is something you want to do that the events can't or, to create an enhanced version of a given behavior. If you are having trouble getting something to work, you may get help from the forums here to solve it.

Second, BlueJ is primarily a Java dev learning tool, not Javascript. Those are not the same thing although they may sound like it.

Third, when you create your event/actions you are basically programming with an image based language so, you really can't say making a plugin is the only way to program.

Forth, if you do need to write a plugin, the environment in which you write it does not really affect how it interacts with Construct. You could write it in a full Javascript development environment, or just in a basic text editor like notepad and the script will work the same in the end. There doesn't need to be any compatibility between the software you write it in and Construct as long as the script you write follows Constructs format and implements its framework.

Just a little background, I currently work as a software developer using Java for server side code and Javascript for the client side. I have used Construct for more than 3 years. In all that time, I have not found a reason to write my own plugin and I have even found many current plugins others have created to be completely unnecessary. The event system is more than powerful enough to handle most things you want to do.

Instead of triggering the actions by the direction of the thumb stick, you could set a direction variable on the sprite object. Then the event to trigger the action would be the value of the variable. Since a thumb stick doesn't directly spring back 0 but could over shoot it a little, you would want the axis greater/less than an acceptable value so the player doesn't accidentally windup walking the wrong direction. Also you would have to set up another event specifically for setting the variable back to 0.

Note, using a value of 0 with a thumb stick or joystick always has the possibility of causing adverse affects when the player releases it. If the player pulls the stick to it's farthest right position and releases it for example, it could spring back to the left a couple degrees causing the system to reset the value to the opposite of what the player wants.

If you know you need a new line in your text, you could use the built-in newline object:

"Hello" & newline & "World!"

This would take a little more thought if you are creating the string on the fly.

Give the sprite an instance variable called something like "Moving" which stores a boolean value. Set it's default to true. When the toggle action happens, set it to false when it is true and use a System Else event to Toggle it back to true. You need to use the Else event so it doesn't just immediately switch back to the previous state.

[attachment=0:29zx9sxd][/attachment:29zx9sxd]

A lot of times, people try to just say, if true set false, if false set true but what this does is, when the event triggers for true, it sets the value false and since right after setting it false, it checks to see if it is false it triggers the second event setting it right back to true.

So, to help you trouble shoot the issue, what you need to know is, the events are always processed in order. You have 2 events that define if the player is clocking in or out. Because the clock out event and clock in event do not in any way declare that you cannot immediately change clock state right after it just changed, you are getting a cascade effect. The first event sets the clocked in value to one, then the second sees the value as 1 and sets it to 0. When ever you implement a toggle system like this, you need to be mindful of these cascading results that will throw off your result.

As always, there are many different ways to solve this issue. You could utilize a state called "Clocking In". You could incorporate an if/else structure into your events. You could require a time limit for the user to be clocked in before clocking out. You could require at least 1 layout change before clocking out. Any one of these suggestions could give you the result you want. You would just need to decide what works best for you.

I am attaching a modified version of your project showing how I would fix this issue. I would suggest you try to solve it yourself given the above information before you take a look at my change. Doing so would help you in your future trouble shooting.

Add another condition to the touch event that checks to see if the panel is visible.