Duke4.net Forums: jwaffe - Viewing Profile - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Reputation: 28 I seem to be liked
Junior Members
Active Posts:
6 (0 per day)
Most Active In:
Everything EDuke32 (5 posts)
13-February 16
Profile Views:
Last Active:
User is offline Private

My Information

Age Unknown
Birthday Unknown
Male Male

Contact Information


Posts I've Made

  1. In Topic: MP—What's broken?

    26 March 2019 - 04:17 PM

    Okay, let's see what I can cover from this tonight, I sent you a message on Discord too just so you know who I am on that.


    A question I have, what is stored in g_mostConcurrentPlayers? It looks like it always have the same value as numplayers until someone leaves the server.

    g_mostConcurrentPlayers is kind of a carryover from the p2p code that I kinda wanted to remove for a long time because it makes it really hard to handle players that join late to a game. It might be kept in for CON compatibility or something but its original purpose isn't very helpful for c/s multiplayer. If a player in the middle of the list drops out, you can't just go from 0 to g_maxConcurrentPlayers without hitting some players that aren't there, but in the original p2p code you'd be guaranteed to only hit players that are in the game because all players have to join before the game starts.


    What I try to fix next is checking when a player joins it gets the same player spot as the server. Because I noticed than when a client joins, it always spawns on the same spot as the server player. They are somehow connected while it shouldn't be.

    What game mode are you running the map in? Are there player starts in the map? With the existing code I've had the client show up in odd places (e.g., getting warped directly to where the server player is standing rather than a real spawn, or at some oddball corner of the map), but it doesn't seem to happen every time.

    Really the spawn code needs to be reworked, I had a couple branches where the server sent all clients all of the spawn locations on the map as part of the initial snapshot, I think it might be a good idea for me to add you to my gitlab repo so that I can show you some of my experiments on that; hit me up on Discord.


    Next, when a player disconnects, its player sprite is not removed, only hidden. In P_RemovePlayer() the call to P_QuickKill() only hides it.

    In general clients don't really delete or insert sprites, they just hide them or insert them to a temporary "scratch pad" list that's wiped out when a snapshot is received; the server handles sprite deletions and inserts. This is because the only way the client and server can communicate about sprites is through the sprite index, (e.g., the server and client have to agree on what sprite[343] is so it can be synchronized).

    I think probably the best route to handling players joining midgame would be to preallocate a range of sprite indexes in the sprite list that are reserved for only players (like Quake does), that way there wouldn't be any disagreement between clients and servers as to what sprite belongs to which player (which has been a challenge in the c/s code to sync for quite a long time). That's been easier said than done though, I haven't had much luck in changing the behavior of the startup code to support that.



    I think your function to remove players from the list is a pretty good idea, but I kinda wonder if we even really need the connectpoint2 array anymore. I vaguely remember that at one point a field was added to the player struct that indicated whether the player was connected or not (something other than playerquitflag), maybe we could just iterate up the player indexes and just check to see if the player is connected?

    I really think that field was implemented but I can't seem to find it, I'll have to dig around for that commit

    EDIT: I was mixing up something that got added to oldMP, unfortunately the c/s netcode never had the playerdata_t::connected field, though something like that would probably be worth adding

    (to be continued)
  2. In Topic: MP—What's broken?

    25 March 2019 - 04:50 PM

    Sorry for the late reply, I guess I forgot to click the "watch topic" button, I just noticed this now,

    Feel free to keep posting anything else you find, I'm going through what you wrote but it might take me a bit of time. Thanks for the suggestions!
  3. In Topic: MP—What's broken?

    25 January 2019 - 02:56 PM

    Hi there, I'm 75 AKA Jwaffe,

    Take a look at this post I made a while back it's still pretty much up to date as far as the main issues the c/s netcode is facing right now: https://forums.duke4...988#entry309988, since then my work has been merged into mainline, it's no longer on a private repo.


    What's actually broken? Does the code buggy, or an actually totally broken WIP mess full of //TODOs?

    - The netcode is functional as in you can launch it and play it, but it's not very stable unfortunately
    - The sync code is done in that it can sync pretty much any change in the map except gamevars (I held off on those for now but I have a plan)

    Most of the work left relates to integrating that sync code in with the rest of the engine, right now there are significant parts of the engine that I have trouble converting from p2p to c/s. While the netcode is in net.cpp, other files like premap.cpp could use some work (G_EnterLevel, for example)

    Here are some of the main issues still present:

    - Players joining and leaving mid-game isn't reliable
    - Some sector effectors don't work well yet with the c/s netcode
    - Animation smoothness can be improved in general, there's some sector movements that aren't interpolated that really should be
    - Map transitions don't work most of the time
    - Usermaps don't work correctly, I think this problem's related to the map transition problems (i.e., the player sprite code on startup doesn't quite work right in c/s)
    - The player position sync code is vulnerable to speedhacking


    What would it take for us to get it working?

    - Adjust the startup code / map loading code so that player sprites are allocated in a way that allows midgame joining
    - Investigate some of the SEs and find out special cases where the game should ignore some stuff like t_data values that should be interpolated instead of directly synced

    Also, if there's any volunteers:


    At this point what would really help is:
    - If somebody could help me work with the map loading / startup code because I have had a lot of trouble figuring out how to implement some of the map change / initialization code for the netcode.
    - If somebody who is really knowledgeable with Duke3D (somebody who's worked with the Duke3D source for a long time, or perhaps a really good modder) could go through and find more struct fields that should / shouldn't be synced for certain SEs, picnums, etc.

    I've been trying to fix the startup code / map change code for a while but nothing I've done seems to have worked; I'm hoping that after IM ships somebody who's worked with that part of the code more can help me figure out what I'm doing wrong.
  4. In Topic: How much damage has lack of multiplayer and general IP incompetence caused?

    28 November 2018 - 05:46 PM

    Hi there, I also go by 75. I'd like to take this chance to give a brief status update on the C/S netcode; sorry for not replying earlier, I must have missed this thread. I'm usually on Discord if you want to reach me.

    - It's still being worked on in a private repo, what's on there is significantly better than what's on the mainline SVN, but it still has some major issues that need to be worked out
    - The game array data gets synced over the network (sprites, sectors, walls, actors, etc) but gamevars aren't synced yet, I have a plan for them but I haven't implemented it yet
    - There are some choppy movements and animations in the netcode that need to be smoothed out. I started out with every field of every struct getting synced but I noticed that it's best to just let the client handle some fields over time. NY00123 helped find a bunch of other cases which was really helpful.
    - The current code has issues with players joining mid-game and running maps with more players than spawns. It also has issues with usermaps. These problems have been particularly challenging to fix, I tried a bunch of different fixes for this but they have been hard to integrate into the existing code.
    - Map transitions are buggy, I've also had a hard time fixing these bugs on my own.
    - Terminx and I have talked about merging in what I have right now into mainline, but I want to do a couple things like making sure there are no warnings when building under GCC, and some other cleanup work.
    - Some of the older parts of the netcode (e.g., the player updates) is vulnerable to hackers. I have a plan for this but other issues with handling players make this tricky.

    This is just a reminder, but when the netcode is merged into the SVN, things might still change. I wouldn't recommend starting to make mods on the way it behaves now.

    And less pressing issues,

    - There is a lot of optimization work to be done as far as how much memory the netcode uses and how fast it runs, I would like to play with how often the game creates and sends snapshots to see if I can reduce bandwidth usage, too.
    - There is a lot of testing to do as far as how well it works with very high latency conditions (we're not ready to start testing that yet, though)
    - ... and some other bugs and missing features, I'll go into more detail on that later.

    At this point what would really help is:
    - If somebody could help me work with the map loading / startup code because I have had a lot of trouble figuring out how to implement some of the map change / initialization code for the netcode.
    - If somebody who is really knowledgeable with Duke3D (somebody who's worked with the Duke3D source for a long time, or perhaps a really good modder) could go through and find more struct fields that should / shouldn't be synced for certain SEs, picnums, etc.


    I am willing to contribute. I am a C#, Python, Numpy, Julia, SQL programmer. I dont know C++ but I could learn.

    As somebody who knows C, C++, Python, and C#, I appreciate your enthusiasm but note that Python/C# and C/C++ are very, very different languages and have totally different memory management strategies. Feel free to PM me if you'd like to get involved, though.
  5. In Topic: Coop in both Original Campaign and Custom levels

    06 October 2017 - 07:20 PM

    View PostMaisth, on 06 October 2017 - 06:26 PM, said:

    When i use the command method i spawn under the floor and died and i can't get out, is there anyway to fix this?

    also to play with Dukematcher do i need portforwarding or i can use Hamachi?

    The C/S code is still being worked on, Eduke32-OldMP is probably your best bet for right now. Check out this topic:



jwaffe has no profile comments yet. Why not say hello?

All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Maiden! ;) © 2018 Voidpoint, LLC

Enter your sign in name and password

Sign in options