99Instances2Go's Forum Posts

  • I have a problem with the logic of the assumption.

    Say, the goal is to minimise lines of code.

    Starting from 1 object. Addressing is no problem.

    Need many, use instances.

    Need many objects and there instances, use a family.

    Next logical step would be a group containing 2 family's. Cant have a group of family's, but can use 2 family's.

  • Show the problem in a reduced capx ?

  • Use a system > 'for', .... from array.width - 1 .... to ...... 0.

    Now you walk trough the array from the end to the start.

    Sub event .... Compare 2 values ... Array.at(loopindex) ... = .... "badge"

    Action ... Array > delte ... x-axes ... index = loopindex

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Any recalculation of the collision polygons (sine, scaling, animation) will give you a memory related java error, when physics is used, anywayz.

    Depending on how many affected objects, the error pops up in 1 minute or 20 minutes later.

    Try it, give the objects in your capx a sine (on size) behaviour. Empty event sheet.

    Try

    ?

  • The player parts are instances of the same object 'player', so, without picking, 1 action moves them all. They just have another animationframe (can be done with animations too)

    Catch: they all have the same origin.

  • timcs, this is ofcourse made for basic needs, and it answers your first question.

    If you need the parts to have displaced origins, then we got to go a step further.

    If the parts need to be able to (by instance) rotate or scale, when we got to take it 5 steps further.

    Need to know your needs.

  • Here is 1 of the many possible solutions.

    Notice that the instance variables and behaviors are not present in the second family,

    It further shows you picklists, and how they work.

    https://drive.google.com/open?id=0B1SSu ... 2RfUnNZS3c

  • I can tell you why the presented code does not work as you expect.

    The Picklist made in event 119 contains 1 object.

    The 'for each' does not matter, picking wise. It does logical wise.

    So, it iterates trough each member of the family. When that member of the family meets the two conditions. It picks that member. If not, the picklist for that family will be empty.

    With 1 object in the picklist, the condition is true. It wil run its sub conditions.

    With zero objects in the list, the condition is false, and wil not run its sub events.

    So, if it runs its subevents, it has 1 object in the picklist, for the following subevents that is the 'previous picked list'.

    Now. Event 120 starts from that 'previous picked list'. Containing 1 object.

    It will not check those objects that are not in that picklist, they are excluded by event 119.

    Hence. It can only check LOS between that 1 picked object and itself.

  • I do that all the time. I, by instance, always group a condition and its else under a blank one.

    I think that the readability beats any minor drawback.

    Not advisable for people with the free version, amount of events run fast out of the max allowed.

  • 6 Parts. The super simple way (you misunderstood 'layout' in BoundToLayout).

    https://www.dropbox.com/s/qp8ylpczixfrt ... .capx?dl=0

  • Best keep crafting. And i find your XML adventures interesting.

  • See, the thing is. A condition has a logic part (if true it runs its actions) and a picking part (it makes a list of selected objects).

    If you want to set a Boolean based on the logic (true/false) you best use an 'else'. Else means 'if the previous condition did not run (hence it is false), run this condition.

    If you want to set a Boolean to a list of picked objects (true), and set the opposite the unpicked objects (false), then the the second condition will be the first inverse. But, that second condition cant be a sub of the first because those objects are not picked by the first one.

    Now, those two 'rules' combined. Often it means (for the logic based else) that the top conditions are the picking conditions. Then a sub with that logic condition, then attached to that sub the logic else. Or in general:

    Pick object A

    Pick object B

    ______Logic condition

    _____________________actions

    ______Else

    _____________________actions

    Example

    You want set a boolean if a object is onscreen, if none of that object is onscreen you want to set the boolean to false.

    (object) Is onscreen

    _____________________set boolean true

    else

    _____________________set boolan false

    Or. You want to set a boolean of all instances of an object to true when they are on screen, and to those that are offscreen you want to set the boolean to false.

    (object) Is onscreen

    _____________________(object) set boolean true

    (object) Is (NOT) onscreen <----- no sub and INVERSED

    _____________________(object) set boolean false

  • Working like a light switch

    https://www.dropbox.com/s/k6ig0q0k7o18f ... .capx?dl=0

    Working as something standing on a scale.

    https://www.dropbox.com/s/0qya7l0g66r43 ... .capx?dl=0