07:55:46 Essex20 joined the channel
08:21:46 Essex20: mrh
08:21:49 Essex20: meh
09:41:04 Schrompf joined the channel
09:59:55 Schrompf: /moin
19:53:45 efjam88 joined the channel
19:53:57 efjam88: hi again
19:55:18 Schrompf: huhu again
20:00:16 efjam88: https://pastebin.com/QntgyC3F
20:00:43 efjam88: der teil is korrektj, richtig?
20:03:16 Schrompf: weiß ich nicht ausm kopf, aber sieht gut aus
20:03:42 efjam88: nexter teil: recvfrom(sockIn,(char*)plrs,sizeof(cPlayer)*MaxPlayer,0,(sockaddr*)&game->server_addr,&sz);
20:04:03 efjam88: ich dachte der befehl wartet auf was reinkommendes?
20:04:24 Schrompf: ja. tut's.
20:04:55 efjam88: wieso stop der breakpoint dann immer wieder aufs neue?
20:05:08 Schrompf: weil du nen breakpoint gesetzt hast? oder weiL's crasht?
20:05:16 efjam88: wegen dem bp
20:06:53 efjam88: achja muss ich eigentlich drauf achten dass ne msg an 127.0.0.1 von der selben anwendung aufgegriffen wird?
20:08:07 efjam88: jedenfalls wartet recvfrom nicht?
20:08:47 efjam88: achja...
20:10:00 efjam88: kann ich eigentlich das sockaddr die ich für den ausgangssocket verwendet wird, auch für den eingangssocket nehmen?
20:11:12 Schrompf: a) versteh ich nicht
20:11:23 Schrompf: b) recvfrom() wartet nicht, das pollt man
20:11:25 efjam88: zuerst noch: ich brauch ja einen eingangssocket und einen ausgangssocket
20:12:05 Schrompf: c) du brauchst nen dedizierten ausgangssocket für das senden beim client und nen dedizierten eingangssocket für das empfangen im server
20:12:10 Schrompf: alles andere ist wurscht
20:13:57 efjam88: hm
20:17:29 efjam88: sry, aber: wie reagier ich so auf eingangspakete wenn man nicht drauf wartet bis was kommt?
20:22:15 efjam88: endschuldige die blöde frage
20:23:14 Schrompf: kein thema. Du musst einfach immer wieder recv()
20:23:21 Schrompf: die profis machen das 120 mal die sekunde :-)
20:23:40 Schrompf: manchmal kriegste was. meistens nicht
20:23:56 efjam88: hmm
20:24:32 efjam88: MSG_WAITALL vllt?
20:25:19 Schrompf: keine ahnung. pollen geht einfach so. du fragst einfach immer und kriegst als antwort "nö, grad nicht"
20:25:25 Schrompf: kannst du auch irgendwo einstellen
20:25:39 Schrompf: bei tcp ist "warten" das standardverhalten
20:26:26 efjam88: bei recvfrom einfach ne schleife mit sleep(8); oder so?
20:27:08 Schrompf: weiß nich. normalerweise ist das doch ein spiel, oder?
20:27:18 Schrompf: also hast du ne renderloop, die 100+ mal pro sekunde das bild neuzeichnet
20:27:34 Schrompf: da machst du jeweils einmal recv() (ich würd mir recvfrom() ersparen)
20:28:02 efjam88: bin ned so effizient, drum nur 25fps
20:28:11 Schrompf: egal
20:28:27 Schrompf: das zeug bleibt im puffer, bis du es abholst
20:28:54 efjam88: aha
20:29:25 efjam88: und tcp und udp verbinden funktioniert ?
20:33:39 Schrompf: beides? nein. das sind absolut getrennte kanäle. wie als ob du nen brief oder nen richtlaser aufstellst
20:34:28 efjam88: aber recv ist doch tcp?
20:42:23 Schrompf: nö
20:42:27 Schrompf: gibt's für beides
20:42:34 Schrompf: heißt halt gleich
21:00:05 efjam88: also alle 125 sec checken macht sinn?
21:08:07 Schrompf: nein, alle 10ms
21:08:32 efjam88: achja,verschrieben fällt mir grad auf
21:11:21 efjam88: meinte 125 mal pro sec
21:16:20 efjam88: wie mach ich das eigentlich am besten wenn ich verschiedene arten von Paketen hab?
21:16:41 Schrompf: willkommen beim protokoll-design. du schreibst ne kennung ins erste byte
21:17:11 efjam88: achja pakete mit maximal 512 byte?
21:17:12 Schrompf: du brauchst aber sowieso nen header in jedem paket. manchmal willst du auch bei udp sicherstellen, dass das gegenüber das bekommen hat
21:17:26 Schrompf: nein, die MTU ist üblicherweise 1400 und ein bissl bytes