Is there any way to somehow use the highlighted debug value in a script? Like, um... GetFocusDist() or some global variable name that I can reference in the script? I know that this one is kind of an obscure request, but thanks ahead of time for any assistance anyone is willing to offer.

(This post was last modified: 12-20-2014, 10:44 AM by BonesTheRabbit.)

You could create it, with the new patch you can get where the player or an entity is located.
Using both you can create the function GetFocusDist()
Now, the code you gotta figure it out. It needs testing and time. Let us know how it goes. :]

(12-20-2014, 03:40 PM)Daemian Wrote: You could create it, with the new patch you can get where the player or an entity is located.
Using both you can create the function GetFocusDist()
Now, the code you gotta figure it out. It needs testing and time. Let us know how it goes. :]

GetPlayerPosX(); all return values based upon the origin point of the player entity, but doesn't deal with where the player is looking. The highlighted debug variable returns a combination of that value, and where the player is actually looking. I was hoping to work with this in tandem with the aforementioned function, to calculate how far a player's focus is from an object's center point. Alternatively, if I could somehow return the pitch and yaw of the player's camera, I could work with that as well (In-fact, that would be ideal). Only way I can think of is a really questionable brute force method that I'm worried might be wonky.

Thanks for the suggestion, though.

(This post was last modified: 12-20-2014, 09:31 PM by BonesTheRabbit.)

Remember, there's more than just the GetPlayerPos functions. How about using the StartPlayerLookAt and the look callback? That will be called whenever the player looks at a certain object. How about using that along with GetEntityPos of this object, then doing a calculation of the relation of distance between the player and the object?

I have a rough idea of how it can work, although actually putting it down to script and making it work will require testing and lots of calculations and a clear mind. Good luck.

(12-20-2014, 09:34 PM)Mudbill Wrote: Remember, there's more than just the GetPlayerPos functions. How about using the StartPlayerLookAt and the look callback? That will be called whenever the player looks at a certain object. How about using that along with GetEntityPos of this object, then doing a calculation of the relation of distance between the player and it?

I have a rough idea of how it can work, although actually putting it down to script and making it work will require testing and lots of calculations and a clear mind. Good luck.

Well, to give you a better idea of the functional application, I'm trying to mimic a sort of vertigo effect. The idea is that when the player enters an area, a boolean variable returns true, and starts a function that will adjust the intensity of certain camera effects the more that the player looks down from where he is.

The problem is I'm trying to get a nice fluid transition. Basically, if the player's focus isn't far below the horizon, the effect is almost non-existent, but looking straight down makes things go pretty crazy, with a variable intensity between the two extremes. The only way I can think of doing this well is by having areas that move with the player, and which trigger a function callback whenever the player looks at one of them.

I figured there might be a way to reference the debug variable, because there's no function that allows me to return the pitch or yaw of the player camera, and player position doesn't really care where the player is actually looking. It would be a pretty simple matter of using a trig function to remove the player's positional distance from the value and solely calculate the relative focus of the player for use in the function.

I was just hoping to avoid making the area entities constantly move with the player, especially since it would result in a less smooth effect, as I can't adjust the intensity with a fluid variable such as that generated by the debug value. There's other ways I can think of to brute force it, but they become progressively less elegant.

(This post was last modified: 12-20-2014, 09:46 PM by BonesTheRabbit.)

So let's say the player is going up a spiral staircase and the further up they get, the more intense this effect becomes IF they decide to look down. I'm guessing it should at the same time be more intense depending on how far down they look. Is this what you're after?

I'm sure there are more ways to achieve this effect. If I sit down and try to create it, I think I might be able to, but it would surely take me time. Just remember to be creative. Many things can be fooled into resembling something else.

(12-20-2014, 10:09 PM)Mudbill Wrote: So let's say the player is going up a spiral staircase and the further up they get, the more intense this effect becomes IF they decide to look down. I'm guessing it should at the same time be more intense depending on how far down they look. Is this what you're after?

Yes, that's more or less what I'm experimenting with. Another scenario would be if the player needs to cross a narrow beam between two buildings or to cross a chasm. The difficulty of it would be that the camera effects would become more intense the more the player looked down to ensure they had good positioning.

(This post was last modified: 12-20-2014, 10:43 PM by BonesTheRabbit.)

Hm... Maybe focus distance in itself is not the right tool for this problem. If you think about it, focus distance doesn't give you any information about look-at direction, so, ideally, you should combine it with something that does; for example, since player movement is relatively constrained in the scenarios you are describing, you can use that fact to strategically place script areas below and around the player that you'd then use to control the vertigo effect. In fact, you could probably get away with using script areas alone.

To give you some idea, consider a situation where the player is crossing a narrow bridge across a (effectively) bottomless chasm. The player movement is basically constrained to this bridge, which means that you, as a developer, have a pretty good idea where the player is at any moment during the scene. If you place, say, 3 script areas far below the player, one rather wide, one of medium width, and one narrow, in the center (so, "concentrically"), you can detect intersections with them, and thus infer the look-at angle, and then set the intensity based on that (see the image below).

By carefully taking the environment into consideration, you can place these script areas in a way which avoids the full vertigo effect in case the player is looking at the nearby sections chasm walls, or directly at the bridge, etc. - or alternatively, you can place additional script areas on the walls and the bridge that you'd use to limit the effect.

This is similar to the method I was alluding to. The difference is that it would be four areas, three of which are dynamically positioned using the new X, Y, Z positioning functions. Three nestled concentrically as you mentioned, immediately below the character, and a fourth around the beam itself. When the player enters the beam area, a looping script updates the three other areas to remain below his position, so no matter what it's the correct angle. Upon leaving the area, the loop is interrupted. It's just not as elegant as calculating the value fluidly.

Well, maybe not - but you have to work with what you've got available; that's on the implementation side, though; from the user experience / gameplay perspective, this probably works very well and feels smooth enough, right? If not, you should be able to make it feel smooth by controlling effect transitions themselves from the code?

Anyway, what I was suggesting is to actually construct the areas so that they work in conjunction with the structure of the level, in such a way so that you don't have to move them with the player at all.