Řešíme to zbytečně moc efektivně, nesral bych se s tím tolik a neoptimalizoval. I kdyby měla 1kb a to je dost a každou vteřinu zprávu, tak generujeme 1 Kbs, to je směšný. Takže to neřešit, všechny tyhle optimalizace, znovuvyužívat zprávy, to nemá cenu, vybodnout se na to a prostě všechno co klient potřebuju, to si zažádá a pošle se mu to. Klidně když budou dvě obrazovky sdílet data, tak se vezme maximum. 

Měli bychom fungovat i když nedojde zpráva. Klient si prostě řekne znova. Na začátku si říct o konstanty, to pak někde musí být jejich seznam. Takže by bylo lepší, kdyby se to prostě zasílalo souběžně s daty. Je to asi zbytečné. 

Třetí složku u pozice budu dávat implicitně 0, protože máme 2D vesmír.

Server si přepočítává souřadnice, co mu pošleme, to je logika serveru, nemusíme se zabývat tím, kde má klient zazoomováno. 

Planety se nemění, planety jsou jako měsíce, to stačí tedy zaslat jenom jednou, protože se to nemění. Mělo by se to ale synchronizovat. Pozici planet a úhlovou rychlost, takže je na klientovi, jak často se bude ptát na planety.

GET_PLANETS_IN_AREA udělá se dotaz na obdelník a vrátí se seznam hvězd. Když budeme chtít planety kolem hvězdy, tak to bude další dotaz. 

Když se podívám na sluneční soustavu, tak hvězdy jsou statické. Bylo by dobré, aby makropohled šel šoupat, pokud by to šlo, posouvat v něm. Může vidět libovolný hvězdy a soustavu ale vidí, až když je v ní. Martin bude chtít hvězdy z radiusu. Takže pohled se může hýbat. Řekne si klient o hvězdy v radiusu. 

GET_SHIPS_IN_AREA se pošle serveru id lodě a vrátí mi to, co vidí senzory. Server ví, co mám za senzory a pošle mi to. Přičemž tam bude odpověď navíc - nemáš zapnutý senzory a nebo v okolí nebyla nalezena loď. Senzory jsou na požádání, není to automatické. Když se ztratí zpráva, tak hráč si musí kliknout znovu. Automaticky přichází jen zpráva, že někdo nabíjí zbraně. 

GET_BASES_IN_AREA

Umožnit disablovat chat. Přejmenovat na komunikační kanál.

Destination position je na serveru něco jiného než na klientovi. Například změny kurzu jsou na klientu k ničemu. Musí se proto vrace nikoliv skutečná position, ale místo první změny kurzu. Když se provede update pozice (kurzu) na serveru, tak se to automaticky klientovi zase pošle. Takže se může posílat i od cizích lodí, protože z toho stejně moc klient nezjistí.

Hráč bude mít Id soustav, ve kterých už byl. Nebude se ukládat jejich planety, ale to se dá odvodit. 

Původně možnost sken cizí lodi. Objevím loď a pak na ni zacílím sken. Na to teď kašleme.

Použít sken dát do hlavního panelu a říct, že to stojí energii.

----

Senzory pracují jinak než sondy. Senzory nezkoumají potenciál těžby, ale cizí lodě a podobně. Senzory se dělí na dva druhy. Citlivé a dálkové. 
Citlivé senzory mohou být použity ke čtyřem různým účelům. Buď "plošný scan", který odhalí všechny lodě v dosahu, dodá hráči jejich seznam (jména lodí, majitelů a zevrubné informace o lodi, například rozměry, třídu, ....). Další možností je "scan lodi", který je nutné zacílit na nějakou již objevenou loď. V tomto případě získá uživatel senzorů kompletní informace o lodi (včetně nákladu a podobně). Třetí možností je "scan-warning režim", který hráči dodává informace o tom, že jej někdo cizí scannoval cíleným scannem lodi. Čtvrtou a poslední možností je "weapon-warning režim", který hráče informuje v případě, že někdo v okruhu dosahu zbraní nabíjí nějaké zbraně.
Dálkové senzory mají jen jeden způsob použití. Jsou-li zapnuté, dodávají hráči jednou za čas informace o okolních slunečních soustavách, planetách a lodích. Všechny informace jsou však jen zevrubné. O hvězdách ví každá loď i bez senzorů, o planetách zjistí dálkové senzory jejich počet ve sluneční soustavě a základní charakteristiky. O lodích zjistí polohu, ale nic dalšího (tedy ani jméno hráče, kterému loď patří). Dálkové senzory používají technologii, která znemožňuje okamžité získávání informací, takže jsou informace dodávány nepřesně a mohou být i se zpožděním (realita je taková, že to nejde rozumně naprogramovat, takže to bude fungovat jen nějak přibližně, což hráčům zdůvodníme těmito kecy, které jsem tu napsal).
Obsluha z hlediska hráče je taková, že pokud chce provést "plošný scan" nebo "scan lodi", stojí prostě zvolí okamžik, kdy chce tuto akci provést a to ho stojí nějakou energii (kolik to stojí, by se mělo objevovat vedle toho tlačítka, informaci dodá server). Ty dva "warning" režimy fungují automaticky a nestojí žádnou energii, jen je třeba mít na tyto akce zapnuté senzory (což samo o sobě nějakou energii stojí).
  citlivé i dálkové senzory mají naprosto stejné parametry:
    dosah
      na jakou vzdálenost mohou něco zjišťovat
    úroveň
      jak kvalitní informace dodávají (a jestli umí odhalovat zamaskované lodě)
    spotřeba
      kolik energie za sekundu spotřebují; okamžité použití citlivých senzorů spotřebovává energii v závislosti na této spotřebě, třeba jeden scan cizí lodi bude zabírat například 15 minut těch warning režimů, nebo tak podobně


-----

Blízkový, dálkový. Blízkový dávají podrobnosti detailní, dálkový jen informace o lodi. Pronásledovatelné lodě je to, co vidí dálkové senzory. U dálkových dám Martinovi jako typ jen Unknown a dst position mu vyplním jako ship position, prostě jakoby nikam neplula.  U pronásledovatelné lodě nebude znát její jméno, takže to vyhodit z widgetu. 

přihlašovací obrazovka buď odmítne, nebo ho přihlásí. 

paprsek kašleme, maskování kašleme, těžba kašleme, vybavení tak půl na půl, průzkum kašleme, androidi kašleme na opravu jsou, počítač je.

Impulzní pohon je to co jsem dělal.
warp je jednoduchý, jen zadám cíl (shodný klidně s tím ostatním v navigačním widgetu, až na to že nejde pronásledovat loď). Když vstoupí loď do warpu, tak to dám klientu najevo, řeknu mu přesnou dobu a nesmí během té doby nic dělat. Může ho jedině ukončit. Nemůže  útočit, těžit, zkoumat, 

Štíty do kterých můžu dát energii. 
Vybavení to je přehled. 