Difference between revisions of "Development:Network:Todo"

From VsWiki
Jump to: navigation, search
m (add space junk bug)
(Some networking updates, some documentation/intrapersonal debates.)
Line 1: Line 1:
 
= Bugs for deathmatch =
 
= Bugs for deathmatch =
−
* Sometimes, player 1 doesn't see player 2 after player 2 logs in. (however it receives the enterrequest, and prints out "Now 1 clients in system") -- Probably fixed, may also be targetting problem.
 
 
* With renamed units (renamed aeon in both test2 savegame files, Player 2 seems to load fine, but cannot fire guns.
 
* With renamed units (renamed aeon in both test2 savegame files, Player 2 seems to load fine, but cannot fire guns.
 
* missile starts wobbling into the same place (doesn't seem to receive updates?)
 
* missile starts wobbling into the same place (doesn't seem to receive updates?)
−
* server crashes if player unit dies (GetUnit() is often dereferenced without checking for NULL)
+
* Bolts/missiles don't collide any more. (is this still true?)
−
* Bolts/missiles don't collide any more.
+
* Space junk not networked (serial is 0) Also true for Asteroids
−
* Space junk not networked (serial is 0)
 
  
 
= Network TODO =
 
= Network TODO =
 +
 +
List of stuff to be done (that is... the to do in "TODO")
 +
 +
== CMD_CARGOUPGRADE and other Docking-related stuff ==
 +
* credits -- both server and clientside ee 0 credits
 +
** Nope, that was just my buggy savegame file stored on the server (phpmyadmin-v.sfnet)
 +
* cargo -- exact quantity and price must be synced for each base.
 +
** Fix: For now we're just setting the stddev's to 0 if in network or server-side modes (unit_csv.cpp:451)  This keeps all cargo initially at nice round numbers, and all prices at nice round numbers.  It's the best solution I can think of for now...
 +
** It should be possible to send the saved CSV's for all Planets AND Base Units upon joining.  This might already be done for units... if it is, the saved CSV's will have the correct cargo list for each units as the server sees them.
 +
* add sellcargo and upgrde and downgrade calls to NetClient::cargoRequest.
 +
** broadcast cargo messages to all clients
 +
* Fixme: Right now the CMD_CARGOUPGRADE message allows players to trade between each other.
 +
** However, there is no way for a client to reject a transaction, so this allows players to steal cargo
 +
* Upgrades vs. Cargos
 +
** How to figure out if it's an upgrade correctly?
 +
*** hellcatv says that the only way is to do a string compare in the category for "upgrades/".
 +
** In addition, Weapons cannot be added as cargo.
 +
** All other upgrades MUST be added as cargo.
 +
** Cargo should not be upgraded.
 +
* To do much much later: Buying ships, missions, saving/loading from COMPY interface.
 +
 +
Some other bug I wrote down, probably doesn't belong here:
 +
* Gas Giant ice rings appear in front of the planet - z buffer.
 +
 +
== General list ==
  
 
* Clean up server-client-authserver communication
 
* Clean up server-client-authserver communication
Line 18: Line 41:
 
** 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.
 
** 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:
 
* Exiting:
−
** VSExit(1) is somewhat brutal way of quitting the game.  It often doesn't even nicely inform the server until it closes the connection.
 
 
** Games should be saved? (see below)
 
** Games should be saved? (see below)
 
*** How much data should actually be saved?  What if you have died?
 
*** How much data should actually be saved?  What if you have died?
 +
*** Does saving actually work?
 
* Damage:
 
* Damage:
 
** Theoretically implented, but I have yet to see collisions and weapons actually do damage client-side.
 
** Theoretically implented, but I have yet to see collisions and weapons actually do damage client-side.
−
** Figure out how to gracefully detect dead units (Crashing because the unit is NULL is not the right way to do this).
+
*** 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! [[User:ace123|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.
 
** 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 the game will implement dying...
+
** 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.
 
*** It would be bad to have to start from scratch every time you crash into something.
 
*** Have the respawn key re-join?
 
*** 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".
 
*** 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.
 
**** 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.
Line 33: Line 57:
 
***** 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. ([[User:Zeog|Zeog]] 01:24, 4 July 2006 (PDT))
 
***** 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. ([[User:Zeog|Zeog]] 01:24, 4 July 2006 (PDT))
 
* Weapons:
 
* 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.
+
** 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.
 
** 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.
−
* Jumping, Docking, multiple systems:
+
* Docking.
−
** Server switching???
 
−
** Having the server load a new system may not be a good idea.  The server should always have all systems it will handle running at once.
 
−
** This also means that the universe must be limited.
 
  
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 06:04, 25 February 2007

Bugs for deathmatch

  • With renamed units (renamed aeon in both test2 savegame files, Player 2 seems to load fine, but cannot fire guns.
  • missile starts wobbling into the same place (doesn't seem to receive updates?)
  • Bolts/missiles don't collide any more. (is this still true?)
  • Space junk not networked (serial is 0) Also true for Asteroids

Network TODO

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

CMD_CARGOUPGRADE and other Docking-related stuff

  • credits -- both server and clientside ee 0 credits
    • Nope, that was just my buggy savegame file stored on the server (phpmyadmin-v.sfnet)
  • cargo -- exact quantity and price must be synced for each base.
    • Fix: For now we're just setting the stddev's to 0 if in network or server-side modes (unit_csv.cpp:451) This keeps all cargo initially at nice round numbers, and all prices at nice round numbers. It's the best solution I can think of for now...
    • It should be possible to send the saved CSV's for all Planets AND Base Units upon joining. This might already be done for units... if it is, the saved CSV's will have the correct cargo list for each units as the server sees them.
  • add sellcargo and upgrde and downgrade calls to NetClient::cargoRequest.
    • broadcast cargo messages to all clients
  • Fixme: Right now the CMD_CARGOUPGRADE message allows players to trade between each other.
    • However, there is no way for a client to reject a transaction, so this allows players to steal cargo
  • Upgrades vs. Cargos
    • How to figure out if it's an upgrade correctly?
      • hellcatv says that the only way is to do a string compare in the category for "upgrades/".
    • In addition, Weapons cannot be added as cargo.
    • All other upgrades MUST be added as cargo.
    • Cargo should not be upgraded.
  • To do much much later: Buying ships, missions, saving/loading from COMPY interface.

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

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

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))
  • 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.
Retrieved from "http://wiki.vega-strike.org/mediawiki/index.php?title=Development:Network:Todo&oldid=12612"