Re: Direction comparisons
So are you asking how to see if a player is withing the fishie's view? What I would do is have some invisible object always in front of the fishie, or have the fishies always shooting invisible objects, creating an invisible beam sort of.
Or, if you want it to be if the person is close to the fish, just make an invisible circle whatever size you need it and have it always at the position of the fish.
Re: Direction comparisons
Well to do this, I wouldn't recommend using the built in directions, rather angles. But if you must, you can start a loop to create a spray of detectors from each fish separately in the direction area they are facing to test if the detectors overlap the player. If they do it means they are in the fish's view. If you need it also to be within a certain distance, you can destroy the detectors after a period of time or distance.
Re: Direction comparisons
Thanks for the suggestions :)
I don't think I was quite clear enough in my post - basically, all I need to do is find out if the player is within a certain focal range of the fish (for instance, if the fish is looking at direction 16, and his focal view is 8 degrees each side, then the direction to the player must be between 24 and 8).
I don't need to worry about testing for obstacles, since I already have a system to do that. What this is basically doing (or will do) is reduce the number of fishies that I scan.
So for instance if 12 fishies are onscreen, but only 3 are facing the player's direction, only those 3 need to be tested for obstacles in their line of sight.
But anyway, I think I've got a fair idea how to do it:
Focal View = 7 units either side
Fish's Direction = 16
a = 16 - 7 = 9
b = 16 + 7 = 23
Fish's direction is GREATER THAN the lower of the two values, therefore player's direction must be >= 9 or <= 23.
----
Fish's Direction = 4
a = 4 - 7 = -3 = 32 - 3 = 29 //Because directions can't be minuses
b = 4 + 7 = 11
Fish's direction is LOW THAN the lower of the two values, therefore player's direction must be >= 29 or <= 11.
I think that'll work, now just gotta convert it to forumla and events. :) Thanks anyway for your help!! :D
Re: Direction comparisons
Doh, doesn't work.
I'll have to leave it for now. How about using angles? Any suggestions in that situation?
Re: Direction comparisons
If you give me exact details on what you are trying to do, I can hopefully make an example for you to show how I would do it.
Re: Direction comparisons
Thanks, I'll have a go. This is what I want to achieve:
If we forget about obstacles for a minute, a fish can see his enemies so long as they're within 160° of his own angle. It's a sidescroller, so basically he can see 80° up and 80° down.
He finds the angle between himself and the player, and checks whether that angle is within his field of view or not. In other words, does the player fall within that 80° up or down.
That's pretty much it.
I can then run a Line of Sight process (which I've already coded) to determine if there's an obstacle blocking the fish's view.
At the moment, because I can't determine which fishies are actually facing the player, the LOS routine runs for them all. So a fish can 'see' you, even if you're behind him.
Re: Direction comparisons
Hopefully this is what you need: http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=80765#Post80765
Re: Direction comparisons
I think this is a simpler solution without any need for extensions:
* Always
- Fish: Set Value A to Dir("Fish")
- Fish: Look in Direction of "Player"
- Fish: Set Value B to Dir("Fish")
- Fish: Set Direction to Value A("Fish")
* Always
- Fish: Set Value A to (Value B("Fish") - Dir("Fish") + 48) mod 32
* Value A of "Fish" > 8
+ Value A of "Fish" < 24
- Do stuff
Edit:
Your example fails if the fish is facing Right and the player is below the fish...
Re: Direction comparisons
The extension isn't really needed anyway for my example, it was just a substitution for the equations. I find that angles are much more exact compared to directions (32 compared to 360). And now with HWA the angles are float, so its even more exact. Yes, the facing right thing is a problem, but it should be relatively simple to find a work around.
Re: Direction comparisons
My code can easily be converted to use angles as well... Just change the +48 mod 32 to +540 mod 360.
Re: Direction comparisons
Thanks for the replies, all :)
Good news! I found my old engine, after much rummaging. It uses 'Immediate IF Object' to make sure it works on multiple objects:
(it uses directions, purely for simplicity. Accuracy isn't needed)
ALWAYS
- Fish: Set "Angle of fish" to 'dir("FISH")'
- Fish: Look in direction of Player
- Fish: Set "Angle to player" to 'dir("FISH")'
- Fish: Set direction to 'Angle of fish("FISH")'
- Fish: Set alterable string "Is Player in Focus" to:
'CompareIntegers$( "Immediate If Object", (pl angle( "FISH" )-(me angle( "FISH" )-16)) mod 32, ">=", 16-Round(range( "FISH" )/2.0), CompareIntegers$( "Immediate If Object", (pl angle( "FISH" )-(me angle( "FISH" )-16)) mod 32, "<=", 16+Round(range( "FISH" )/2.0), "YES", "NO"), "NO")'
...heh, lol. Then you just check if 'Is Player in Focus' reads YES or NO.
The expression boils down to this, in pseudocode:
Code:
//What the vars mean:
pl angle = angle to player;
me angle = angle of fish;
range = range of view;
//The IF statement, which is bizarre but works somehow:
if( (pl angle-(me angle-16)) mod 32 >= 16-Round(range/2.0))
{
if( (pl angle-(me angle-16)) mod 32 <= 16+Round(range/2.0))
{
"YES"
}else{
"NO"
}
}else{
"NO"
}