VR Multiplayer

    Hallo zusammen,
    ich bin relativ neu in Unreal Engine und möchte gerne ein VR Mutliplayer-Spiel erstellen.
    Als Vorlage nutze ich das Steam-Project von den Epic's.
    Dies ist allerdings nur für ThirdPersonCharacters ausgelegt. Ich dachte mir jetzt der Einfachheit halber zwei der ThirdPersonCharacter durch den MotionControllerPawn des VR-Templates zu ersetzen.
    Das funktioniert weitesgehend auch.


    Sobald allerdings ein zweiter Spieler das Spiel betritt und den jeweils anderen VR-Pawn auswählt spawnen deren Hände am Nullpunkt bzw. werden nicht attacht. Außerdem erhalte ich folgende Fehlermeldung:
    Warning: UIpNetDriver::ProcessRemoteFunction: No owning connection for actor


    Benutze ich jedoch anstelle des VRPawns wieder die normalen ThirdPersonCharacter funktioniert alles reibungslos...


    Ich sitze jetzt schon seit Wochen daran ein fähiges Multiplayer Szenario zu erstellen und bin wirklich langsam am Verzweifeln. Ich hoffe ihr könnt mir helfen.

    Hallo


    Etwas auf dem Client hat keine Owning Connection. Du benutzt Listen Server. Der Client versucht eine Netzwerkfunktion auf dem Server durchzuführen, ihm fehlt aber die Berechtigung.Du hast hier keine Angaben gemacht, wie genau du das Ganze ersetzt hast. Aber du kannst einfach den PlayerController vom Client als Owner eintragen. Dann funktioniert das.
    Natürlich kannst du es einfach für alle entsprechend eintragen.


    In diesem Thread habe ich auch mehr Informationen zu dem Problem gepostet.


    Gruss

    Leider fehlte mir immer das VR Equipment ... Aber so auf die Schnelle würde ich schon beim ersten Branch behaupten, dass beim Client die Meldung angezeigt wird (also dass die Message "not locally controlled" o.Ä anzeigt wird), ist das so?


    Mit der "Set Owner" Node kannst du den Owner zuweisen. Aber ich vermute es gibt bereits einen Owner. Kannst du den mal mit "Get Owner" ausgeben lassen?
    Also zuerst "Get Owner" und dann mit "Print String" ausgeben.


    Gruss

    Nochmals vielen Dank für die Antwort. Ich kann das leider erst Montag machen. Ich werde dann aber sobald ich etwas neues weiß sofort Bescheid geben. Vielen Dank für deine Hilfe.
    Die Message "not locally controlled" wird übrigens weder auf dem Clienten noch auf dem Server angezeigt...
    Heißt im Umkehrschluss also, dass beide Player kontrolliert werden, richtig?
    Was ich insgesamt nicht verstehe ist, dass es ja mit den normalen ThirdPerson Character funktioniert, obwohl dieser ja gar keine Blueprint Scripts beinhaltet.

    Hi, habe den thread leider eben erst gesehen. Für Multiplayer VR kannst du mal locker 1000 Stunden in das Grundgerüst stecken - oder du nimmst sowas wie das Proteus Template...


    https://forums.unrealengine.co…s-blueprint-only-template


    HTC, Rift, WIndows mixed reality, leap motion, sream, oculus network, WIndows home, oculus avatars, usw... ALLES SCHON DRIN. Ich glaube Worte könnenkaum beschreiben wieviel das wert ist - ist aber kostenlos. Kaum zu glauben. Ich nutze es nur für single player VR, aber schon da isses Gold wert.

    ja das habe ich auch vorerst benutzt. Trotzdem würde ich auch gerne die Logik dahinter verstehen.
    Weißt du denn noch genaueres darüber? Also bei mir scheint es ja irgendwie an dem Verhältnis von Server zu Client zu liegen... hatte das Protein Template auch mal als Vergleich herangezogen. Allerdings funktioniert diese Vorgehensweise bei meinem Projekt leider nicht:(

    Also Proteus funktioniert bei mir auch. Allerdings ist da auch seeeehr viel dabei, was ich gar nicht brauche.
    Mir geht es eigentlich im Prinzip darum zu verstehen, wie ein Multiplayer VR Projekt funktioniert.


    Ich habe es jetzt auch "FAST" hinbekommen. Ich habe die MotionController einfach direkt dem Character hinzugefügt. Also als Component quasi. Das funktioniert auch so. Server kann sich teleportieren, Client kann sich teleportieren und alle sehen die Bewegungen des anderen. Soweit so gut.
    Wenn der Server einen PickUpCube aufhebt, sieht das auch der Client. Umgekehrt jedoch nicht. Fehlermeldung ist leider die gleiche wie zuvor:


    UIpNetDriver::ProcessRemoteFunction: No owning connection for actor


    Hat jemand eine Idee?



    Übrigens:
    Wenn ich einen GetOwner Eintrag versuche ausgeben zu lassen, bleibt dieser leer...
    Siehe Screenshot

    Ich wüsste jetzt nicht genau, wie...
    Ich kenne den Node Set Owner, aber wen gebe ich da dann als Owner ein? GetPlayerPawn? oder GetPlayerController?
    Bei mir funktionieren allerdings beide Varianten nicht. :(

    OK, ich bin wie immer etwas late... Bevor ichs vergesse - ich bin hier der lokale troll. Also wenn ich was freches sage oder so dann kannst du immer auf mich schimpfen, kratzen beissen treten, ich kann das ab. Manchmal ist mein Deutsch auch etwas eingerostet, also ist es nicht immer so höflich.


    Also ich bin immer direkt, ist nie böse gemeint, ich bin einfach so.


    Aber back to topic...


    1. VR und Multiplayer sind 2 Konzepte, das kann man nicht so zusammenwürfeln. Beides hat so basics und es geht zusammen aber eigentlich sind es 2 topics. Und yeah - beides ist echt schwer als Project für einen Anfänger - zusammen - welcome to hell.


    2. Proteus ist ein super template, das ist sehr mächtig. Wenn du nur 5% davon benutzt ist das schon echt viel. Am Anfang ist das echt overkill - du denkst "Hey was ist Hololens, was willich mit rift, verdammter oculus store", geradewenn du nur ne Vive hast. Aber machst du ein commercial game, dann bist du irgendwann sowas von froh daß du das auch supporten kannst, denn dann hast du viel mehr potentielle Kunden. Das ist wie eine Schatztruhe, vielleicht denkst du am Anfang nur "hey ich will nen Diamant Ring", dann später denkst du "Wow ein Armband würde gut dazu aussehen" und am nächsten Tag "Mann eine Halskette steht mir gut". So ist das mit Proteus. Da ist viel drin, aber wenn du VR machst und du machst Multiplayer dann ist da echt verdammt viel drin was man brauchen kann - um ehrlich zu sein alles was man braucht und noch mehr.


    3. Der PickupCube. Der arme Proteus - er hat die function als Gag da reingemacht damit man im Single Player mit was werfen kann. Es war echt nur ein Spass von ihm. Aber ich wette er hat hundert mails dazu bekommen. Der arme. Ja aber gutes training für Multiplayer. Was da fehlt - kommen wir zum nächsten Punkt.


    4. Replikation. Ja proteus hätte den PickupCube replizieren können. Hat er aber nicht. No sir - Proteus ist nicht gemein oder böse. Er will daß du verstehst was du tust. Ja du kannst jemandem einen Fisch geben oder du kannst ihm angeln beibringen. Proteus kann dir nicht aneln beibringen aber er will daß du es lernst - damit du ihn nie nach einem Fisch fragst. Klingt sehr mythisch. Aber Replikation ist das Herzstück von Multiplayer. Jetzt muß ich ausholen. Du siehst - Bewegung ist repliziert. Das lässt sich nie vermeiden. Egal was für ein Online Spiel du spielst du siehst immer die Replizierte Bewegung aller anderen Mitspieler. Aber selbst hier ist eine Gefahr. Ja was für eine Gefahr? Ich könnte ein sehr langes Buch über Replikation schreiben und warum das ALLES ist woran ein muliplayer game stirbt oder lebt. Die Gefahr nennt sich "Cheater". Dazu muß man das Client/Server Konzept verstehen. So ziemlich alle namenhafte Multiplayer Spiele haben einen Server. Der ist auch vom Betreiber gestellt und macht auch Sinn - wegen cheating. Kein Server kein Schutz vor Cheatern. Also wie hilft der Server? Er bestimmt die meiste Replikation. Das wichtigste um Cheatern vorzubeugen ist die Replikation - geauer - was wird von wem wohin repliziert? In einem Shooter zum beispiel sehen wir uns die Replikation an. Du bewegst dich. Wird von deinem Client an den Server und somit an alle repliziert. Du tätigst den trigger, also schiesst du.Wird von dir an den Server repliziert. Die Flugbahn der Kugel und ob die durch den Kopf eines Gegners geht? Wird nicht von dir repliziert. Nie. Warum?Weil cheater sonst einfach die Aktion "meine Kugel tötet Gegner XY" repliziert. AUch wenn er gar nicht geschossen oder in die Richtung von XY geschossen hat. Ich glaube jetzt verstehst du das Prinzip. Noch extremer bei loot. Sagen wir malin dem Spiel schiesst du auf Zombies und die lassen eine Münze fallen. Der Spieler habt die durch Druck auf "X" auf. Erst mal cool. Was macht der Cheater? Der hebt alle Münzen immer automatisch auf - evtl auch wenn er gar nicht in der nähe ist. Repliziert das der Client dannist der Cheater ein Münz Staubsauger. usw.


    5. Fazit - es gibt viele Dinge wo du Mist bauen kannst und es ist nie schlimm. Machst du bei der Replikation Mist ziehst du im Multiplayer Cheater an wie ein Misthaufen die Fliegen und du hast immer Ärger und alle legit Players werden quitten.Lerne alles was du kannst über "Replikation" und mach dir gedanken und Konzepte bevor du in die testen haust - alles was der Client repliziert ist manipulierbar. Selbst die Bewegung - da hast d dann Cheater die laufen 10 mal so schnell, teleportieren sich ne Meile weit und fliegen in der Luft. Das kann man aber über Plausi Checks (Movement Geschwindigkeit, Abstand zum Boden, usw) abfangen und die bannen. Alles andere ist schlimmer und schwieriger.Viel probieren, viel Studieren, viele beta tester. Multiplayer ist die Königsdisziplin. Habe 100 nette Beta Tester und nie Probleme. veröffentliche das Spiel und habe 1000 Cheater die dasSpiel kaputt machen. Nur so als Warnung. Cheers!

    Danke für die ausführliche Antwort.
    Weißt du denn ob im Proteus wirklich alles Blueprint ist, oder auch C++?
    Wenn ich versuche deren Vorgehensweise nachzumachen, funktioniert das nämlich leider gar nicht.


    Trotzdem würde ich gerne wissen, wie ich das Problem mit der fehlenden OwningConnection beheb... Habt ihr dazu noch einen Ratschlag?

    Proteus Steam/LAN ist Blueprint only. Bei der Oculus Store Version musste aus technischen Gründen C++ eingebunden werden, merkst du aber nur beim kompilieren (Brauchst Visual Studio).


    Was versuchst du denn nachzumachen?


    OwningConnection fehlt total bei Actors die im Editor in die Map geworfen wurden. Die gehören erst mal niemand. Wenn du einen cube vom Player spawnst dann ist der Player auch owner. So ist es niemand. Am einfachsten ist es den cube zu killen und vom Player aus zu spawnen wenn er ihn aufhebt.

    ok. Das habe ich verstanden.
    Aber wenn ich jetzt die motioncontroller zuordnen möchte gehe ich Wie folgt vor.
    Im Lobby Game Mode wird der playercontroller des Klienten, als auch der Server festgelegt.
    Im Lobby Menu (Widget) kann man dann seinen character auswählen. In diesem Fall nimmt der Server Player 1, der motioncontrollerpawn also. Der Client nimmt Player 2, ebenfalls motioncontrollerpawn. Führe ich auf dem motioncontrollerpawn einen print string aus, bestätigt dieser mir, dass Player 1 Server und Player 2 Client ist. Soweit so gut. Jetzt spawned der Server beide motioncontroller und attached diese an sich selbst. Der Client macht genau das gleiche, nur funktioniert es bei ihm nicht, die Hände spawnen lediglich bei 0. Und der Client kann diese auch nicht bewegen. Im Gegensatz zum Server. Dieser sieht, sobald der Client spawned beide Hände an der richtigen Position des clienten. Allerdings sobald ich auf dem Server die motion Controller bewege, bewege ich zeitgleich auch die des clienten in Sicht des Servers. In Sicht des Clients bleiben diese unverändert.
    Hier muss also schon bei spawnen und zuweisen irgendwo der Fehler liegen... :(

    Blöde Frage - aber den Playercontroller replizierst du nicht, oder? Der existiert nämlich schon auf dem Server. Grundsätzlich - was du spawnst solltest du auch replizierenwenn es für andere sichtbar seinsoll. Kann es sein daß du den motioncontrollerpawn nicht replizierst?



    Edit: Die Motioncontroller sollte auch der Playercotroller oder zumindest Posessed pawn spawnen.