TackerTacker's Forum Posts

  • Hmm, ok.. so the wheel should spin and move the unicycle or no?

    The frame should only change its rotation, but not affect the wheel?

    If thats the case then maybe dont use the physic behavior on the frame but pin it.

    if you want physic on the frame hmmm idk ... maybe set the frames density to nearly 0 or make the wheel super havy so it doesnt get affected so much?!?!

    The thing is as long as both are physic objects and they are attached to each other they will always interact with each other... that's the point of the physics behavior :/

    Maybe you could pin a sprite with physic behavior to the wheel, set immovable to yes, make it invisible and attach the frame with an revolute joint to that invisible sprite?!?!

  • oh and if you just want the wheel to spin you can do

    torque -1000 to move left

    torque 1000 to move right

    all the numbers depent on your physic settings of course.

    If you work with torque you should play with the friction of your wheel

  • try applying force to the center of the wheel with a little offset on X like ...

    force 50 towards (self.X-10,self.Y) at imgpoint 0 for it to go left

    force 50 towards (self.X+10,self.Y) at imgpoint 0 for it to go right

    ...is that what you want?

  • Its difficult to help without seeing the actual setup of your physic objects,

    but it may helps to play arround with angular and linear dumping to make it easyer to balance the unicycle regardless of the setup.

  • another way is to use the pin behavior and pin the yellow circle to the player.

    Everytime you are moving the circle on its own you disable the pin > do what ever movement you want > and repin it.

    something like this

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Unfortunatly Controller Feedback isn't supportet in C2.

    Here is a statment from Ashley:

  • Check out the basic Top-Down tutorial https://www.scirra.com/tutorials/405/ho ... onstruct-2

  • You can also check out the beginners guid tutorial https://www.scirra.com/tutorials/37/beg ... onstruct-2

  • Thanks for the updates latly, great stuff.

    I got a couple questions:

    What's up with this 500 Msg/s limit ?

    According to the calculator on your website I can send 31 Msg/s for a 4 Player game before i hit this threshold. How can that be enough for a realtime game?

    The fish example works because of the choosen input method, but what about games that are controlled with gamepad or WASD ?

    This kind of games have a much less predictable movement and have to be updated frequently.

    Construct 2 runs with 60 FPS, so if I update my 4 players position every other tick im already at the max Msg/s allowed.

    I know i can update less per sec and interpolate between the received updates but you can only go so far with that before it get's wonky and thats only the 4 player possitions, what about bullets, enemys, level changes...

    Why can we only send strings ?

    Can we? Maybe I overlooked something?!?!

    Else, is this a general limit of photon or is this specific to Construct 2 ?

    I mutch rather would prefer to have it more like in the official C2 Multiplayer plugin.

    What i'm getting at is that with the focus on limiting the Msg/s i feel like i'm forced to send big clumps of data at once instead of trying to keep the bandwidth low and send small data more frequent and bigger data less frequent.

    In my understanding the later method will result in more fluent gameplay and less stress on the server, no?

    Or are the Msg/s more straining for a server then the bandwidth?

    I made a messy test for an 8 direction movement that sends small data often and bigger data rarer.

    test.capx

    I send the user input in an small interger every 0.1 second

    and correct the deviation with the bigger data (x,y coordinate) only every second.

  • Thanks, Cool FX.

    I made a nice example with it, check it out.

  • A behavior version where you can check for the distance to an obstacle on angle x would be quite usefull to build better AI.

    Something like AI_Sprite.raycast.checkDistance(angle) would return the distance to the obstacle at the angle choosen.

    image

    It could be used to support the pathfinding behavior to:

    1. keep the AI from grinding along the walls (keep a little distance from walls or move in the center of hallways... stuff like that)

    2. interact with or avoide moving obstacles without refreshing the obstaclemap of the pathfinding behavior

    I know this is all possible with the plugin how it is right now, it would just be more convenient this way i think.

    Something like trace ray at angle x starting from pos x,y with max length x would be great no matter what tho

  • Ok, thanks for the clarification.

  • ... and I will keep everyone up to date once we're close enough to start giving ETAs.

    ETA for Spriter2 or has the announced performance update for Spriter(1) no ETA yet ?

  • like i said as long as you don't expect any further features you are golden.

    But you got a very real game in the pipline and it may make the guys at photon pay a bit more attention to the constuct2 community.

    I really hope so, it's not like I don't like this plugin or the photon guys , i just stated the facts within my best knowledge of the situation.

    still even without any feature updates its a solid plugin, all i say is dont expect any more then that based on the previous responses.

  • digitalsoapbox don't hope for any kind of features for this plugin any time soon ...if ever.

    If you look through this thread you'll find that this plugin only got 1 single feature update back in March 2015, one month after release.

    Either you can pull off what you have in mind with the functionality already provided or you look for an alternative, like the official MP plugin.

    A good thing is they at least keep providing bugfixes if something breaks.

    I have the strong feeling that unity is their main focus and they dont pay much attention to the construct2 community.

    It would be really nice from the photon guys to just say that they dont plan on adding features to this plugin and

    dont keep saying "not implemented in the plugin YET" these are just delaying tactics and a huge waste of time for everybody.

    But that's just my opinion and i could be wrong. Time will tell i guess