TestOverlapSolid just returns true or false. It doesn’t provide any info about what instance it was overlapping.
To know the instance you’d need to use testOverlap(a,b) instead. But for that you’d need a list of instances with the solid behavior to loop over.
One way to get that list is to access an object type that has the solid behavior, and get a list of all instances with solid like so:
let inst = runtime.objects.Sprite. getFirstInstance();
let list = inst.behaviors.Solid.behavior. getAllInstances();
That’s basically how you access behaviors according to the manual. It’s not too generic if you have to tell it a type that has the solid behavior. Also it needs an instance to exist to be able to access the list too.
A generic way could be to have a function that loops over the types in runtime.objects, gets the first instance and if it has the solid behavior save that somewhere. A bit brute force but ideally it would only need to run once, so if it found the solid behavior it would save it. Worst case is you’d have no instances with the solid behavior so it would keep searching and failing to find it.
Anyways with that you’d be able to get a list of the instances with the solid behavior, loop over them and use testOverlap() to see if they overlap. And if they do you could then compare inst.instVars or something. Or you could even access the solid behavior tags but that may be automatic.
You could also try and utilize constructs collision cells. To do that you’d use runtime.collisions.getCollisionCandidates() but for that it needs an object type. To get those you could loop over the list of instances with the solid behavior and make a second list without duplicates of the object types.
Anyways I’d argue that js is fairly easy to learn. However, the hard part is finding ways to access things from the engine. Some things are easy to access, some things have to be accessed in round about ways, and for some there’s no access at all.