When bringing a node into view, I don't like how it is travelling and then suddenly stops as it reaches it's moveTo point. What I would like to do is slowly reduce the speed of the node as it approaches it's moveTo point, but after 2 days of contemplating how I would achieve this, I have not figured out a solution (it is most likely very simple).
I have managed to increase and decrease a nodes speed gradually using a timer and moveBy (Not moveTo), but that does not stop the node at a specific point or if I tell it to stop once it reaches a specific point, the speed the node could be small or could be large.
Does anybody have an idea of how I might be able to solve my problem.
You could set the timing mode of your action to EaseOut or EaseInEaseOut (The default is Linear). For example
let moveAction = ...
moveAction.timingMode = .EaseOut
From the SKAction documentation, other options include:
Linear. Specifies linear pacing. Linear pacing causes an animation to occur evenly over its duration.
EaseIn. Specifies ease-in pacing. Ease-in pacing causes the animation to begin slowly and then speed up as it progresses.
EaseOut. Specifies ease-out pacing. Ease-out pacing causes the animation to begin quickly and then slow as it completes.
EaseInEaseOut. Specifies ease-in ease-out pacing. An ease-in ease-out animation begins slowly, accelerates through the middle of
its duration, and then slows again before completing.
Related
I am trying to extinguish the fire particle using Unity water particle. Which is working. But the water particles Splash effect is overflowing. I tried to scale it but it"s not working. So how can I reduce the splash effect?
To stop the water particles from overflowing you can do a combination of two things:
decrease emission rate of particles or the velocity of particles. You find these things under certain modules. Here is the list of modules:
To change the emmission rate, find the particle system in the inspector and go to the emmission module. If not already opened - open it. Adjust the Rate over Time variable to a lower value, you should notice a lot less particles being formed.
Then to change the velocity of the particle system, this one can be change a few ways. And, it depends on how you change it for your water to go upwards. A good place to check is in the Velocity over Lifetime module and you want to decrease the speed modifier or the linear velocity values.
You may also want to check if lowering any velocity values from Limit Velocity over Lifetime, Inherit Velocity, Force over Lifetime solves your issue.
EDIT
To stop emitting particles just set the prediscussed particle emission Rate over Time back to 0. To do this inscript:
GetComponent<ParticleSystem>().emission.rate = 0.0f; // Or a higher number if you want to restart it
Also, when I notice your particle system, you don't have to add burst like I have done so in the examples. Just change the specific variables mentioned.
I'm in the process of learning sprite kit and decided a catapult style game would be a good project to start with.
I am launching a projectile by using physicsBody?.applyImpulse(CGVector(dx: strength * dx, dy: strength * dy)) and this all works fine.
I'm currently trying to predict the trajectory of the projectile. I am doing this by applying the same impulse to a hidden SKNode and plotting the path it takes.
The problem is that the user has to wait until the impulse/physics has finished until they can see the full path. (see image below)
Path Image
(from the image above) I want the green path to either appear instantly or appear a lot faster.
I've tried to adjust the speed of the SKNode but it doesn't seem to have any effect on the simulation (it always runs at the same speed). I've also tried using SKAction.applyImpulse with the speed property being adjusted but it didn't have any effect either.
The only thing that has worked is setting physicsWorld.speed but I don't want to change the speed of the whole physics world, only the hidden trajectory node.
I was wondering if there was a way to run the physics simulation on a specific node instantly, or at least speed it up so it runs quicker?
Thanks in advance.
You can massively increase the gravity, and then factor this increase into the increase in the force used to project your object. This will result in the same arc of flight, but rising and falling much faster.
I have a particle effect for a muzzle flare set up. What I'm currently using is a low numParticlesToEmit to limit the emitter to a short burst, and doing resetSimulation() on the emitter whenever I want to start a new burst of particles.
The problem I'm having is that resetSimulation() removes all particles onscreen, and I often need to create a new burst of particles before the previous particles disappear normally so they get erased early.
Is there a clean way start up the emitter again without erasing the particles already onscreen?
Normally particle systems have a feature missing from SKEmitters: a duration. This controls how long a system emits. I don't see this in SKEmitter, despite being in SCNParticleSystems
Never mind, a work around:
SKEmitters have a numParticlesToEmit property and a particleBirthRate. Combined, these determine how long the particle system emits before shutting down.
Using these as a control of the emission it's possible to create pulses of particles emitted in the way you want for something like a muzzle flash or explosion.
I'm not sure if it remvoes itself when it reaches this limit. If not, you'll have to create a removal function of some sort. Because the way to get your desired effect (multiple muzzle flashes on screen) is to copy() the SKEmitter. This is quite efficient, so don't worry about overhead.
There is a targetNode on SKEmitters that are suppose to move the particles to another node so that when you reset the emitter, the previous particles still stay. Unfortunately, this is still bugged from what I can tell, unless somebody else has figured out how to get it working and I just missed it. Keep this in mind though in case they do ever fix it.
Hi to help future readers, the code that I use to calculate the duration of the emitter is this:
let duration = Double(emitter.numParticlesToEmit) / Double(emitter.particleBirthRate) + Double(emitter.particleLifetime + emitter.particleLifetimeRange/2)
It works perfectly for me
Extension:
extension SKEmitterNode {
var emitterDuration: Double {
return Double(numParticlesToEmit) / Double(particleBirthRate) + Double(particleLifetime + particleLifetimeRange/2)
}
}
i'm writing here cause i really need your help. i've created this script linked on a gameObject light (Directional).
var time : int= 0;
function Update () {
time+=1;
transform.Rotate(time*Time.deltaTime, 0 ,0);
yield WaitForSeconds(0.2);
if (time == 360){
time = 0;
}
}
when i start the game, the object don't rotate and if i remove the line:
yield WaitForSeconds(0.2);
the rotation starts slowly then increses its speed until (every 2 rounds) it returns to 0.
Jerdak is right. Update() is called every frame, and not every second. That way, time reaches 360 very fast. In order to get the elapsed time since last call to Update, use Time.deltaTime. Which basically means when you do transform.Rotate(Time.deltaTime * speed, 0, 0);, it'll rotate according to your speed. So use a speed measure rather than a time measure.
the rotation starts slowly then increses its speed until (every 2
rounds) it returns to 0.
This is expected behaviour. Like I said, you used time instead of speed. You increase the speed (named: time) every 0.2 seconds, thus increasing the rotation speed.
when i start the game, the object don't rotate
I am unsure why this happens but when you wait long enough, you'll see the rotation occuring anyway. It might be happening but very slowly.
Take CABasicAnimation for example. How do you lower the frame rate (overhead)? Animations run smooth, but my touchesMoved method skips a beat. Want to reduce the animation frame rate so touchesMoved is not skipping movements.
You don't have any inherent control over frame rate once you start your CABasicAnimation.
Probably the best way to achieve this would be to create multiple interpolations for a single animation (i.e. if you're moving 50 px down and 50px across, do 2 x 25px each) and induce an artificial sleep in your thread. Not a perfect solution, but will perhaps achieve slightly better results that you're seeing.
Be aware that this technique will have different framerates on different CPUs, and is therefore not generally recommended. Essentially, YMMV.