Posts by PatrickOtt

Hab noch etwas gefunden:

showInventory(Player player)

Zeigt das Intentar eines anderen Spielers

Quote from Deirdre

Warum? Das hieße zwangsläufig, dass der Server ein bestimmtes Texturpack vorschreibt. Ob das im Sinn von neuen Spielern ist, wage ich zu bezweifeln.

Die Diskussionen über serverseitige Texturen hatten wir vor Jahren schon.

Nein. Der Server soll nur Empfehlen. Der Spieler soll schon selbst entscheiden, ob er das Texturpack übernimmt.

Hallo red51 ,

wie kann man mit der API sagen, dass ein NPC sich z.B. ein NPC um 90 Grad nach rechts bzw. nach links dreht?

Aber red51 , es wäre Super, wenn ein neuer Spieler kommt, dass der Server ihm ein Texturpack empfihlt. (Solte man in der Config regeln)

Wie wäre es mit Texturepack

Es wird dringend Empfolen allen Serverbetreiber das Update zu installieren, da auch in der 1.2.0 viele Bugs behoben worden sind. In der Alten Version gibt es noch in den Events Bereiche, die zum NULL-Fehler führen können!

Das Plugin ist jetzt aktualisiert und enthält jetzt alles, was gebraucht wird.

Hab es mit einer Kuh versucht. Hat wunderbar funktioniert.

Was soll ich noch sagen? Hier wurde schon alles geschrieben, was man dazu sagen kann.

Ich frau mich sehr auf die Demo. Auch wenn ich es kaum noch erwarten kann.

Da kann man ja richtige Pässe bauen und ein Ski-Gebiet wäre auch nicht schlecht.

Jetzt fehlt nur noch eine Gondel oder so was.

UPDATE 1.2.0

Hallo Leute,

das Update 1.2.0 ist da. Wie immer im ersten Beitrag.

Was neu ist, habe ich ja schon in die Vorankündigung geschrieben.

Außer einer Sache: Der Befehl /amt gethere brauch keine ID, wenn es mit /amt select bereits auswählt worden ist.

UND: Mit /amt free können Eigentümer (oder Admins) die NPCs wieder wild machen!

Viel Spaß damit.

Ich freu mich auf Feedbacks.

Download here: Download

Vorankündigung Version 1.2.0

Hallo Leute,

es wird nicht mehr lange dauern und die Version 1.2.0 ist draußen.

Was wird es alles neues Geben?

1. Ab dieser Version können nicht nur Pferde, sondern alle NPCs eingetragen werden. (Auch Monsters)
2. Nicht reitbare NPCs können mit dem Befehl /amt select (danach mit NPC interagieren) - kann jeder nutzen - ausgewählt werden
   Natürlich nur wenn:
   > NPC noch wild ist (Kein Eigentümer vorhanden) - Man wird dann automatisch zum Eigentümer
   > Man selbst der Eigentümer ist
   > Man Admin ist
3. Fernzugriff auf NPCs mit Befehl: /amt select [ID] (Das schönste: Jeder kann diesen Befehl nutzten)
   > Die IDs eurer NPCs bekommt ihr mit dem Befehl: /amt getlist (mit Name, wenn vorhanden)
   > Admins können jedes NPC auswählen (auch wenn es einen Eigentümer hat)
   > Neue Funktionen durch Fernzugriff:
   >> NPC kann zur Spieler-Position teleportiert werden
   >> Die Position des NPCs kann im Chat ausgegeben werden
   >> NPC kann gelockt werden (NPC bewegt sich nicht mehr) - Nur einsetzbar bei nicht reitbaren NPCs
   >> Alle anderen Befehle wie Name ändern, funktionieren auch
4. Admins können alle NPCs zu Spezial-NPCs machen. (Typ wird automatisch festgelegt, wenn nicht reitbar)
   Vorteil: NPC kann nicht getötet werden, da NPC auf "unsterblich" gestellt wird
5. Neuer Typ für reitbare NPCs: timed
   > NPC wird wie bei "fixpos" an einer gewissen Position gespeichert. Wenn ein Spieler auf den NPC aufsteigt, hat dieser nur so viel Zeit, wie in der Config angegeben worden ist. Muss in Sekunden angegeben werden! (Standart: 1 Stunde - 3600 Sek)
   
   EDIT:
6. Das Inventar eines NPCs wird jetzt auch geschützt!

Ich hoffe, ihr freut euch schon wie ich, auf die nächste Version.

Ich weiß es nicht, aber das sag man ja nur so. Anders Satz für: Es kommt früh genug.

Quote from Deirdre

lenko Dass Gäste eigene Tiere töten, egal welche, sollte nicht sein. Wenn ich in einem Zoo Tiger ausstelle, dann sind die nach wie vor gefährlich. Es ist aber recht mühsam Dekotiere endlich an der gewünschten Position zu haben und dann kommt jemand und meint, der Zoo sehe ohne Tiere besser aus.

Das Personalisieren wünsche ich mir ja schon lange. Aber ein Tiger bleibt ein Tiger und ist nun mal kein Kuscheltier. Ich sage immer zu Besuchern "gm 1" einschalten, aber man ist ja nicht überall.

Soll ich noch ein Admin-Befehl Befehl einfügen, wo man auch NPCs registrieren kann, die nicht geritten werden können?
Dann sind diese auch geschützt!

Quote from lenko

So einen Tierschutz kann es immoment nur duch ein Plugin geben, dass AntiMountTheft würde sich da anbieten so etwas noch zu integrieren.

Wird erledigt. Ab dem nächsten Update kann man nur seine eigenen Reittiere oder die noch keinen Besitzer haben töten.

Die neue Version ist schneller da, als ihr denkt.

