Duke4.net Forums: MP—What's broken? - 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!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

MP—What's broken?

User is offline   ThothXV 

  • 0

#1

Okay, so eduke32 MP has been broken for... jeez. Years. Which is why OldMP is around.

However, I can't find any documentation as to why the MP is in an unworkable state right now. What's actually broken? Does the code buggy, or an actually totally broken WIP mess full of //TODOs? What would it take for us to get it working?
0

User is online   Mark 

  • Honored Donor
  • 2,822

#2

Its being totally rewritten for a modern client/server approach. I don't know the reasons behind why its taking so long. It looks like OldMP has had quite a few upgrades and people here have been using it and having a good time.

This post has been edited by Mark: 24 January 2019 - 02:40 PM

0

User is offline   oasiz 

  • 866

#3

Build never had proper MP, it was an outdated p2p approach that introduced other things such as copious amounts of input lag that increased with your latency. Desyncs galore, etc..
Making proper MP for something like this and an engine that is not MP friendly (very extensive scripting & dynamic geometry) is just not that simple.

general lack of coders / time / people crazy enough / etc.. is probably the biggest thing.
2

User is online   Hendricks266 

  • Sperge Overlord
  • 6,315

  #4

View PostThothXV, on 24 January 2019 - 02:30 PM, said:

What would it take for us to get it working?

Wait 6-8 months for IM MP dev to complete.
6

User is offline   ThothXV 

  • 0

#5

View Postoasiz, on 24 January 2019 - 03:39 PM, said:

Build never had proper MP, it was an outdated p2p approach that introduced other things such as copious amounts of input lag that increased with your latency. Desyncs galore, etc..
Making proper MP for something like this and an engine that is not MP friendly (very extensive scripting & dynamic geometry) is just not that simple.

general lack of coders / time / people crazy enough / etc.. is probably the biggest thing.



Since I AM crazy, where's MP on the source tree? I know originally Build's MP was on the Build side of the Build/Duke divide, but it looks like the new stuff has jumped the gap and is currently in net.cpp/net.h. Just wanna make sure I got that right. It also has licensing implications, as the Build tree is of course under BUILDLIC, and Duke is GPL2 (and thus I don't have to make EXTRA sure I haven't been seen near the Quake sources lately)...

Also... coding convention? Are we 1TBS, K&R, or Allman? Tabs or spaces? I don't wanna muck any of that up.

Sorry for asking so many questions, but while I am a lazy git who promises nothing, if I'm gonna try and do this I wanna do it right.

This post has been edited by ThothXV: 24 January 2019 - 05:47 PM

0

User is offline   necroslut 

  • 229

#6

View Postoasiz, on 24 January 2019 - 03:39 PM, said:

Build never had proper MP, it was an outdated p2p approach that introduced other things such as copious amounts of input lag that increased with your latency. Desyncs galore, etc..
Making proper MP for something like this and an engine that is not MP friendly (very extensive scripting & dynamic geometry) is just not that simple.

general lack of coders / time / people crazy enough / etc.. is probably the biggest thing.

In my experience it always worked pretty flawlessly over LAN, and JF/ED32 online worked pretty well too if the distance between players wasn't too big.

Blue barrels are heavier than regular barrels
0

User is offline   Striker 

  • Auramancer
  • 1,006

#7

View PostThothXV, on 24 January 2019 - 05:46 PM, said:

Since I AM crazy, where's MP on the source tree? I know originally Build's MP was on the Build side of the Build/Duke divide, but it looks like the new stuff has jumped the gap and is currently in net.cpp/net.h. Just wanna make sure I got that right. It also has licensing implications, as the Build tree is of course under BUILDLIC, and Duke is GPL2 (and thus I don't have to make EXTRA sure I haven't been seen near the Quake sources lately)...

Also... coding convention? Are we 1TBS, K&R, or Allman? Tabs or spaces? I don't wanna muck any of that up.

Sorry for asking so many questions, but while I am a lazy git who promises nothing, if I'm gonna try and do this I wanna do it right.

Most of the C/S netcode is in net.cpp/net.h. Spaces, no tabs. Allman braces.

There's a number of things that need to be done. Handling of sector animation and synchronization (Changes in both the netcode and the game code itself need to be made), handling of allocating player sprites and spawning needs to be rewritten, etc. [IFOC]75 (jwaffe on the forum here) could give you a better run-down of what needs to be done.
2

User is offline   Photonic 

  • 1,255

#8

Might as well ask here, where is the bot ai in current EDuke32?

Also will Ion Maiden have bots?
0

User is offline   jwaffe 

  • 26

#9

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.

Quote

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

Quote

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:

Quote

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.

This post has been edited by jwaffe: 25 January 2019 - 03:04 PM

5

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


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