CannonSimulator #164
Keine Reviewer
Label
Kein Label
Bug
Codeverbesserung
Einsteiger Freundlich
Idee
In Arbeit
Neues Feature
Prio A
Security Breach
Überprüfung notwendig
Verbesserung
Zu Beobachten
Kein Meilenstein
Niemand zuständig
3 Beteiligte
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/BauSystem#164
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "CanonSimulator" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
Closes: #128
@ -0,0 +41,4 @@
private static final Vector Y_VECTOR = new Vector(0, 0.0625, 0);
private static final Vector NY_VECTOR = new Vector(0, -0.0625, 0);
private static final Vector Z_VECTOR = new Vector(0, 0, 0.0625);
private static final Vector NZ_VECTOR = new Vector(0, 0, -0.0625);
Diese Vektoren brauchst du an genau einer Stelle im Code, du musst sie nicht static final ständig vorhalten, es würde glaube auch ein .add(x, y, z) gehen.
Dies geht nicht.
Das ganze gibt es nur mit Vektor, sonst hätte ich das schon gemacht.
@ -0,0 +42,4 @@
private static final Vector NY_VECTOR = new Vector(0, -0.0625, 0);
private static final Vector Z_VECTOR = new Vector(0, 0, 0.0625);
private static final Vector NZ_VECTOR = new Vector(0, 0, -0.0625);
private static final List<String> LORE = Collections.singletonList("§7Klicken zum ändern");
Der Text ist nicht wirklich schön. Zum Ändern klicken wäre schon mal eine bessere Formulierung.
@ -0,0 +46,4 @@
static Map<Player, TNTSimulator> tntSimulatorMap = new HashMap<>();
public static final ItemStack WAND = new SWItem(Material.TRIPWIRE_HOOK, "§6Kanonen Simulator", Arrays.asList("§eRechts Klick Block §8- §7Füge einen TNT hinzu", "§eRechts Klick Luft §8- §7Öffne den Simulator", "§eLinks Klick §8- §7Starte die Simulation"), false, null).getItemStack();
Kanonensimulator (§6 ist keine Farbe unseres Farbschemas, bitte zwischen 78e wählen)
Rechtsklick
Linksklick
@ -0,0 +66,4 @@
lore.add("§eX§8: §7" + tntSpawn.getPosition().getX());
lore.add("§eY§8: §7" + tntSpawn.getPosition().getY());
lore.add("§eZ§8: §7" + tntSpawn.getPosition().getZ());
swListEntryList.add(new SWListInv.SWListEntry<>(new SWItem(Material.TNT, "§6TNT", lore, false, null), tntSpawn));
6
@ -0,0 +70,4 @@
});
swListEntryList.sort(Comparator.comparing(SWListInv.SWListEntry::getObject));
SWListInv<TNTSpawn> swListInv = new SWListInv<>(player, "Kanonen Simulator", false, swListEntryList, (clickType, tntSpawn) -> {
Kanonensimulator
@ -0,0 +91,4 @@
tntSimulator.tntSpawns.add(tntSpawn);
editTNT(player, tntSpawn);
}));
swListInv.setItem(47, new SWItem(Material.FLINT_AND_STEEL, "§eSimulation Starten", clickType -> {
starten
@ -0,0 +109,4 @@
openSimulator(player);
}));
// Delete icon
icon? Oder doch eher tnt
@ -0,0 +110,4 @@
}));
// Delete icon
swInventory.setItem(53, new SWItem(Material.BARRIER, "§cDelete", clickType -> {
Entfernen oder Löschen
@ -0,0 +118,4 @@
// Change Count of spawned TNT
swInventory.setItem(10, new SWItem(SWItem.getDye(10), "§a+1", clickType -> {
tntSpawn.setCount(tntSpawn.getCount() + 1);
if (tntSpawn.getCount() > 1000) {
1000 TNT an einem Ort? Wenn du bei 100 schluss sagst (ggf. 200) und dem Nutzer dabei eine Fehlermeldung ausgibst, sollte das vollkommen fine sein.
Ich habe Lupf Kanonen mit 312 TNT, Kann ich das limit auf 400 setzten?
@ -0,0 +171,4 @@
}
editTNT(player, tntSpawn);
}));
swInventory.setItem(21, new SWItem(Material.CLOCK, "§eFuseTicks §8- §7" + tntSpawn.getFuseTicks(), LORE, false, clickType -> {
Was soll der Spieler mit Fuseticks anfangen? Ich glaube, die Einstellbarkeit der Fuseticks ist nicht wirklich nötig, da das alles auch durch den Spawnoffset geregelt werden kann und die Nutzer beim Bauen der echten Kanone auch keine Fuseticks haben. Dürfte mehr Leute verwirren als nützen.
Ich glaube das die FuseTick besonders beim SFA bauen ein Vorteil sein werden. In sofern finde ich sollte man dies behalten.
@ -0,0 +187,4 @@
editTNT(player, tntSpawn);
}));
// Velocity Settings
Weiß nicht, ob das nicht die User auch zu sehr verwirrt bzw. zu selten benötigt wird.
Das wird ziemlich oft verwendet. Alleine allen, denen ich das schon gezeigt haben fanden das wichtig und sinnvoll.
@ -0,0 +188,4 @@
}));
// Velocity Settings
swInventory.setItem(13, new SWItem(tntSpawn.isxVelocity() ? Material.LIME_WOOL : Material.RED_WOOL, "§7Start §eVelocity X §8- §7" + active(tntSpawn.isxVelocity()), clickType -> {
LIME_WOOL und RED_WOOL wird dir in der 1.12 um die Ohren fliegen.
@ -0,0 +206,4 @@
tntSpawn.getPosition().add(X_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(23, new SWItem(Material.PAPER, "§ePosition-X §8- §7" + tntSpawn.getPosition().getX(), LORE, false, clickType -> {
x-Position
@ -0,0 +222,4 @@
tntSpawn.getPosition().add(Y_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(24, new SWItem(Material.PAPER, "§ePosition-Y §8- §7" + tntSpawn.getPosition().getY(), LORE, false, clickType -> {
y-Position
@ -0,0 +238,4 @@
tntSpawn.getPosition().add(Z_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(25, new SWItem(Material.PAPER, "§ePosition-Z §8- §7" + tntSpawn.getPosition().getZ(), LORE, false, clickType -> {
z-Position
@ -0,0 +252,4 @@
}
static void startSimulation(Player player) {
if (tntSimulatorMap.containsKey(player)) {
Ansonsten Fehlermeldung.
@ -0,0 +261,4 @@
if (!tntSimulatorMap.containsKey(player)) {
tntSimulatorMap.put(player, new TNTSimulator());
}
tntSimulatorMap.get(player).tntSpawns.add(tntSpawn);
Statt jede Menge static zu machen und zu haben, und über all if(!tntSimulatorMap.containsKey()) zu haben, mach die Funktion doch NICHT static und biete dann noch eine get()-Funktion an, die das Wenn nicht da, erstellen, automatisch einfach mitmacht.
Auch ne Option (für die .get()-Funktion): computeIfAbsent
@ -0,0 +295,4 @@
}
private static double clamp(double d) {
return (int)(d * 100) * 0.01;
Wenn du schon woanders mit 16teln arbeitest, warum nicht hier?
Weil es auch sowas wie mirkoverschiebung gibt.
@ -0,0 +302,4 @@
public void start() {
tntSpawns.forEach(tntSpawn -> {
Bukkit.getScheduler().runTaskLater(BauSystem.getPlugin(), tntSpawn::spawn, tntSpawn.getTickOffset() + 1L);
+1 ist unnötig
Doch weil. Ansonsten die von 0 Tick und 1 Tick gleichzeitig gespawned werden.
@ -0,0 +30,4 @@
import java.util.function.Consumer;
public class TNTSimulatorAnvil {
Dieser Wrapper um die AnvilGUI scheint mir nicht nötig, es gibt schließlich eine SWAnvilGUI.
Nein dieser ist wichtig, da ich ein default value (den jetzigen Wert) haben möchte, wenn man es öffnet. Kann man in das jetzige nicht einbauen ohne SpigotCore Änderungen.
@ -0,0 +19,4 @@
* /
*/
package de.steamwar.bausystem.canonsimulator;
cannon, nicht canon, das ist was anderes.
@ -0,0 +32,4 @@
public class CommandSimulator implements CommandExecutor {
private boolean permissionCheck(Player player) {
Diese Überprüfung findet nur beim Command statt, nicht wenn ein Spieler versucht, einen Simulatoritem zu verwenden....
@ -0,0 +54,4 @@
player.updateInventory();
return false;
}
TNTSimulator.openSimulator(player);
Da das auch mti dem wand geht und es echt keine Info dazu gibt, wie man den Wand erhält, würde ich einfach den Befehl nur zum Erschaffen des Wands nutzen.
Also erstes gibt es dafür direkt ein TabComplete und zweitens wird der /sim command mehr verwendet um die UI zu öffnen als der Wand. Womit ich glaube das diese Sachen wichtig ist.
CanonSimulatorzu CannonSimulatorAuch hier habe ich alle deine Sachen behoben.
Hab erstmal keine Lust mehr den PR zu machen, Später kommt nochmal was. (Evt.)
@ -0,0 +19,4 @@
* /
*/
package de.steamwar.bausystem.cannonsimulator;
Warum braucht das sein eigenes Package? Und kann nicht einfach in das
world
package rein?@ -0,0 +71,4 @@
lore.add("§eZ§8: §7" + tntSpawn.getPosition().getZ());
swListEntryList.add(new SWListInv.SWListEntry<>(new SWItem(Material.TNT, "§eTNT" + (!tntSpawn.getName().isEmpty() ? " §8- §e" + tntSpawn.getName() : ""), lore, false, null), tntSpawn));
});
swListEntryList.sort(Comparator.comparing(SWListInv.SWListEntry::getObject));
Warum muss diese List nochmal sortiert werden?
Damit diese nach den tick, wann despawned wird sortiert ist.
@ -0,0 +116,4 @@
}));
// tnt Name
swInventory.setItem(45, new SWItem(Material.NAME_TAG, "§eName", clickType -> {
Warum brauchen die Tnts einen Namen? Diese Simulationen sind nicht abspeicherbar, deshalb sehe ich den Sinn in einem Namen für das TNT nicht.
Ist aber trotzdem wichtig, damit man in einer Simulation einfach die TNT auseinanderhalten kann
@ -0,0 +182,4 @@
}
editTNT(player, tntSpawn);
}));
swInventory.setItem(21, new SWItem(Material.CLOCK, "§eFuseTicks §8- §7" + tntSpawn.getFuseTicks(), LORE, false, clickType -> {
Fuseticks
@ -0,0 +286,4 @@
}
private static void changeCount(Player player, int defaultValue, Consumer<Integer> result, Runnable failure) {
SWAnvilInv swAnvilInv = new SWAnvilInv(player, "Zahl", defaultValue + "");
Zahl? ZAHL! evt. Mal etwas beschreiben deren Titel nehmen
@ -0,0 +315,4 @@
return (int)(d * 10000) * 0.0001;
}
private Set<TNTSpawn> tntSpawns = new HashSet<>();
Kann das nicht am anfang der Datei stehen? May be final
@ -0,0 +348,4 @@
}
private void spawnRandomList(List<TNTSpawnPair> tntSpawnPairs) {
AtomicInteger index = new AtomicInteger(tntSpawnPairs.size() - 1);
Warum wird hierfür ein AtomicInteger benötigt?
Weil effectively final und final variablen!
Wobei im Moment vllt auch nicht mehr so wichtig.
@ -0,0 +32,4 @@
import org.bukkit.event.player.PlayerQuitEvent;
import org.bukkit.util.Vector;
public class TNTSimulatorListener implements Listener {
Vllt. solltest du dir mal den Detonator und den AutoLoader anschauen, und am besten auch so machen. Das heist diese Listener klasse entfernen und den TntSimulator den Listener machen. Schau dir in diesen Klassen mal an wie das da gemacht ist und mach es ambesten auch so.
Warum sollte ich denn n Listener laufen lassen, wenn einer reicht?
@ -0,0 +26,4 @@
import org.bukkit.entity.TNTPrimed;
import org.bukkit.util.Vector;
public class TNTSpawn implements Comparable<TNTSpawn> {
Wieso ist das eine eigene Klasse? Die könnte genau so gut eine Unterklasse vom TntSimulator sein.
@ -0,0 +57,4 @@
break;
case "start":
TNTSimulator.get(player).start();
break;
vllt. noch ein Default Case mit einer kleinen Help message
@ -0,0 +48,4 @@
private static final List<String> LORE = Collections.singletonList("§7Zum ändern klicken");
static final Map<Player, TNTSimulator> TNT_SIMULATOR_MAP = new HashMap<>();
private final Set<TNTSpawn> TNT_SPAWNS = new HashSet<>();
Kein static final, also Bitte camelCase
@ -0,0 +84,4 @@
}));
swListInv.setItem(49, new SWItem(Material.TNT, "§aNeues TNT", clickType -> {
Vector vector = player.getLocation().toVector().multiply(16);
vector.setX((int) vector.getX());
vector.getBlockX()? auch bitte unten benutzen.
@ -0,0 +142,4 @@
if (count > 400) count = 400;
tntSpawn.setCount(count);
editTNT(player, tntSpawn);
}, () -> editTNT(player, tntSpawn));
Man könnte noch etwas mehr Feedback an den Spieler geben. z.B. das diese Zahl nicht zu einer Zahl gemacht werden kann etc.
Was für ein Feedback würdest du dem Spieler hier denn geben wollen?
@ -0,0 +50,4 @@
static final Map<Player, TNTSimulator> TNT_SIMULATOR_MAP = new HashMap<>();
private final Set<TNTSpawn> TNT_SPAWNS = new HashSet<>();
public static final ItemStack WAND = new SWItem(Material.TRIPWIRE_HOOK, "§eKanonen Simulator", Arrays.asList("§eRechtsklick Block §8- §7Füge einen TNT hinzu", "§eRechtsklick Luft §8- §7Öffne den Simulator", "§eLinksklick §8- §7Starte die Simulation"), false, null).getItemStack();
Kanonensimulator
@ -0,0 +62,4 @@
List<SWListInv.SWListEntry<TNTSpawn>> swListEntryList = new ArrayList<>();
tntSimulator.TNT_SPAWNS.forEach(tntSpawn -> {
List<String> lore = new ArrayList<>();
lore.add("§7Klicken zum einstellen");
Einstellen groß (nach zum), und evtl. wäre konfigurieren das bessere Wort.
@ -0,0 +64,4 @@
List<String> lore = new ArrayList<>();
lore.add("§7Klicken zum einstellen");
lore.add("");
lore.add("§eTNT-Anzahl§8: §7" + tntSpawn.getCount());
Finde das Coloring genau falsch: Den User interessiert nicht TNT-Anzahl, sondern die TNT-Anzahl (also §7TNT-Anzahl§8: §e53)
Auch untendrunter fixen.
@ -0,0 +82,4 @@
tntSimulator.TNT_SPAWNS.clear();
openSimulator(player);
}));
swListInv.setItem(49, new SWItem(Material.TNT, "§aNeues TNT", clickType -> {
Ich würde die Methode gar nicht in der GUI anbieten, sondern nur über den Wand. Diese Option mit der eigenen Position dürfte User nur verwirren.
@ -0,0 +86,4 @@
Vector vector = player.getLocation().toVector().multiply(16);
vector.setX((int) vector.getX());
vector.setY((int) vector.getY());
vector.setZ((int) vector.getZ());
getBlockXYZ() (siehe Chaoscaot)
Ist nicht ganz das gleiche aber da das eh rausfliegt ist es nicht mehr benötigt
@ -0,0 +272,4 @@
static void startSimulation(Player player) {
if (TNT_SIMULATOR_MAP.containsKey(player)) {
TNT_SIMULATOR_MAP.get(player).start();
getOrDefault?
@ -0,0 +276,4 @@
}
}
static void addTNT(Player player, TNTSpawn tntSpawn) {
Kann addTNT nicht einfach einen Vektor nehmen und einen TNTSpawn returnen?
@ -0,0 +280,4 @@
if (!TNT_SIMULATOR_MAP.containsKey(player)) {
TNT_SIMULATOR_MAP.put(player, new TNTSimulator());
}
TNT_SIMULATOR_MAP.get(player).TNT_SPAWNS.add(tntSpawn);
Ich glaube, mit compute (oder vergleichbarer Funktion, musst mal schauen, gibt aber garantiert eine passende), wäre diese Funktion ein Einzeiler.
@ -0,0 +317,4 @@
return (int)(d * 10000) * 0.0001;
}
private static class TNTSpawnPair {
Bitte ohne (siehe Kommentar zu .start())
@ -0,0 +344,4 @@
spawnRandomList(tntSpawnPairs[0]);
spawnRandomList(tntSpawnPairs[1]);
}, integer + 1L);
});
Ok, deine Datenmodelle sind mal wieder ein komplettes Chaos. Du brauchst 3 Werte: Delay, wie viel TNT, TNTSpawn, oder? Und warum brauchst du dann dafür eine ominöse List[]?!? Vereinfache doch den code mal. tntSpawn weiß doch selbst, wie häufig er spawnen soll, warum musst du das nochmal woanders speichern? Warum tut TNTSpawn nicht einfach in der Anzahl spawnen, wie benötigt wird? Warum brauchst du die Funktion spawnRandomList, die irgendwie einfach nur in einer komplexen Art und weise alles in den TNTSpawnPairs spawnt? Das ist viel komplexer als nötig. Und wenn du das alles nur wegen der Berechnungsreihenfolge machst: Streamlinen (Eine Liste, in der jeder TNTSpawn so häufig wie sein .count() vorkommt, und dann einfach .shuffle()!
@ -0,0 +347,4 @@
});
}
private void spawnRandomList(List<TNTSpawnPair> tntSpawnPairs) {
Sollte ohne gehen (siehe .start())
@ -0,0 +363,4 @@
private static final World WORLD = Bukkit.getWorlds().get(0);
private String name = "";
Das Tool ist ein Tool, um mal schnell eine Kanone skizzieren zu können. TNT extra Namen zu geben, scheint mir dabei relativ überflüssig/unnötig.
Das soll es dem Benutzer einfacher machen, wenn er komplexe Kanonen skizzieren möchte die einzelnen TNT auseinander zu halten.
@ -0,0 +398,4 @@
return position;
}
public void setPosition(Vector position) {
Die Position wird nie verändert. Daher setPosition entfernen & position final machen.
Die Funktion wird nie verwendet, also ja ich kann diese Ausbauen, da sie ein Relikt der früher nicht innen class ist. Jedoch wird die Position als Vector definitiv verändert. Gut anscheinend setzte ich es nicht neu sondern verändere nur also ja kann final sein.
Ist alles geändert
Bin kurz essen, gleich wieder da
@ -0,0 +72,4 @@
lore.add("§7X§8: §e" + tntSpawn.getPosition().getX());
lore.add("§7Y§8: §e" + tntSpawn.getPosition().getY());
lore.add("§7Z§8: §e" + tntSpawn.getPosition().getZ());
swListEntryList.add(new SWListInv.SWListEntry<>(new SWItem(Material.TNT, "§eTNT" + (!tntSpawn.getName().isEmpty() ? " §8- §e" + tntSpawn.getName() : ""), lore, false, null), tntSpawn));
Zum Item Namen: mach doch noch so ein Kleines int i welches hoch zählt
, damit da net nur TNT steht.
@ -0,0 +85,4 @@
}));
swListInv.setItem(47, new SWItem(Material.FLINT_AND_STEEL, "§eSimulation starten", clickType -> {
startSimulation(player);
player.closeInventory();
Erst das Inventar schließen, weil so verleitet es mehr zum draufspammen, wenn startSimulation einen Fehler wirft.
@ -0,0 +108,4 @@
swInventory.setItem(45, new SWItem(Material.NAME_TAG, "§eName", clickType -> {
SWAnvilInv tntSimulatorAnvil = new SWAnvilInv(player, "Name", tntSpawn.getName());
tntSimulatorAnvil.setCallback(s -> {
if (s.startsWith("»")) s = s.substring(1);
Wird schon im AnvilInv gemacht -> muss nicht gemacht werden
@ -0,0 +50,4 @@
if (event.getItem() == null) return;
if (!event.getItem().isSimilar(WAND)) return;
event.setCancelled(true);
if (!permissionCheck(event.getPlayer())) {
In einer Methode Zwei unterschiuedliche If Style. ARRRRRRRRRRRRGGGGGGGHHHHHHHH
Auch das ist nun alles geändert.
@ -0,0 +16,4 @@
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
* /
Wo kommt das Slash her?
@ -0,0 +58,4 @@
if (args.length == 1) {
switch (args[0].toLowerCase()) {
case "wand":
player.getInventory().setItemInMainHand(TNTSimulator.WAND);
Kannst du bitte
@ -0,0 +16,4 @@
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
* /
Selbes Slash
@ -0,0 +16,4 @@
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
* /
Auch hier
@ -0,0 +46,4 @@
private static final Vector Z_VECTOR = new Vector(0, 0, 0.0625);
private static final Vector NZ_VECTOR = new Vector(0, 0, -0.0625);
private static final List<String> LORE = Collections.singletonList("§7Zum ändern klicken");
private static final List<TNTSpawn> EMPTY = new ArrayList<>();
Collections.emptyList()?
Wegen dem
Collections.shuffle()
intern@ -0,0 +188,4 @@
}));
// Repeater before Comparator
swInventory.setItem(4, new SWItem(tntSpawn.isComparator() ? Material.COMPARATOR : Material.REPEATER, "§7Gezündet durch §8- §e" + (tntSpawn.isComparator() ? "Comparator" : "Repeater"), clickType -> {
Ich weiß nicht, was ich von diesem Konzept mit den Comparator oder Repeater Zündung halt soll, weil besonders für neue Spieler wird dies verwirrend sein, da es dort oft noch nicht das Verständnis von Update order gibt.
Vor allem, gibt es aber viel mehr als nur zwei zünd quellen: Redstone, Observer oder Piston mit einem Block o.Ä.
Und in welcher Reihenfolge werden die gezündet? und meinst du nicht das zwei UpdateOrder reichen?
@ -0,0 +208,4 @@
}));
// X Position
swInventory.setItem(14, new SWItem(SWItem.getDye(10), "§a+0,0625", clickType -> {
Bei diesen Items sollte man sich auch an das Farbschema halten
@ -0,0 +313,4 @@
Set<Integer> ticks = new HashSet<>(first.keySet());
ticks.addAll(second.keySet());
for (int tick : ticks) {
Bukkit.getScheduler().runTaskLater(BauSystem.getPlugin(), () -> {
Wie wäre es, wenn man nicht für jeden Tick einen einzelnen Task macht, sondern einen Timer Task, welcher jeden Tick die Spawnt, die für diesen Tick geplant sind?
@ -0,0 +322,4 @@
private void spawnRandomList(List<TNTSpawn> tntSpawns) {
if (tntSpawns.isEmpty()) return;
Collections.shuffle(tntSpawns);
Warum muss die Liste noch mal gemischt werden?
Damit wenn ich rechts und links in der Reihenfolge das spawne nicht immer das ganze nach links wegschießt im trace. Ist also wichtig. weil sonst viele Kanonen einen gewissen Drall haben.
@ -0,0 +36,4 @@
return detonaterTabComplete((Player) sender, args);
}
private List<String> detonaterTabComplete(Player player, String[] args) {
Das ist nicht der Detonator
@ -0,0 +195,4 @@
}));
// Velocity Settings
swInventory.setItem(13, new SWItem(tntSpawn.isxVelocity() ? Material.LIME_CONCRETE : Material.RED_CONCRETE, "§7Start §eVelocity X §8- §7" + active(tntSpawn.isxVelocity()), clickType -> {
Start Velocity? Wie bitte? Würde eher irgendwas um Tnt Sprung x/y/z empfehlen
@ -0,0 +195,4 @@
}));
// Velocity Settings
swInventory.setItem(13, new SWItem(tntSpawn.isxVelocity() ? Material.LIME_CONCRETE : Material.RED_CONCRETE, "§7TNT §eSprung X §8- §7" + active(tntSpawn.isxVelocity()), clickType -> {
Das §7 am Ende ist unnütz, da active seine eigenen Farben mit bringt.
@ -0,0 +316,4 @@
}
});
AtomicInteger currentTick = new AtomicInteger(0);
Bukkit.getScheduler().runTaskTimer(BauSystem.getPlugin(), () -> {
Der Task muss auch gestoppt werden...
@ -0,0 +58,4 @@
return;
}
if (event.getAction() == Action.LEFT_CLICK_BLOCK || event.getAction() == Action.LEFT_CLICK_AIR) {
Könnte man hier nicht für die Lesbarkeit ein Switch-Case Statement nutzen?
Glaube nicht, weil es an sich nicht viele Sachen in dem switch gäbe es gebe ein über komplizierten default und ansonsten nur zwei case mit
LEFT_CLICK_BLOCK
undLEFT_CLICK_AIR
, welche das gleiche machen würden. Also neinÜberkompliziert? Dafuq? Es Gabe das
LEFT_CLICK_BLOCK
und dasLEFT_CLICK_AIR
, dasRIGHT_CLICK_AIR
zum Inventar und noch dasRIGHT_CLICK_BLOCK
zum Hinzufügen. Also überkompliziert ist was anderes und es wäre deutlich einfacher zu Lesen.@ -0,0 +33,4 @@
public class CommandSimulator implements CommandExecutor {
private void help(Player player) {
player.sendMessage("§8/§esimulator §8- §7Öffnet die Simulations GUI");
Das GUI
@ -0,0 +35,4 @@
private void help(Player player) {
player.sendMessage("§8/§esimulator §8- §7Öffnet die Simulations GUI");
player.sendMessage("§8/§esimulator start §8- §7Startet die Simulation");
player.sendMessage("§8/§esimulator wand §8- §7Legt den Simulator ins Inventar");
Der Simulator ist ein System, evt. den Simulatorstab oder etwas ähnliches
@ -0,0 +308,4 @@
Map<Integer, List<TNTSpawn>> first = new HashMap<>();
Map<Integer, List<TNTSpawn>> second = new HashMap<>();
AtomicInteger lastTick = new AtomicInteger(0);
TNT_SPAWNS.forEach(tntSpawn -> {
Mann kann auch eine Normal foreach loop nehmen, dann muss man keinen AtomicInteger nutzen.
Doch weil ich sonst noch die Variable einmal kopieren muss, damit diese effectively final ist für den BukkitTask.
@ -0,0 +319,4 @@
});
AtomicInteger currentTick = new AtomicInteger(0);
AtomicReference<Runnable> taskCanceler = new AtomicReference<>(() -> {});
BukkitTask bukkitTask = Bukkit.getScheduler().runTaskTimer(BauSystem.getPlugin(), () -> {
Die runTaskTimer kann eine Consumable von einem BukkitTask nehmen, die könnte man nutzen
@ -0,0 +26,4 @@
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.block.Action;
Unused Import
@ -0,0 +124,4 @@
}
editTNT(player, tntSpawn);
}));
swInventory.setItem(19, new SWItem(Material.TNT, "§eAnzahl §8- §7" + tntSpawn.getCount(), LORE, false, clickType -> {
§e und §7 tauschen
@ -0,0 +148,4 @@
}
editTNT(player, tntSpawn);
}));
swInventory.setItem(20, new SWItem(Material.CLOCK, "§eTick §8- §7" + tntSpawn.getTickOffset(), LORE, false, clickType -> {
§e und §7 tauschen
@ -0,0 +172,4 @@
}
editTNT(player, tntSpawn);
}));
swInventory.setItem(21, new SWItem(Material.CLOCK, "§eFuse-Ticks §8- §7" + tntSpawn.getFuseTicks(), LORE, false, clickType -> {
§e und §7 tauschen
@ -0,0 +195,4 @@
}));
// Velocity Settings
swInventory.setItem(13, new SWItem(tntSpawn.isxVelocity() ? Material.LIME_CONCRETE : Material.RED_CONCRETE, "§7TNT §eSprung X §8- " + active(tntSpawn.isxVelocity()), clickType -> {
Wie schaut es mit dem Ding auf der 1.12 aus? Den RED_CONCRETE gibt es dort nicht.
@ -0,0 +213,4 @@
tntSpawn.getPosition().add(X_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(23, new SWItem(Material.PAPER, "§ex-Position §8- §7" + tntSpawn.getPosition().getX(), LORE, false, clickType -> {
§e und §7 tauschen
@ -0,0 +229,4 @@
tntSpawn.getPosition().add(Y_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(24, new SWItem(Material.PAPER, "§ey-Position §8- §7" + tntSpawn.getPosition().getY(), LORE, false, clickType -> {
§e und §7 tauschen
@ -0,0 +245,4 @@
tntSpawn.getPosition().add(Z_VECTOR);
editTNT(player, tntSpawn);
}));
swInventory.setItem(25, new SWItem(Material.PAPER, "§ez-Position §8- §7" + tntSpawn.getPosition().getZ(), LORE, false, clickType -> {
§e und §7 tauschen
Joa, die Kleinigkeiten würde ich auf jeden Fall noch ändern, ansonsten habe ich jetzt nicht nochmal alle Strings überprüft, ansonsten ggf. noch den ein oder anderen offenen Punkt von Chaoscaot aufgreifen.
@ -0,0 +31,4 @@
return Material.CONCRETE;
}
public static Material repeater() {
Repeater und Comparator können über SWItem.getMaterial() erhalten werden, bitte hier entfernen.
@ -0,0 +39,4 @@
}
private boolean permissionCheck(Player player) {
if (Welt.noPermission(player, Permission.world)) {
Der Simulator ist ja eher eine Regional beschränkte sache, ich würde ihn eher unter WE oder ggf sogar unter build nehmen.
@ -0,0 +37,4 @@
private static final Vector HALF = new Vector(0.5, 0, 0.5);
private boolean permissionCheck(Player player) {
if (Welt.noPermission(player, Permission.world)) {
Auch hier so etwas die Frage.
Merge Conflict!
Resolved!
@ -0,0 +36,4 @@
}
public static Material comparator() {
return Material.REDSTONE_COMPARATOR;
Hier kann man noch ordentlich Zeilen mit
SWItem.getMaterial()
sparen.@ -0,0 +33,4 @@
public class CommandSimulator implements CommandExecutor {
private void help(Player player) {
player.sendMessage("§8/§esimulator §8- §7Öffnet das Simulations GUI");
Es ist die Simulation und das GUI aber das Simulation passt net, Am besten noch einen Bindestrich dazwischen machen.
@ -0,0 +35,4 @@
private void help(Player player) {
player.sendMessage("§8/§esimulator §8- §7Öffnet das Simulations GUI");
player.sendMessage("§8/§esimulator start §8- §7Startet die Simulation");
player.sendMessage("§8/§esimulator wand §8- §7Legt den Simulatorstab ins Inventar");
Der Satz macht keinen Sinn:
@ -0,0 +82,4 @@
SWListInv<TNTSpawn> swListInv = new SWListInv<>(player, "Kanonensimulator", false, swListEntryList, (clickType, tntSpawn) -> {
editTNT(player, tntSpawn);
});
swListInv.setItem(51, new SWItem(Material.BARRIER, "§cLösche alle TNT", clickType -> {
Kann man dafür noch einen Command machen?
@ -0,0 +323,4 @@
Map<Integer, List<TNTSpawn>> first = new HashMap<>();
Map<Integer, List<TNTSpawn>> second = new HashMap<>();
AtomicInteger lastTick = new AtomicInteger(0);
TNT_SPAWNS.forEach(tntSpawn -> {
Anstat deinen Komischen AtomicInteger zu nutzen, könnte man auch eine normal foreach Schleife machen
Sollte nun wieder gelöst sein.
Du darfst dich auch noch hier mit im Bau GUI eintragen
@ -0,0 +36,4 @@
player.sendMessage("§8/§esimulator §8- §7Öffnet die Simulations GUI");
player.sendMessage("§8/§esimulator start §8- §7Startet die Simulation");
player.sendMessage("§8/§esimulator wand §8- §7Legt dir den Simulatorstab ins Inventar");
player.sendMessage("§8/§esimulator delete §8- §7Lösche alle TNT");
Löcht
@ -0,0 +47,4 @@
private static final Vector NY_VECTOR = new Vector(0, -0.0625, 0);
private static final Vector Z_VECTOR = new Vector(0, 0, 0.0625);
private static final Vector NZ_VECTOR = new Vector(0, 0, -0.0625);
private static final List<String> LORE = Collections.singletonList("§7Zum ändern klicken");
Hier sollte man, dass man es ändern kann betonen. Ambesten alles mit §e
@ -0,0 +361,4 @@
private static final World WORLD = Bukkit.getWorlds().get(0);
private String name = "";
Der Name ist immer noch komplett unnütz. Für ein solches Tool, welches zum schnellen testen von Winklen o.Ä., bring der Name einfach keinen Richtigen nutzen. Ein Name wird nicht benötigt, da wenn man eine Kanone Simuliert sind die TNT eh nach den Zündphasen Sortiert. Dazu kann man sich die Simulationen nicht abspeichern, und ich glaube, wenn man so ein Feature nutz, dann hat man nicht ein Kurzzeitgedechniss wie ein Metal Gear Solid Bot.
@ -19,6 +19,7 @@
package de.steamwar.bausystem;
import de.steamwar.bausystem.world.TNTSimulatorListener;
Der import scheint mir etwas unnütz
@ -45,6 +45,18 @@ public class CommandGUI implements CommandExecutor, Listener {
Bukkit.getScheduler().runTaskTimerAsynchronously(BauSystem.getPlugin(), LAST_F_PLAYER::clear, 0, 20);
}
private static ItemStack wand(Player player, ItemStack base, String command, Permission permission, String noPermissionMessage) {
Kannst du bitte eine Utility Methode zu den Utility Methoden tun?
@ -0,0 +59,4 @@
if (args.length == 1) {
switch (args[0].toLowerCase()) {
case "wand":
if (player.getInventory().getItemInMainHand().getType() == Material.AIR) {
Noch der alte ItemGiver