[Line of Sight] LoS between objects in same family

Hey, so I've looked up a bunch of threads online (most of which were old) but could not find something to solve this issue of mine. Take a look:

In short, I need to test for line of sight between an object in the "Fighter" family (e.g. a fighter in a fighting game) to another object in the "Fighter" family... but then the code "Fighter Type =/= Fighter.Type" is supposed to represent checking if the Fighter whose line of sight I am checking (codename "Bird") is the same type as the Fighter that was spotted--for example, if they are both Player, then the events won't do anything, but if one is Player and one is Enemy, then it should proceed with the next action.

Solutions that won't work:

• individual objects - this defeats the entire purpose of having families. I originally referenced the "Bird" object in the Fighter family manually, but this causes its own issues in the code, and is also inefficient, because then I have to manually attach line of sight behaviors for each enemy, and then write separate events for each as well (rather than writing a system for everything where I only need to specify LoS values and what to do when line of sight is detected).

• what you see here - basically, the fighter being selected from the line of sight is different from the fighter checking the line of sight, but there's no apparent way for me to distinguish the two, and I'm not sure how C2 is coded to handle such things. (Similar question: what if two objects in the same family collide with each other? How do you pick each specific instance?)

I'm not looking for exact code, but any tips/suggestions would help.

The hacky solution would be to check against positions because I'm not actually using any instance variables on the "seen" fighter, but then I would need a for each loop to record the X and Y coordinates of every "player" fighter (usually 1, mind, but still) and then check line of sight against each of those... it might work, but it'd be less than pretty IMO, and I'd like to learn how I should approach this kind of problem anyway.

Thanks~

It's hard to say. You haven't said what the complete mechanic is supposed to do.

I can tell you that the for each is probably not needed, and that it will definitely cause a slow down with a lot of instances.

I can tell you why the presented code does not work as you expect.

The Picklist made in event 119 contains 1 object.

The 'for each' does not matter, picking wise. It does logical wise.

So, it iterates trough each member of the family. When that member of the family meets the two conditions. It picks that member. If not, the picklist for that family will be empty.

With 1 object in the picklist, the condition is true. It wil run its sub conditions.

With zero objects in the list, the condition is false, and wil not run its sub events.

So, if it runs its subevents, it has 1 object in the picklist, for the following subevents that is the 'previous picked list'.

Now. Event 120 starts from that 'previous picked list'. Containing 1 object.

It will not check those objects that are not in that picklist, they are excluded by event 119.

Hence. It can only check LOS between that 1 picked object and itself.

Here is 1 of the many possible solutions.

Notice that the instance variables and behaviors are not present in the second family,

It further shows you picklists, and how they work.

https://drive.google.com/open?id=0B1SSu ... 2RfUnNZS3c

99Instances2Go haha sorry, I knew that code would not work, I just wanted to illustrate the logical conundrum, since I came to the same conclusion that you did... but did not have a solution besides my hacky one.

As for your solution, thanks a lot, it looks cool... but it does kind of defeat the premise of the problem, which as the topic states, is that they are in the same family, not different ones. I could arbitrarily create another family, but it feels more like avoiding the problem. Still, it's basically a solution, so thanks.

I have a problem with the logic of the assumption.

Say, the goal is to minimise lines of code.

Starting from 1 object. Addressing is no problem.

Need many, use instances.

Need many objects and there instances, use a family.

Next logical step would be a group containing 2 family's. Cant have a group of family's, but can use 2 family's.

It's hard to say. You haven't said what the complete mechanic is supposed to do.

I can tell you that the for each is probably not needed, and that it will definitely cause a slow down with a lot of instances.

btw, didn't mean to ignore you earlier, just kinda slipped my mind

the complete mechanic is irrelevant IMO since the problem is only "how to detect line of sight between two objects in the same family based on instance variables", not "what to do once line of sight has been detected"

and the for each is needed logically as mentioned (but not picking-wise since C2 does that already), and generally there won't be more than 5 instances of a "Fighter" object at once so I don't think scaling is an issue: even at 10 instances it should be fine, and the code and other such things are generally optimized throughout.

I have a problem with the logic of the assumption.

Say, the goal is to minimise lines of code.

Starting from 1 object. Addressing is no problem.

Need many, use instances.

Need many objects and there instances, use a family.

Next logical step would be a group containing 2 family's. Cant have a group of family's, but can use 2 family's.

unfortunately I did not understand the last sentence. what do you mean by a "group"? and what is the "problem" that you are trying to solve as you see it?