Condition to find member of family fails

Link to .capx file (required!):

dl.dropboxusercontent.com/u/17275929/Temp/Bug%20Test.capx

Steps to reproduce:

1. Create a sprite.

2. Create a family and put the sprite in it, and add a variable (anything).

3. Create sprite in a Function (Func1).

4. Call a second Function (Func2) from Func1 to set the FAMILY variable. In the second function, use the condition to select by UID.

The steps are contrived to produce the bug. There are obvious work arounds, but functions should make things easier, not harder. Besides the bug, I recommend as a feature request to also allow returning the object that was constructed for the calling actions to use, and passing as a parameter as well if possible. There needs to be a better way of "type casting" objects to family types.

Observed result:

Condition fails

Expected result:

Condition selects the family (type-casting the object created in Func1).

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

Windows 7 x64 SP1

Construct 2 version:

r125

The reason it fails isn't because of families. It's because you can't pick an object by UID immediately after creating it. You have to wait til the next top-level event (a function doesn't count as a top-level event).

Well then, I guess that's all the more reason to support returning created objects from functions. ;) I mean honestly, simple games are perhaps okay, but more complex ones need to create functions to encapsulate some kind of shared functionality - object creation for example, then return it for usage - and this is especially true when there's no way to group sprites (treated as single entities). Having to "pin" via code is not good practice for an IDE of Construct's caliber. At the very least, if I have to pin objects to objects via scripts, it would be nice if I could at least wrap that in a function, which returns the object for use. For functions to be really useful beyond simplistic games, they need to encapsulate some functionality that can be "applied" and reused for various objects. Either a function needs to accept certain family types as a parameter so the function can apply some state values, or other functionality, or it needs to support returning them.

Example: I have a space drone. It has a "shadowing" sprite overlay, and 4 line of sight sprite overlays. I have to create all this, AND PIN, via a function. To make matters worse, I have to dump them all sprites onto a layout before I can even use them. The "line of sight" sprites can be used by many objects, so I tried to encapsulate the creation in a function, and got the issue above. Now, I have to duplicate my efforts for each object, which makes the functions useless for their expected functionality (to reduce repetitive scripting).

If functions are made a bit more powerful, it totally makes up for a lot of other stuff (like lack of grouping as mentioned earlier). ;)

ramones was right, there's a fairly complicated rule about newly created objects not being pickable until the next top-level event completes. This is deliberate, because the way the engine is architected, allowing this could cause crashes. So the problem is any condition in the function call cannot pick the newly created instance. However it's been reported enough now that I think it deserves a workaround specifically for 'pick by UID'. I've done this for the next build, and now 'pick by UID' can even pick instances that are freshly created. I tested the example and it seems to work now. So hopefully that makes creating objects with functions a lot more convenient!

Sounds good... is that for r127 yeah?

Bless you heart! LOL. This is a great step in the right direction, much appreciated! :) I must say, I love that you guys can take feedback and make changes in quick beta releases - it really helps get the community's needs out sooner than later. :)

FYI: As a workaround, apparently putting "Wait 0" before the call fixes it for now. ;)