SoldjahBoy's Forum Posts

  • Hello Sol,

    Thanks for the reply, I already checked the template and it looks like you need a hosting player. Won't it create a conflict if the hosting player leave the game? I mean, in a MMO, people can join and leave the room without creating issues.

    Can the built-in MP support handle this?

    As Oos alrready said, yes... you just make a host program that keeps the server running (like Minecraft and similar).

    ~Sol

  • Add 'else' in 29, 30 & 31.

    Yeah, this should also work

    ~Sol

  • Construct 2 has built-in multiplayer support. I suggest you check out the multiplayer examples that come with Construct 2, such as the multiplayer Ghost Shooter capx file.

    ~Sol

  • It looks like your collision polygons have invalid design. You have to make sure all polygon angles are outer curve... you can't make collision polygons with inner curve. I'm not sure of the correct term but try making polygon like a circle, always angle the next point outwards. For complex shapes that require inverted angles, you have to use multiple objects for collision.

    ~Sol

  • This is a very broad question and difficult to understand exactly what you want. If you are making ropes out of many objects joined together then you can make a function for generate rope and just give each rope some identification with instance variables. This way you can create as many ropes as you want but can make them individual. I'm not sure what else to suggest without knowing more about what you are already trying.

    ~Sol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try doing a forum search for "boids". This behaviour might be what you're looking for

    ~Sol

  • The problem is that in your logic, you have told the variable to change based on it's condition... but it is changing the variable several times in the single event because it's processing your code in-line. You need to have some way of changing the variables in a more controlled way. Currently if the variable is "left" it changes to "right" but is then immediately pocessed from "right" to something else. Maybe adding a "wait 0 seconds" after each state change might work... otherwise you need to break down your state change engine to be more controlled over the variable adjustments.

    ~Sol

  • > How are you creating the ragdoll parts and joints? It could be a case of the code not processing all in the same tick, and therefore the joints aren't positioning correctly (because your ragdoll is spawned already in motion?). You can try spawning and creating the joints for your ragdoll using a Function, which should give a more solid result. The function will process the creation and pinning of the ragdoll itself in a more precise way, since all of the function code *should* run all at the same tick.

    >

    > ~Sol

    >

    I have to thank you buddy

    I solved the problem because of you i used the wait action before i apply the revolute joint because as you said its was spawned in motion

    I really appreciate your help tnx.

    No problem at all!

    ~Sol

  • Hi thank you. I want to use values because i use many animations on my player. I have walking , walking shoting, shoting idle, running , running shoting , jumping , jumping shoting, crawl, and so on and it seems too complicated use arrows.

    Makes sense, but you can use the arrow keys to simply set a variable (instance or global, whatever suits) just to get a value for the direction. Use this in your comparison event as a flag/trigger for current direction.

    It would however be easier, as suggested by others, to make a variable for curX and curY, and compare to another set of variables like oldX and oldY. This will tell you which direction you are moving and/or facing.

    ~Sol

  • Poxnixles

    I messaged Quazi to ask if he would mind updating the links in his tutorial. I was trying to cut down my project that I made using IK chains so I could send it to you, but it seems like too much work to get it all working correctly... it would be faster to remake it all as an example - but Quazi's tutorial is even easier if he has the reference links there.

    Will give him a few days and see what happens... if he can't or doesn't want to fix the links I will try to remake a simple example.

    ~Sol

  • How are you creating the ragdoll parts and joints? It could be a case of the code not processing all in the same tick, and therefore the joints aren't positioning correctly (because your ragdoll is spawned already in motion?). You can try spawning and creating the joints for your ragdoll using a Function, which should give a more solid result. The function will process the creation and pinning of the ragdoll itself in a more precise way, since all of the function code *should* run all at the same tick.

    ~Sol

  • Is there some reason you don't want to use triggers like "is pressing left" to set your animations? It sounds like you're trying to make it hard on yourself for no purpose.

    X position is always going to be positive unless you have unbounded scrolling enabled... 0 is left side of the layout and it only counts up as you move to the right. This is how coordinates work. If you don't want to use the supported triggers for simple actions, then you will need to make some variables that check the position of the player every tick - then compare those values to see if the player moved left or moved right, and set your animations accordingly.

    Honestly though, unless you have some unavoidable necessity to NOT use "is pressing left" (or right) then I would just use those triggers... that's why they're there.

    ~Sol

  • The only way to do this is to export it to NWjs so it can run independently of your system browser. HTML5 needs at least *some* kind of browser to run, so NWjs will encapsulate your game and allow it to run "offline".

    ~Sol

  • You should check out some of Quazi's tutorials on inverse kinematics... IK chains.

    This makes a really nice ragdoll and uses the many pieces of sprites to combine into one object.

    *EDIT*

    I just realised all of the tutorial images and links are broken thanks to Dropbox changes to public folder... however it's all described in the text and the images and examples are not required. If you get stuck with it let me know, I have made some IK chains in another project and can possibly help or elaborate on something if you need help.

    ~Sol

  • OK, I have found a solution that seems to work pretty well. I will do my best to explain in simple terms/method.

    First I have a main "player" that I move around with 8 directions behaviour. You can use whatever movement method you like.

    Secondly I have a "node" sprite and "allies" sprites (which are to follow the player).

    The "node" sprite has the behaviours of BOID (original boids not rex boids), as well as line of sight and custom movement. The "allies" have pathfinding behaviour only.

    So I make a node for every instance of the allies (when ally is created, make node as well and pair together with instance variable for some kind of ID system - you can use UID if you like). The "nodes" are set to boid behaviour to flock with the other node instances, and target/destination to the main player, and the "allies" are set to path find to the node that belongs to their specific instance.

    This works really well to simply pathfind to the location of the boid and avoid stacking up on top of each other. I will explain now the purpose of custom movement and line of sight...

    I discovered that, when I walked into a box of solids (walls to make a room) that some boids would be inside the walls or on the wrong side of the wall to the player - causing the allies to pathfind to the incorrect place. I use the custom movement behaviour so if the boid node is overlapping a solid object (wall) then it will push out at angle towards the player. The line of sight is used as a correction to this because sometimes the boid will still push at some weird angle and through the wrong side of the solids (because the boid behaviour is trying to maintain the constraints you provide to it) so i check if line of sight is not available to simply set the node to be at player.x player.y, then the boid movement will take over for it again since it has line of sight once more.

    If this is too confusing to follow I can make an example that demonstrates this - but I think I explained in simple terms how it will work.

    ~Sol