oosyrag's Recent Forum Activity

  • Here's a visualization of what happens during an array pushing, see if it helps. When you push, you only push on the x axis, the other axis gets filled by whatever you pushed.

    docs.google.com/spreadsheets/d/1muTLyfKFaxD5WykJ2YoKYfg_lRQeuuABC5HwNi2t670/edit

    NaN means "Not a Number", which is what you get when you try to combine a string (animation name) with a number (ID), and try to put it into a number variable.

    I'm not sure about what's wrong with setting your items from the array, but maybe try again when your array is how you want it.

  • For situations like this, I like to use an invisible helper sprite, a "spawner" that stays in the original position and keeps track of values like timing and position.

    The objects created from the spawner can have an instance variable "origin" or "source" that I like to set with the UID of the spawner on created, so that each instance knows where it was created from, and I can use that to pick the correct spawner when the object gets destroyed. This helps in situations where you might have to work with multiple spawner objects.

  • 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?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • dropbox.com/scl/fi/ga8noow4efnwqhh5tyzzm/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.

  • 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.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies