Good day everyone. I have a question I’d like to get some feedback on. I am following along on a tutorial and the tutorial version works whereas mine is failing. Of note, the tutorial is done in Unreal 4.27, and I am using Unreal 5.0.2.
Apologies if Actor-Replication is not a proper tag, I don’t know what else to tag this as and it seems to be a requirement that I tag it with something.
Class h
UCLASS()
class SIMPLESHOOTER_API AWeapon : public AActor
My weapon is of type AActor. The example that I am going by is simply passing “this” in for the DamageCauser for TakeDamage and in that tutorial the weapon is “AGun” and is of type “AActor”. The only difference is my version is “AWeapon”.
Casting does not work and as I understand, you cannot cast a child instance to its base parent.
I cannot find any good examples of TakeDamage being used that aren’t blueprints. How do I get the AWeapon instance “this” to compile properly in TakeDamage?
I can get around this by using UGameplayStatics::ApplyDamage but…
I’d like to know why this is not working anymore with TakeDamage
I don’t understand when I should use one over the other.
Resolution was that I had the function it resided in marked as a const function. Removed the const from the function and it works fine. Though if anyone with more knowledge than I could answer why I’d use TakeDamage over ApplyDamage I’d appreciate you greatly.
Well, that’s exactly what the error message said, so I’m glad the compiler could help you
Second, UGameplayStatics::ApplyDamage() is a shallow wrapper on top of AActor::TakeDamage(), that formats the damage values you pass in as a damage event, and calls TakeDamage() for you. If you already have the data in the necessary format, ApplyDamage() isn’t useful. (Well, it also tests for NULL pointers, but hopefully you don’t have a lot of those to damage )
(How did I find this out? Ctrl-Shift-F across the engine source is very fast, and searching for ::ApplyDamage found the instance, and the code is pretty easy to read.)
I’ve been a C# dev since it beta’d in 2000. My last deep foray into C++ was borland in the 90s so I’m learning the compiler and all of the messages it sends me so while I can read C++ easy enough and have over my career had to make edits to existing game engine code and other c++ drivers, writing it fluently is a new skill I’m learning.
The message that it was giving me didn’t make a whole lot of sense; it was after seeing the word const over and over again that I started looking for where that was before it connected with me (the const AWeapon* part - const is still a new concept for me in terms of declaring it and understanding that the function being const apparently means that the this variable inside it is also treated as a const and that that applies to its signature now)
I’m learning more and more that with Unreal you have to learn to deep dive the engine’s source code and figure out how the engine works on your own as opposed to documentation.
Thank you for the response and the summary on ApplyDamage vs TakeDamage.
the function being const apparently means that the this variable inside it is also treated as a const
That’s not quite right. Regular functions cannot be const, but member functions can be const. When member functions are const, the member variables (anything using implicit or explicit “this”) are treated as const, as well as the “this” pointer itself. In general, const correctness does require a bit of care to get right, but in general is quite helpful to avoid mistakes of what should or shouldn’t be changed by “outside users.”
Also, “const” only applies to the thing it’s right next to, any array or pointer or reference qualifier “stops” the constness. So const AWeapon * means “a pointer to an aweapon that’s const” and AWeapon const * means “a pointer to a const aweapon” (which is the same thing) but an AWeapon * const means “a pointer that is const, to an aweapon that is not const.” Also a thing we have to learn to pay attention to!
Obviously, I’m too late here, but since I am…
Take<->Apply damage shouldn’t be ‘versus’. These two work well together. But since the question rises, I think taking COMPONENT-based design in play can answer some doubts. Composition over Inheritance is a useful pathern and in that case separating concerns of Damage-control can be passed on an Actor Component that reacts smartly on same Damage-data. Then ApplyDamage can Interface TakeDamage and one can make a good use of both.
Point is - instead of avoiding these Take and Apply Damage (since you could), rather make good use of them by giving data to Components and let Components take care of what to do with them.
I hope that makes sense and use to you
)