systemneo / recipes Goto Github PK

Version 1.7
http://pastebin.com/Y5xybV8d

Heyho...Mir ist grade aufgefallen, dass, wenn man ein Item per Rezept erstellt und diesem "Lores" hinzufügt, diese dann später in den Inventaren (.dat) folgendermaßen abgespeichert sind: "§rBezeichnung§r"
Ich gehe mal davon aus, dass das §r später mit dem Farbreset überschrieben wird.

Kann man trotzdem, wenn man bei der Lore in der rezeptconfig keine Farbe angibt das Ding ohne die Farben speichern, sodass später in der .dat wirklich nur "Bezeichnung" steht? Damit kann ich besser über die Lore drauf zugreifen (Stichwort "Custom Item Textures").

Rezept:

Goldnugget_zu_Geldsack:
ingredients: "371,64 334 0 0 0 0 0 0 0"
result: "351:9"
resultName: "&r&eGeldsack"
type: free

Das Problem... wenn ich in das 3x3 Feld Leder rein lege und 64 Draken und nun wieder Draken in die "Hand des Cursors" nehme und damit auf das Resultat Shit+R.Klick, wird im Craftingfeld 1 Leder und 1 Draken abgezogen aber der Spieler erhält einen Geldsack...

ORIGINAL_Kein_Trapdoor:
result: "96"
type: remove

oder

ORIGINAL_Kein_Trapdoor:
result: "96,2"
type: remove

lässt nun keine Trapdoor mehr aus den normalen 5:0 Planken craften, jedoch noch immer mit den anderen 5:1, 5:2 und 5:3.

Idee ist, dass man in der recipes-datei bei den Rezepten auch Custom-Items abfragen könnte. Das heisst für ein Rezept brauche ich exakt ein Diamantschwert mit der Bezeichnung §rDämonenschwert (Displayname eines vorherigen Rezeptes) und nicht nur ein Diamantschwert. Dies könnte man dann als praktisches Beispiel für Sockel in Waffen nutzen:

Rezept 1: Diamantschwert (276) mit entsprechendem Displayname "§rDämonenschwert" ($r für einen Resettag, damit User dieses Schwert nicht einfach so durch umbenennen herstellen können)

Rezept 2: Bergsmaragd (388) mit entsprechendem Displaname "§rBergsmaragd".

Rezept 3: erwartet nun bei "ingredients" 276 und 388 ABER bei "namedingredients" entsprechend der obigen Reihenfolge noch den Namen.

Somit könnte man Waffen mit "Sockel" ausstatten und durch verschiedene Einsetzbare Steine andere Effekte drauf packen.

Mir wurde grade von einem User mitgeteilt, dass man bei Shiftclicking (um mehrere male das Ergebnis zu bekommen) bei einem Craftingrezeotergebnisslot falsche Anzahl an Items bekommt (meist viel weniger). Habe es getestet und konnte folgendes feststellen:

Beispielrezept: Geldsack(Pinke Wolle)->Draken x64(Goldnugget),Leder
Ergebnis im Slot: 64x Draken/Geldsack.

Linksklick geht einwandfrei (1 x 64.)

Legt man mehrere Geldsäcke rein, wird ja durch Shift klicken das Rezept so oft durchgeführt, bis das benötigte Material ausgeht.

Beispielrezept 2: Geldsack x 3 (Pinke Wolle)->Draken x 64 x 3(Goldnugget),Leder x3
Ergebnis bei Shiftklicken: Draken x 64 x 3(Goldnugget),Leder x3 (alles supi) -ES SEI DENN man hat bereits ein wenig Draken im Inventar. Dann wird durch irgendeine Weise etwas falsch berechnet und man bekommt mit Glück 1 Stack Draken und etwas Kleingeld...

Siehe Headline.

Auf Grund einer fehlerhaften Methode in Bukkit (habe ich bereits gemeldet, wird wohl aber nicht gefixt) gibt es Probleme mit Werkzeugen und Verzauberungen. Sie werden schlichtweg nicht berücksichtigt, z. B. bringt Glück nichts.

By the way: Zudem gibt die Block.getDrops() Methode teilweise falsche Items zurück, z. B. bei Weizen (auch das möchte Bukkit nicht fixen).

Idee: Das ganze muss quasi simuliert werden. Eine Liste (am besten eine eigene config) liefert Infos für eine eigene getDrops-Methode in Bezug auf Enchantments und fehlerhafte Rückgaben von Bukkit. Damit wird dann eine eigene Methode gefüttert.

Die Spitzhacke verliert je Block-Abbau dennoch einen Punkt Haltbarkeit.

Idee von Maddis: Statt in einer Datei Blöcke mit Namen oder Lore abzuspeichern einfach aus den vorhandenen Rezepten eine "Namensliste" erstellen (welche man durch eine eigene Liste überschreiben/erweitern kann). Spawnt irgendwo ein Entity wird geprüft ob es einen Namen verpasst bekommen muss.

Zudem muss beim Öffnen des Inventories einfach jeder Stack geprüft werden ob der Name passt (statt nach Config-Änderung den ganzen Server abzugrasen, wie von Maddis vorgeschlagen, dies halte ich nicht für sinnvoll, da es nicht alle Gegebenheiten, wie Öfen und Co, abfängt - die ja auch Dinge produzieren).

Wichtig ist, dass Rezepte die Namensliste selbst auch berücksichtigen und gleich korrekt verwenden.

Probleme könnten Öfen & Co darstellen, die ja "Sachen" herstellen und während sie offen sind und weiter produzieren können, was zu Konflikten führen könnte.

Prüfen, welche Problemstellen es sonst noch gäbe.

Vorteil ist ganz klar, dass die Config wegfällt und es durch die Änderung nicht mehr Performance kostet als vorher. Zudem ist man flexibler.