Development:Network:Todo

Bugs for deathmatch

• With renamed units (renamed aeon in both test2 savegame files, Player 2 seems to load fine, but cannot fire guns.
  • Yes. This is a feature, not a bug. The way it sends saved games is by starting with the original entry in units.csv. If that does not exist, it sends a blank CSV file to the clients. Patrick 02:28, 29 July 2007 (PDT)
• missile starts wobbling into the same place (doesn't seem to receive updates?)
  • Missle kills firer... is parent not set? Is it moving with no velocity??
• Bolts/missiles don't collide any more. (is this still true?)
• Asteroids not always networked... Space junk doesn't display the cargo type because of the way it was created....

Network TODO

List of stuff to be done (that is... the to do in "TODO")

CMD_CARGOUPGRADE and other Docking-related stuff

• Client basecomputer notifications are bad:
  • Whenever anyone docked at (Fixme: any????) base buys or sells cargo/upgrade, the menu for all other players resets to the top level...
  • Needs to keep menu open but still keep cargo in sync.
• To do much much later: Buying ships, missions, saving/loading from COMPY interface.
• Not saving games very well serverside... maybe related to dying and respawning versus loggin out normally?
  • I see the server sending the saved game to the accountserver so maybe it's sending the old saved game.

More bugs

• For guns with ammo, the ammo needs to be kept in sync.
• There are two different functions to send damage, and I have seen three distinct error messages in a few cases (?!?!?!)
  • zonemgr.cpp:614, broadcastDamage AS WELL AS zonemgr.cpp:538, addPosition CALLS zonemgr.cpp:688, addDamage
  • netserver_devices.cpp:136, sendDamages CALLED FROM Unit::ApplyLocalDamage
• Damage functions do not send Hull over. Makes it hard to know when you/the target should be almost dead.

Other synchronization bugs

• System file not transfered over network.
• Saving games: WriteSavedGame() being used to send ADDCLIENT messages to other players, but original saved game used for player himself.

Crashes

• ClientPtr is a shared_ptr<Client*>. I see crashes related to that occasionally.

Some other bug I wrote down, probably doesn't belong here:

• Gas Giant ice rings appear in front of the planet - z buffer.

I'll think of more later

...

General list

• Clean up server-client-authserver communication
  • I would really like if the messages sent and received could be done in a more uniform way.
  • Clean up some unused messages.
• Login:
  • Encrypted authentication, possibly using a random server token.
    • This means that login data cannot be the first packet sent -- it must first negotiate a key.
  • Would SSL be a good idea here. I think we currently link with a Crypto++ library... but I'm not sure how it is currently used or how to use it.
  • Make sure authserver-server-client time synchronization works correctly. Maybe every few minutes (or even hours) A,S,C should sync in case a clock gets off somehow.
• Exiting:
  • Games should be saved? (see below)
    • How much data should actually be saved? What if you have died?
    • Does saving actually work?
• Damage:
  • Theoretically implented, but I have yet to see collisions and weapons actually do damage client-side.
    • The problem is: Clients are responsible for position, so they often bounce before the server has a chance to give damage. Other times you die because the client doesn't respond fast enough! Patrick 20:04, 24 February 2007 (PST)
  • Not sure what CMD_SCAN is to be used for... it's used in one place -- that is in NetClient::scanRequest.
  • I don't know yet how a MMORPG would implement dying...
    • It would be bad to have to start from scratch every time you crash into something.
    • Have the respawn key re-join?
    • Right now you save only if you disconnect without dying. I guess that works.
    • How do we implement saving? Respawn doesn't work without a way to save... or should you keep everything the same as when you died, and then start from a random "spawn point".
      • I believe most FPS games make you lose all upgrades, but this is not an option in Vega Strike, or things will get boring quickly.
      • How do games like Ultima or WoW behave when you die? Do you lose everything (obviously you can't lose all your experience)?
        • Diablo II: A dead body is left at the place where you died. With it are all your equipment, upgrades and the gold (credits) you carried. Your team members can recover all that for you or you can hurry there yourself. Some of the gold is alsways lost however. In more difficult settings (hell and nightmare) also some of your experience is lost. (Zeog 01:24, 4 July 2006 (PDT))
        • WoW: Your equipment takes some damage. With high-end gear, this costs enough that death is worth avoiding. (top-level characters don't have to worry about the XP loss). There's also the time it takes to run your ghost to your corpse. If you just log off without recovering your corpse, I think your gear takes more damage. In Vega Strike, you could lose some of your cargo, and take some damage to your upgrades.
• Weapons:
  • Energy needs to recharge client-side (interpolate between CMD_SNAPSHOTs) -- this is one (if(Network==NULL))'ed out statement in some updatePhysics-related function in unit_generic.cpp -- Really easy to fix. (I thought I fixed this.)
  • Clients with NULL targets constantly send out streams of CMD_TARGET to the server (from withing FireKeyboard::ForceTarget. We sohuld either disable it client-side (but then people will have to manually re-target when their target dies), or else have the server instead check for any nearby targets, and then broadcast a CMD_TARGET only once it becomes non-NULL. This way we avoid the flooding.
• Docking.