[Striker]

Drek: Here's a better means of implementation, using the .connected member from the recent OldMP build:

	ifmultiplayer
	ifvarn COOP GM_COOPERATIVE
	{
		setvar SCORE_COUNTER 0
		setvar SCORE_PLAYERINDEX 0
		setvar SCORE_YOFFSET 8
		whilevarvarn SCORE_COUNTER MULTIMODE
		{
			getplayer[SCORE_PLAYERINDEX].connected SCORE_PLAYERCONNECTED
			ifvare SCORE_PLAYERCONNECTED 1 // Is connected
			{
				// Print Background Bar
				myos 267 SCORE_YOFFSET NAMEBAR -127 569
				
				// Get palette
				getplayer[SCORE_PLAYERINDEX].palookup SCORE_PLAYERPAL
				
				// Get and print name
				getpname 500 SCORE_PLAYERINDEX
				minitext 268 SCORE_YOFFSET 500 -127 SCORE_PLAYERPAL
				//screentext 3072 268 SCORE_YOFFSET 65536 0 0 500 -127 SCORE_PLAYERPAL 536 0 3 5 1 1 8192 0 0 xdim ydim 
				
				// Get and print frags
				getplayer[SCORE_PLAYERINDEX].frag SCORE_FRAGS
				getplayer[SCORE_PLAYERINDEX].fraggedself SCORE_SUICIDES
				subvarvar SCORE_FRAGS SCORE_SUICIDES
				redefinequote 500 %d
				qsprintf 500 500 SCORE_FRAGS
				minitext 311 SCORE_YOFFSET 500 -127 SCORE_PLAYERPAL
				//screentext 3072 318 SCORE_YOFFSET 65536 0 0 500 -127 SCORE_PLAYERPAL 536 0 3 5 1 1 8193 0 0 xdim ydim 
				
				// Move y offset down
				addvar SCORE_YOFFSET 6
				addvar SCORE_COUNTER 1
			}
			
			// Move on to the next player
			addvar SCORE_PLAYERINDEX 1
		}
	}

[Hendricks266]

The kind of loop structure Striker uses here with two different iteration variables is mandatory for any loop over all players to work correctly. For modern EDuke32, we could probably add an iterator to the for command (something like "connectedplayers") that does the hard work of this for you.

[Kyanos]

Yeah the loop is way better and .connected lets me get the names straight into the HUD no need to store any info from the synced event game. I got my leaderboard code in it too, now it's 20 lines instead of 100+ I had before lol.

[Striker]

Another release. This one has a ton of fixes. Release notes within: https://gitlab.com/m...oldmp_release_5

[Striker]

Release 6 was put out a couple of days ago, but I forgot to link it here.

So, here it is: https://gitlab.com/m...oldmp_release_6

[Master O]

Hendricks266, on 01 June 2013 - 12:44 PM, said:

EDuke32-OldMP
Cobbled together by Hendricks266
Maintenance by Striker

Download: https://gitlab.com/m...intenance/tags/


This port has one purpose and one purpose only: to provide a usable EDuke32 in online multiplayer in the interim of the completion of the client-server rewrite.

How's that coming along?

[Striker]

Not a whole lot to say yet. It's being worked on though. Still figuring out how to best handle CON in client/server, and a lot of stuff still needs fixing.

[icecoldduke]

Striker, on 15 June 2017 - 02:07 PM, said:

Not a whole lot to say yet. It's being worked on though. Still figuring out how to best handle CON in client/server, and a lot of stuff still needs fixing.

The problem with build is you can't do prediction because you have to assume everything can fucking change and any time. The only two solutions I can think of is to force sync the deltas between sprite/sector/wall arrays which will take a lot of bandwidth or let the game logic run on both client and server, let it modify the sectors and walls, and only sync sprites/player movement from the server. If the game runs out of sync you'll have to update the correct state from the server, which means there would be visible snapping in areas that are out of sync. You would also have to force update con script vars from the server.

[Mark]

Am I on the wrong track in thinking that close to 98 percent of deathmatch maps have static geometry which means way less sector and wall changes to monitor for change? So syncing will be less of an issue?

Ah, never mind. I forgot all about co-op mode for single player maps with all sorts of changing map geo possibly in them.

[Kyanos]

I can say from my experience that elevators are a great source for sync errors. The height speed ratio needs to be stable or divisible evenly if I am explaining it good enough. Anyways, yeah moving sectors have been known to cause lag issues at the best of times.

[TerminX]

icecoldduke, on 15 June 2017 - 02:42 PM, said:

The problem with build is you can't do prediction because you have to assume everything can fucking change and any time. The only two solutions I can think of is to force sync the deltas between sprite/sector/wall arrays which will take a lot of bandwidth or let the game logic run on both client and server, let it modify the sectors and walls, and only sync sprites/player movement from the server. If the game runs out of sync you'll have to update the correct state from the server, which means there would be visible snapping in areas that are out of sync. You would also have to force update con script vars from the server.

