Beiträge von MadeByProxxy

    Ich würde grundsätzlich als Anfänger davon abraten sowas selbst zu machen

    Ich hab es jetzt auch gelassen und hab lieber wieder auf die guten alten Zombies zurückgegriffen. Zwar hat man damit nicht so viele Möglichkeiten was das Aussehen angeht, aber besser als gar keine bewegenden Viecher.


    Damit ich diese nun verändern kann (von der Bewegung her), hab ich sie mit Pathfinding (mit diesem Tutorial hier) gespawnt: https://www.spigotmc.org/threa…rgoals.18519/#post-193576


    Jedoch wird der einfach nicht gespawnt.. Ich hab mir die Location ausgeben lassen, die stimmt. Die Welt ist die richtige, die Methode wird 100%ig aufgerufen und Fehler in der Konsole kommen auch keine. Ich kann dafür auch gerne nochmal einen neuen Thread öffnen, aber es ist ja im Prinzip das gleiche wie bei den NPCs.

    Ganz ehrlich, für dieses Ziel sehe ich nach deinem scheinbaren Kenntnisstand keine Möglichkeit, das zu erreichen.

    Hm ja, kann sein. Ich werde dieses Projekt aber nicht aufgeben und es stattdessen lernen. Eine letzte Frage hätte ich noch: Dieses Attach-Packet besteht ja aus 3 Daten oder wie auch immer man die enthaltenen Daten nennt. Einem Integer und zwei Entities. Den Integer lasse ich erstmal "0" und eines der beiden Entities ist mein ArmorStand. Nach dem Code, den ich dort habe, habe ich ja von dem NPC nur die Entity-ID, die das Entity einzigartig macht. Aus dieser ID kann ich aber kein Entity bekommen, was ich dann für das Packet nutzen kann. Heißt das, ich muss das Entity an sich aus dem Packet heraus auslesen oder wie soll das genau klappen?

    Dann machst du etwas falsch. Das Protokoll ist dokumentiert, du kannst dir selbst durchlesen, was die Datenfelder für eine Bedeutung haben. Das erste "Relative Move"-Paket nimmt also eine Änderung von X-, Y- und Z-Koordinate entgegen, aber nicht in Blöcken, sondern in Einheiten von einem zweiunddreißigstel Block. Wenn du da Blöcke reinpackst, oder der Wert aus anderen Gründen ungültig ist, funktioniert es nicht. Richtig genutzt ist es aber für normale Bewegungen die beste Wahl

    Genau, das mit den "Block"-Einheiten wusste ich, daher habe ich die Zahlen mit 32 multipliziert und ihn dann dort hin "laufen" lassen. Ich habe immer die gleichen Daten im Command gehabt, mal ist er hoch geflogen, mal runter, mal links etc. Hab mir auch das Packet mal angeguckt, was dort überhaupt alles rein muss, aber so, wie ich es in den Dokumentationen gefunden habe, war alles anscheinend richtig eingestellt.


    Man Ziel ist es halt, dass der NPC zum Spieler hin läuft und ihn schlägt, wie eine Art Bot. Dafür ist vermutlich doch das EntityPlayer besser, oder? Bzw. für mich einfacher zu kontrollieren, anstatt mit Packets wo ich (fast) keine Ahnung von hab.

    Was ich vielleicht noch vergessen hab mit reinzuschreiben: Die Frage, wie der sich bewegt.

    Hab es mit 2 Packets versucht: PacketPlayOutEntity.PacketPlayOutRelEntityMoveLook und mit dem PacketPlayOutEntityTeleport.


    Problem: Das MoveLook Packet teleportiert den NPC sonst wo hin.. Irgendwie kann ich das nicht kontrollieren.

    Das Teleport-Packet ist gut, da kann ich bestimmen, wo er hin geht. Die Geschwindigkeit, bis sie da sind, ist die gleiche bei beiden. Kann man die Geschwindigkeit irgendwie verändern? Bzw. verlangsamen?

    Ich würde dir wirklich davon abraten, so vorzugehen.

    Ich weiß. Wobei ich mir den Code auch angucke und nicht einfach nur einfüge in meinen Code und hoffe, dass er geht. Ich bemühe mich den Code zu verstehen, was meistens auch klappt. Nur bei Packets tu ich mich schwer.

    So, der ArmorStand wurde jetzt gespawnt, wie bekomme ich ihn jetzt aber zum NPC? Ich könnte ihn jeden Tick teleportieren, aber das wäre sicher nicht sehr performancefreundlich denke ich mal..

    Guten Tag,

    da ja die Namen von Spielern und somit auch von NPCs nicht länger als 16 sein dürfen (so ists bei mir zum Mindest), muss ich den NPCs ein Rüstungsständer mit dem Namen auf den Kopf setzen bzw. als Passenger.

    Zum Spawnen der NPCs benutze ich den Code von GERVobis, weil ich selber nicht ganz genau weiß, wie das funktioniert. Hier einmal der Code, falls manche nicht wissen, wie der aussieht:


    Hier ist nochmal die Reflections-Klasse:


    So. Es gibt dort oben ja eine Entity-ID (NPC-Klasse). Wie kann ich diese zu einem Entity verwandeln, sodass ich dem Entity einen Armorstand als Passenger setzen kann?

    Danke für die Hilfe!


    MfG,

    Proxxy

    Hm, das wäre mir tatsächlich neu. Bist du dir sicher, dass es von der Blickrichtung abhängt?

    Ich habe mal beim Joinen, wo die NPCs also neu gesetzt werden, F5 gedrückt und somit nach hinten geguckt.

    Dann wurden nur die hinteren NPCs geladen. Die vorderen hatten dann keinen Skin mehr

    Das liegt daran, dass du du das PacketPlayOutInfo Packet ein bisschen verzögert nach dem Spawnen des NPCs senden musst.

    Viiielen Dank! Ich hab soo lang nach einer Lösung gesucht und keine gefunden, danke!

    Eine Frage hätte ich da noch: Nehmen wir mal als Beispiel Hypixel. Die haben ja unendlich Custom Heads und Skins bei NPCs oder als Item.

    Ich meine mal gehört zu haben, dass man eigene Köpfe mit eigenen Skins einfügen kann, ohne einen Account zu besitzen. Geht das oder geht das nicht?

    Habe keine Lust mir nur dafür 8 Accounts zu kaufen.


    MfG


    Okay, ein Problem gibts dabei dann doch noch.. Es funktioniert nicht immer und nur für die 4 NPCs, die in der Richtung liegen, in die ich gucke. Alle hinter mir bekommen den Skin nicht.

    Liegt es daran, dass der Chunk nicht geladen ist?

    Guten Tag nochmal,


    ich wollte dieses Thema nochmal in einem neuen Thread aufgreifen, da es 1. nicht zum alten Thread gepasst hätte und 2. dieser eh abgeschlossen war.

    Ich habe auf meinem Server NPCs, die soweit auch funktionieren. Heißt die stehen da, gucken in die richtige Richtung, haben einen Namen und halten ihr Item.

    Jedoch haben diese keine Skins.

    Ich bin leider auch nicht wirklich in der Packet-Sache drin, deswegen habe ich die NPCs damals von GERVobis "abgeschrieben".

    Mein Problem:

    Es gibt 2 Möglichkeiten der NPCs: 1. sie haben Skins, sind aber in der Tabliste zu sehen oder 2. sie haben keine Skins, sind dann aber auch nicht in der Tabliste.

    Ich weiß echt nicht, wie man es hinbekommt, dass sie Skins haben und nicht in der Tabliste sind..


    Hier der Code:

    Und der remove-Tab:

    Wenn ich das rmvFromTablist(); aus der Methode rausnehme, dann geht es, aber sie sind dann, wie gesagt, in der Tabliste sichtbar..


    Ich hab gerade nochmal etwas getestet: Wenn ich den Skin vor der Tab-Sache setze, dann kann man ihn teilweise sehen. Aber nur bei einem von meinen 8 NPCs und auch nur sehr selten.


    MfG

    Danke. Warum ich es nicht asyncron hatte... Weiß ich nicht. Vermutlich, weil das System noch aus früheren Zeiten ist.


    Dann gibt es da noch das Problem, was ich bei vielen Anfängern sehe.

    Das stimmt leider.. Mit MySQL hatte ich nie viel zutun, gerade weil das ab und zu bei mir macht, was es will.

    Ich werde mal gucken, dass ich die Datenbank cachen kann und alles mal asyncron laufen lasse.

    Was mich dann jedoch wundert:

    Wieso funktioniert es dann bei allen anderen Tables einwandfrei? Da müssen viel mehr Daten als nur diese 4 oder 6 Daten geladen werden.. Und das Inventar öffnet sich sofort, ohne lange rumzuhaken. Die anderen Inventare sind ebenfalls syncron. Da müsste es doch theoretisch noch viel länger laden, oder?

    Also ja, Code wäre hilfreich.

    Okay, das hier z.B. ist für das Getten, ob man den Arrow hat:

    In die MySQL wird folgende Tabelle eingetragen:

    Code
    PreparedStatement stat5 = connection.prepareStatement("CREATE TABLE IF NOT EXISTS GameKnockFFA(UUID varchar(64), KnockLVL2 int, JumpBoost int, Bow int, Arrow int, CoinBoost1 int, CoinBoost2 int, CoinBoost5 int);");
    stat5.executeUpdate();
    stat5.close();

    Für das Inventar wird 4x diese Abfrage ausgeführt (für alle 4 Items).

    Connected wird die Datenbank so:

    Code
    public void connectMySQL4() {
    try{
    me.madebyproxxy.spigot.rc.lobbysystem.utils.mysqlGadgets.MySQL.connect("*****", "******", "******", "******", 3306);
    }catch (SQLException e){
    e.printStackTrace();
    }catch (ClassNotFoundException e){
    e.printStackTrace();
    }
    }

    Die anderen Gadgets laufen über die gleiche Datenbank und bei denen muss das Inventar viel mehr abfragen.. Und es lädt sofort.

    Eine wichtige Sache vielleicht noch:

    Wenn man auf der Lobby 1x das Inventar mit den Gadgets geöffnet hat & dann wieder schließt, dann öffnet es sich beim nächsten Mal auch instant.

    Wenn jedoch ein anderer Spieler dann das Inventar öffnet, lädt es bei diesem Spieler ebenfalls 2 Sekunden. Ein Timeout etc. kann es also nicht sein.

    Das gleiche gilt übrigens für die CoinBooster, die da noch mit drin sind in der Tabelle.


    Btw. ja, ich weiß.. Diese Art der Speicherung der Gadgets in der MySQL ist nicht die effizienteste und performance-schonendste, aber es geht bis jetzt.. Sobald das ganze lädt, kümmere ich mich um eine bessere Speicherung,

    Guten Abend zusammen,


    ich habe ein Problem mit meinem Lobby-System. Auf meinem Lobby-System gibt es, wie bei vielen, Gadgets. Man kann z.B. Gadgets für den Spielmodus "KnockFFA" gewinnen oder CoinBooster für 2 Spielmodi.

    Diese kann man dann per Inventar anzeigen lassen - in der Lobby.

    Das Problem jedoch ist, dass das Inventar 2 Sek braucht, um sich zu öffnen.

    Genau so ists dann beim Chest-Opening. Der Gewinn wird als Hologramm dargestellt, auch das braucht 2 Sek, um angezeigt zu werden.

    Die einzige Möglichkeit, die mir da einfällt, ist, dass es an der mySQL liegt.

    Jedoch kommen keine Fehler im Log dazu. Reconnecten tue ich diese oft genug, daran darf es also nicht liegen.

    Ich verbinde diese genau wie alle anderen Datenbanken, die ja auch schnell arbeiten.


    Falls Code benötigt wird, schicke ich diesen gerne noch hinterher.

    Vielleicht hat aber auch so schon einer eine Idee.


    MfG

    Okay, ich habe wieder den selben Fehler wie beim letzten mal eingebaut... n++ nochmal durch ++n ersetzen mit selbiger Begründung wie vorhin...


    Und dann noch vielleicht eine Idee: ich weiß nicht, wie intern die Disconnects gehandelt werden - ob der Spieler sofort disconnected wird, also sozusagen direkt nach p.disconnect(...) auch der Disconnect-Listener aufgerufen wird, oder aber ob das Event erst abgehandelt wird und dann der Spieler tatsächlich disconnected wird oder oder oder... ersteres wäre nämlich schlecht, dann würde die Spieler-Referenz nämlich für immer in der Map verweilen und es würde ab diesem Zeitpunkt immer ein Spieler auf dieser IP zu viel gespeichert sein -> Memory-Leak. Erste kurze Recherchen sagen mir, dass 250ms gewartet werden (aber nicht etwa, um solche Bugs zu vermeiden, sondern wegen irgendwelchen Minecraft-Protokoll Interna), das sollte reichen... an der Stelle bin ich aber auch vom Bungee API Design nicht so wirklich begeistert, weil das doch schon durchaus zu Fehlern (insbesondere auch eben zu Memory-Leaks) führen kann, wenn man Spieler-bezogene Daten im PostLoginEvent speichert.


    Falls dich das alles nicht so wirklich interessiert und du zufrieden bist, wenn dein Plugin funktioniert, ignoriere den letzten Absatz und verbessere einfach den oben genannten Fehler nochmal.

    Vielen Dank!

    Soweit funktioniert es nun. Der Absatz interessiert mich schon, jedoch komme ich mit den ganzen Infos etc. noch nicht so ganz zurecht. Ich werde probieren es zu verstehen ^^

    Okay, ich habe das jetzt so, wie du es mir geschrieben hast, angepasst. Funktionieren tut es jedoch immer noch nicht.

    Ich habe mal "n" beim Joinen ausgeben lassen. Das hier ist der Ausschnitt aus dem Log:


    Ich habe das ganze mal ein wenig anschaulicher zusammengebastelt.

    n = vor dem Ändern des Integers, n (2) = nach dem gesamten Event, wenn "n" also verändert wurde.


    Alle Accounts kamen übrigens auf den Server.

    Okay,

    habe ich soweit geändert, jetzt geht es auch. Jedoch ist das ganze noch sehr verbugt.

    Wenn man den Proxy restartet und 2 Accounts joinen, dann ist n bei 2. Sobald ein dritter joinen will, wird dieser gekickt.

    Wenn jetzt jedoch ein Account den Server verlässt, dann ist n wieder bei null. Heißt dann können 2 neue wieder rauf. Das ganze ist auch passiert, als der dritte Account ein paar mal gejoint ist, bzw. als sich eine Lobby restartet hat (Wobei das mit der Lobby nichts zutun haben sollte). Dann war n wieder bei null und der dritte Account kam rauf.

    Errors kommen keine.

    Hier nochmal der aktuelle Code dazu:


    Code
    Integer n = ips.get(playerIp);
    if (n == null || n < maxPlayersPerIp) {
      ips.put(playerIp, n == null ? 1 : n++);
    // Kann joinen
    } else {
    // Halt stopp!
    }

    Ich habe es jetzt genau so gemacht, wie du es hier geschrieben hast. Statt KannJoinen habe ich eine Nachricht ausgegeben, statt Halt stopp habe ich den Spieler disconnected.

    Die Nachricht kommt auch, jedoch konnten 3 Accounts von mir joinen. Also habe ich mal n beim Joinen ausgegeben. Beim 1. Acc kam "null", beim 2ten Acc kam "2" und beim dritten kam ebenfalls "2", aber dieser wurde nicht disconnected.

    Bist du sicher, dass der Listener wirklich registriert ist? Fehler gibts auch keine?

    Ja, ein Fehler kommt, und zwar eine NullPointerException in folgender Zeile:

    Code
    if(ips.get(p.getAddress().getHostName()) <= 2){

    Der Code ist der gleiche wie oben.

    Mittlerweile wird man auch gekickt, wie ich es im Listener programmiert habe. Jedoch nicht erst, wenn mehr oder gleich 50 Leute drauf sind, sondern immer, wenn man die Permission nicht hat.

    Heißt also, irgendwie wird die Abfrage mit der Spieler-Anzahl übersprungen oder diese Zeile gibt nicht die Spieleranzahl zurück.

    Okay, ich habe das ganze jetzt so umgeschrieben:

    Jedoch bekomme ich weder die Nachricht, noch werde ich bei einem Online-Player gekickt.

    Wie gesagt: Der Listener ist aber registriert, die anderen Listener funktionieren.

    Naja, wenn du beim Disconnect von einem User die IP Adresse aus der Map entfernst und noch ein User mir der Adresse auf dem Server ist, können ja wieder zwei weitere Spieler mit der Adresse drauf.


    Die Methode die du benutzt um die IP Adresse zu bekommen sollte passen.

    Oh stimmt..

    Daran habe ich gar nicht gedacht. Gut, also um eins verringern, wenn sie aber 1 ist, dann entfernen.