WACOM tablet emulates mouse drivers basically - so I don't think it's going to work with "on touch" events since this is capacitive touch not mechanical.

My WACOM works in every game exactly how a mouse would do - minus the software specific pressure application.

Someone would have to make a plugin for WACOM in order to get the result you desire - I think.

~Sol

I would recommend using a dictionary object instead of an array personally.

You can add a dictionary object into a container with any other object - and then you automatically have a constant set of "plain language" accessible information sets.

The main benefit of this method is that you can easily track instances of each object (since it's in a container with the dictionary) and you can still save the dictionary data as JSON string for webstorage or NWjs writing files to hard disk.

I find array to be more useful when handling un-named data (like tile positions or something) but this is personal preference.

~Sol

Also, moving physics objects using other behaviours (like bullet for example) can also cause weird results. It is recommended when using physics to only move the objects by applying forces - and not using "set speed" or "set angle" etc from other behaviours. Usually the option of having two or more behaviours is if you want to move the object sometimes by physics, and other times not.

~Sol

A quick and dirty fix would be that pathfinding only works if the object ISN'T overlapping the destination object... then when it touches the destination to have it move to the X.Y position of the destination manually - since by the time it has touched the object the pathfinding has already done it's job.

You could even create a small buffer around the destination (use a slightly enlarged version of the same sprite maybe) so that it "corrects" itself before it's already on-top. It might make this look a little less "oh um let me just fix myself at the last second".

~Sol

My guy > collides with button > set button.variable to "active"

button.variable = "active" and button.Y is greater than the ground > button.Y = button.Y - 0.2

button.y = ground.Y > set button.variable to "done"

button.variable = "done" > Do something

That's probably how I'd do it

~Sol

You can also have a set of functions...

Call 1st function

--- Shoot

--- Wait 0.2 seconds

--- Call function 2

Function 2

--- Shoot

--- Wait 0.2 seconds

--- Call function 3

Etc

Being functions though, it may cause un-intended results.

You could do the same thing without funtions, if you use a variable to control which thing is shooting...

[GlobalVar.ShootOrder = 0]

[Left Mouse Clicked]

--- Shoot

--- Wait 0.2 seconds

--- Set ShootOrder to 1

[ShootOder = 1]

--- Shoot

--- Wait 0.2 seconds

--- Set ShootOrder to 2

Etc

This would probably be better actually.

~Sol

If you want the player also not to "clip through" the object which is crushing them, try placing the "crusher" on top (zorder top) to the player - so when it closes down the player is behind it and you can't see.

~Sol

Before I download this, can you tell me what you mean by "they don't work"?

Do the animations not play properly? Do they play one time then no more? What exactly are they doing or not doing?

The most common problem people have with triggering animations, is that they trigger them every tick and the frame never goes past frame 1. I'm going to guess that this is the same problem that you are having.

It also may be better to make a new project with just one or two animations in it for people to check, rather than having your whole project there. If you have the problem in your project, it will be the same in a new project if you build it the same way.

~Sol

You need to add conditions that it only follows the player ship if the playership.count is greater than 0

I guess it's going to coordinate 0,0 because the ship isn't there anymore - but you're still trying to follow the ship.

~Sol

You will need to make your own particle emitter if you want more specific control over particles.

I rarely use the particle object built in with C2 - I almost always make my own.

All you need to do is create your dust particles at the feet of your character when you want them to be there (IE player is running at speed greater than 100, or whatever) then you can make them rotate, fade, resize, float around, etc. Just be sure to add your own way to destroy them after a while, or they will clog up your RAM/CPU usage.

~Sol

—: Your idea would work similarly to mine, but I think it would also encounter the same problem.

I think the problem is that the weapon wheel is probably on its own layer with a (0,0) parallax, right? So unless you're in the very top-left of the map, the mouse is actually really far away from the wheel's center, and any movement only means a tiny change in angle.

Meanwhile, looking at absolute x and y, it seems like that refers to the mouse position for the entire screen, not just your game's window. Possibly not a problem once you port to mobile?

So a potential workaround: you could use (mouse.x, mouse.y), set the weapon wheel's layer to a (100,100) parallax, then set the wheel's position to (scrollx,scrolly) every tick. It does make the rotation work correctly. However, you would have to put your onscreen buttons in a separate layer or move them every tick as well. This method also makes the weapon wheel look a bit jumpy when it repositions, but it'll only be visible when the timescale is very low, so it might not be noticeable.

If you want to track the mouse from a layer that has parallax, that's what LayerToCanvas and CanvasToLayer is for

You can move/relate things on different layers with different parallax values using these expressions

~Sol

You need to drag it with your mouse and drop it ABOVE the main event that it's "indented" under. It's a quirk with the drag and drop system - for some reason it will only "un-nest" itself when dropping it above.

~Sol