Collision tracing?

[Thalassicus]

I'd like to do a very simple task in a script: place an object in front of the player on the floor, like with the editor's F key.

 

Basically I need a collision trace (plotting a line and detecting if/when collision occurs). I've found at least one built-in function that does a trace, GetLOS, but the return value isn't useful. Is tracing exposed in any other way outside the game's c++, that could be used for the above task?

[DavidBudreck]

Depending on how you are going to use this, it can be very easy, or a complete pain.

 

Easy first: The command "PlaceAtMe" creates a new object and can be controlled where it appears relative to the player. There are, of curse some considerations. Read this article http://cs.elderscrolls.com/constwiki/index...fulltext=Search

 

 

If you intend to move a persistant object, or something you don't want to keep creating new every time, as this could cause game bloat, then you need to triangulate the position. This is way beond my math skills, but someone else has done the math. I'm not going to post it here because, as I said, it's not mine. It originally came from a mod that summoned a bed or bedroll, but I can't remember exactly, and don't remember the mod.

 

I found the code by doing searches, so it can't be that hard to find :)

[Thalassicus]

My first thought was also trying PlaceAtMe, yet I discovered it doesn't appear to do any collision detection with geometry objects (architectural statics), only terrain (exterior landmass). I tested this, it placed objects inside of stairs, or over open air. The three bedroll and tent mods on this site use placeatme.

 

OBSE's functions can also be used to move items relative to the player's position, but there's still the problem of detecting collision.

[DavidBudreck]

No, the bedroll and/or bed mod I am referring to does NOT use PlaceAtMe, but calculates the desired position using math. But I unfortunately never intended to publish, and never occurred to me that I might want to reference, so I did not keep the original script.

 

However, you could use PlaceAtMe for the proper XY coordinates, then set your own Z position relative to the player or the object, etc.

 

Simple enough, but of course it is a little tricker than it should be because using Object.MoveTo does not update the visual rendering.

 

Here is another article http://cs.elderscrolls.com/constwiki/index.php/MoveTo

[Vagrant0]

The use of a marker rat as described in

http://cs.elderscrolls.com/constwiki/index...Teleport_Recall

 

can do some limited collision checks since the creature is always moved to the nearest pathnode, but this is not always practical.

[Thalassicus]

[...] calculates the desired position using math. But I unfortunately never intended to publish, and never occurred to me that I might want to reference, so I did not keep the original script.

 

However, you could use PlaceAtMe for the proper XY coordinates, then set your own Z position relative to the player or the object, etc.

 

I'm not sure I'm understanding you right, or maybe I'm not wording this correctly...

 

Calculating a point in space relative to the player isn't the problem; obse has functions to convert a spherical coordinate (distance, azimuth, inclination) to cartesian (xyz), so it doesn't matter whether I use placeatme or another of the 4 set position functions.

 

The problem is that whether moveto, placeatme, setpos, or positioncell is used, none check whether the target point is going through another object, hovering high in the air, in a wall or floor, etc, so can't be used to determine where the ground is. From my testing, I found placeatme only alters azimuth (xy plane angle), but leaves inclination at 0, so only works on flat spaces or exterior object-free terrain. If the player is facing a stairway or ramp, for example, the object appears within the stairs and falls through the world.

 

Dropping an actor marker that'll snap to the nearest pathnode isn't a bad idea, I'll try that if more precise options won't work. One problem with that is many places in the world have missing or poorly built pathgrids, and exterior auto-generated pathgrids are spaced out very far (I think 512 units).

 

From further research and experimentation I've found at least these three things (outside the physics engine itself) that run a collision trace: GetLOS script function, the CS's F key, and one more I've realized: pulling an item from inventory by holding the mouse down. I'm not sure how any of them might be useful, though. If GetLOS returned the point the collision trace failed, rather than a boolean value indicating failure, it would work... but no such luck, which is why I'm trying to find a workaround. Another possibility is dropping an actor from the air and waiting for IsInAir to return 0, but in average circumstances that's at least a 3 second delay, more if looking downhill, so it doesn't really work.

[DavidBudreck]

I meant that I did not save the original script and cannot remember exactly where I go it. However, the script I was referring to would not work anyway, because it places objects in relation to the player regardless of whether that placement puts it in walls or in the ground (but it is very handy for summoning chests).

 

I'm sorry; I did not understand what you were asking.

[Thalassicus]

It's ok, I think I didn't word it very well at first.

[QQuix]

GetLOS does not work for what you need.

It does work for detecting collision on most objects, but not for ground (it only returns false - no LOS - one or two feet below ground). If you are interested in details, I released a mod just for this demonstration - check the file QQuix Test Environment - GetLOS V1

 

The best way I have found, so far, to detect ground in a specific spot is dropping an actor and check when it stops falling, but it may take a second or more, as you already said. I used this technique to position the crop on the ground in QQuix Conceptual - Realistic Farming V1a (or YouTube:

)

 

The second best, is using MoveTo on an actor. An Vagrant daid, MoveTo snaps the actor on the nearest path grid, which may or may not be where you want it.

 

Either way, when the actor (I usually use a customized dog, scaled to 0.01) is in position, you can move your object to it.

 

Nothing better than that, I am afraid.

[Thalassicus]

Ah drat. I'd just spent quite a few hours working on an algorithm to run a loop of small GetLOS tests outward and downward from the player's eyes. I guess I should have tested if the function actually worked as advertised first. :rolleyes:

 

Now that you mention it though, that makes sense - many games ignore terrain for los.

 

For a dummy marker actor, have you done any testing with atypical nifs that aren't normally actors, and what are the ramifications of that? Such as non-physics-enabled nifs and nifs that are invisible ingame.

 

I think a drop time will be ok, as this is for a spell with several seconds' casting time anyways, so special effects will be playing to pass the time. Something we take for granted in the editor is certainly difficult to reproduce ingame! (although, F does tend to crash the editor from time to time...)