Page 4 of 4
Re: Facing manipulation
Posted: Sun Jun 23, 2013 5:53 pm
by Norbo
But I don't know why. You see ?
If adding those additional tests help, then the sender is not the same as the vehicle body/turret. For example, if the event is attached to the incoming missile, then even after the vehicle gets removed, the missile's Space will still be non-null, so the sender's space will still be non-null.
Another potential problem is the use of the pair's EntityB property:
Code: Select all
if (pair.EntityB != null && (string)pair.EntityB.Tag == "missile")
There is no guaranteed order for the pair's objects. The missile associated with the event might be related to EntityA, or it might be related to EntityB. By only checking EntityB, some cases will be missed. Consider making use of the 'sender' and 'other' parameters, or testing both EntityA and EntityB.
2/ I think also ( question 2 ), that when I delete a thing in the creatingContact event, bepu have bugs. But it's occure only when the objet is colliding with multiple objets. Why ?
CreatingContact is an 'immediate' event, as opposed to the ContactCreated 'deferred' event. Immediate events run inside engine execution. Further, if multithreading is being used, immediate events will be called from another thread. Busting in during the middle of execution and corrupting the book-keeping with a remove would be bad enough by itself, but doing it from an asynchronous context is a recipe for unpredictable disaster.
If you meant ContactCreated instead of CreatingContact, then I do not have sufficient information to diagnose the issue.
Re: Facing manipulation
Posted: Sun Jun 23, 2013 7:55 pm
by kavatortank
Norbo wrote:
2/ I think also ( question 2 ), that when I delete a thing in the creatingContact event, bepu have bugs. But it's occure only when the objet is colliding with multiple objets. Why ?
CreatingContact is an 'immediate' event, as opposed to the ContactCreated 'deferred' event. Immediate events run inside engine execution. Further, if multithreading is being used, immediate events will be called from another thread. Busting in during the middle of execution and corrupting the book-keeping with a remove would be bad enough by itself, but doing it from an asynchronous context is a recipe for unpredictable disaster.
If you meant ContactCreated instead of CreatingContact, then I do not have sufficient information to diagnose the issue.
Yes but, when I'm using the CreatingContact event, this is perfect, but when there are multiple collision, I have a exception.
Re: Facing manipulation
Posted: Mon Jun 24, 2013 6:22 pm
by Norbo
Performing a Space.Remove (or many other operations) from within the immediate CreatingContact event is unsupported by design and will result in undefined behavior. It may appear to work sometimes, or fail more frequently in certain conditions.
However, even if it appears to work, it is never actually working properly. It may take minutes or hours or days for the inevitable failure to show up, but it will show up, and it will be nasty.
There are very few state-accessing operations that can be safely performed within the context of an immediate event. If you aren't sure if something is safe, assume that it is not. Take measures to ensure safety. For example, instead of removing within the execution of the immediate event, safely (i.e. with appropriate thread synchronization) enqueue the object for later removal.
These complexities are why deferred events (like ContactCreated) exist. Deferred events queue up and then execute at the end of the frame sequentially. With some care, it is acceptable to remove objects and modify state from the deferred context.
Re: Facing manipulation
Posted: Tue Jun 25, 2013 6:23 pm
by kavatortank
Ok.
How can I can take the height of a position in a terrainShape ?
Because the terrainShape have et methode, getposition, but I can only give the x and z, and I want the Y.
Is there are any trick to do it ?
Re: Facing manipulation
Posted: Tue Jun 25, 2013 6:34 pm
by Norbo
The GetPosition function takes the horizontal indices of a vertex and provides the full position, including the post-transform Y value. It is the proper choice if you've got the horizontal indices.
If you do not have the horizontal indices, or if you want to determine the height on a part of the terrain which is not on a vertex, then casting a ray straight at the terrain would work.
Re: Facing manipulation
Posted: Tue Jun 25, 2013 6:37 pm
by kavatortank
I never understood this principle of RayCast, can you develop?
Re: Facing manipulation
Posted: Tue Jun 25, 2013 6:59 pm
by Norbo
A ray cast starts a line somewhere in space, and sends it off in some direction. It searches for intersections with whatever is being ray casted. Should it find something, it outputs information about the hit such as the location, normal, T parameter (the distance along the ray to the hit location in units of the length of the ray direction, such that ray.Origin + T * ray.Direction = hitLocation), and the object.
You can ray cast the entire Space using the Space.RayCast, or you can ray cast individual collidables using functions like Terrain.RayCast.
Re: Facing manipulation
Posted: Tue Jun 25, 2013 10:37 pm
by kavatortank
Thanks.
I'm in a rush, because I have my final presentation of my project in 1 day, so sorry in advance for my impatience
Re: Facing manipulation
Posted: Sun Aug 04, 2013 5:43 pm
by Garold
wow