How do I take the current SOL and select objects in the current family that are also in another?

Post reply
0 favourites
  • 9 posts
From the Asset Store
Mayan Temple - Platformer Tileset
$7.50 USD
50% off
Hand-painted tiles, objects, animated objects, and background to build a colorful Mayan civilization environment.
ludicarts's avatar
ludicarts

  • Currently...

    I simply have a variable on FamilyA, isFamilyB.

    Then if I am doing stuff with A and need to pass off to familyB, I have to do a for each FamilyA where I take the current the object's UID and then pick familyB by uid.

    It works, but I hate it because its a forloop and I can't afford unnecessary loops in the event sheet.

    From an organizational standpoint, in makes sense to keep this functionality in separate families, as they are not mutually inclusive in all circumstances. But Family B will always be indicative of Family A.

    Is this the way, or are their better methods, either from an organization perspective or some other trick to transfre the current SOL from object type to object type.

  • Guess you could do it by marking all the instances in a way independent of the families. Unfortunately it can’t be a variable since that’s family specific, but maybe something global like opacity, or something you aren’t using.

    So the process would be to start by marking nothing then after filtering the sol set the mark and pick the other. 

     Every tick
— family1: set opacity to 100

Some event that picks instances of family1
— family1: set opacity to 50

Family2: opacity=50
— do stuff

Every tick
— family1: set opacity to 100

    It’s a bit annoying to have to utilize opacity so you could add picked Boolean variable per family as well.

    Basically you need a picked Boolean per family you want to copy the sol from. And for this to work the families involved need to all have the same object types. Hopefully the iid order of both families is the same too.

    Then with all instances of both picked you can use pick by evaluate as an implicit loop. 

    Every tick
— family1: set picked1 to false
— family2: set picked2 to false

Some event that picks instances of family1
— family1: set picked1 to true

Pick all family1
Pick all family2
Pick family2 by evaluate: family1.picked1
— do stuff

    Either method requires resetting the picked value before using again.

    Edit: iid stuff shouldn’t be needed.

  • I suppose I could use the z value on my colliders. Opacity is set to 0, since they are non-rendered, and the model is a separate sprite.

    I like the simplicity of version 2. Its a nice way to avoid the event sheet loops. Very nice :D

    I, uh, ... forgot that Overboy has a utility for this. And I have it in my project lol. That solves the issue for me, though in projects I intend to share I keep vanilla c3 only, so this method is good to know of. Thank you.

    I swear R0J0hound , you are an absolute treasure trove of knowledge when it comes to elegantly phrasing events; A true Shakespeare of construct.

    10 years ago, you showed me how to get a vector projection. I didn't even know what sin and cos were at the time, or how to ask about the math... , but you were a real help. Thanks for taking the time to share what you know. It means a lot.

  • In the second case, why did you have a pick2 variable when it isn't used? Is that for the reverse case?

    Secondly, I was wondering why you have a pick all for fam1 and fam2 in the condition for pick by evaluate. It seems in my test you don't need it.

    Last, how does this work? I don't understand the magic occurring in the pick by evaluate and how that transfers picking. Is there any limitation or caveat? How does it create an implicit foreach loop?

    Finally, If you use an else, it doesn't work as I would have expected, which I have noticed using pick by evaluate in the past. It will only activate else block if there are no picked instances in the prior. meaning until the picking condition is false for all instances, no instance shall be picked. But if you did a if compare variable condition, the else would work on other instances.

  • Yeah, the pick2 is for the reverse case.

    The pick alls aren’t needed but I added them to show that you need all the instances to be picked for this to work. Actually, it would work if the same instances were picked in both families too.

    This is what a normal filtering condition like this:

    Sprite1: width = sprite2.width

    Expands to roughly under the hood: 

    // Sprite1 and Sprite2 are lists of the current picked instances. 
for(let i=0; i<Sprite1.length; i++) 
if(Sprite1[i].width == Sprite2[i%Sprite2.length].width)
 Pick Sprite1[i]

    A normal filtering condition is stuff like compare width, compare x, pick by comparison, … etc. Static conditions such as is overlapping or pick nth instance do their own thing.

    Anyways the relevant bit is what instance of other types are used in the condition. In practice we tend to just filter the other types down to one instance before doing a condition like that but it can be useful when the instance counts are the same.

    Actions reference other instances in the same way and has more utility. Most useful is “sprite1: set position to sprite2” if sprite1.count=sprite2.count then each sprite2 will have a sprite1 on it. And if sprite1.count=2*sprite2.count then each sprite2 will have two sprite1 on it.

    And yep that’s how else works with picking. You’d have to use a for each to avoid that.

  • Just to make sure I am following this correctly,

    If I have a condition that narrows down famA to a few selected objects, I will still need to set pick1 to true, select all famA and famB, and then run the evaluate?

    Is there an assumption that famA count much be equal to famB count then?

    In the end, I may very well have 30 different object types in famA and only 10 in famB. For sure, I know that all famB are also famA, just not the other way around.

    But I'll also have cases where I don't know at all all but want to check. I am using families in this way like interfaces, such as iHaveHealth and iTakeDamage. Basically contracts and functionality that guarantee a particular object has a way to interface with basic data.

    A door, for example has health and can take damage, can take interactive commands, but it can't be confused and take other stat modifiers, etc...

  • In regards to the else, I understand why. Else only runs if no objects meet the first condition.

    Is there a clever way to simply have a way to invert the current sol?

    It seems silly to either run a for each or double a collision test when technically, you should already have everything you need.

    Maybe we need a systme condition that is "alternatively", or "alt". Bacially, do this to the inversion of the current sol, after doing the other thing to which objects met the condition.

  • Okay, it seems this method does not work consistently. For example if I have 2 sprites, and two families and I put sprite A in famA and sprite AB in famA and famB, depending on the order of creation, it may work or may not. In the case where the family transfer doesn't work, when famA gets picked, but the sprite is not in famb, object AB will be picked when the family transfer happens. But when the same condition picks famA and sprite AB gets picked, the family transfer won't work.

    Simply changing which sprite is in both families will cause it to work suggesting to me some sort of internal ordering that plays a part. On the other hand, if both objects are in famA and famB it will work, but that sort of defeats the purpose. If all objects in A are in B and vica verca, there is no reason to have the families be separate.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Most of the ideas have limited times they can be used. Events aren’t flexible in all ways so I generally decide what I want to do with consideration of what you can do with events.

    Stuff like interfaces lose me. I mean I could look up what they do but they seem like just an abstraction like much of object oriented stuff that just adds complexity.

    The event system is basically a mix of multiple things. The picking system which is kind of like functional programming, and without that it’s structured programming like a limited c without pointers or structures. On the object oriented front we have plugins which act as objects and families which are more like genetics than inheritance. I guess behaviors and custom actions could considered a bit object oriented too.

    As a whole the event system doesn’t adhere to any specific paradigm or even map directly to JavaScript. It’s just a little of everything with many useful parts, arguably missing parts, and a few really awkward parts that require you to choose a different approach when doing some things.

    In the end we all have our preference on how we want to structure or abstract our code.

    Personally I want to use as few languages as possible so I use events and js only to add missing engine features when absolutely necessary. The engine as a whole has good coverage of features but like anything it has limits which require doing things a different way. I don’t make plugins or effects because I hate dealing with build systems, I don’t want to maintain such addons and deal with comparability across browsers and systems. The reason I use a program like construct is because I enjoy the fast edit->run cycle to iterate on stuff. My goal is to do stuff in the least amount of events possible while remaining readable so only add abstractions where it simplifies stuff and makes it readable.

    Cheers

Post reply
  • 9 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)