Beiträge von Shura

    Das Problem ist, das bei der Erstellung des HUD (Event Construct) ne Variable definiert wird, die im MP nicht gültig bzw. korrekt ist wenn es nicht der Server ist.
    Verzichte auf das befüllen im Event Construct und frage den playercharacter direkt ab wenn Du sie brauchst.

    Sobald ich im MP bei den EventConstruct die Variable localPlayer definiere (wie im Video) und die auch als Binding verwende, läuft der HUD beim Client gegen die Wand.
    Wenn ich allerdings beim Binding direkt die Referenz auflöse (also get und cast) läuft alles sauber.
    Hatte bei meinem Test das EventConstruct (aus unnötigkeit) weggelassen, weshalb es erst jetzt mir aufgefallen ist.


    Hintergrund kann ich nur mutmassen, der HUD ist am PlayerCtrl gebunden, der Pawn allerdings wird erst vom Server erstellt und dann dem PlayerCtrl übergeben. Denke mal das die Referenz einfach zu früh gesetzt wird im HUD auf den localPlayerCharacter.


    Wenn Du mehr Prüfungen einbaust, würde sowas schneller auffallen.
    Bei MP kann es schnell sehr tricky werden, Du wirst es nicht bereuen ;)

    Wohl wahr Exclusiv... startet ja beides in verschiedenen Threads. War nicht ganz zu ende gedacht -.-


    Aber zu Deinem Fehler... setzt Du auch den Wert des Clients der den ServerRPC macht korrekt ? Oder setzt Du nicht einfach nur den Serverwert ? ;)
    Also nicht einfach nen set [value] nach dem authority check machen, sondern auch vom korrekt playerchar den value setzen.
    //edit: also das target fürn RPC übergeben


    Habs gerad mal nach gebaut und es funkt so wie es sein sollte, ka wo bei Dir der Fehler ist.
    Allerdings musst Du auf das Binding achten, das Binding ist immer nur auf Basis das Viewportgebundenen Actors. Siehe Beispiel:
    Links, Oben == Echter Wert
    Kopf, Links == WidgetBinding Value für alle Sichtbar
    Kopf, Rechts == Reeler Wert korrekt repliziert

    Debug ausgabe und Prüfung schon reingemacht ?
    IsLocalController() oder IsLocalPlayerController() `müsste für prüfen ob es gerade für den lokalen Spieler (Client Window) ist.

    Finde die aktuelle Aufteilung sehr übersichtlich, also schonmal nen thumbs up von mir ;)


    Entwicklung: Allg, BP, C++, Mobile, VR
    Grafik&Sound: inkl. Showroom
    Allgemeines: inkl. Projekt Vorstellung

    Bin jetzt kein Experte was MMO Server Farmen angeht, aber afaik ist das Engine unrelevant bzw. BESSER: nicht von der entscheidenden Tragweite wie man im ersten Moment vermutet.
    UE hat Netzwerkunterstützung sozusagen out of the box und (mit dem KnowHow) kannst Du auch "einfach" Dein eigenes Layer machen.
    UE hat eine Schwäche was das replizieren von vielen vielen Dingen (in der Anzahl) angeht mit dem out of the box netzwerk (zumindest sagt das Epic immer wieder).


    (das ist jetzt rein Mutmassung) UE ist halt initial für Egoshooter ausgelegt und damit auf schnellen und effizienten Datanaustausch in einer überschaubaren Masse, keiner mag nen Ballerspiel mit Lags bzw Desyncs ;) Das heißt nicht das man nichts anderes damit machen kann, definitiv nicht, aber es kann halt effizientere engines geben für spezielle bereiche.


    Bei einem MMO vs. einem Multiplayerspiel mit sagen wir <= 64 Spielern ist der unterschied, das beim 64er (in der Regel) ein Server für das Spiel läuft und (ebenfalls in der Regel) das nur lokal (Server) persistiert ist, bei nem MMO sind das viele Server für verschiedene (lvl)Bereiche und beim Wechsel wird dein Char sozusagen auf den anderen Server übergeben, abgesehen davon sind dann noch server die die server balancen, nur die inventories und chars verwalten, authentification machen etc etc etc


    Schlussendlich verbindest Du dich halt mit 1-n Servern und hast noch Authorisierungsmechanismen dazwischen, also kein grosses Hexenwerk auf dem Papier ;)


    //dlay war schneller, (0.o) hab 22 minuten zum schreiben gebraucht

    Mit dem Check "HasAuthority" hat Exclusiv recht, sollte (laut Epic immer !) zusätzlich verwendet werden bei ServerCalls.


    Bin mir aber gerade nicht so sicher wie Du die Realsierung des Scoreboard gemacht hast bzw. die Umsetzung des beschriebenen Ziels.


    PlayerState hat jeder PlayerController inne und der wird auch repliziert, d.h. für ne Scoreboard müsste eigentlich ne abgeleitete Klasse mit den replizierten Properties für die Score des jeweiligen Spielers.
    Der Server (genauso wie alle Clients) können dann über GetWorld->GetGameState()->PlayerArray die States casten und an die Values mit zugehörigen Spieler kommen.
    Dort kannst dann auch die serverseitige Manipulation des Scores vornehmen um es um die alten (bereits erbrachten) zu erhöhen sobald der Spieler sich verbunden hat (bedenke wie Du die Einzigartigkeit des Spielers realisierst ;)).
    Also damit wäre schonmal das asynchrone Problem eleminiert.


    Mit RPC's in BP hatte ich bisher nur schlechte Erfahrungen, aber das liegt auch schon viele (BP&MP verbuggte) Versionen zurück. Kann da leider nicht helfen ausser dem was Exclusiv sagte zustimmen.


    Was die Speicherung betrifft, ohne Dir jetzt zu Nahe treten zu wollen, würde ich für so einfache Datenstrukturen dann eher ne CSV als ne MySQL DB nehmen.
    Entweder mit Rama's Plugin über BP oder direkt in C++ (ist nicht so schwer ;))
    Links: C++ Realisierung, AnswerHub Guide für BP

    Da die Räume der Häuser doch recht klein sein und die Cam fix, würde ich pro Haus ne Map machen und pro Raum dann einfach den pawn umplatzieren, aber das ist Geschmackssache.


    Die Kämpfe sind ja doch recht schlicht gehalten (Video 1), da würdest Du wahrscheinlich mit einem HUD Change schneller zum Ziel kommen. Background, Sprites bzw Pokemon Grafiken und Co müssten halt parameteriesiert sein.


    //Edit: Der Kampf selbst, die Startanimation ist wieder was anderes, sorry war im Video vorgesprungen und hatte das "Intro" erst nicht betrachtet..

    Moin,


    bin mir nicht so sicher ob ich Dich richtig verstanden habe, aber ich probier es mal.
    Das ist jetzt ein instiktiver Ansatz, also defentiv nicht die beste Möglichkeit.


    Wenn Kampf in 3D ablaufen soll, bringen Widgets dir nichts bzw sind viel zu aufwendig.
    Ich vermute mal stark das Du ein SinglePlayer Spiel machst.. also warum dann der Kampf nicht auf dem Platz wo sich das Pokemon oder der Trainer(?) befindet ?
    Einfach die relative Camera vom Character so geschickt bewegen das sich der Eindruck eines "Tribünen" Platzes am Rande des Schauplatzes schlussendlich ergibt. (Also das wäre z.B. links vorne tief und um 90° nach rechts gedreht)
    Alternativ und ein Tick komplexer wäre den Pawn zu verlassen und den PlayerController in einen anderen Pawn possen, der als virtueller Zuschauer fungiert. Der könnte dann auch das "Kampf UI" von dem Pokeman haben z.b.

    Schau mal hier: https://docs.unrealengine.com/…ework/GameMode/index.html insbesondere das [Blockierte Grafik: https://docs.unrealengine.com/latest/images/Gameplay/Framework/GameMode/WorldSettings_GameMode.jpg]


    Bei deinem anderem GameMode muss auch der TopDownCharacter(BP Version) (z.B. vom Titel her aus dem Screen) stehen als DefaultPawnClass.
    Denke mal nicht das Du diesen Wert zur Laufzeit manipulierst ;)


    Bin gerade auf den Sprung, deshalb nicht so ausführlich.

    Ist ja auch keine Revolution, aber zu wissen ob der "Inhaber" erreichbar ist bzw. bereit ist auch das auf unbestimmte Zeit das Forum fort zu führen ist schon relevant.
    (Fortführung kann ja auch auf Spenden beruhen, diese Domain kostet afaik 8,53$/jahr, ka was da im Moment noch alles hinten dran hängt)


    Schlussendlich ist es ja auch Arbeit die man hier rein investiert.
    Wenn jetzt die Domain im August ausläuft, wird das Forum vermutlich nach einer Karenzzeit gelöscht und alles ist fürn A...


    Was die Überschautbarkeit betrifft ist ein "OFFEN", "GELÖST" etc.. im Subject ganz sinnig, kann aber auch der Threadersteller machen (ggf. darauf hinweisen).
    Zusätzlich würde ich für Tags stimmen, sie wären meiner Meinung noch sinnvoller bzw. wenn mehr Threads da sind ist es einfacher zu filtern.

    Wenn Du alles in C++ machen möchtest kannst Du auch gleich Slate nehmen, das ist für C++ besser dokumentiert und UMG baut afaik nur darauf auf. Ist sozusagen die Blueprint Variante davon, aber mag mich irren, hab es noch nicht so mit GUI.


    Ansonsten kann ich Exklusiv nur zustimmen, Slots sind der Dreh und Angelpunkt der Widgets.
    Aber so wie ich dein Ziel interpretiert habe, ist vielleicht ne Wrapbox mit nen "Kategorie Schalter" einfacher und effizienter.

    Schaut gut aus. :) Habs nicht getestet also folgendes ohne Gewähr.


    Was wäre wenn Du das ENUM EQualityLevels um ein "unset" oder ähnliches erweierst (was dann 0 sein sollte). Der würde als Default geladen und beim SetScalabilityQuality kannst Du gegenprüfen ob der Wert überhaupt geändert wurde.


    So könnte man bei einem SetScalabilityQuality ggf. nur die Werte ändern die man ändern möchte und die anderen würden bleiben wie sie vorher eingestellt waren.
    Ansonsten müsste man aktuell (so wie ich den Code intepretiere) immer ein GetScalabilityQuality voranschalten um die anderen Werte auf den aktuellen Stand zu lassen, wenn man das vergisst würde man alle anderen Parameter auf low reduzieren.


    Auch wenn Ihr das wahrscheinlich über das Menü machen wollt, wo dann die Werte erst eingeladen und dann ausgelesen werden. Das Menü kann sich aber auch schnell ändern (z.B. erweiterte Grafiksetting) irgendwann mal, wo nur ein Teil der Optionen im Direktmenü sind und die anderen in nen Untermenü.


    Nur so ne Idee
    Gruß Shura

    Hi,


    bin letztens auf folgenden Link gestossen und fand diese Zusammenfassung ganz brauchbar.


    https://www.unrealengine.com/resources (Epic Informations Sammlung)
    https://unreal-engine-4.zeef.com/tom.looman (Tom Looman Zusammenfassung von Quellen)
    http://www.kitatus.co.uk/ Kitatus Tutorials


    Wäre schön wenn wir hier mal einen Linksammel Thread machen können.
    Das Wiki und die Docs sollten ja allen bekannt sein.



    //edit: Add Tom Looman 16.04.2015
    //edit: KITATUS 21.04.15

    Nur der Vollständigkeithalber... (nicht das ich als Nekrophil gelte ^^)


    Wenn man einen Tag in den ComponentTagArray definiert muss man auch in den Componenttags suchen.


    comp->ComponentHasTag(...)
    oder
    comp->ComponentTags.Cointains(...)


    An die Components kommt man über die Actor Methode GetComponents() und die Rückgabe ist ein TArray<UActorComponent>


    Gruß Shura

    Hi,


    würde Dir empfehlen statt über die PlayerController über den GameState zu gehen.
    Tick Verwendung würde ich wenn immer möglich anderweitig lösen..... also so wenig wie möglich, so viel wie nötig.


    Beispiel wäre dann
    ServerFunction (colorChange, team, time)
    GameState sollte ja auch die Teams kennen und kann dann gezielt nur die PlCtrl ansprechen die dem Team gehören mit einer ClientFunction (? theorie, ungetestet)


    Ansonsten kann man natürlich auch vars breitquatschen
    [rep] Effect_T1 (Struct)
    [rep] Effect_T2


    Viel Erfolg
    Gruß Shura