Scirra
containers aren't working with families
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
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
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.
Here is how the picking should work. Demonstrated with the flash behavior.
The Family is setup like this
https://github.com/Scirra/Construct-bugs/assets/18266300/2f5b7caa-2145-41c4-8667-d40f1b20e1c1
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.
https://github.com/Scirra/Construct-bugs/assets/18266300/d8d0d965-e75b-4f7b-9be5-b61ea7e7a880
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
When I enable the flashing action for yellow
ObjectCit flashes no matter what object fromfamilyI click on. What I expect to happen is that yellowObjectCflashes if I click on it, but nothing happens if I click on the greenObjectA.
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?
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.
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
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?
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?
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.
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.
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.