Quote from red51

Wir überlegen evtl. aber auch, das Permissionsystem generell für die neue Version zu überarbeiten. Das funktioniert zwar an sich ganz gut, doch ist YAML wirklich sehr pingelig was Einrückung etc. angeht - und das führt ja immer wieder mal für allerlei Fehler. Aber hier werden wir in naher Zukunft noch etwas Feedback sammeln

Naja, das Einrücken in YAML kenne ich bereits von Minecraft. Das hat man schnell raus. Besonders mit Tutoeials.

Und was mir noch eingefallen ist: Plugin-Permission.

Es wäre super, wenn es langesam mal möglich wäre, die Plugins in mit Permissions in einzelne Breich einzuteilen. Dann könnten Server auch eine Support erstellen und denen dan erlauben, gewisse Breiche eines Plugins zu benutzen.

Es ist als Admin eines Server nämlich nicht schön, wenn man alles aleine machen muss,

da das Plugin nur von Admins oder Nicht-Admins unterscheidet. (Arme Admins )

Aussehen (z.B): <Pluginname>.<Permission>

Für mein Schilder-Plugin wäre z.B. beim erstellen:
AktiveSign.sign.create.<Typ> oder AktiveSign.sign.create.* (für alle)

Auf jeden fall ist der Pluginname ganz vore Pflicht.

Die Permissions selbst, würde ich dan in den einzelnen Gruppen-Daten (admin.permission etc.), die bereits schon existieren, einfach unter der Kategorie: "Plugins" einfügen. (Pro Zeile 1 Permission)
In der API müssen natürlich in der onEnabled alle Permissions registiert werden. (Oder in der plugin.yml unter "Permissions")

Quote from red51

Das könnten wir machen, wobei das ja unabhängig von der API wäre. Gäbe es einen bestimmten Grund für diese Änderung?

Ja. Mein AktiveSign-Plugin brauch zum Handeln die ID, die Verkauft bzw. Gekauft werden soll.

Manche wissen aber nicht, welche ID das Item/Objekt/Kleidung hat. Deswegen habe ich ein Kommando eingefügt, um die ID zu erhalten. Geht aber nur, wenn der Spieler es in der Hand hält.

Quote from red51

Hmm... wie meinst du das genau? Also aktuell ist es ja so, dass es nur das universelle "Item" gibt, was quasi erstmal jeglicher Item-Typ sein kann. Wobei wenn wir von "Items" reden bezieht sich das natürlich nur auf die Art von Items, die man auch tatsächlich im Inventar haben kann. Da nun für spezielle Items (zB Kleidung) noch zusätzliche Informationen gespeichert werden müssen (für andere Items hingegen aber nicht), gibt es für diese Items die besagten Attribute. Aus Performancegründen wird so ein ItemAttribute normalerweise nur den Items vergeben, die auch wirklich eines benötigen (denn beim Standarditem wäre das Attribute ja quasi nutzlos und würde unnötig Speicher verbrauchen).

Tatsächlich weiß ich aber noch nicht, ob wir das in der neuen Version weiterhin so handhaben werden. Möglicherweise werden wir das etwas anders aufbauen und ggf. auch die API dahingehend anpassen (und in dieser Hinsicht vll etwas vereinfachen)

D.h. Ich kann mit der ItemAttribute definitif festellen, ob das Item z.B. eine Schaufel, Schrank oder Jacke ist.

Sagen wir es einfach so. Ich warte mal ab, was da kommt. Vielleicht passt jetzt ja dann bereits so.

Aber dennoch habe ich die Frage: Was ist das für ein Item, wenn bei ItemAttribute ein NULL kommt? Ein Item oder etwas, was man nicht ins Inventar tun kann?

Hi red51 ,

ich hätte ein paar Bitten für die neue API:

1. Es wäre Super, wenn man mit der neuen API genau feststellen kann, ob das Item in der Truhe/Hand/Inventar ein Objekt (Tür, Truhe etc.) , Item oder Kleidung ist. Du hattest mir mal vor langer Zeit mal gesagt, dass man immer Nachprüfen muss, ob ein Item, dass ich ihn die Truhe lege, immer nach einem "ItemAttribute" abfragen muss und dies dann prüfen muss, ob diese nicht NULL ist, weil nicht jedes Item ein Attribut hat.

Ich würde mir wünschen, dass jedes Item ein Attribut besitzt, wo man genau feststellen kann, was es ist. Das würde viele Fehler beim Handeln beheben.

ODER noch besser: Jedes Element hat seine eigene ID (einmalig). Somit muss man nur eine ID eingeben und man hat das Item.

So das man nur eine ID oder Code auf ein Schild schreibt und somit genau dieses Item, Objekt oder Kleidung bekommt.
Es muss ja nicht jeder Variation seinen eigenen Code erhalten. Das Standart würde schon reichen.

2. Kleider sollte man als Paket oder so in die Hand nehmen können.

3. Könnt ihr euch nicht noch überlegen, die Schilder-Position zu speichern? Von einer Storage bekommt man ja auch die Position. Das selbe sollte auch mit Schildern der fall sein. Es würde mir die Block-Position reichen, damit ich die Distanz zwischen Object/NPC/Player ermitteln kann.

4. Dann hätte ich noch eine Frage: Wenn ich npc.kill() mache, bleibt da ein Leiche zurück?
Wenn ja, wäre es super, wenn es auch ein npc.despown() gäbe. (NPC löschen ohne Leiche)

noci ,

Hier wäre auch die Javadoc für SnakeYAML

Vielen Dank. Habe zwar schonmal was von HashMap gehört.

Hatte aber nicht verstanden, wie sie funktioniert. Jetzt habe ich mal einen Leitfaden.