Group condition to another group

Would be a little complex (but doable).
May risk slowing down your game though, depending on how many items would be present in both groups.
You should nest a couple of loops, the first running through all "player" objects,
the second, for each "player", would loop each "enemy" (or reversed).

How many objects would be present in this "player" group?

Could even be easier hard-coding, if few and pre-determined.

Sure it's necessary?
Is it for multiplayer, multiple character moveable on screen...?
If applicable, maybe you could use a simpler sighting system for this other group?

hmmm you could make it with objects following the X,Y position of each player, these objects would act as sensors
each time an enemy is overlapping one of these sensors it will attack the player.

XD something like that

Fusion is completely object-oriented, so you just need to use a for each loop. If someone can put together an example for you today, that'll be really great. If not, I'll try to remember to do it tomorrow, and remind me please if I forget to do that.

There had been a line of sight extension but I don't know if it's still around.

OK since I already knew the code I took another look, and it was a quick run:
Please login to see this attachment.

But I only did the multiple LoS creating / positioning part,
I'm a bit in a hurry now and couldn't comment - perfection more,
if you need help for the "what to do when one or the other los is activated?" part,
I could take a look tonight.

(as it is now, enemy will be activated only when seeing both players, you obviously need to activate and do stuff when seeing each player... anyway, that will be easy!)

Note: you could've done only with 1 los per enemy and repositioning that for each player,
but since players are going to be few I made 1 los x each enemy x each player,
guess this is easier and more intuitive for debugging.

Ok, this will activate when a single player crosses sightline:
Please login to see this attachment.

I guess next step could be "deciding" which player is enemy's current target, when more than one are in sight...

You shouldn't use Line of Sight 4; it's only here so you can see what's going on internally. I optimized Line of Sight 6 for general-purpose uses but you should be very wary of running a line-of-sight function anytime a sensor's involved. This should work well up till you get to about 100 objects--after that, you'll want to consider what it is you want to achieve because I'm fairly sure what you're asking for isn't what you want. A level created in an array, for example, would completely remove the need for the sensor object and it'd drastically improve performance.

Each class gets its own list of all objects it can see, including itself and its friends. These lists are created dynamically in Line of Sight 6 and you can customize what it sees and what it ignores, though any conditional rules will reduce performance.

I was looking at Schrodinger's example and that one's definitely going to help you! Mine's specifically in response to your first question: "how to make it that instead of making them just see player 1 they see all actives in another group. So the group enemy makes a line of sight for every thing in another group?" If you need to track sets of objects within sets of other objects, this will do that. If all you want is to have line of sight for player characters, Schrodinger's will work great for that.

Wow, really interesting work Snail.
I studied it for a while but I don't get what the non-player items can see,
green square gets its non-seen squares alphaed when hovered,
is this mechanic also replicated in some way for other square classes?

This request by Lukiester has a backward history I was aware of:
Please login to see this link.
so I guessed the simpler task he was in need of X)

I don't have the minimap object sorry,
anyway, you'll have to play with foreach loops again,
to replicate what you're already doing for one player, to each of the other too.

If you can provide an example without this extension I could take a look.

A consideration: maybe you should already decide the chasing logic,
if you want it to be "first seen is chased" or maybe "chase the nearest", or "chase the one who is shooting at me" etc.
(or a combination of various behaviours).
Depending on this, your code may already change consistently so I would address this question before shaping these events.

First of all you must implement the new sightline system provided some posts ago,
I see the LoS are still "single-player" in your example.

So, add your new players, qualify each player as "group.player",
implement the grouped LoS events posted shortly before,
and then you can start debugging-working on the rest.

As a first quick insight,
you've switched from "active" obstacles to backdrops,
thus you must change line 75
from "los overlapping group.obstacles"
to "los overlapping a backdrop"
(which was a good idea, btw XD)

then you can start debugging your AI system

I could take another look later if you're experiencing problems after futher testing