containers aren't working with families

[F3der1co]

Problem description

Report as Ashley asked for a repro
you can only add containers to base object types, not to families (serious projects use families all the time for scalability). Because of this wee need to use for each to reference the correct instances, which leads to additional performance cost and more complex events.

Attach a .c3p

familyContainerReport.zip

Steps to reproduce

tbh I don't know what to write here xD
1.try finding a way to to set up containers so the correct array is filled with this event, you can also try slightly changing the event as long as it works by referencing the family variant alone

Observed result

you cannot find a way, all arrays get filled when clicking an instance of the family

Expected result

Families should have containers.
When you add an object to a family container, an instance of that object should be automatically spawned when ever an instance of that family is created.
The same goes for destroying a family instance, it should destroy the instances of the container objects too.
When a family is picked in an event, it's container object instances should automatically be picked too.
When referencing an object property in an expression on another object the correct container instance is referenced.

More details

Affected browsers/platforms:

First affected release:

System details

View details

PASTE HERE

[XHXIAIEIN]

This will work

Also reproduces for other objects type. family-container.c3p.zip

Solution:

[TackerTacker]

This solution defeats the purpose of Families.
If you add more objects to family you would need to add another Pick instance with UID for every new object in the Family.
But even then, you can't add ObjectB to any other objects container, every object can only be added to 1 container.
That is the whole problem why it is impossible to make Families work with containers.

[TackerTacker]

Here is how the picking should work. Demonstrated with the flash behavior.
The Family is setup like this

msedge_2023-10-24_15-36-55.mp4

This next part is a bit off topic, so if it is considered an issue by Scirra I can create another Git issue for it.

This is something else that I would expect to work differently with Families.
Here I'm executing the Flash Family Action directly with the objects that are in Family.

msedge_2023-10-24_15-48-12.mp4

When I enable the flashing action for yellow ObjectC it flashes no matter what object from family I click on.
What I expect to happen is that yellow ObjectC flashes if I click on it, but nothing happens if I click on the green ObjectA.

Same happens if I enable the flashing action for green ObjectA, but because there are 2 green objects in the layout, they both flash.

Here is the modified project:
Family_issue_02.zip

[ruskul]

When I enable the flashing action for yellow ObjectC it flashes no matter what object from family I click on. What I expect to happen is that yellow ObjectC flashes if I click on it, but nothing happens if I click on the green ObjectA.

This part makes total sense and is working, unless I misunderstand. The condition is family is clicked. The action is object flash. If you click an greenObjectA, it is in the family. The family SOL, I believe, is independent from the list of specific objects. You are picking the condition filters on an object from the family, but you didn't filter specific object type ObjectC or ObjectA with the condition, thus those objects are all picked. If you only want the yellow object to flash when the yellow object is clicked, then you shouldn't have the family as a picking condition.

Why would you want the expected behavior? Cant you solve it by replacing the family condition with the type condition?

[TackerTacker]

Yea I had a lengthy discussion about this on discord.
From how Families are implemented right now it make sense.

For me it made intuitively more sense if it behaved the way I described it how I expect it to work.
But it might just be my intuition that's off, and it's the other way around for others.

It would also break a lot of projects, so I think that 2nd half of my previous comment can just be ignored.
I'm not going to delete it though to keep the discussion here comprehensible.

[WilsonPercival]

I have a workaround:
issue7485_workaround.zip

[ruskul]

Yea I had a lengthy discussion about this on discord. From how Families are implemented right now it make sense.

For me it made intuitively more sense if it behaved the way I described it how I expect it to work. But it might just be my intuition that's off, and it's the other way around for others.

It would also break a lot of projects, so I think that 2nd half of my previous comment can just be ignored. I'm not going to delete it though to keep the discussion here comprehensible.

On the other hand, form an oop standpoint, I understand the intuition. You basically want to define a condition (player overlaps enemy) and then be able to have a specific type of enemy do a specific thing. If we could have a way to get objType from family type, this would totally be feasible. You would simply do:

Pick family - Do Family Actions
--- pick ObjA from family - Do ObjA things.

I think the custom Action with overrides is meant to solve this problem though, in part, or at least it does solve it in its way. The issue I have with all functions and custom actions, is that they have 5x the overhead of inlined events. A basic function call can be inlined, but I see no way of removing the overhead from the custom action with overrides.

Imo, the custom action system is pretty awesome and starts to add that sweet oop magic we desperately need :D

[ruskul]

I have a workaround: issue7485_workaround.zip

On initial glance, this doesn't look like it works for more than one object picked rather still only affecting the first object returned.

At that point, it looks similar to other uid picking solutions to solve this problem, but with the overhead of a js block and function call (for me that tends to matter alot for my projects). The benefit I see here is that you can put the object into a container, instead of creating boilerplate object creation and uid setting functions. On the other hand, you still a have to loop through the instances, either in script or events, and that is the primary issue with uid picking. Is there another benefit this solution brings that I missed?

[WilsonPercival]

I have a workaround: issue7485_workaround.zip

On initial glance, this doesn't look like it works for more than one object picked rather still only affecting the first object returned.

At that point, it looks similar to other uid picking solutions to solve this problem, but with the overhead of a js block and function call (for me that tends to matter alot for my projects). The benefit I see here is that you can put the object into a container, instead of creating boilerplate object creation and uid setting functions. On the other hand, you still a have to loop through the instances, either in script or events, and that is the primary issue with uid picking. Is there another benefit this solution brings that I missed?

@ruskul I don't quite understand what you're talking about. Are you saying that my project file is not working?

[ruskul]

It works, but only for one object at a time. If you have a condition that picks more than one, it will only work on the first instance and the rest will be unaffected.

[WilsonPercival]

It works, but only for one object at a time. If you have a condition that picks more than one, it will only work on the first instance and the rest will be unaffected.

@ruskul I have resolved the issue posted in the original report. If you have a new problem, please provide your problem file. Otherwise it will be difficult to understand what you are talking about.

[ruskul]

The issue is not completely resolved as I see it. Container picking allows you to pick associated objects in pairs, regardless of the picked count. The solution provided only works on one picked object at a time. As a consequence, a forEachloop needs to be added in order to handle the cases where more than one initial object is picked.

The second issue arises when the solution is corrected with a forEach loop; Since a JS block is used to fetch container instances and would be inside that necessary foreach loop, performance for the solution provided will be dramatically worse than the standard "pick-by-uid-stored-in-an-instance-variable" reference as the overhead for a JS block is really high.

I do really like the cleanness of your solution as it stands for solving the exact example case, though it doesn't function at a generic level, meaning this pattern will have to be recreated n-times over the course of a project, which also isn't ideal.

Therefore, I would strongly argue that since this solution creates more problems than it solves, it is in no way a substitute for built family container compatibility, and isn't the best alternative at the moment.

[WilsonPercival]

@ruskul Can I contact you to discuss this? For example, discord?