I’ve been developing a multiplayer game with dedicated servers for about a year now and it became more and more confusing over time. As the C++ noob that I and the rest of my team are, we are trying to get this to work with as little C++ possible. I even thought our dream could become real, when I found this tutorial regarding Steam integration and dedicated servers. I now know, that it’s inevitable as of now to at least have C++ in your project for server support, although it’s not being used for anything else. Then I found this huge thread about this topic, but all I could deduce from that is, that we NEED to use C++ functions such as RegisterServer to make this work (Sidenote: The tutorial I followed worked up to the point where I had my server executable running, it just never registered with steam).
Apart from the steam, we of course have to test things while developing, to see if stuff replicates properly and things like that. But I noticed something recently: When testing multiplayer in the editor with either dedicated or listen server, my shooting system for example works absolutely perfect: bullets are spawned, effects are played etc. But when I packaged the game for the first time and tested it with a listen server ( which isnt intended as an option for the final game, but since we havent been able to get dedicated servers running, we have to take what we can get) I was frustrated to see, that it was bugged as hell: Bullets sometimes wouldnt spawn, hits wouldnt register correctly, fx would sometimes spawn, sometimes not. If the results differ so much, why should I bother to test in editor in the first place? I dont even want to think about, if the development and shipping package builds differ from each other…
So yea, any insight on that is greatly appreciated
All critical functions, such as spawning the bullet are reliable. FXs are not, but that doesnt explain for example why the successfuly spawned bullets dont register hits.
If your bullets are moving fast they may be not getting the overlap. You might want to turn ccd on the projectile physics. Just note this is an expensive request? So machine guns might not be a good idea as opposed to a sniper rifle.
well, most of the guns are using automatic fire, so thats not an option i guess. Is the hit detection as opposed to the overlap detection more accurate?
I believe overlap uses the same sweep to detect as a hit would a fast moving physics object will pass through and object.
Think of the frames the moving not object is going at. If it isn’t a constant detection it might not detect a overlap or collision.
For instances
Bullet is moving 10 units per frame.
You are standing 11 units away.
It checks first frame not overlapping
Then again at 20 units not overlapping
No collision detected. It essentially passes through the object.
If bullets are moving at such a high rate you may want to use a line trace for the hit detection and use the actual physics object for visual only. Or try ccd just know for the life of that object it is basically guaranteeing to check for collision constantly which is more taxing.
Sorry for the late answer, I was away for the last days:
Inoh1del, this sounds plausible, but unlikely. A former coworker has made a very simple set up in his test project, which achieves exactly what I want, but I cant implement it in our project, although I dont think any settings are different. So its definetly possible!
About the teleport example: My bullets velocity doesnt matter, since they get destroyed after collision and damage handling, so I dont really know how this helps me.
Monkey, my latest solution spawns a non replicating bullet bp with a multicast, the server bullet handles damage, since Event AnyDamage is only called on the server. collision should be the same for all, since they all spawn at the same location with the same velocity until they collide. However it still shows weird behaviour such as inconsistency with the impact location. Would it help, if i upload a small project, which contains my coworkers solution? Our own project is rather big unfortunately…
