Also, if we put aiming in the tank it’s hard to argue to put movement as a component. At that point the tank class becomes quite large.
I completely agree re the lack of readability, however I feel it’s better to learn to use components almost as a refactor tool first then learn to make them more generic and reusable. Hope that makes sense
Well it’s hard to assess without knowing the end picture. It’s just the fact that right now the components don’t seem general enough to warrant them existing.
Edit: I think it would be great to showcase being able to re-use these components with a different vehicle at the end and maybe make it the final challenge to get same/similar results that you achieved in showcasing it.
The aiming component is ideal for a mortar, so the plan is to make a few AutoMortars ™ to spread around the level.
Looks like you’ll be getting at least one sneaky video today while my weekend guest is out for a dog walk!
And another 2 or 3 today, including fixing the sideways slipping.
One published and a 2nd just processing today, the tanks finally drive nicely.
I’m just watching this YouTube video on Quaternions to make sure it’s a good resource for you… I think it is so far (at 8 mins in)
Haven’t been watching the videos as they were being released due to recent addiction to a certain game but other than the quiz I’m all caught up. Regarding Avoid Boolean Flags, you said something incorrect “it’s ambiguous to the compiler to whether these are intergers or floats”, it’s not, to the compiler they are ints for the same reason I gave here
Thanks Dan, Pokemon Go?
Re that Clamp method, you’re right I guess I’m saying it’s not explicit to us what we’re asking hence using <float>. Having said that I’m uploading a patch now.
A video on fixing aiming using Quaternions coming soon…
Nah, Stardew Valley.
I was thinking of getting that for us to play as a family, glad you like it.
Quiz problems, these should all be checking against nullptr or NULL(though probably not this one) as null isn’t a thing. Also I don’t see anything wrong with the last option and the correct answer is missing a )
2nd question could do with ThisClass.generated.h or not including it as its sort of misleading.
Must have been late, thanks I’ll review now.
Also disregard what I said about the last option, forgot for a moment that you’re checking for nullptr and returning rather than just checking against it.
No worries, I’m probably going to re-do the last 3 videos, and insert a few after “Avoiding Boolean Flags” in order to tackle aiming and rotations properly.
OK, “Improving Tank Aiming” has replaced “Using FindBetweenVectors()”. See here for the code changes.
The next two will be roughly the same (on tank AI, and ammo display) but I’ll re-record so the videos are consistent.
Not sure why you didn’t just turn on bDrawDebug in the SuggestProjectileVelocity function to showcase the traces the aiming is doing, also this lecture might also have been a good time to remove the GetLookDirection function since all that does is call DeprojectScreenPositionToWorld.
Edit: Also your solution for the aiming only appears to work in one direction, i.e. if you go to look behind you going left before passing directly behind it seems to work, but not going right. So the problem is half solved.
Hi Dan, re the debug line it would be helpful to show it at some stage and here would have been good. My concern is the number of concepts in one video. Having said that I’ll aim to use it shortly as it’s a handy tool, thanks for the nudge.
Re that GetLookDirection() method, it is a little onerous to have a function for one statement but it does provide some self-documentation and the statement spans many lines. I’ll consider removing it in a refactor, thank again.
Re the aiming, I stopped-short of the full-blown solution we’ve prototyped as the concepts are heavier. I still have it up my sleeve if we need it, it’s only a few lines of code. However I can’t reproduce the issue you’re having. Does your code match the commit precisely, not perhaps including some code from the previous version of the video(s)?
If so, could you do me a quick video, or steps to reproduce as I can’t make the aiming misbehave with this simple solution my end. As I said I don’t mind if we do need to go to the fell-blown solution of transforming from world to tank space, but if I can avoid it and keep it this simple I will.
I even got this problem checking out your commit too, so your project should have the same problem.
This code seems to work
if (DeltaRotator.Yaw < -180.f)
{
Turret->Rotate(360.f + DeltaRotator.Yaw);
}
else if (DeltaRotator.Yaw < 180)
{
Turret->Rotate(DeltaRotator.Yaw);
}
else
{
Turret->Rotate(-DeltaRotator.Yaw);
}
Thanks Dan, so I’ve managed to reproduce it my end now. Well-done finding that solution. I’m a bit reluctant to put 2 special cases in as we’re approaching the complexity of the coordinate-transform solution.
The simple introduction of FMath::Abs() works though, basically saying “avoid reflex angles”…
if (FMath::Abs(DeltaRotator.Yaw) < 180)
{
Turret->Rotate(DeltaRotator.Yaw);
}
else
{
Turret->Rotate(-DeltaRotator.Yaw);
}
However, this whole approach only works if the tank isn’t on it’s side…
