Well I think the main thing is that you need to set the mesh to replicate on dedicated by setting a boolean flag. Then if you Add Impulse or Force to the root component then it replicates better. I have yet to try it any other way, but it seems to work decently enough for us.
I just tried using the replication on a StaticMeshActor with physics and I must admit - it looked really good! I’ll scrap my current code and see how I go using the UE4 movement replication on some other objects.
Definitely my bad on that one, can’t blame Epic.
Ok, time for another update. I’ve re-written my custom replication code to use Epics code, and so far everything on that front is going well.
The only issue I ran into which stumped me for a while was that I have forces on the ship to make it stay upright, and also to lock it to a Z plane. The problem was I kept getting this unstable wobble. I figured it was due to my force being too high, or my damping too low, so I tried all sorts of alternatives and couldn’t get it to work. Then I figured, ok, something isn’t working, I’ll try a physics constraint.
I spent an hour working on the physics constraint, but no matter what I tried it was locked to the Z plane it initially spawned on. I tried linear drives, velocity drives, targets, everything. After an hour I gave up and went back to my original code.
Turns out my issue was networking - the local player movement forces were called on the server and replicated back, but I’d also unfortunately included the local locking forces in that call to the server, so I was getting a delayed correction causing the oscillation. Removing that fixed my original issues.
Again documentation would have helped a lot here. The PhysicsConstraintComponent I found to be poorly documented, so it cost me more time trying to reverse-engineer everything, and when I did I still couldn’t get it it to work. Sure I could post on the forum or answerhub, but if I have some core component that needs to be completed before I move on, what do I do in the meantime?
I think that people can easily get into this cycle where they try something obvious (which may in fact be correct) in UE4, and then not be able to get it to work due to a lack of documentation or a bug. So they try something more exotic and complex, and end up increasingly lost and frustrated, and wondering why they didn’t listen to their parents and become an accountant. This issue turned out to be my fault, but trying to resolve it was much slower and more frustrating that it needed to be.
Well this one has me stumped. I have asteroids in the world that when they collide with a certain actor they get destroyed via:
Asteroid->Destroy();
Works great! Only problem is, I have a totally separate actor, that is not connected to the asteroid in any way, that all of a sudden starts falling through the world when the asteroid is destroyed. It just plummets down the Z axis to infinity (and beyond!). If I comment out the above line, no issues at all, everything works fine.
Has anyone seen anything like this before? It just seems completely illogical, but unlike other UE4 issues I’ve come up against, I have no choice but to go straight through this block, rather than around it.
My right eye has started to twitch, and I’m sure I had more hair before I started this project.
More time wasted on odd behaviour. I thought the object was going to sleep, and noticed that if I didn’t delete the asteroid on the server, then if I kept it moving it wouldn’t fall away. I’ve tried setting the physx directly (no option of this in UE4)
MiningActiveComponent->BodyInstance.GetPxRigidDynamic()->setSleepThreshold(.0f);
StaticMeshComponent->BodyInstance.GetPxRigidDynamic()->setSleepThreshold(.0f);
I tried adding a force to the component as well. That seemed to work if I didn’t delete the asteroid. However even with this hack once I delete the asteroid I still get this component falling away out of the level.
And again I find myself in the situation where something just doesn’t work as expected. There is minimal documentation to help me solve the problem on my own, so I end up getting into more and more exotic possible explanations - is it falling asleep? Is the code I’ve written to try and keep it awake correct or incorrect? Is PhysX just disregarding everything? Maybe it’s being garbage collected? Could there be a bug in UE4?
The only solution I can think of is to keep destroying and respawning the component on a set timer to try and prevent this.
Update: I changed the collision on this component to BlockAll - and it now falls to the ground and bounces around. It seems that my physics settings on just this single component are being reset when I call Destroy() on another completely different actor.
I found out I was attaching the mesh that keeps dropping away to the player ship with weld = true. Removing that seems to have solved my issue. I still have no idea why one actor being destroyed would affect a component on another actor so randomly.
Now I’m trying to use the Physics constraint to attach one StaticMesh to another on my ship, but they are flexing about like they are made of rubber, rather than being rigid.
Draw the root component (RootComponent->bHiddenInGame = false; (I think)) and observe what happens to it when the objects fall down through the world. Also in your case I would turn off gravity and handle it yourself. You can even test the lack of gravity from the World Details panel (I think). The issue you are having is probably the root component is stable but the pieces/those simulating physics are still under the influence of the world gravity setting. I’ve had similar issues. If none of those help you can also enable the bUseCCD boolean and you may have to check that box on the Physics Asset itself as well (I’ve had to do it in both cases before to get it to work).
Well that was the odd thing, I did have gravity disabled, and it all worked fine. It was just for whatever reason when that actor was destroyed it messed up the physics on another object - gravity was re-enabled and it was no longer welded.
Sounds like a bug. I would try to replicate it, then minimize your project, and then file a bug report and post that project up for them to investigate. Or fix the code yourself and do a pull request. Which version of the engine are you using? If it is not 4.8+ then try that first as I know for a fact there were mutex locking issues in 4.7.6.
Hi
So I am in the same boat. Not sure to proceed with ue4 over unity. Out of curiosity why did you go for ue4 over unity?
I went for UE4 because it didn’t have a high up front cost, it gave access to the source code, and from the demos it seems capable of some truly amazing things. To be honest though, given it’s taken me a month to do some really basic things, that I think I could do in a day in Unity, I’m honestly thinking of switching over, if not just to see the comparison in productivity. I’ll push on though for now, maybe things will improve?
Franktech - Interesting suggestion about getting paid help… I wonder if that’s how the larger developers managed to get things done? I’m a hobbyist so it’s that sort of thing is not really an option, but it does explain a few things.
After several weeks tinkering about with attaching meshes that simulate physics together I’ve come to the conclusion that it’s not possible to do without modifying the engine. Here’s the result of my experiments:
** 1. Straight parenting (ie, AttachParent = MyMesh)**
- Produces a nice rigid attachment
- Doesn’t work if you simulate physics, which means you can’t get Hit events
- If the object collides with a physics object, the other object goes flying (ie, mass is infinite).
- Seems reliable
- Replicates well
** 2. Physics Constraint**
- Allows physics to work, so you can get Hit events
- Often not rigid, so you get wobbles. Can be sensitive to mass scaling
- Seems to provide good physics interaction (ie, other objects don’t go flying)
- I’ve had issues with replication becoming excessively jittery
** 3. Welding**
- Produces a rigid attachment
- Allows physics to work, although there are issues (see below), and it seems experimental (? new in 4.7)
- Mass and center of mass move, seemingly independent of the mass of the attached object. This can be corrected via direct PhysX calls only.
- Different collision settings on different components like Overlap or Block don’t seem to work, at least not for me.
- It produced a bug where deleting Actor B caused a welded component on Actor A to detach and have it’s physics reset. The Actors are not related in any way, with no obvious references to each other.
- Replicates well
- Not sure how it works with skeletal meshes and other more dynamic content
** 4. Disabling forces on collisions but still generating Hit events**
- Needs heavy modification of the engine physics
- You need to write all of your own Force/Impulse code
- Kind of defeats the purpose of having physics in the first place
I’ve decided to go with option 1, disable blocking, and put a single physics capsule/ mesh around the pawn for the collisions. Not ideal but should at least work.