Thank you.

In the meantime I realized that event a REST API which I erronous thought is synchronous -- is in fact most often used asynchronous -- it requires some kind of call back handing -- promises and the like.

But, i guess, an asynchronous query API doesn't yet exist for C3 -- although, I am now thinking that i can "bend" web-sockets to this purposes, when i figure out how to implement such a call back mechanism on the client side.

Btw, it seems that the multiplayer game offers some built-in means to request information from other games in the network - but its not a general purpose mechanism.

Hi,

Many thanks for your message.

I didn't see that the multiplayer plugin supports arbitrary synchronous messages between peers ...

re: instantaneous

I didn't mean instantaneous, but synchronous -- this means that the client send a request to C3 to obtain some information, and then waits until the respond from C3 arrives back.

If, possible, the client could also have a timeout mechanims - i.e. to not wait indefinitely.

But, surely, since all this happens over the network there is latency -- i.e. it takes time.

Edit:

In theory, perhaps this can be accomplished by introducing a REST API plugin that treats the game as if it were a source of data on the web.

Edit 2:

Perhaps, the NW.js is a good example -- quite like the NW.js plugin which augments C3 with file system capabilities, a REST.js plugin would turn C3 into a web data source.

thanks,

Dan

Thank you Ashley,

Luckily, it turns out to be even simpler to get match rotation to work with the event sheet.

In my code example, which is based on the code dop2000 posted in a "parallel" thread, it works with car.angle = car.orbit.rotation, even omitting the +/-90, when the car orbiting state is enabled.

Here is the attaching a link below:

u.pcloud.link/publink/show

If i may suggest, to add a short description (and perhaps example) of this workaround into the orbit documentation.

It could save a lot time (and frustration) to someone else who has trouble hitting the simple solution of the orbit's rotation property to adjust angle during orbiting, as an alternative to match rotation, when sprite flipping with negative speed is a problem.

thank you,

Dan

Hi Ashley,

Many thanks again for your response.

Truefully, I don't understand.

I don't want to use set mirror nor suffer the consequences of its use -- since its merely a workaround.

What is needed is to simply have correct image behavior for counter clock wise orbit, with Match Rotation set -- no flipping -- the sprite actually should move counter clockwise, in a forward direction (i.e. positive speed).

In my mind this is really simple and straightforward requirement -- yet, i am struggling with this already for a week to get something like this to work on the event sheet, simply to replicate straightforward behavior.

Clearly, this can't be the intention by design.

What effort would it be to create an official counter-clock orbit plugin a clone of clock-wise orbit.

That then behaves correctly for positive speeds, and matched rotation, while turning counter clockwise.

No need for negative speeds, no need to break already existing behavior that expects negative speed, elsewhere. No need for mirror or frame workarounds that don't actually work, visually. And no need to force developers to vector and circular math for something that essentially already exists as behavior in the clockwise direction -- which makes this even more frustrating.

And, hence, no need to let customers struggle with something that should really be trivial.

It would be great if you could offer that.

Dan

The sprite is not mirrored if you use a negative rotation speed. It just uses the same angle as if it had a positive rotation speed.

I believe this is by design as it matches other features in Construct, like the Platform behavior. If you intend to flip the direction of the sprite, you can use the 'Set mirrored' action. For example a typical platform game will use the 'Set mirrored' action as the player presses the left and right movement keys - the behavior does not control that for you.

Hi Ashley,

I now got the code to work using set mirrored action -- however, quite like my earlier work around -- where I set a flipped frame, to rectify the flipped image -- the set mirrored is visually noticeable by making the sprite blink.

I still believe that there is a case for having a dedicated property for orbit action to make it circle counter clock wise without the need for negative speed (which is semantically unclear) and related work-around.

If this clashes with platform behavior then perhaps the design there is not optimal either.

And, if two designs need to co-exist, the perhaps two orbit plugin variants are needed -- or a third property that establishing default behavior such as now, and counter clockwise behavior such as I now need for here.

The way it is now, its unfortunately, not usable since it significantly reduced the visual quality of the end results.

It would be a pity if due to that i need to try to work things out with vector math, which has its own problems (e.g. how to set and adjust speed consistently across computers, if speed is angular displacement).

And, overall -- what I really like about C3 is that it makes such things really simple to do -- so, just to get counter clockwise orbit -- shouldn't require one to drop down to complex circular vector math.

u.pcloud.link/publink/show

Hello,

I just noticed that when a sprite with move-to behavior is initialized with a negative speed number -- it moves away from the a move-to target.

However, when max speed is updated once movement towards the target has commenced, then updating the maxspeed to a negative number causes the sprite to stop.

It seems the interpretation of a initial negative number is to move "away" from the target -- along an inverse vector; whereas once the sprite moves towards the target a negative number doesn't carry this meaning anymore.

Not sure what to make of this.

I guess, mathematically speaking having negative speed doesn't make sense, unless speed is a vector, but i think its just a scalar.

Edit:

Btw, i couldn't understand why set speed (vs. set max speed) had no effect on the sprite -- when updated after move has commenced -- only an update of max speed caused the speed to change -- not sure why -- its a bit counter intuitive for me --

Perhaps, its because speed is controlled by the move algorithm, so speed only reports current speed but can't be set, whereas max speed is the max speed the sprite can reach along the vector to the target ... hmm, i guess, that's it.