Yes, because you block the update thread with your loop.
There is no magic here. JME calls your update once per frame. JME calls your enqueued Runnables every frame… your Runnable.run() method will loop over and over and over and over until eventually returning and letting the update thread continue.
If you want to do something after time elapses then count time and do something after a certain amount of time has elapsed.
when I press the button, the skill is executed and it should disappear after a certain amount of time
at this moment I don’t have access to tpf
I need to create a thread that will run after a certain amount of time
something like this
final ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor();
executorService.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
myTask();
}
}, 0, 1, TimeUnit.SECONDS);
Or you can have your own app state to run recurring tasks until complete.
Or you can use existing app states to run recurring tasks until complete from some external libraries. For example, Lemur has an AnimationState that among other things can run Animation objects until they return that they are done:
Or you could use the Tween support to create your own sequence that calls a method after a certain period of time has expired.
There are just so many ways to do this that don’t involve background threads or blocking the update loop busy-waiting.
First, the whole point is to AVOID all of the Runnable nonsense that you’ve added that is only making your life 100000000x harder. Your life would be a million times easier if you let JME deliver key events to you and you respond to those. enqueue() is unnecessary.
Second, as said before: this is part of Lemur. You must use Lemur if you want this functionality. Lemur is necessary to get this code. You’d have to link to Lemur.
If you don’t have Lemur then you can’t use the animation state. If you don’t have the animation state then you can’t add a tween to it.
Third: Tweens.delay() is only creating a new tween. It’s not executing it. And if it did, you’d be right back where you started. Your run() method would wait 5 seconds before completing.
Anyway, probably forget all of my advice because I’m too tired now to help anymore. I’ll let someone else take over now.
To me it sounds that you are trying to create these effects for your entities. This is how I would model it.
Like in OpenKeeper, you could just create these components (OpenKeeper/Slapped.java at master · tonihele/OpenKeeper · GitHub). And have a system manage their removal on certain point in time. Code game logic accordingly. And this approach also directs you to decouple your game logic from visuals.
thanks
unfortunately there is no documentation and simply tutorial
i use old object oriented modeling
something like this
class Player {
public Spatial spatial;
public CharacterControl characterControl;
public String location = "StartLevel";
public int hp = 100;
public int level = 1;
public int corretnHp = 100;
public int str = 10;
public int dex = 10;
public int cont = 10;
public int exp = 0;
public int nextLevel = 10;
public Item helmet = null;
public Item armor = null;
public Item boots = null;
public Item gloves = null;
public Player(AssetManager assetManager){
spatial = (Spatial) assetManager.loadModel("Models/char.glb");
}
}
There is nothing really wrong with OOP (even if it has a bad reputation nowadays). But you should still keep the visuals separate. And if you are going on a multiplayer route at some point… Well, then you really should look at Zay-ES.
Depends how you learn the best. For me, running working examples is the best. The concept is well defined, of course there are differences in implementations per libraries. Still, same same, not that much different. So whatever source you find on the topic holds.