If static means that the player follows the rings when in rest. Like we do on earth.

https://

drive.google.com/open?id=0B1SSuCVV8v74RnVnWUhvdmh0M1U

If static means that the player when in rest does not move at all. Then delete the rotation for the game layer.

You can walk over the rings with the default platform keys. Not needed ? Set the platform's default keys off.

Not against a single "attack"-routine. But, i know for sure that the logic will break if (yet exactly do as advertised) if you gooing to call that function by differend players.

There is only one wait action i will use. The wait 0 seconds action. I will not use it in any other cases. And excuse me for trying, but i still try to get you to do the same. My intentions are good, althought they probaly sound stubborn.

I dont use 'wait' actions because:

1/

The time they wait is not reliable. That 0.5 seconds you wait looks fine. But then youre charakters get in a big fight. Trowing particles all over. Dropping the framerate temporaly. And before you know it, that 0.5 second will be 2 seconds in reality.

2/

If the event containing the wait actions executes again before the waiting is over, the logic will collapse. You will never know wich results pair with wich call.

3/

Pauzing the game will mess up the logic.

4/

And in youre case (and in so many other cases i have seen) the wait actions have no 'feeling' with the reality of the game. They just happen unconditional. At one point in developping you will not want players to overlap. But then 1 Collision is enough to break the logic. Because 'the wait' is not personal, it is not attached to a certain instance (player). There will (by instance) still be wait actions waiting while the objects that are meant to wait are killed and destroyed.

5/

Timers still are a more reliable solution. Because its a behaviour attached to an instance, and each instance has its own running timer. They dont mix up. On top you get triggers for free. You can leave them in the wild until a trigger gets your attention. Althougt there time is not reliable, they will never cross over.

Thank you for taking me serious independed of my childish English. I cant do better.

So there is more then one player? And they call the same function ?

That will still not guarantee that a 'in game time unit' is the same as a 'outside game (real) time unit'.

Or. A second in the game will usaly not be a second on your watch.

Time units in the game will be differend then those on the watch on your wrist when you use timescaling, but also in case of low frame rates.

In other words: when dt gets bigger, 'game time' will pass slower.

How sure are you that the function wil not get called again in the time that the wait action waits + the time that the delayed actions excute ?

Ther is NO 'on item get' condition in that screenshot. None . Zip.

Look at this.

https://

drive.google.com/open?id=0B1SSuCVV8v74OTB4V2Foc21KWW8

Do you know what it wil do before you run it ?

I dont think that 'wait' action does what you expect it to do.

Do the follow test.

Make 1 sprite.

Make 1 'every tick' condition.

Add 1 action : system > wait 5 seconds

Add second action: sprite > set x > x = Sprite.X + 10

What do you think it wil do ?

Also, i think the 'wait' action only delays the next action.

Also, i think a wait action nested deep in subevents wil not stop the other events from ticking. So the other functions get called, wait or not.

I dont know the LiteTween plugin. But it sounds as inbetweening. I suppose it does something that takes time. All other plugins that i know and do time-conditional things have triggers and expressions build in. So you can find out in what state they are.

De Platform (i know that one) has a 'on landing trigger'.

After a jump you dont code a wait action because you think that it takes x seconds for it to land. Nope, you use the 'on landing' trigger.

Does the LiteTween plugin has those triggers ?

Where is the ''On item get' in there ?

You cant do it this way. (to my knowledge)

It takes time to load something from the local storage. A trigger will be set if the loading is done.

You can use the loaded data after the trigger is set, not during.

Also. The trigger 'On exist' you use to make a decisson in two cases.

During 'setting' to decide if a new key is needed.

During 'getting' to decide if data can be used or if you have to make the data another way.

Example: For 'Best_kmh' you check if it 'exists', and then there is no decission in the case that it dont exist. Meaning: the use of 'on exist' is in that case useless. Can as well just 'get' unconditional.

So, how do you 'get' data ?

First you the use action 'Get item'. It is fine to do that in a 'on exist' event. As long as you also cover the 'non exist' case. But its not necessary to use the 'on exits' event. Often u know it is there. Or, you can use 1 key in localstorage that sets a "local storage is previous used' state and then savely conclude that all the other data will be there, because you always store all the data in one pack.

So 'on exist' is NOT used to know if a value in the localstorage has been written, its used to see if 'the key' is in the localstorage. And that is al it does.

So: First you the use action 'Get item'.

Then you have to wait till that item is loaded.

So next you make an 'On item get' trigger. (or an 'On all gets complete' to do them all at once).

When the item is loaded, the trigger will go off an execute the actions. Actions will be things like: set variable to retreived data.

So in youre case, i would do it this way (the whole story again):

1/ Make a key in the local storage 'SavedState'. Give it the value '1'

Make all the other keys you need, give them the basevalue.

Now you know for sure that all keys are in the localstorage. And you can check this in a 'on exist' event. Preferable in the 'on start layout' section. If it dont exist then just make the needed keys.

2/ Make a condition to decide when to 'set' in the local storage. (like every 10 seconds, or anything you want)

Then do all the unconditional sets in actions. Be sure the 'gets' and 'sets' dont happen at the same time. So you need at least a timer, preferable a system that knows if the 'sets' are done.

2/ Make a condition to decide when to 'get' from the local storage.

Then do all the unconditional gets in actions.

3/ Make a 'On item get' condition.

Then assign the values in actions under that condition.

4/ Special case.

So you want to add the current earned coins to the previous earned coins (those stored in the local storage), and store the sum.

Then you need an get action for the previous earned coins, under whatever condition.

You need a ''On item get' condition, to wait for the loading to complete. And under that condition you add them up. And you set the new value in the locale storage.

Be aware that also writing in the localstorage takes time. So you need a 'On item set' trigger to be sure that there will be no 'get' happening during that time. You can (for example) make an action under the 'On item set' condition that assigns a value to a variable that will be checked in the condtion that handles the 'set' in the localstorage.

Hope i made some things clear.

Works perfect. It just all happens in less then 1 tick.

Suppose you made a container with in it a ship, a truster and a radar.

Rule 1:

When you create a ship. A truster and a radar will be created on the same position as the ship.

Yes you can calculate and reposition the origins of the truster and the radar so they will fit where you want them.

Origins can be way outside the sprite. That will work (besides that you will have trouble rotating truster and radar)

If that is a good practic, i let you decide.

Rule 3 is also present in rule 1. Because after creation, the created object will be in picklist. Hence, it is a pick action.

Rule 2:

Is what it says.

Rule 3:

If you pick a particulair ship, based on conditions, the right truster and the right radar are also in the picklist.

Any action targetted to that particulair ship, will only target that ship. Moving that ship will not move the others. No sync. But, the right truster and radar is picked. You do not have to make a new pick event. That is what the rule says.

Meaning, you have to move them anyway. Can as well move them on creation too whit exact the same actions.

Rule 0:

But why fiddle with the origins? If you still have to move things anyway.

Can as well use imagepoints, you directly see where they are on the sprite that matters. And origins stay where you might need them to easely rotate.

But it is up to you. Althought, did't you say dat moving the origins is not that easy ?