Ruskul's Recent Forum Activity

  • You can say if A is overlapping B then set to 1. If A is not overlapping B then set to 0. So the first one but right-click inverted.

    That duplicates the collision check though, right?!

  • dop2000 good suggestion. I had it combined, and for whatever reason uncombined it and I don't remember why :/

  • Lets say I have:

    A overlaps B -> set A.somevar to 1

    Else -> set B.somevar to 0

    The else statement will never run if a single A is overlapping B. What I want it to set any remaining A not picked by the first event and set somevar to 0.

    I can't afford to duplicate collision checks or run for eachs. Both are costly from a performance standpoint so the best I have is:

    EveryTick

    ---Set A.somvar to 0;

    A overlaps B

    ---Set A.somvar to 1;

    A.somvar = 1?

    ---Do the things

    A.somvar = 0?

    ---Do the other things.

    Its seems verbose, has more events than it should, and still duplicates the number of checks. Is there now built in In case of A do this or B do that?

  • I am sure this has been asked before... but...

    Simple question: Why can't a family be in a family? Why can't one family know all objects in it are also in another family? As it stands, you can't put an object into a family that has the same variable as another which obviously means construct knows what families an object is in or not in.

    I think everyone understands the reason why, so I'll not get into detail here, but if you don't I'll try to explain.

    The basic idea is that, while you can recreate the effect of family in family, you often have to duplicate functionality across multiple families(bad programing period.) or have conditional branches based on object type variable stored in the family (extremely bad programing technique, full stop page break period.) This isn't to say conditional branches are bad - but they are in this case, because you can easily find that everytime you have an event for FamA you need a series of sub events to pick for type (meaning you are repeating yourself, and creating a terrible codebase). Now you have a project where everytime you add a new type, you have to hunt down all the different sub picking events to add to it and woe to those who forget where. Then removing a type involves the same thing.

    The above isn't a opinion as much as it is an accepted industry truth for the last 30 years. Those who disagree simply haven't felt the pains of managing such a product at an appropriate scale long term.

    The work arounds for family in families involve techniques that make a project harder to scale, increase difficulty of maintaining codebase, etc...

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

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • One way c# can hold your hand is access modifiers.

    Correctly used, nobody using the code can possibly misuse any variable or function. JS lets you seemingly use anything however you please. Don't want to be bothered with get/set functions? Just grab the variable and change it as you see fit. lol

    Its a real potential to shoot self in foot. Of course... c3 editor side does the same thing, since there is no way to protect variables or limit them to only some uses or scripts.

    Its a thing that doesn't make the language itself harder, just code one is working with.

  • So apart from distorts changing or adding collision poly points nothing is setup for modifying collision polys outside the editor.

    Maybe with JavaScript but you’d have to bypass the scripting api to get into the unsupported and undocumented innards that has a has the possibility of changing per release and breaking anything you do with it.

    I actually was hunting down what methods I might use. I see that you can use world info to get a poly's info, but so far I think the code for setting might be editor side.

    The mesh distort may be the way I go. I only need triangles and squares anyway.

  • Thank you everyone! I was trying to find it in a project setting or something, but sys action is great. Thanks !

  • Hey, I thought I saw a while back that there was going to be an added option for tweaking collision cell size in construct for optimizing collisions in specific cases.

    I might be misremembering, or perhaps it wasn't a setting that user was going to have access to it. Does anyone remember this conversation?

    It was based on a vampire survivor like game as the use case. Can't remember who all was involved and I can't seem to find it in google. :(

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies