Progress is starting to slow down but still making my way through it.

I've managed to fix crashes related to damaging the other player or the other player dying/the other player damaging me.

https://gyazo.com/5f49f51effe24e340895de706c4ec659
https://gyazo.com/ca7195ef6809065998b222acabc617c8

I'm able to make the other player fire/shoot as seen above via code with any weapon this was what a majority of the work today went into as well as finding a way to make the player uncrouch after crouching, and I can successfully make the player respawn.

So we're getting close to having everything we need to start synchronizing the data over the network and doing some testing with people online playing vs just controlling the player via local code.

There are still minor issues I want to fix before getting to that point such as:

• I've noticed slowdown when switching to the rocket launcher while the second player was holding it, like actual frame lag/game freeze for a half a second or so... need to determine if this is related to the second player in any way... it's possible there's some game lag in relation to secondary rendering occurring.
• Player death messages and other hud elements such as health and ammo for the other player still appear on the first screen, I have an idea of where to look to resolve this but have not done it yet.
  
• Player hud elements such as health, and pickups are still appearing currently but will be fixed.
• Powerups (Damage increase, power boots, speed increase, health regen, etc) is still not something I've been able to synchronize or determine how they work, there will be de-sync issues with this.
• When the 1st player dies they control every player in the game. I have an idea on why this is happening and just haven't really decided on how to go about fixing it yet.
  Example: https://gyazo.com/839ad45aa3a64bd9a922144bcc233f72
  
  If I can think of anything else I need to add to this list before I think this is ready for any kind of testing I'll be sure to do so, these things are not major issues so hopefully I'm able to fix them within a few hours tomorrow and start working on networking side of things.
  
  EDIT:
  Discovered a new bug...
  
• When there's more than 2 additional players spawned into the game when a player is re-spawned their 'first person' weapon spawns/is visible for some reason.

Now working towards integrating networking and coming back to the rest of the bugs over time.

Progress for tonight:

I was able to confirm I'm able to spawn more than 3 players ( meaning we can play more than 4 man games ).
I was able to disable control to other players and only control my player specifically, meaning we're right on track.

Figure I should probably update this thread since it's been some time since I've made any progress here.


So the last I was working on this I hit a wall attempting to spawn additional players, I managed to solve that and ran into an issue where when spawning the additional player there was hud elements and camera mash between the two players.



If you notice there's two of the little walk-way as well as other things...

I also ended up having some fun with talset throwing a tantrum...
https://gyazo.com/cb2e68619eeab773f8f90b1c8d525a8f


Here's another example of the camera issues:


And I'm happy to say I've managed to find a way to solve this, while it's not solved yet.... I am able to make only the spawned player's camera appear.



Within the same sub routine I've also been able to identify effects (Water overlay, pickups, damage - red screen when taking damage) and how to disable them for specific players meaning I've actually fully accomplished this feat and can now start to synchronize the data between dynamically spawned players.

After a long break I've made some serious progress and I'm pretty happy with myself as of right now.

The next steps I'm going to have to take...

* I need to disable the input from player 1 going into player 2, I haven't determined what's causing that yet but I should be able to figure it out.
* Sounds still play for the spawned player picking things up but this is probably a wont-fix at this time.
* There is no sync or multiplayer functionality currently.
* I cannot force the game into a level yet on startup which I'd like to do so that we can have an external lobby system similar to znandroum or zdaemon.
* I have no way to *destroy* players upon a person leaving currently, we could simply kill them and never re-spawn them but this presents other problems which hopefully I'll be able to overcome.

In the mean time things are progressing quite nicely with this roadblock finally out of the way.

Quote from: PermaNull on May 07, 2016, 06:31:55 PM

Thanks for the input,
I probably don't have much more experience then you do with multiplayer networking and I feel as if protobuf would just make things easier in terms of transferring data I use it in another of my projects and from what I've read on gamedev.net it's actually kind of preferred as its fast and you can store data how ever you'd like.

The other project I'm working on (halo2) does use bitpacking and it's own custom read/write serialization, I've just never gotten too deeply into processing data like that in C/C++.