Well, at least someone outside the team understands why client/server hasn't been fully achieved yet.

[icecoldduke]

You guys have to make the data more deterministic in order to get multiplayer working properly. Instead of syncing each sector you would sync the state of each sector effector for example. So if you have a sector effector for a door, you would not sync each frame of movement you would only sync if the state of the sectoreffector is open or closed. So the client and server both execute the simulation but what simulation gets executed is determined by the server. Unfortunately this means a lot of code changes, and existing mods would have to be modified to work in multiplayer; but I can't see any other way to get this done.

[TerminX]

Yep, you aren't saying anything we don't already know. It's a tough task but we actually have most of it figured out at this point.

[Striker]

A new release of EDuke32-OldMP: https://gitlab.com/m...aintenance/tags
Just fixes the fraglimit in Team Dukematch, defaults r_downsize to 0 (like modern EDuke32), and backports EVENT_PREGAME (needed for a mod).

[Micky C]

TerminX, on 15 June 2017 - 04:18 PM, said:

Yep, you aren't saying anything we don't already know. It's a tough task but we actually have most of it figured out at this point.

It would be great if something as complex as the AMC TC could be made to work flawlessly with the new MP. There's a LOT of content for both vs and coop gameplay.

[Striker]

EDuke32-OldMP_Maintenance Release 8 is now out.

https://gitlab.com/m...oldmp_release_8

Release notes within.

[Striker]

Stupid me rushed things, and I ended up introducing a ton of bugs. They should be fixed now in release 9: https://gitlab.com/m...oldmp_release_9

[Striker]

https://gitlab.com/m...ldmp_release_10

Release 10 is out. Just adds raw mouse/keyboard input from modern EDuke32.

BTW, ever since release 9, I've noticed there's a bug with the automap's lines not matching the sectors in widescreen... not sure how to fix.

[Striker]

New release.
https://gitlab.com/m...ldmp_release_11

[Jblade]

Thanks for your work on these - I really wish I had time to work on a seperate branch of the AMC TC to utilise this for co-op purposes...but if I get some more time next year I'll definitely try and at least get something like Nuclear Showdown working with it

[Paul B]

Striker, on 09 December 2017 - 04:16 PM, said:

New release.
https://gitlab.com/m...ldmp_release_11

You sneaky guy ! I'll try and keep a current version posted here as well: http://www.dukemaps.net/?page_id=38

Keep up the great work!

[Striker]

EDuke32-OldMP Release 12 with the Discord Matchmaker has been released!

https://gitlab.com/m...ldmp_release_12

[Striker]

EDuke32-OldMP Release 13 is out! Metric fuckton of fixes and improvements in this one.
https://gitlab.com/m...ldmp_release_13

[Striker]

Since I'm a worthless fucking idiot, please re-download EDuke32-OldMP Release 13: https://gitlab.com/m...ldmp_release_13
I fucked up the discord launcher, gimping it entirely into non-functionality, and needed to fix it.

[Striker]

*sigh* Re-uploaded yet again. Since I didn't realize I forgot to commit the -net command instructions in the command help menu (-? command) before reverting experimental changes in my repo a while back.

https://gitlab.com/m...ldmp_release_13

I need to stop working on stuff when I'm lacking sleep.

[Paul B]

Striker, on 19 March 2018 - 12:26 PM, said:

*sigh* Re-uploaded yet again. Since I didn't realize I forgot to commit the -net command instructions in the command help menu (-? command) before reverting experimental changes in my repo a while back.

https://gitlab.com/m...ldmp_release_13

I need to stop working on stuff when I'm lacking sleep.

Don't be too hard on yourself, it's human to error. I'll update the download again at DukeMaps.net. Keep up the great work!

[Striker]

EDuke32-OldMP Release 14 is out. Fixes netcode desync in cross-platform play between Linux and Windows. Also fixes a bug that was royally pissing me off.

Sorry for so many releases in rapid-fire... it's been rough tracking down every issue.

https://gitlab.com/m...ldmp_release_14

[Striker]

Just released EDuke32-OldMP Release 15. This doesn't have much aside from some stability improvements and the ability to create detailed crash logs if the game shits itself. This will help me in improving stability in the future.

https://gitlab.com/m...ldmp_release_15

If you get any crashes, please send your crash.log file here, or in the the gitlab repo as an issue tracker ticket.

[Striker]

EDuke32-OldMP Release 16 has been released.

This just fixes an access violation that can occur with hitscan trails. (Such as the ones for the railgun in StrikerDM)

https://gitlab.com/m...ldmp_release_16

[Danukem]

Does that access violation happen in the main branch of Eduke32? I use a lot of hitscan trails myself.