Been having a problem with SpawnEmitterAttached. The SetBeamSourcePoint and SetBeamTargetPoint work great it appears, but it’s always one or more frames behind the mesh/socket to which it’s attached. Just as a test, I tried redoing the SetBeamSourcePoint every frame, and that had no effect. When we set up our ground game, we never noticed this, I think because of the slow speed a biped moves in aiming, running etc. In our flight portion, fast ships leave their laser beams quite a ways back at times. Even slow ships show this a little, because the source point is a hair off when you are moving.
The code we are using looks like this, and seems to work fine other than the lag of the start location. Note, I’ve tried every EAttachLocation enum.
BeamParticlePtr->SetBeamSourcePoint(0, BeamStartLocation, 0);
FVector BeamEndLocation=BeamStartLocation + (BeamForward * ((BeamStartLocation + Hit.GetActor()->GetActorLocation()).Size()));
BeamParticlePtr->SetBeamTargetPoint(0, BeamEndLocation, 0);
BTW, in an AnswerHub post, it appears that a couple of people had the same problem in blueprints, but no one responded to that.
I do hope someone sees this and sets me straight on whether or not beam emitters actually do lag as it appears to me, or has a workaround better than the one I chose.
As the space craft moves through space, I take a “PreviousLocation” each frame, which is then used in the next frame to calculate forward of where the beam should have had it’s source position. This is added to the location I put in the SetBeamSourcePoint and offsets it to the correct position for that frame. It looks like this:
BeamSourceOffset=BeamStartLocation + (MyMountedWeapon->FlightPawn->GetActorForwardVector() * ((MyMountedWeapon->FlightPawn->GetActorLocation()-PreviousLocation ).Size()));
In our case, the MyMountedWeapon->FlightPawn is the pawn actually moving through space. PreviousLocation was last frames GetActorLocation() of that pawn. Then instead of using the BeamStartLocation in the SetBeamSourcePoint, I use BeamSourceOffset. This works to place it at the right location forward, but fails on the side to side. If you fly at high speed back and forth, the beam wavers to the side. I will correct that but this is all just hacks. I find it hard to believe that the Engine’s Beam Emitter functionality is offset from current positions you feed it, and I’m still hoping someone will confirm or debunk that assumption. On this, the blueprint programmer did a test yesterday where he hard wired the emitter to the barrel of the weapon, it still lagged at high speed.
Another assumption I’m making that I’d like to confirm or have dispelled, is that SpawnEmitterAttached, when using a template with a Target and Source point, doesn’t actually attach itself in the same manner that say you would attach a mesh to a socket of another mesh. It appears that there is no “attachment” in this sense, it’s more of loose connection solely based on the SetBeam<Source|Target>Point calls. Is that correct?
I’ll continue this monolog since it appears we have a solution. The comments I made about hoping this wasn’t a bug are resolved that; it is a bug and I found two instances where devs stated it was and that a replacement for the emitters would eventually fix it. That was a couple of years ago so it looks like a workaround is valuable. Tick sync between component and actor did not help us though it was listed as a solution by someone.
My son (the modeler and blueprint guy) came up with a better solution than messing around projecting from distance travelled as I was doing above. I converted his blueprint prototype to C++ and aside from some jitter, it works quite well. Here is how we now set the BeamSourcePoint using velocity.
BeamParticlePtr->SetBeamSourcePoint(0,MyMountedWeapon->SumMuzzleOffset+(MyMountedWeapon->FlightPawn->GetTransform().TransformVector(MyMountedWeapon->FlightPawn->GetTransform().InverseTransformVector( MyMountedWeapon->FlightPawn->GetVelocity())/ 30.f)), 0);
If someone needs the blueprint version, I can probably get it from him and post a photo of it.
The SumMuzzleOffset is the world location we actually would have like to have the beam. The additive is how we get it actually be there. The 30 is a magic number which appears to work for the range of speeds our flight pawns travel at. Taking the raw value of GetVelocity() would put the beam source too far in front. I’m not certain why going to relative and back was important, but I’m not arguing since I can get on with something else.
I’m using this same location calculation when I spawn the emitter and in tick for the SetBeamSourcePoint as shown here.
Bottom line, our emitters no longer lag nor project too far in front.
Would love to have the Blueprint solution photo, struggling finding a solution