I am making an FPS game and I need for the forward facing vector to hit exactly where the crosshair is aiming.
This is my current blueprint.
It takes all references from the camera position where the players head should be. (as it usually is in FPS games).
When "shooting" the vector it is slightly offset though. (pink dot near crosshair)
Things I have tried:
Increasing distance of vector makes the problem go away but it then becomes inconsistent, which means it's a bad solution to the problem :(
Manually changing axis values, but that was also very inconsistent.
Changing between 3 different nodes of taking rotation from the camera, they all (didn't) work the same way :/
Maybe there is an issue of the values that I am taking, although the starting position of the camera seems to be correct.
Thank you for any insight you may have!
Suggested by user Ruzihm the issue was that the crosshair was off-center. My blueprints were actually okay.
So for anyone looking see if your crosshair is in the center.
Related
I have a sphere with bounciness set to 1
The ball has no drag and uses gravity
It hits a platform, which has bounciness set to 1 and no friction
Yet, the ball bounces higher on every bounce, going to infinity. How is such a thing possible, when I have not given it any extra momentum?
The issue comes from the fact that physics in games happens in discrete frames, and that a moving object will be "inside" another at the frame where there is a collision. The physics engine then has to separate the objects before the next frame, and figure out how much energy to "bounce" with.
One of the steps to do this involves figuring out how much the objects overlap, and that's where this phantom extra energy is comin from. Less error in the overlap equals less error in the energy.
Don't fiddle with the bounciness; those are naive solutions, not to mention they sidestep the issue rather than solving it.
What you should do is to fix what's wrong with your collisions. That can be done a number of ways, the most appropriate/performant of which depends on each specific game:
Increase your physics frame rate (decrease fixed delta time). This reduces overlaps and makes physics frames "smoother". It doesn't really solve phantom energy though; only makes it's causes and effects smaller (maybe so small they become unnoticeable, which is all you need).
Set your sphere's collision detection method to Continuous Dynamic,
and set your ground to static. If you need the sphere to collide with
other stuff, those other stuff present similar issues, and those need
to be non-static, set their rigidbodies' collision detection method
to Continuous. (This is the method I most often find to be the best, but I've had projects where others were better for various reasons)
Increase your Default Solver Velocity Iterations
Change your solver type to Temporal Gauss Seidel
I have had a similar issue with javascript/html/css canvas animations. I have no explanation for this. Use a number like 0.99999 or 0.969399 and that should do the trick. I do get what you mean though it's weird. Just get close to 1. That's all I can say. I hope this helps anyway.
I have been using Unity for a while and still Im not sure about some things, I know there are like 5 different ways to move our character (not using prefabs like for 1st or 3rd person controller I mean just code from scratch) so far for moving a character on a terrain I think setting the speed of the rigidbody works overal for me, just setting the x and leaving the y component as what it was before assigning that, so that gravity effect is kept, overal it works, I manage to collide with wall and other objects, manage to go on terrain and could add jump later in same fashion, but the trouble I find is that my character flies when it steps over any small object like a stone on ground, if he goes over it he starts flying, not a big distance but definetly looks like walking on the moon maybe, also I see that if I have a bridge that is lower in the middle part of it (like U shape) well the character goes like flying from the begining almost until the middle or so, as said works like being on the moon, however gravity seems ok on other objects, I know I can change the gravity value to be higher but Im affraid I could be breaking all that so my question is, is there a better way to move a character on ground that will work better without changing the gravity value? I guess that it can work right without affecting this value, I used other method to change velocity and adding a certain value to the y component but again I see it not right as an apparent correct value for small stones and small objects makes it hard to go over slopes too, any help is greatly welcome =).
I'm currently trying to create a 2D plane game (a bit Retry like), and I just discovered an annoying
problem : the plane motion has a lot of jitters (didn't saw it earlier because I didn't zoom enough to see it).
I'm using a ConstantForce2D on the plane to move, and the arrow keys (in FixedUpdate) to rotate the object. I tried change Interpolate mode to "interpolate" and "extrapolate", extrapolate is worse, and the first one works only when strictly moving on x axis (jitters when there's a small rotation).
I'm quite stuck on this :/
Has someone found a solution on this problem?
(I wasn't sure if any code was needed)
So, I'm attempting to create a simple dynamic endless terrain using simplex noise.
So far I've got the noise working just fine - however I am having issues with the terrain having discontinuities at the edges. At first I thought this was due to the fact that I was not calling SetNeighbors on the Terrain objects, but adding this did not seem to yield any improvement.
terrain.GetComponent<Terrain>().SetNeighbors(left, top, right, bottom);
This problem seems to be caused by the slight differences in height between each terrain position - but making these set the same will effect the terrain quality (will reduce how jagged the terrain can be in certain cases) and generally seems inelegant. I've been going through the unity docs trying to find how to address this, but have yet to find anything.
Is there something I'm missing? Or is my only option to fiddle the heights on one of the sides to match the other?
Thanks for reading, appreciated as always.
Terrain image for reference
A couple things-
First, make sure you're setting SetNeighbors() on ALL the terrain objects, not just one.
Secondly, if the terrain don't match up exactly, it either means that the terrains aren't calculating their data quite correctly, or there's some floating point error going on. However, I have a suspicion that it's the first one, given that manually changing the points affects the quality. Make sure you know that terrains have n^2 + 1 points, and also make sure that the point to query from your simplex function with is calculated in world space.
If you can't figure it out, post your code and I'll take a look.
Also, your terrain might look better if you used octaved (a.k.a factal) noise on your Simplex noise function, depending on what you're looking for.
Cheers!
I got a field in unity3d that has some depressions in it (like small holes). The field's slope always leads towards the nearest depression.
A sphere is dropped at random somewhere in the field, rolls around a bit until it stops in one of the depressions.
The problem is, this is taking too long. It could roll around for 5-10 seconds until it stops. I'd like to stop faster.
Any ideas how I can achieve this?
Edit: The main issue is when the ball is next to the depression, but it has speed that is 90 degrees from the hole, then it starts going in circles and takes a while to stop.
Ok, after getting some advice in the comments, and experimenting, this is the way I solved it:
Apply a small measure of strength towards the depression
If the current velocity is more than 30 degrees away from the center of the depression, slow the ball (apply strength in the opposite direction of the velocity)
IF the ball gets very near the center of the depression, stop it and place it in the center
Thanks for all the tips. If anyone comes up with a better way, I'm still open to suggestions.