grossd's Forum Posts

  • 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

  • Hello,

    I am using websockets to communicate from a client with a C3 game. The communication is bi-directional and asynchronous, that is a client can send a message to C3 and C3 can send a message to a client.

    I wondering if there is a way to do synchronous messages from a client to C3 -- quite like having the C3 game act as a REST (API) server.

    e.g. suppose the client want to query the C3 as to how may sprites there currently are instantiated and receive a response immediately back.

    Can something like this be done via web-sockets or otherwise?

    Tagged:

    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

    Thank you for letting me know- - i will give it a try.

    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

    I've tried to come up with a formula to adjust the sprites angle while it turns, so that i don't have to rely on setting Match Rotation.

    But, as i suspected, it non-trivial to work this out -- so, far I haven't managed -- i've tried a formula that uses some kind of atan and also looked at how the sprites rotation could be translated into an angle.

    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.

    Hi,

    Thank you for trying this out.

    Try to activate match rotation and use a sprite image where you can see the forward direction.

    You will notice that when you set speed to a negative number and activate matching rotation the sprite image is inverted making it drive backwards.

    thanks

    Good idea.

    Now that i think of it, its actually a bug.

    First, i thought its a feature request, but i think you are right, its a bug.

    Hmm, where do you file a bug report.

    I just did that work around and, by switching to the horizontally flipped frame, the vehcile doesnt change direction due to negative speed -- however, the frame change is felt visually -- so its not an optimal solution.

    Looks like when i enter speed as negative and activate match rotation, then the sprite is turned around -- i.e. the vehicle now drives around in reverse.

    I think this is a side effect of working around the counter clockwise with negative speed.

    Better, if orbit has a dedicated boolean to specify circling direction -- clockwise or counter clockwise -- so that one doesnt need to rely on negative speed.

    I guess one work around is to create two opposite frames -- and upon entering the circle with negative speed switch to the other frame.

    hopefully in the future orbit will get real booleans to specify direction

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

    Yes -- it was overwritten by the code -- i thought it only works clockwise.