Perhaps the a virtual Vessel function would be a good home for the code that says "If the vessel did X, the owning player is cheating"?

Very basic movement will be addressed by #1, but we'll need something more accurate eventually.

Eventually the server will need to be smart about where it spawns players, but for now this deserves a fix.

Everything should be a capsule or rectangular prism for now.

The player alone should have control over where their vessel is and what it's doing. This is independent of #9 since the player will still have to get their updates through the server's validation before the server lets anyone else see their updated state.

Currently there's a lot of jitter due to server and client disagreeing on the state of the client's own vessel.

campreilly/UnderSeaModelingLibrary#216

This will need a fix before the 0.1 release. I'll try and work on it after #6 is finished if it isn't already fixed.

It would be nice to use the same bathymetry data USML uses so we don't have to keep copies around in memory.

The only firm requirement for this UI is that it must make it easy to see who is where. A huge part of the game is going to be making it difficult to detect things, so it's important that during development there's a way to bypass that.

Nothing fancy, not even a closed-loop controller. Just let users select pitch in addition to heading.

Probably just add a virtual method to the Vessel class that will let USMLManager give a more definitive answer to the question "How much do I hear vessel A in frequencies X, Y and Z?"

This should propagate all the way to the broadband waterfall display.

This should include at least 2 subs, complete with narrowband information, top speeds, crush depths, sound intensities at various speeds and depths (undecided about how to handle cavitation for now).

Narrowband information will have to be guessed at because I'm sure it's all classified.

Continued from #4

This is the first step towards a working waterfall display. Some of the work put into this will ultimately be thrown away, but it'll be a good way to figure out how to use USML.

Continued from #4

Currently there are some issues where USML will fail to find eigenrays intermittently. We also have some issues where small differences in position cause large changes in propagation loss.

USML failing to find eigenrays seems to be alleviated by closer spacing of the propagated rays and/or a smaller timestep, but I have no way to reproduce this consistently. And I have no idea what's causing the jitter or if the simulation is being accurate and I'm just erroneously second-guessing it. A test case would be really nice. Maybe add some unit tests to the project?

It would also be good to get #5 done before starting on this so it's easier to visualize what's happening.

It shouldn't take 150ms to resize that image. Investigate if this is a driver thing on my new linux install or if something changed in a sublte way and made this slow down.