Clear all SOLs

For developers using the Construct 2 Javascript SDK

Post » Sat Nov 29, 2014 9:59 pm

Is there a convenient way that i can empty every SOL ? i have a condition that picks objects in an advanced way that first requires all the sols for all objects except the one calling the condition to be empty (it then picks a specific subset of objects).

the condition basically needs to work as follows

Condition:
"Main object -> pick children"
{
wipe all SOLs except possibly the sol of "Main object" which is calling the condition.

iterate over children of main object, adding them to sol.instances.

return true.
};
B
77
S
13
G
8
Posts: 1,973
Reputation: 9,891

Post » Sat Nov 29, 2014 10:27 pm

Maybe something like this should work?
Code: Select all
for (i = 0, len = runtime.types_by_index.length; i < len; i++)
{
   var type = runtime.types_by_index[i];
   var sol = type.getCurrentSol();
   sol.select_all = false;
   sol.instances.length = 0;
}

It's untested but should work as types_by_index is used elsewhere to loop over the types. You'll probably need to save the old SOL first with pushCleanSol() or something like that. You can find it in preview.js as well as examples of it's use.

You may need to do some experimenting with it as I don't know if doing that will cause issues with the event sheet, since the standard behavior is to terminate evaluating and other sub-events if 0 of something is picked. I could be wrong but it's just a thought.
B
92
S
32
G
107
Posts: 5,274
Reputation: 69,959

Post » Sun Nov 30, 2014 6:17 am

This is how i was doing it but i didn't know what the type's list was called so i was grabbing all the children's types through the instances that were children. gonna try this now and see what happens.
B
77
S
13
G
8
Posts: 1,973
Reputation: 9,891

Post » Sun Nov 30, 2014 12:01 pm

You should avoid this kind of thing for performance reasons. Since you have code that runs for each unique type in the project, you will have a slowdown proportional to the size of the project, and we've had bugs reported (and fixed them) based on accidentally having code like that which slows down large projects.

Also in the event engine you are not actually allowed to modify the SOL of any objects apart from your own or anything passed in object parameters to the current condition/action. Doing so will break the event engine optimisations aimed at avoiding the above performance problem.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Sun Nov 30, 2014 12:24 pm

@Ashley

Or provide more high level SOL functions for picking in SDK, to indicate event engine here has SOL changing?
I would like to have some picking in my plugins which could be more compactly.
B
108
S
26
G
267
Posts: 4,456
Reputation: 149,747

Post » Sun Nov 30, 2014 1:55 pm

It's hard to provide many useful "general purpose" functions without incurring a serious performance penalty, or having to make some significant changes to how the engine predicts which SOLs are going to be modified.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Sun Nov 30, 2014 5:12 pm

i think a nice solution would be to have a param where you can let users select multiple types or none at all at once for certain conditions, and then the param in the run-time function is an array of the types which a user has selected? this way we could make flexible functions that operate on many types, but only as many as the user selects, circumventing the issue of slowdown proportional to a large number of types in the project for stuff like this?
B
77
S
13
G
8
Posts: 1,973
Reputation: 9,891


Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 1 guest