Talk:GetLOS

--Tegid 11:25, 14 April 2006 (EDT):Line of Site seems to be defined as true based on heading as well as whether there is a clear line between the actors. Is this the case? Is there any way to get a generic LOS IE even if I'm not looking at them, I COULD see them if I wanted to?

The only method I've come up with for that is to place an invisible actor at the player's location and set its viewing angle to match the player's. Not the greatest solution, but it works. Scruggs 10:13, 28 June 2006 (EDT)

Elim Garak: Morrowind CS-Help described this as slow function (which seems most likely as it has to find any potentially blocking stuff on that eye-vector), should we mention that in the article? In MW, the direction of facing was NOT considered!

When called with an actor as the param it is actually a very fast function; LOS is cached by the game so the function just retrieves that cached data. With a non-actor as the param the game appears to calculate LOS on the fly so that could potentially slow things down a bit. Scruggs 09:23, 7 April 2008 (EDT)

So, if the first note is correct and at least one of the parameters must be an actor, then it would always be best to use the actor as the first parameter? Or do you mean both need to be actors for it to be fast?--Haama 00:36, 8 April 2008 (EDT)

that's a very good point. it'd probably be a good rule that if you're going to use this function every frame, it'd be best to use it at the end of the condition. but this is assuming that the script interpreter is optimized enough to stop evaluating conditions after the logic is false. if not, then you can still use multiple if statements.--Snake 18:53, 28 June 2006 (EDT)

Dragoon Wraith TALK 10:25, 29 June 2006 (EDT): I would recommend a note of some kind for the article to that effect. I also use nested IFs when I want to be sure that a condition isn't run as often, rather than using logical operators.

if ( whateverFaster )
  if ( whateverSlower )

rather than

if ( whateverFaster ) && ( whateverSlower )

I do not know that this is necessary, however

Oblivion uses RPN internally, so "( whateverFaster ) && ( whateverSlower )" evaluates as "( whateverFaster ), ( whateverSlower ), &&" - you the second term isn't skipped, unless the Oblivion script interpreter uses some mighty complicated run-time profiling and optimization code, which I kinda doubt ... --Khadir 10:31, 29 June 2006 (EDT)

Dragoon Wraith TALK 10:38, 29 June 2006 (EDT): So if I understand what you're saying, I should do what I mentioned above?

The nested "if ( whateverFaster ) if ( whateverSlower ) ..." stuff? Yes, you should. However, I'd consider this the last optimisation step after your scripts are long done, tested and bug-free. During the development, I wouldn't bother. --Khadir 10:45, 29 June 2006 (EDT)

GetLOS tests

I did a lot of tests with GetLOS as a side effort to determine whether it is a reliable way to determine collision while moving objects around with SetPos. It seems it is kind of reliable, but has a few unusual behaviors:

• NPCs and creatures don’t break the LOS.
• Many times the LOS goes beyond the apparent surface of the objects
• Ground and walls have different kinds of returns
• Tree trunks don’t interfere with LOS above around eye level

• When used more than once per frame, sometimes GetLOS returns true at points far behind an object.

For example, I probed 41 points along a straight line from the player. Every 10 units from 100 to 500.

With the player looking at the ground by his feet:

• probing FROM the player (100, 110, 120,. . ), GetLOS returns false around 150 (which is kind of right).
• probing TOWARDS the player (500,490, 480,. . ), GetLOS returns true at 370.
• When I started from 1000 (toward the player), GetLOS returns true at 870.
• Then I changed the resolution to 20 units, starting from 500, it returned true at 240.
• It is as if, at some point, it ‘gets tired’ and starts returning 0, even when a previous check for the same position returned 1

[EDIT] I uploaded a test mod that shows where GetLOS starts returning False. It covers both single frame and multi frame tests. The mod is here. There is also a demo video here

QQuix 01:21, 5 October 2008 (EDT)

I have just found a most unexpected behavior from GetLOS when called on the player (Player.GetLOS xTarget): it returns different values depending on whether the player is in first or third person view.

It seems it returns true if the target is rendered in the screen, visible by the human player.

Scenario: PC is facing north and there is an NPC behind her/him to the south. In first person view, GetLOS returns false. Turn to third person view and start moving the camera further back. As soon as the NPC shows up on the screen, GetLOS starts returning true. Move the camera closer to the PC and GetLOS starts returning false just after the NPC disappears from the screen. (all of this without ever changing the PC position or heading, of course)

QQuix 12:04, 31 October 2008 (EDT)

Very good to know. I guess I'll add that to the Notes section since you didn't? Not exactly sure what to say about the first test you ran, though.

Dragoon Wraith TALK 13:41, 31 October 2008 (EDT)

You phrased it very well. I added a new finding also. I suppose the first test results don’t belong in the article page. Anyone that has problems with GetLOS will read the talk page anyway (I guess) - QQuix 14:45, 1 November 2008 (EDT)

It's not that they are inappropriate, or that I'm particularly optimistic that people will find it here - it's simply that I'm not sure how to present it on the article. It's an interesting results, but without some kind of conclusion, some confirmation as to the cause, it's really hard to put it in the article, I think.

Dragoon Wraith TALK 17:00, 1 November 2008 (EDT)

Maybe the first one could be moved to the article after being confirmed under different game environments (it seems odd that GetLOS considers NPC and creatures transparent). The others are more like observations and oddities of how the function works. Not much conclusions to take from them. - QQuix 21:45, 1 November 2008 (EDT)

GetLOS Field Of View

I ran some experiments using GetHeadingAngle, and figured out the field of view for LOS is 190 degrees (+/- 95 degrees off the center line), so I added it to the article. It seems to apply to all creatures, npcs, etc., regardless of eye placement, or if they even have eyes. But I haven't tested every scenario. Feel free to edit if I have made any errors.

--saebel 02:26, 10 May 2011 (EDT)