-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathTo-Do List.txt
45 lines (45 loc) · 7.5 KB
/
To-Do List.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
eX0 To-Do List (highest priority on top)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
-Think about "commands that fail".
/?-Refactor the WpnCommand packet sending code so that when a gun is empty, the client won't flood the server with 500+ packets/sec of impossible FIRE wpn commands.
-Fix the WpnCommand packet sending code not to spam same weapon change packets.
-Look into why oParticleEngine.Tick(); sometimes takes >3ms even without any active particles (when doing heavy multitasking, i.e. >1 eX0 instances running).
-Partially rewrite the particle class so that there are particle-prototypes that define each particle's starting parameters (rather than them always being custom supplied by AddParticle()).
-Improve the packet parsing system, so that the server isn't vulnerable to badly formed packets, i.e. throw exceptions when parsing fails, and drop the misbehaving client. Do this nicely.
-Remove CPlayer::GlobalStateSequenceNumberTEST because it's just an alias for latest predicted state seq number I think (aka m_oPlayer.oStateHistory.front().oState.cSequenceNumber). Actually, maybe I can't quite do that, because on server, there is no latest predicted state per se...
-Particle engine class probably also needs a mutex to protect particle logic updates and rendering from interfering w/ each other.
//-PlayerInputListener class probably needs a mutex to disallow being polled by the Logic thread when it's being updated by the Main thread. Added a mutex sub-call to all InputListeners. Done.
//-FIX[rare]: 0 <= 256.00015 <= 1; fHistoryTicks not in range: 256.00015. Fixed. It happens when fTicks >= fTickTime and from->to states are 0->1. Just added a (fCurrentTimepoint >= 256) check when fCurrentTimepoint is calculated. Done.
-Establish a clear ownership relationship between Connection and Player classes (i.e. Connection owns its Players).
xx-Consider if PlayerController should go inside LocalStateAuther rather than CPlayer. No, definitely not (b/c NSA also uses a controller).
//-Refactor CPlayer class not to contain a redundant nLastLatency thing, rather use a dummy connection container for that type of stuff. Done.
-Put a whole bunch of stuff in GameSession class, including players and connections, etc.
-Add ability to add 'bots' on the server while clients are connected (notify them properly); this will require clients to be aware of >1 player per connection; also a way to kick/remove them.
-Finish the Connect to Local Game Server protocol/handshake connection.
//-Rename LocalServer class to GameServer and create some sort of offline server ('n'either) connection ability. Done.
-Figure out if I need to close the UDP socket in ~NetworkConnection(), not just the TCP socket.
-Camera class
/-InputManager/InputListener classes
-Console class
/-GameSession class
//-GameTimer class
//-Still need a better separation between rendering and logic timeframe/player location/etc. system. Accomplished by using two timers, with the Render timed synced to Logic timer. Done.
//-FIX: Render thread should use RenderTimer for player positions; also fix the glitch that happens when g_cCurrentCommandSequenceNumber is incremented in logic thread, during player rendering (thus breaking RenderInPast()). Done.
//-Refactor (and move to Thread class) and clean up the FpsCounter class
//-FIX: When you are connecting (i.e. in the middle of clock sync), if another player changes/joins a team, you will not get that packet. Ok, now it's better, but make sure not to send PlayerJoinedTeam (packet 28) to UDP_CONNECTED clients that didn't send their local info (packet 21). I think I need to add another state in between UDP_CONN and IN_GAME, that indicates player got the current world state info packet (21). Only send player joined/left to players with >= PUBLIC_CLIENT state. Done, but could use more testing/verification (i.e. some code review).
//-FIX: Right now all clients share the same TCP packet buffer, which is bad, as they can interleave their stuff and mess each other up. Each client should have his own TCP packet buffer. Done.
//-Change TCP packet header to 1 byte for type and 2 for length, where length doesn't include the size of the TCP packet header. Done.
//-Rewrite classes that create a thread into using Thread class.
-Make a better design for the way Process***Packet() accepts/figures out packet length and type. Also think about splitting CPacket into two: write-only and read-only ones.
//-Keep clocks in sync by periodically sending time-correcting ping packets. Perform the time-correction based on statistics over the last minute or so. Make the local time adjustment more robust, rethink how often to really perform it, and maybe make it smooth(er)... Perhaps check if all oRecentTimeDifference values are positive/negative before doing anything, to be completely sure your adjustment won't do more harm than good. I.e. check if oRecentTimeDifference Mean >> Std Deviation. Done time syncing on the client for now, could use more work/tweaking in the future if needed.
//-FIX: Right now CPlayers are never reset on the server, even when a completely different client gets assigned to it. Maybe I should make a new CPlayer when a client gets assigned one, and delete it when CClient is deleted, instead of a silly array of CPlayers. Done.
//-Design a better time->state determinant system. Did some tests, and it turns out current system is more than good enough, there are no precision problems with adding 0.05 to dNextTickTime.
-Change packet 21 to not include current state#,x,y,z but rather have the client accept values from the 1st Server Update UDP packet (type 2). Maybe? Not sure if a good idea, but think about this.
//-About removing bFirstCommand on server - a test with red indicates might need it after all, as server might be slightly ahead of client and client will send a 'duplicate' command which server will thus ignore. Maybe have srvr accept duplicate cmd once if first packet is true? Think! See Last Problem.txt for the test with red log. Introduced a 'command series' number that is incremented on each respawn/team change, thus eliminating the problem. Done.
//-Make spawning/joining a new team a timed event in the future, in case old UDP command packets arrive late. Or think about this, see if it's really neccessary. Solved above. Done.
/-Have the server know its ping time to the clients too, and broadcast it to all clients. Keep an average (on the server), not just the latest - this is for the future to do with shooting, etc.
//-Add a time out for non-ACCEPTED connected sockets, i.e. to get rid of connected non-clients.
-Add a way for server to kick TCP-timed-out clients, perhaps have select() check for errors. Also, clients should send keep-alive TCP packets every now and then.
//-FIX: Rethink the Terminate()->exit() technique for quitting, as it may leave memory on the stack unfreed. Normal termination should always return from main(), do not use exit() if everything is ok.
//-TODO: Make use of throw for one of my classes... HashMatcher, I think. Use try/throw/catch instead of returning null on error, and using another procedure to Get the value in case of no error. Same with Connection class, make it throw if passed nTcpSocket is INVALID_SOCKET. Done with HashMatcher, but need to think about the NetworkConnection classes. Nah, leave 'em as is and throw only when neccessary, use return values otherwise. Done.
-FIX: A potential deadlock in killing TimedEventScheduler thread on unusual shutdown (when ~ClientConnection() happens, it calls RemoveEventById, and at the same time main thread Deinit() calls ~TimedEventScheduler().