EDIT: The final realization of this thread (discovered by blackhornet) was that when Gravity is set to higher than 50, "Properties > Framerate Mode" behaves jittery when in V-Sync mode and works flawlessly when set to any other mode. It could be a bug according to dop2000, but I would like to hear from Ashley first before reporting it because I don't have the technical knowledge on the matter.

Hi there.

I've tried a bunch of different settings and tutorials, but I just can't seem to stop these dice from trembling all over the place.

Just left click to create a bunch of squares and see the behavior in action.

I believe this is mainly something wrong with my input values, so if you could help with that it would be awesome.

github.com/dupuqub/constructs/blob/master/Dice.c3p

The GIF below is using the out-of-the-box settings that come with adding the physics behavior in both the green dice and the black immovable block. Should I file a bug Ashley, since it immediately fails without me touching anything?

EDIT: After some testing with the out-of-the-box settings, I saw the jittering only occuring with a gravity higher than 50. Later I tested with many tweaked settings and gravity seems to always be the culprit. I couldn't find anything on the matter in the docs, so should there be some relevant note in the docs or is it a bug or am I missing something? It is very much a trap for anyone tinkering with physics, since there's no obvious reason to not go further than 50 in gravity, and there's also no clear indication that gravity is screwing things up.

Deeply appreciate any feedback, Cheers.

Honestly, I was incapable of finding where the flaw was in your code because ultimately I was unable to untangle the code in my head. It was very nested and maybe not so organized, so I can't properly say to you what went wrong, sorry about that.

On the skeleton note, you can still stop them from moving when attacking, since you have the boolean called "attacking", so... just make it not move when "attacking = true".

The skeleton follows the player from a certain "Range" already, this is defined by the "Line of Sight" behavior. It also only attacks from a certain "Range", this one defined by the instance variable inside each skeleton.

Also it's hard to properly give any insights on the matter because when it comes to combat, every behavior and every move is unique in their own way, and each game may handle them differently. I would suggest only for you to take your time and work the logic gates the best you can to avoid convoluted code, also make it modular. Treat movements apart from animations for instance, and in this way it will be easier to debug when things go south.

Glad I could help, but keep me posted on your evolution. If anything comes up just continue this thread.

EDIT: You also already have something like your old "following" boolean, which is "Has LOS to object" from the "Line of Sight" behavior. If it has LOS, it is following, so no need for adding an unnecessary variable.

github.com/dupuqub/constructs/blob/master/Melee%20(1).c3p

Hi there.

There is a lot of work to be done still. This is nothing but the simplest possible resolution to your problem, but I had to do a lot of work to get here. Mainly notice that every animation had their hitboxes "fixed", by that I mean they are all rectangular and that is incredibly good for movement.

You can see that now the skeletons move to the left without stutter. This is because every point in their hitbox is a round number. Before you had a lot of floating numbers as points and it causes many weird behaviors.

The player also had a lot of work. I moved each frame to a point where the "face" of the hitbox hit 33 pixels always, it helps when jumping an falling back down. If they had been different, those animations could trigger each other and create a loop of doom, as I like to call it. Its funny as hell, but undesirable.

Also, I believe you were not using the "Line of Sight" behavior, I might be wrong, but I used it now.

Hope it helps. Feel free to further discuss this project, because there are still many challenges awaiting you.

Best of luck!

EDIT: Another detail about the player's animation is that the jumping and falling frames don't necessarily need to be higher and/or lower than the Idle animation, it's best to keep them linear because the jump action is enough to create the effect. It also avoids weird behavior on landing.

Hi there, I checked your code and there are some fundamental flaws in the logic and the hitboxes of the actors that may compromise their behavior slightly. Do you mind if I rewrite the code at least for you to use as maybe a reference?

Also I would recommend looking at some tutorials on the matter. I don't exactly have a specific one to recommend.

ps: what a f****** beautiful art, congratulations!

You could make something like this:

• String Lane_A = "this is something"
• String Lane_B = "this is something completely different"
• String Lane_C = "nobody expects the spanish inquisition"

And then change whichever lane you need changed.

Lastly you can assemble each lane into the Text object through the action "set text":

• Lane_A & newline & Lane_B & newline & Lane_C

Feel free to ask for further help.

You are not wrong, but also not right, because if the first is true, nothing that comes after matter, so it is logically incorrect to assume an "OR" block also works when both are true. It hinders logic thinking.

And as for your solution, I believe it is not the best solution possible. "OR" blocks are useful and you should be able to use them as much as anyone.

And again, a sample project would help the community identify what's going on since, as blackhornet stated, it does look odd.