Severely depressed from UID pick failure

I'm so frustrated I feel like punching a baby.

Can anyone please tell me what the heck is going on with this code? A pick operation is not picking *anything* even though the UID is valid and the object type is correct.

I'm seriously about to cry, I've been at this for the last two hours.

Here's the capx for anyone who could shed some light on this...

(It's pretty simple)

Pick failure project

I gutted the project file so that it would be a small capx download, cause this originally comes from a much larger project.

Help me obi-wan kenobi, you're my only hope (bends over really ackwardly)

-- cacotigon

I'm not sure what I did, and even if this is a solution to the problem, but on line 2, change

Set UID_CommonArray to BaseArray.UID

to

Set UID_CommonArray to BaseArray.UID + 1

Why not use the pick by furthest/nearest? Just use the exact x-y co-ords for the object (as long as it's stationary, or use [object-name]-x/y), and it'll never fail.

Just a few remarks.

I don't get why you create two instances of the array object.

Disabling both actions of creation of an instance in "GameInitialization" seems to make things work as expected.

The array object is "global" to the project, you can access/size/use it at will from any event sheet.

Another thing to have an eye on is the function plugin. It may act on the SOL (and so on the picking).

I think you just need to let c2 create the array before trying to pick it.

It seems c2 need a tick to do that.

This seems to work as expected :

arrayPicking.capx

Kyatric, as I mentioned before, this code is from a much larger project, one where I initialize several different arrays, each containing different information. Sorry, can you explain what SOL means? Thanks for the info about the function plugin, I will try removing it and seeing if the same problem occurs.

Yann, that seems strange, especially since I can access the arrays class properties immediately after create object including the UID, which would seem to indicate that the object has been already created. Unfortunately, if I make this change, my code order is going to get messed up, I guess I might have to make a IsReady var and group everything else under.

I'm still kind of unhappy about this, in normal Construct behavior, after you create an object, any further commands will act on that object essentially an automatic pick operation occurs, so why doesn't a deliberate pick work? So frustrating.

SOL is the Selected Object List.

Basicly the list that contains the instances you picked (by filtering with conditions) and to which the actions will be applied.

This doesn't work because subevents carry on picking where the parent left off.

The event runs like this:

1. First array instance created. The 'create' action picks it.

2. Its UID is saved.

3. Second array instance created. The 'create' action picks it. This is now the only picked array! The other array instance is no longer picked!

4. Enter the subevent. The subevent inherits the parent event's picked objects, i.e. *only* the second created instance.

5. Conditions only ever run on the picked instances. So "pick by UID..." in that subevent will only pick from the second created instance, which does not have the UID you want, so the event can never run!

There's no bug here, it's just Construct 2 working normally.

There are three possible solutions:

1) Use system 'Pick all BaseArray' before the 'Pick by UID' to go back to both arrays picked rather than just the second array picked.

2) Make a new start of layout event and move the pick by UID to there.

3) Don't use multiple instances of array - it's much better to use two different array object types than two instances of the same array (i.e., insert a new array in to the layout again and use that).

[quote:28kt5we4]that seems strange, especially since I can access the arrays class properties immediately after create object including the UID, which would seem to indicate that the object has been already created.

ou can access all Action/Condition/Expression of any object type of your project any time. The fact that an instance is created at runtime or not is irrelevant, as there's no parsing of the event sheet to check if you created something before accessing it.

Anyway, I gave it another try as it is indeed a weird behavior.

It seems that somehow, creating another array before trying to pick the first one makes the picking fail.

So that seems to work like that.

arrayPicking2.capx

I wonder if it deserves a bug report or not.

Ashley should be the judge.

Ashley

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU!

That's exactly what is happening! I had no idea that a PICK command in a subevent could only pick from its inherited "pick list" which happens on a Create object command. Subeventing the Pick UID code under a Pick All completely fixes the problem. I think I've got a much better understanding of the code-flow now. Also, I created a completely new project and tested extensively with sprites/arrays/etc and there doesn't seem to be any bugs. Hurray!

Damn I've been so ninja'd!

Well, Ashley, why is it such a bad idea to create instances of array?

I was planning on doing that do stream the creation of next levels of a maze while playing the current one. So running the same algorithm on the same array but with an instance variable to differenciate them.

Like if Array.level = nexLevel -> run the algo on it

Ashley: Regarding Option (3), that's what I had initially; separate array objects, the problem with this is that I have a rexrainbow function which takes an array as a method parameter. Normally, I would consider putting all of my arrays into a single Family, but I assumed that cast to Family like ArrayFamily(Function.Param(0)) where Param(0) is a UID of an Array belonging to ArrayFamily would fail or would have some unexpected results since Family is still fairly new and Family behaviors are not yet implemented.

Well the main issue with different instances of an array is it can be confusing. For example, the way event picking works is if you pick more than one array instance it will be writing to two arrays at the same time. And this all happens "invisibly" - it's hard to check which arrays are being written to and what their content is.

It's clearer to think about if you only have one instance of an array. If you need multiple 2D arrays, use one 3D array instead, or different array objects if possible. On the other hand, if you know what you're getting in to, I guess you can go ahead and use multiple array instances!

Cool :D That should simplify things!

But I understand the fragility of such method. I'll be keeping an eye on debug values.

Its not that fragile. Pick nth, or the index should work for all objects.

array(1).at(x)