Duke4.net Forums: Little Tijn - 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: 27 I seem to be liked
Junior Members
Active Posts:
39 (0.1 per day)
Most Active In:
Bug reports & "help me" threads (21 posts)
16-April 18
Profile Views:
Last Active:
User is offline Apr 22 2019 09:17 PM

My Information

Age Unknown
Birthday Unknown
Male Male

Contact Information


Posts I've Made

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

    18 April 2019 - 10:15 AM

    View PostStriker, on 17 April 2019 - 10:00 PM, said:

    Just so you know, I've been working hard on refactoring a lot of Duke's startup code, and bits of the C/S netcode to address some major roadblocks to getting this working. I've made some significant headway, but I'm not out of the dark yet.

    Either way, I've eliminated TRAVERSE_CONNECT, and I'm well on the way to getting rid of connectpoint2 (coop spy is the only thing left that uses it, I need to fix this). Player sprites are also spawned and deleted on the fly, auto player color selection behavior has been made more robust, there's no technical limitation on how many players can be supported by EDuke32 now, etc. Now, I need to find out why statnums aren't being synched properly (and possibly other bits of sprite data).

    That is great to hear! I was messing with this, but your solution by eliminating TRAVERSE_CONNECT is really nice. Just a little question about this, will the order of the players in the fragbar not change? My latest idea was to make a linked list out of the players, so that when a player disconnects the order of all the other players is kept in the fragbar (but not the position). Also no need for a array that way. But I see that is covered already :)

    I was a bit busy lately. Hopefully I can spend some time this weekend...

    (Also I'm a simple Magento 2 webshop developer by day, so C++ is quite tricky for me ;))
  2. In Topic: MP—What's broken?

    27 March 2019 - 04:28 AM

    View PostStriker, on 26 March 2019 - 07:42 AM, said:

    Do NOT use G_CollectSpawnPoints on the client, AT ALL. Because this will make the client consider other players as spawn points (It treats all existing APLAYER sprites as spawn points, and this would include active players moving around the map). Send the contents of g_playerSpawnPoints and the value of g_playerSpawnCnt to the clients in the initial snapshot, and put a if(g_netClient) return; at the top of G_CollectSpawnPoints.

    That might be a better idea. My initial idea was that to get all the spawn points in g_playerSpawnPoints calling G_CollectSpawnPoints before getting a snapshot. Then the snapshot will modify the spawn points as needed. Because calling G_CollectSpawnPoints after loading the map but before getting the snapshot, the other players on the server aren't loaded yet and G_CollectSpawnPoints will collect the correct points only from the static map file. This way we do not need to add specific logic for getting the g_playerSpawnPoints contents from the server.

    View PostStriker, on 26 March 2019 - 07:42 AM, said:

    EDuke32-OldMP also has a refactor to that code that I want to bring to mainline, where it can allocate and de-allocate player sprites on the fly, making this a whole lot easier.

    That's interesting! Will definitely check this out. Maybe this can fix the problem we are having now...

    View PostStriker, on 26 March 2019 - 07:42 AM, said:

    Also, about connectpoint2: You should refer to how it works in EDuke32-OldMP, it does properly remove someone from connectpoint2, while properly updating the linkage of the rest of the clients. (It's a linked list, after all)

    Linkage of the other clients? Not quite sure what you mean with that. Another bit of code to study ;). Or do you mean you made it in a linked list instead of the array it is now, (that behaves like a linked list)?

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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.

    That was my idea also. It isn't used for anything anymore. About looping all available players, that TRAVERSE_CONNECT(i) isn't making it easier.

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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.

    I had to with both Co-op and Duke/Grunt Match. I think it happens after getting the latest snapshot from the server.

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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.

    That will be really nice! Send a message already :)

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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).

    Have found references to this scratch pad and wondered where it was used for. Now I know :). I guess there is still something not completely right with it, like when I get many explosions from a single pipebomb for instance.

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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.

    That's going to be a challenge for me. Hopefully the code in Eduke32-oldMP can help in this regard.

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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 use it to store the order of the players. So when players connect and disconnect, that the order in the fragbar, etc. isn't dependent on the player index but in the position in this array. Like in my examples. Because we can have situations where player with index 3 is still in the server while 1 and 2 have left before. When a new client connect, it might get index 1 but should be in the fragbar after player with index 3. The connectpoint2 array stores this order (like [3,1,-1])

    View Postjwaffe, on 26 March 2019 - 04:17 PM, said:

    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

    Something else to borrow from Eduke32-oldMP :)
  3. In Topic: MP—What's broken?

    25 March 2019 - 10:57 PM

    View Postjwaffe, on 25 March 2019 - 04:50 PM, said:

    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!

    That's nice to hear! Thanks!

    My idea with the change of connectpoint2 is that it is a list of currently connected players in order of connect time.
    Maybe a example will explain it:

    At first we have the server started without any player, so the array will be:
    [-1] (the rest of the indexes are not important)

    Then three players connect, and the array looks like this:
    [1, 2, 3 ,-1]

    When the first and second client disconnect the array will be modified to look like:
    [3, -1]

    The frag bar will only show the server player (with ID 0) and the player with index 3 next to each other. All the spots that where used by the other players will be cleared.

    Next a new client connect, we give it the lowest available ID (that is 1) and add it to the array:
    [3, 1, -1]

    Now the frag bar will still be in the same order (0 and 3) and the new player will be in the spot of the previous second client.

    As far as I see, the order does not matter, as long as the IDs are unique.

    The only problem with this I see is that the macro TRAVERSE_CONNECT(i) will loop all the indexes in connectpoint2 by using the player index. The idea I have is that it should loop the indexes in the order set in the array. In the latest example that will be 0, 3, 1.

    One thing I do not understand at the moment is that it looks like my modification does work. But if I read the loop in TRAVERSE_CONNECT(i) it shouldn't work. Or does TRAVERSE_CONNECT(i) loop the array correct? Hmm.. Maybe I should check that i variable with a nice breakpoint :)

    Also, with the change of the connect time I get a nice loading screen for the map, following the message "Waiting for snapshot" and finally the game with the latest snaphot applied. The screen with garbled sprites is no longer. What I noticed is that before this change, the demo's where started and just after that the map get loaded. I think the demo's should not be loaded because we want to connect to the server instead (and by using the command line, we can support multiplayer launchers later on). When a -connect parameter is set, the demo running is skipped, like when using ud.warp_on (but loading the level when we received it from the server) and in the meantime, we should show a nice "waiting for server" screen.

    Only when no parameters are given should the demo's be loaded with the default main menu. In this menu there should be a option to join a running game. (The code for this is already available. Maybe add a temporary -netmenu parameter to enable this menu option for testing purposes. When multiplayer is ready, the parameter can be dropped and the main menu should have the multiplayer option with host and join in it.)

    Another thingy, when I throw a grenade I sometimes get a thousand explosions instead of a single one. (A grenade?! Yes, I test sometimes with NAM, because I'm a bit silly ;)). I was wondering, how does the syncing goes? When a player spawns a item (like grenade, pipebomb etc) how does this get communicated to the other clients?

    What I though is:
    - Client send new actor to server
    - Server add it to list of new actors
    - Server send new actor to other clients but not the client that made the actor
    - Actor is in every game

    Then, who decides the lifetime of the item? In other words, when the actor code is executed on what time? Does the server send ticks of it to every client or does every client execute the code associated with the actor? I guess not because it all needs to be in somewhat the same time. Or is time synchronised somehow? And if a actor spawns something (like a explosion) how is that synced? This is something I could not figure out at the moment. Just like hitting a player etc.
  4. In Topic: MP—What's broken?

    25 March 2019 - 10:14 PM

    View PostStriker, on 25 March 2019 - 07:31 PM, said:

    Spawn positions are initialized at map start. They only time they should ever move, is if they're moved by certain sector types.

    Like in E2M2. It's correct that they do not change in most levels. But if they move (for instance by a moving sector), the latest snapshot from the server will set them correct. Right? So therefore the coordinates collected from G_CollectSpawnPoints are not always the correct ones. Because the snapshot will modify all changed sprites, including the spawn points, they will get set correct when the client connects while a game with modified points is joined. If the are not changed, they will not be in the snapshot and therefore not be changed at all.

    So we use G_CollectSpawnPoints to get the sprites and the start coordinates and later on get and apply the snapshot to modify them when needed.
  5. In Topic: MP—What's broken?

    25 March 2019 - 11:23 AM

    That's explaining the name of the variable. Although I though it was used for that, I couldn't find the reason to store this information.

    About that problem with spawning, I notice that it is likely occuring when loading the snapshot from the server. When I have time, I will check it again.

    Btw, I have a git repository available where my changes are at https://github.com/l...tijn/eduke32-mp

    Also, how should the flow for connecting go? That I think is:
    - When using the command line to connect, store information given in cmdline.cpp
    - Start game as usual till S_ClearSoundLocks()
    - Start connecting to server (should not block, so we can show a nice "Waiting for connect" screen
    - Get the map to load from and load it with G_NewGame(). This will show the loading map screen
    - Call G_CollectSpawnPoints so we get the spawn points for the map
    - Wait for snapshot and apply it to the current map (Also with "Waiting for snapshot" message)
    - Start game with G_EnterLevel()

    Connecting from within the game render will allow us to implement connecting via the menu. It is already there, but not in a working state.

    The snapshot will modify the spawn point positions, like all the other sprites. This is wanted, because some levels have changing spawn points (Like E2M2).

    Is this correct?

    Hope that I can help and not bother you with my questions :)


Little Tijn hasn't added any friends yet.


Little Tijn 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