What is this file about?
Technical information for developers!

Some facts, TODO list etc.
--------------------------

To fix for 0.0.19

- allow more input at gauges screen: more MT options, rudder etc.
- maybe tooltips for gauges screen
- scope down -> no scope view
- fix logbook view (wrap lines)
- better scope gfx (Luis)
- add sounds
- bring coastlines back again (old line code, not 2d heightfield code!)


After version 0.0.17 many changes were introduced.

A new physics simulation engine makes many things more realistic and breaks
even more things :-/ now, most things work again...
But load/save code is broken, too.
Here is much work to be done.

New interface code was introduced (new event handling). Now events aren't
any longer lost. Drawback is that not all old functions work with new code,
that means some part of the interface is broken. Sink records and logbook
isn't any longer hold by the interface but now by the game object itself
(makes also more sense).
Some screens are more or less unusable. Some graphics are missing.
3D display: Some minor visual bugs, like water border visible at screen
border etc. etc.

Damage simulation code is missing completely. We need data for all the
models: how they are partitioned, the damage each partition can withstand,
when does a ship sink etc.

Submarine bouyancy code is missing.

Aircrafts are missing.

Noise simulation is very basic.

Thermal layer simulation is missing.

Wind simulation also, weather completely.

ASDIC simulation is rather basic (reports depths, which real ASDIC
couldn't).

AI is stupid, doesn't use vessel movement to compute DC throw points or for
grenade firing.

Command interface was introduced to support network play, but is pretty much
useless. Network play should work with interchanging of vessel states or
scene states, not single commands. With UDP they could get lost. So class
command should get removed and all its commands converted back to function
calls. Done! except for airplane/ship interface classes, which are obsolete
anyway.


The future
----------

A integrated mission editor would be cool.

A tutorial mission would be helpful.


etc. etc.



old from here: networking doesn't work
ignore from here

Networking/Multiplayer code
---------------------------

One player creates a game, the others join it. The creator's computer is the
"server", the other's computers are "clients". Each computer holds a copy of
the running game, but the server copy holds the "real" state of the game.
Each computer uses its local copy as source for display of the game. Each
client computer sends the commands of its player to itself and the server,
the server computer sends the commands of its player to everyone. So all
local copies are updated incrementally with a minimum network traffic.
To avoid a larger drift between the copies (which occours because the
computers have different performance, even different code or accuracy for
calculations) a full copy of the server game state is broadcasted every n
seconds to all clients.
To achieve this idea, the user_interface (and its heirs and clients) MUST
NOT change their player's object, that means MUST NOT call non-const methods
of class sea_object (or heirs of sea_object). Instead it can send commands
(class command or heirs) to class game, which passed them to the objects.
That way it is not possible to create commands that return values. Methods
that return values are functions and should not have side effects (in real
OOP - according to Bertrand Meyer) and hence should already be const.
The clients can use their local copy to ask wether an command will work or
fail and send it only in the former case to class game.
Also methods of class game that change the game state (spawn functions, ping
or explosion events) MUST NOT be called directly but hidden behind the
command interface. That way all events that change the game can be send over
network.
Each frame class game calls retreive_commands() to listen to the network,
collecting incoming commands and executing them locally.

Side effects: commands could be stored with time stamp to realize replay
recording and display, or to queue commands, maybe limit them to 10 per
seconds or remove opposing commands in the queue etc.

<eof>
