How do I use "overlapping object" more efficiently?

0 favourites
  • 10 posts
From the Asset Store
Hand-painted tiles, objects, animated objects, and background to build a colorful Mayan civilization environment.
  • Hey there.

    Trying to get a condition where sprite (spawner) detects whether sprite (boxes) is overlapping it. Not sure how I managed to make this such a riddle.

    I've tried combinations of "for each spawner", setting an instance value if boxes is overlapping spawner, plus several other attempts to see what would stick. Collisions is enabled on each sprite.

    Any help would be greatly appreciated.

  • Closer but only 4 instances of boxes should exist at a time (one off screen, three spawned by the spawner). However if I set one of the boxes to "selected = 1", five instances exist the next time I run it.

  • Say what you want but how silly an additional instance variable had to be used to help "if sprite.x isn't overlapping sprite.y" condition. I would have thought that condition could stand on its own. Solution found regardless, hopefully this helps someone else trying to find it on their own.

    This post from Dop2000 put me in the right direction

    https://www.construct.net/en/forum/construct-3/how-do-i-8/spawn-random-not-overlapping-152676

  • Final product which allows the system to set the "occupied" instance variable instead of entering it somewhere else. I try to use the KISS method as often as possible (keep it simple stupid). Less variables to keep track of.

  • I feel it could be made simpler but I don’t understand what the desired behavior is from reading your posts.

    When the spawn_button is clicked you want to destroy any boxes that aren’t selected and create boxes on any spawners not overlapping a box? Sounds simple enough but looking at your events it looks like you have more complex behavior in mind?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hey there! I absolutely agree about the simplicity side of the coding. This project has gone on for almost 2 years and I frequently run across a section I did 18 months ago when I didn't have the experience. I tend to redo portions because of wasted coding and lines // streamlining things. This might be another learning experience for me.

    This coding above is my sandbox. I'm trying to replicate the scenario in my larger project of having several sprites to choose from. When you pick one, it becomes "selected" and only one sprite can be such at a time. While you perform actions on that one, you can refresh the choices but I didn't want the selected one to be deleted.

    I couldn't figure out how to delete the sprites that weren't selected, generate new sprites and all in the designated areas. You obviously know your way around development so if you have any thoughts, I'm smart enough to know when to listen/read.

  • Well I still don’t fully understand how you want it to work. I’m guessing you have a box per spawner, and you can select a box. Then clicking a button will create/ recreate the boxes that aren’t selected.

    Global number pickedBox=-1
    
    On box clicked
    — set pickedBox to box.uid
    
    On spawn_button clicked
    [negated] box: pick by uid pickedBox
    — box: destroy
    
    On spawn_button clicked
    [negated] spawner: overlaps box
    — spawned: spawn box

    If you set it up in the layout so each spawned has an overlapping box to begin with then the last two events could be merged into

    on spawn_button clicked
    [negated] box: pick by uid pickedBox
    Spawner:overlaps box
    — box: destroy
    — spawner: spawn box

    But then I wonder if we need to even recreate the boxes at all.

    Again that’s why I don’t think I fully understand fully what exactly you wanted it to do.

  • If you're talking efficiency, when ever you use a foreach object, you should put it last in the conditions list of the event line.

    The difference is at the top it will loop over all objects and the actions will apply to any object that meet the conditions below it, where as if its on the bottom it will only loop over the objects that already meet those conditions.

    It wont make any difference with a small number of objects, but if you happen to be using hundreds or thousands of objects then it makes a difference if the conditions only apply to a few.

  • Thinking it through, I didn't explain it very well.

    1. Spawn a sprite (box) per box spawner (done manually until I can set it to be completed by a function and timed) - there are 6 spawners.

    2. Generate values for several variables of each box (weight, strength, capacity, item(s) inside, etc)

    3. When the box is selected, must complete action with that box which then sets selected back to 0. Only one box can be selected=1 at a time.

    4. While box is selected=1 and other boxes are spawned, the selected=1 shouldn't be destroyed.

    Think of character entering shed, random # of boxes to explore, picks one to take, can't take another until the one selected has an action (drop, destroy, de-select). Can still look in other boxes but can't pick it up (select it).

    I don't necessarily need to recreate/respawn the boxes as long as the values were reset by the trigger (button clicked) however the long-term plan is eventually a random amount of boxes be spawned instead of the 6 each time.

    Did the explanation help some? As I wrote it, Project Zomboid comes to mind.

    I like your coding as it's obviously cleaner than what I had and gives me something to test with what I'm trying to accomplish. I'll see if I can post a mock-up of the code shortly.

    Well I still don’t fully understand how you want it to work. I’m guessing you have a box per spawner, and you can select a box. Then clicking a button will create/ recreate the boxes that aren’t selected.

    Global number pickedBox=-1
    
    On box clicked
    — set pickedBox to box.uid
    
    On spawn_button clicked
    [negated] box: pick by uid pickedBox
    — box: destroy
    
    On spawn_button clicked
    [negated] spawner: overlaps box
    — spawned: spawn box

    If you set it up in the layout so each spawned has an overlapping box to begin with then the last two events could be merged into

    on spawn_button clicked
    [negated] box: pick by uid pickedBox
    Spawner:overlaps box
    — box: destroy
    — spawner: spawn box

    But then I wonder if we need to even recreate the boxes at all.

    Again that’s why I don’t think I fully understand fully what exactly you wanted it to do.

  • Is that right?? Ugh... Thank you for the explanation. I had no idea what impact (if any) the list of conditions made but man does that help a lot. I appreciate the insight.

    If you're talking efficiency, when ever you use a foreach object, you should put it last in the conditions list of the event line.

    The difference is at the top it will loop over all objects and the actions will apply to any object that meet the conditions below it, where as if its on the bottom it will only loop over the objects that already meet those conditions.

    It wont make any difference with a small number of objects, but if you happen to be using hundreds or thousands of objects then it makes a difference if the conditions only apply to a few.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)