oosyrag's Forum Posts

  • You can disable the drag drop behavior with actions when you no longer want it to be able to be dragged and dropped.

  • Use the timer behavior for the intervals. You can use global variables or an array to keep track of wave properties.

  • What exactly are your restrictions?

    What didn't work well with drag and drop?

  • dropbox.com/s/j2oyalr4sc6b5ny/dragdropcraftingexample.c3p

    Sorry! Didn't realize I had two copies in my dropbox. Try this one.

  • Use the timer behavior. You can use multiple timers with tags.

    For the quick hit, on key pressed set a timer "attack" for 0.1s, and another timer "charge" for 1s.

    On key released, stop the charge timer.

    On timer "attack" trigger, check to see if timer "charge" is running. If it isn't, then attack.

    On timer "charge" triggered, then you can immediately unleash the charged attack, or set a variable "charged" to true. On key released, if "charged" is true, then do charged attack.

    Note that games like Zelda classically do the normal attack first no matter if you hold the button down or not, that would make it simpler. Then you simply check if the key is still down up on the animation finished to start the charge timer.

  • One of the simpler effective decollision methods I've used is the bullet behavior to push objects away from each other.

    Default speed 0, with a high negative deceleration.

    Have your object in a family to check overlap with self. If overlapping with self/family, set bullet speed to an amount you want to push away, and set angle of motion for the object and family to away from each other.

    Adjust the bullet behavior numbers until you get a satisfactory amount of decollision knockback.

    Edit: note that most games that use this type of decollision do not do it every tick. Some do it only when every x seconds or on an asynchronous thread, and some only do it only when the object is at rest. You might also want to add other conditions to prevent an object getting yeeted across the screen if there are a lot of objects to collide with.

  • Example updated, see events 12-14. I didn't add a re-enabling event, but that depends on what triggers you want to turn dragdrop back on, like on craft complete, or if the item was dropped again without overlapping the pot. It would pretty much be pick all items and enable dragdrop. Or you can filter by item.id again, like when disabling - I saved the item id to a variable, and used that to pick which items I wanted drag and drop disabled.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Are you using the same move to behavior on the host as the peer side? They need to match for local input prediction to work.

    Is your sync object bandwidth set to normal?

  • items.json contains the item definitions, with "id", "dispName", "animName", "aniFrame", and "desc" keys for each item. recipes.json contains recipe definitions, with ingredients (an array of item ids), and result keys for each recipe. They're different in form and function, which is why I used two files. It works the same if they're all together like they were in the original example.

    On start of layout, the two files are loaded and placed into the "items" and "recipes" paths respectively, resulting in the exact same result as when it was just one file with items and recipes together. I've included that original file into the updated example (same link), if that way is preferable.

    What do you mean only one has drag and drop enabled? If there were two of the same thing, how should which one be draggable be determined?

    There are a few ways to ensure item (or recipe rather) order doesn't matter. The first way would be to not have conflicts to begin with. So don't have an A+B, B+C, or A+C recipe if A+B+C is a recipe.

    Another way would be to use a different trigger to check recipes, like a button the user has to push (after adding items to a pot or something), so that it's not triggered immediately upon dropping. But even then order still kind of matters, you would probably just want check the bigger recipes first before the smaller ones.

    You could also explicitly define a "priority" value in the recipe json, and check the recipes in order of their priority. But this is not much different than just leaving it as is - the priority is simply the order in which they appear in the recipe list.

    One option would be to just not worry about it, and let the player figure it out. If you had A+B=C and A+B+C=D, they would have to add A+C before B or B+C before A to get D.

  • Ok so there's a few problems here, in no particular order"

    Don't use physics unless your whole project is physics based (or you really really know what you're doing).

    Your platform with the sine shaking is probably causing multiple collisions and resets. It is often

    Avoid using wait, it simply delays the actions and doesn't stop events from running in the meantime. Better to use timers and timer triggers for anything that needs to happen over time.

    Using instance variables along with the timer behavior to keep track of the state of various objects could be useful as well. I put together an example for you, hope this helps. dropbox.com/s/2uigcteg6sam753/fallingplatformexample.c3p

  • Set their origins so that they are all at the same coordinate and aligned. Or use the pin behavior to pin the pieces together.

  • Trigger once only works when there are other conditions with it.

  • In the event that destroys the platform, spawn a new one at it's original location.

    You can keep track of it's original position with a pair of instance variables or an invisible helper sprite.

    An alternative would be to not have the original platform fall at all, just make it invisible, turn off solid, and spawn a dummy sprite to fall instead. Then make it visible and solid again later.

  • Is your target sprite origin in the right place? Or are you targeting an image point?

    If you use move to direct and handle your own waypoints, it should be more precise, but they'll slow down and stop at each waypoint.

    Otherwise if you need precision you can try using tween instead, which will be exact.