Download

About Characters....

It has been quite awhile now that I’ve been trying to make a networked game. I understand the character class has the Character Movement Component which is considered to be fully working, etc. However, what if you want to make characters which don’t use a capsule collision? What if you don’t want to use a skeletal mesh? Well, you can’t. Characters need to have skeletal meshes and use it’s capsule component. Even tho you can override them, it is sometimes, not a good option. As my networked game uses spaceships with complex collision for projectiles, it isn’t a good option to use the Character, so I’ve tried making a pawn with Floating Pawn Movement. Character Movement component does support flying, however, you’re still tied to that terrible collision capsule and skeletal mesh. Unfortunately, the Floating Pawn Movement Component is incomplete, I am unable to replicate movement as the Character Movement does. So, what about making Character Movement a little bit less static? Let people use it in a bunch of different blueprints, being a pawn or a character. Binding it to only characters restrain your creativity.

I understand I could only ignore the skeletal mesh and add a static mesh component, however, what should I do with the capsule? Even tho I disable it’s collision, it will still be loaded, initialized and ticked on the game (same for skeletal mesh). If you have a lot of ships (in my case) in heavy battle, firing a lot of projectiles into each other, those extra ticks might be a lot for your computer to handle, causing severe performance issues.

Thanks for reading,
Alanzote.

For spaceships, ever tried meshes with collision already setup in SM editor instead, with enable-gravity unticked?
Focus on use complex as simple etc. The character type isn’t intended for spaceship type applications afaik / imo.
Overall agree, the docs are bad, especially in this regard. So many ways to do things, but no clear best practice…

For spaceships, ever tried meshes with collision already setup in SM-Editor, with enable-gravity unticked instead?
Focus on use complex as simple etc. The character type isn’t intended for spaceship type applications afaik / imo.
The docs are bad at explanations, especially in this regard. So many ways to do things, but no clear best-practice…

I am not actually complaining about the collision mesh, sorry if my text made you misunderstand. What I mean is that the Character Movement component, that contains all networking code working, is only available for characters, so, it can’t be used on a pawn.

What makes Epic so sure that people won’t need to use the character movement component on a pawn? What makes them so sure that you want to make humanoid characters? I understand that a humanoid character preset can save you a great deal of time, but not everyone wants a humanoid character.

In cases like this, programmer build its own “Character” class;
I’ve extended from Pawn class quite a few times when there’s no reason to use the builtin Character feature.

I am currently extending from the Pawn class, building my own, however, the movement component “Floating Pawn” is broken in the network, that’s why I request that the Character Movement Component to be also available for normal Pawns.

Writing your own movement component isn’t that hard either, provided you could use C++ and are capable to find Character Movement Component in code and port necessary parts from there to your own movement component. And it’s way more productive than waiting for Epic to implement it and may even give you extra performance since you will not use half the features from Epic implementation.

The lack of a predicted Pawn Movement Component has been discussed before but I don’t think Epic will do anything that is not AR/VR/Enterprise related from this point on. I have hacked the CMC to use a Pawn instead of a Character but reducing 10000 lines to 2500 was not easy and it’s still a hack. TheJamsh has made a good physx supported component, check out the repo at UE4-Networked-PhysX-Component

:frowning: Sadly true, I’m 1000% sure of it now…

Interesting read from Jan 2017. Tim Sweeney seems confident that VR is at least a decade away from hitting the mainstream.
He also believes ‘VR’ is the real deal versus ‘AR’ which he sees as a fad. So what’s with the priority setting on AR / VR today?
Is he pushing this for Enterprise? Trying to get out ahead of the curve? Seems like an unpredictable call that’s a long time away…

:frowning: Agree, I’m 1000% sure of it now…

Interesting read from Jan 2017… Tim Sweeney seems confident that VR is at least a decade away from hitting the mainstream.
He also believes ‘VR’ is the real deal versus ‘AR’ which he sees as a fad… So what’s with the priority setting on AR / VR today?
Is he pushing this for Enterprise? Trying to get out ahead of the curve? Seems like an unpredictable call that’s a long time away…

Come on, how is this related to work of gameplay programmers?
And could you explain how recent features like brand new clothing tools, physics asset editor, audio engine are implemented because of “AR/VR/Enterprise”? :wink:
For me it’s look like most of the systems and changes are useful for many different kinds of games.

Sorry, but saying “it’s because XR/Enterprise” in the thread of pawn component is simply annoying, guys :wink:
If you need to find a reason, I’d look at Fortnite/Paragon. These games probably drain all gameplay programmers, especially AI/character related.

No one is pretending the engine is exclusively locked into ‘VR / AR / Enterprise’, but it is steering the ship.
Even character movement related fixes that Epic agree with, go head-to-head with new VR / AR features…