I've got stinkee on Skype feel free to add me, tddeadlydata
...

Yes, protocol buffers are fast, but I don't feel like they're quite fast enough for an action based game like a FPS. I'm not sure if the networking protocol is already defined for Turok or if you're just rolling your own in the mod, but if you're rolling your own you probably want to send player inputs at no less than 40 times a second to the server and state updates at least 30 times a second. Protocol buffers work pretty well toward serialization of data for use in things such as a small scale rpg MMO where state updates are less frequent but latency doesn't matter so much. Even at 30 state updates a second you're probably going to ultimately have at least 100ms latency for a client to see other player actions just from state interpolation(extrapolation is different but also not a good idea for an fps game) buffering before you even add in player ping.

I know of some great articles for network data serialization, you don't even have to create separate read/write serialization functions just a single "Serialize" function that reads or writes data from/to a bitpacker depending on an IsReading flag, that eliminates hard to track unaligned serialization function bugs, and it doesn't take much time to get running. I can provide you some easy to use classes to use if you like, that way you don't have to spend time setting up protocol buffers or learning a new library.

With this method your data layouts and definition would be represented via a regular ol' struct in your code, no crazy file generation or huge library to deal with.

Google protobuf isn't very hard to implement but I do understand what you're saying,
From the research I've done there's two goals whether it be FPS or MMO.

1) Deliver the data as fast as possible.
2) Deliver as small of chunks of data as possible.

That being said the idea is to calculate only the values which may have changed since the last send before sending the next packet in order to make sure the size of the packet is as small as possible which is why I agree with you on the bit packing, I'm not sure how efficient protobuf is in terms of 'compression' of the data, I just figured it'd be a decent choice considering I'm already familiar with it.

And I'd have to argue that even MMOs tend to send a shit ton of data, sometimes even more then action fps games do.


Also,
Turok itself does not have any networking capabilities this is being done completely from scratch based on data gathered about the players the obvious solution would be finding places in code where events are triggered (animation update, movement update, view angle changes) then build an event handler around those storing the data and sending it periodically based on available data if it's different from the last send.

Quote from: PermaNull on May 02, 2016, 11:47:29 AM

...
One of my next moves will be integrating Google Protocol buffers in order to handle the data exchanges...
With that I should be able to create deltas of the information per player and handle everything in much smaller packets reducing latency overall and increasing the ability to play even if it's in a 'ghetto' state of syncing at the moment

...

Hey, sorry to just pop in unannounced! I have been amassing a lot of curiosity and knowledge toward multiplayer game networking, even going so far as to reverse engineering some client/server games to create my own servers for education. Unfortunately I DON'T have a lot of knowledge reverse-engineering binary files or generally trying to figure out what the game is doing. However, if I could get in contact with you to explain things to me about how the dll works and modifies the game's behavior, I could probably help / contribute to this project in some way, if you're open to that.

Personally I don't see how protocol buffers would give you much benefit, especially not for a first person action game like turok. Protocol buffers might be a little too much luggage for something like this, I feel like a well built udp protocol with standardized read/write serialization through bitpacking seems like it would serve you better, but I don't have much experience with protobuf and you're probably more experienced than I am in this area.

Thanks for the input,
I probably don't have much more experience then you do with multiplayer networking and I feel as if protobuf would just make things easier in terms of transferring data I use it in another of my projects and from what I've read on gamedev.net it's actually kind of preferred as its fast and you can store data how ever you'd like.

The other project I'm working on (halo2) does use bitpacking and it's own custom read/write serialization, I've just never gotten too deeply into processing data like that in C/C++.

I've got stinkee on Skype feel free to add me, tddeadlydata

-----------------

In other news regarding this project specifically I've got some good news about the player spawning I managed to get ahold of my old friend who was working on this project with me and while he was missing the source to the side of the project which would've handled most of the hooks and stuff since he had wrote it in MASM back then.... (I have the C side but it's not really relevant with that version as it just calls the MASM dll).

He still had the DLL is what I'm getting at so, this is awesome because I can reverse engineer this and figure out how the players were spawned in our previous attempt and add it into my new project so I'll actually start making major progress on this again I feel.