Skip to content

TODO.md

Latest commit

 

History

History
101 lines (79 loc) · 3.34 KB

TODO.md

File metadata and controls

101 lines (79 loc) · 3.34 KB
Raw

To Do

General

It turns out ENet supports a max 4095 connections. This makes sense because on UNIX platforms it uses either select or poll, and those don't really scale past that.

I don't like this artificial limitation though, even though it's tempting to just pick a number below that -- say 2000 -- and say, "we support 2000 players max". For one, I think the limits should be dictated by hardware, not arbitrary limits. But it also confuses a lot of things. There should be multiple counts:

  • maximum connections supported (these may not be full clients)
  • maximum clients supported (these may only be spectators, not players)
  • maximum players supported

Right now we just use MAXPLAYERS for all of these, and that's confusing.

The main issue is working around ENet's artificial limitation. I actually think replacing ENet with regular sockets and libuv is fine. libuv would also clean up some of the directory server code, which would be welcome.

In the interim, I think MAXPLAYERS needs to be removed. It ultimately needs to be removed anyway, but the concepts behind players and playeringame and consoleplayer/displayplayer need to be refactored since the list of player_t instances will be dynamic now.

Smaller Issues

  1. Add error codes to n_proto

  2. Servers shouldn't quit, they should shutdown; also prevents accidentally running /quit in the console instead of :quit and closing the server....

  3. Add auto-scroll to TextWidget

  4. Update/Mirror dependencies somewhere

  • It would be really cool to use the pacman/pkgbuild system and mirror source also
  1. Manually delta compress commands (serverside and clientside)
  • bitmap:
    • index changed = 1
    • tic changed = 2
    • server_tic changed = 4
    • forward changed = 8
    • side changed = 16
    • angle changed = 32
    • buttons changed = 64
  • then deltas:
    • All diffs are char except for angle, which is a short
    • Effectively limits lag to 255 commands, which is way more than enough

Hypothetically: { 4096, 4012, 4008, 50, 50, 180, 1 } // 17 bytes { 4097, 4013, 4008, 50, 50, 180, 1 } // 17 bytes // Total: 34

Becomes: { 4096, 4012, 4008, 50, 50, 180, 1 } // 17 bytes { 3, 1, 1} // 3 bytes // Total: 20, saved: 14

  1. Implement actor vectors
  • Send movement start TIC
  • x/y/z represent the start position at time of last velocity change
  • More amenable to delta compression
  • Easier to nudge projectiles
  1. Add projectile nudging
  • Projectiles are currently predicted, thus they usually appear ahead of where they normally would
  • Projectile nudging would spawn the projectile normally (i.e., right in front of the firing player) with a higher-than-normal velocity, and then adjust the velocity downwards based on the client's lag and a preselected function (curve)

Future/Possible

  1. Remove software renderer
  • See about implementing Doom lighting and 8-bit color using shaders

Features

  1. ZIP/PK3 resource files
  2. Bots
  3. ACS Scripting
  4. DECORATE
  5. EDF
  6. ExtraData
  7. MAPINFO
  8. 3D floors
  9. 3D MixTex
  10. Portals
  11. Polyobjects
  12. Ambient Sounds
  13. Support for other ID Tech 1 games (Heretic, Hexen, etc.)