12
0

CommandFramework3 #94

Manuell gemergt
Zeanon hat 71 Commits von CommandFramework3 nach master 2021-03-30 21:15:40 +02:00 zusammengeführt
Besitzer

Command System

Todos

  • Help Message System (@RegisterHelp([value])?) -> @Register(help = true)
  • FightSystem (Lixfel)
  • Ändern SWCommand von class -> interface? Was hängt alles daran? Wird nicht gemacht, das dies das handling intern nicht einfacher macht!
  • Custom Mapper Testing
  • Grobes Testing von normalen use cases
  • var args testen
  • sub commands testen
  • Enum direct support
  • Bessere Error messages, für das erstellen von Befehlen und weiteres
  • Teste unregister von SWCommand und register
  • Teste das Help system
  • Local Mapper overrides

Beispiel

Als kleines Beispiel, wie man das neue System verwenden würde:

package de.steamwar.acommand;

import de.steamwar.command.SWCommand;
import de.steamwar.command.TypeMapper;
import org.bukkit.Material;
import org.bukkit.command.CommandSender;
import org.bukkit.entity.Player;

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class TestCommand extends SWCommand {

    public TestCommand() {
        // Register this command as 'test'
        super("test");
    }

    // One Help Command, the first Parameter should be some kind of CommandSender
    // The second argument can only be a varAgrs string of what arguments were tried to map
    @Register(help = true)
    public void testHelp(Player player, String... args) {
        player.sendMessage("This is your help message");
    }

    // One Command, the first Parameter should be some kind of CommandSender
    @Register
    public void test(Player player) {

    }

    // Another Command, subCommands can be implemented with the Register Annotation,
    // you can use custom Mappers by putting a Mapper Annotation on a Parameter
    @Register({"two"})
    public void testTwo(Player player, int i, @Mapper("solidMaterial") Material material) {

    }

    // Add Custom Mapper when this command is registered, all Mapper of you class will be
    // created first and than the Commands. Do not use this mapper outside your class, as
    // it can only create failures. Use on your own risk. Definition order should be considered.
    @Mapper("solidMaterial")
    public TypeMapper<Material> materialTypeMapper() {
        List<String> tabCompletes = Arrays.stream(Material.values())
                .filter(Material::isSolid)
                .map(Material::name)
                .map(String::toLowerCase)
                .collect(Collectors.toList());
        return new TypeMapper<Material>() {
            @Override
            public Material map(String s) {
                return Material.valueOf(s.toUpperCase());
            }

            @Override
            public List<String> tabCompletes(CommandSender commandSender, String[] previous, String s) {
                return tabCompletes;
            }
        };
    }
}

# Command System ## Todos - [x] Help Message System (`@RegisterHelp([value])`?) -> `@Register(help = true)` - [x] FightSystem (Lixfel) - [x] Ändern SWCommand von class -> interface? Was hängt alles daran? Wird nicht gemacht, das dies das handling intern nicht einfacher macht! - [x] Custom Mapper Testing - [x] Grobes Testing von normalen use cases - [x] var args testen - [x] sub commands testen - [x] Enum direct support - [x] Bessere Error messages, für das erstellen von Befehlen und weiteres - [x] Teste unregister von SWCommand und register - [x] Teste das Help system - [x] Local Mapper overrides ## Beispiel Als kleines Beispiel, wie man das neue System verwenden würde: ```java package de.steamwar.acommand; import de.steamwar.command.SWCommand; import de.steamwar.command.TypeMapper; import org.bukkit.Material; import org.bukkit.command.CommandSender; import org.bukkit.entity.Player; import java.util.Arrays; import java.util.List; import java.util.stream.Collectors; public class TestCommand extends SWCommand { public TestCommand() { // Register this command as 'test' super("test"); } // One Help Command, the first Parameter should be some kind of CommandSender // The second argument can only be a varAgrs string of what arguments were tried to map @Register(help = true) public void testHelp(Player player, String... args) { player.sendMessage("This is your help message"); } // One Command, the first Parameter should be some kind of CommandSender @Register public void test(Player player) { } // Another Command, subCommands can be implemented with the Register Annotation, // you can use custom Mappers by putting a Mapper Annotation on a Parameter @Register({"two"}) public void testTwo(Player player, int i, @Mapper("solidMaterial") Material material) { } // Add Custom Mapper when this command is registered, all Mapper of you class will be // created first and than the Commands. Do not use this mapper outside your class, as // it can only create failures. Use on your own risk. Definition order should be considered. @Mapper("solidMaterial") public TypeMapper<Material> materialTypeMapper() { List<String> tabCompletes = Arrays.stream(Material.values()) .filter(Material::isSolid) .map(Material::name) .map(String::toLowerCase) .collect(Collectors.toList()); return new TypeMapper<Material>() { @Override public Material map(String s) { return Material.valueOf(s.toUpperCase()); } @Override public List<String> tabCompletes(CommandSender commandSender, String[] previous, String s) { return tabCompletes; } }; } } ```
YoyoNow hat 1 Commit 2021-03-12 14:15:24 +01:00 hinzugefügt
Add SWCommandUtils
Add InternalCommand
Add InternalTabComplete
YoyoNow hat 1 Commit 2021-03-12 15:52:56 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-12 16:30:44 +01:00 hinzugefügt
Add SWCommand.Register annotation
YoyoNow hat 1 Commit 2021-03-12 17:06:40 +01:00 hinzugefügt
Add SWCommand.Register.subCommand
YoyoNow hat 1 Commit 2021-03-12 17:10:27 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-12 17:24:22 +01:00 hinzugefügt
Fix InternalTabComplete
YoyoNow hat 1 Commit 2021-03-12 17:26:43 +01:00 hinzugefügt
YoyoNow hat 2 Commits 2021-03-12 17:48:46 +01:00 hinzugefügt
YoyoNow hat 2 Commits 2021-03-13 15:59:00 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-13 16:02:48 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-13 16:17:35 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-13 19:42:34 +01:00 hinzugefügt
Add mapper support to internal reflections
Add better tab complete support for to InternalCommand
YoyoNow hat 1 Commit 2021-03-25 12:24:03 +01:00 hinzugefügt
Remove InternalCommand.java
Remove InternalTabComplete.java
Add SubCommand
YoyoNow hat 1 Commit 2021-03-25 12:25:54 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 12:27:07 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 12:29:19 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 12:30:35 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 12:38:47 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 12:39:07 +01:00 hinzugefügt
YoyoNow hat 2 Commits 2021-03-25 13:38:19 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 14:13:40 +01:00 hinzugefügt
Add copyright to SubCommand
YoyoNow hat 1 Commit 2021-03-25 14:16:08 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 14:17:40 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-25 14:21:43 +01:00 hinzugefügt
Simplify SWCommand registering mapper and commands
Lixfel hat 2021-03-25 19:44:16 +01:00 Änderungen angefragt
Lixfel hat einen Kommentar hinterlassen
Besitzer

Scheint mir sehr angenehm zu bedienen sein, finde ich grundlegend gut.

Ansonsten scheinen mir das Hilfsmeldungssystem wie der Command funktioniert noch nicht so gut ausgebaut zu sein.

Scheint mir sehr angenehm zu bedienen sein, finde ich grundlegend gut. Ansonsten scheinen mir das Hilfsmeldungssystem wie der Command funktioniert noch nicht so gut ausgebaut zu sein.
@ -0,0 +28,4 @@
import java.util.List;
import java.util.stream.Collectors;
public class TestCommand extends SWCommand {
Besitzer

Ich fände es besser, wenn es ein Implements sein würde, dann kann die Klasse auch noch anderes als ein Befehl sein.

Ich fände es besser, wenn es ein Implements sein würde, dann kann die Klasse auch noch anderes als ein Befehl sein.
Autor
Besitzer

Im Moment geht dies nicht, wegen dem Constructor, und den Sachen, welche dort drin passieren. Dementsprechend ist dies so im Moment nicht möglich. Wie würdest du das umsetzten?

Im Moment geht dies nicht, wegen dem Constructor, und den Sachen, welche dort drin passieren. Dementsprechend ist dies so im Moment nicht möglich. Wie würdest du das umsetzten?
Autor
Besitzer

Ich würde ungern mit defaults und so arbeiten, deswegen habe ich es im Moment so gelöst.

Ich würde ungern mit defaults und so arbeiten, deswegen habe ich es im Moment so gelöst.
@ -0,0 +32,4 @@
public TestCommand() {
// Register this command as 'test'
super("test");
Besitzer

Prinzipiell gut, aber insbesondere im Kampfsystem (nach refactoring) tausche ich die Implementierungen von Befehlen während der Serverlaufzeit mehrfach aus, je nachdem, welche Kampfphase gerade ist. Wäre toll, wenn das mit dem System gehen würde.

Prinzipiell gut, aber insbesondere im Kampfsystem (nach refactoring) tausche ich die Implementierungen von Befehlen während der Serverlaufzeit mehrfach aus, je nachdem, welche Kampfphase gerade ist. Wäre toll, wenn das mit dem System gehen würde.
Autor
Besitzer

Kannst du mir hier zu ein Beispiel geben, was genau du brauchen wirst?

Kannst du mir hier zu ein Beispiel geben, was genau du brauchen wirst?
Autor
Besitzer

Reicht dir die Implementierung von an und ausschalten von Befehlen mit dem enabled boolean? Oder brauchst du mehr als das?

Reicht dir die Implementierung von an und ausschalten von Befehlen mit dem enabled boolean? Oder brauchst du mehr als das?
Autor
Besitzer

Wenn ja sollten wir mal am Wochenende darüber reden.

Wenn ja sollten wir mal am Wochenende darüber reden.
@ -0,0 +50,4 @@
// Add Custom Mapper when this command is registered, all Mapper of you class will be
// created first and than the Commands. Do not use this mapper outside your class, as
// it can only create failures. Use on your own risk. Definition order should be considered.
Besitzer

Liest sich arg hacky, ich fände es gut, wenn Mapperobjekte nur einmal erstellt werden und ggf. von mehreren Befehlen genutzt werden könnten. Evtl. eine Annotation @Mapper mit einem TypeMapper als Argument statt einem String? Dann haben wir auch nicht mehr die dreckige string-lösung.

Liest sich arg hacky, ich fände es gut, wenn Mapperobjekte nur einmal erstellt werden und ggf. von mehreren Befehlen genutzt werden könnten. Evtl. eine Annotation @Mapper mit einem TypeMapper als Argument statt einem String? Dann haben wir auch nicht mehr die dreckige string-lösung.
Autor
Besitzer

Ich wollte die Mapper explizit von dem Parameter weghaben, damit diese explizit auch global erzeugt werden können. Das was du da liest ist eine abkürzung, womit du Mapper, welche du nur hier in diesem Befehl brauchst hier definierst und verwendest. Ab dem Moment wird es für alle Befehle, welche danach erzeugt werden auch existieren. Der String ist explizit, damit man ein Argument 'Material' haben kann, welches jedoch einen anderen Mapper haben kann. Der name ist dann auch so gut zu wählen wie nötig oder möglich.
Die Mapper an sich werden auch nur einmal erzeugt und dann in eine Map intern gepackt. Außerdem kann man in Annotationen keine Interfaces als fields verwenden:
image
Deswegen geht deine Idee leider nicht, hatte ich auch schon als Idee.

Ich wollte die Mapper explizit von dem Parameter weghaben, damit diese explizit auch global erzeugt werden können. Das was du da liest ist eine abkürzung, womit du Mapper, welche du nur hier in diesem Befehl brauchst hier definierst und verwendest. Ab dem Moment wird es für alle Befehle, welche danach erzeugt werden auch existieren. Der String ist explizit, damit man ein Argument 'Material' haben kann, welches jedoch einen anderen Mapper haben kann. Der name ist dann auch so gut zu wählen wie nötig oder möglich. Die Mapper an sich werden auch nur einmal erzeugt und dann in eine Map intern gepackt. Außerdem kann man in Annotationen keine Interfaces als fields verwenden: ![image](/devlabs/attachments/7bc5f00b-475e-4314-bdd1-7fc6a4dbe5f0) Deswegen geht deine Idee leider nicht, hatte ich auch schon als Idee.
YoyoNow hat 1 Commit 2021-03-25 19:52:33 +01:00 hinzugefügt
Autor
Besitzer

Lixfel das Help System bin ich auch noch am überarbeiten. Da habe ich noch keine direkte Idee wie ich es lösen soll. Aber vllt kommt mir ja noch eine.

Lixfel das Help System bin ich auch noch am überarbeiten. Da habe ich noch keine direkte Idee wie ich es lösen soll. Aber vllt kommt mir ja noch eine.
YoyoNow hat 1 Commit 2021-03-25 20:10:56 +01:00 hinzugefügt
YoyoNow hat 2 Commits 2021-03-25 20:27:55 +01:00 hinzugefügt
Autor
Besitzer

Das Help System könnte nun so deinen Vorstellungen nun mehr entsprechen.

Das Help System könnte nun so deinen Vorstellungen nun mehr entsprechen.
YoyoNow hat ein Review von Lixfel 2021-03-25 20:30:57 +01:00 angefragt
YoyoNow hat 1 Commit 2021-03-25 20:46:08 +01:00 hinzugefügt
Add SWCommandUtils.getAnnotation
Add GameMode mapper for better gamemode handling
YoyoNow hat 1 Commit 2021-03-25 20:55:49 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 08:40:13 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 08:44:47 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 08:57:43 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 08:59:17 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 09:06:26 +01:00 hinzugefügt
Optimize SubCommand
YoyoNow hat 1 Commit 2021-03-26 09:09:45 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-26 09:16:06 +01:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 20:52:22 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 22:14:58 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 22:20:09 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 22:28:38 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 22:35:36 +02:00 hinzugefügt
Add SWCommandUtils.addMapper with class
YoyoNow hat 1 Commit 2021-03-29 22:51:33 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 22:57:04 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-29 23:06:35 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 08:22:02 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 08:24:21 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 08:28:12 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 08:36:10 +02:00 hinzugefügt
Lixfel hat 2021-03-30 08:41:03 +02:00 Änderungen angefragt
@ -0,0 +52,4 @@
// Another Command, subCommands can be implemented with the Register Annotation,
// you can use custom Mappers by putting a Mapper Annotation on a Parameter
@Register({"two"})
public void testTwo(Player player, int i, @Mapper("solidMaterial") Material material) {
Besitzer

Das das ganze mit Strings funktioniert, gefällt mir immer noch nicht (und dir wsl. auch nicht). Da anscheinend keine Interfaces, sondern nur konkrete Instanzen einer Klasse verwendet werden können: Mach doch eine Klasse TypeMapper, die als Parameter eine Funktion String -> Objekt nimmt. Dann ist das eine klare Klasse. Ggf. ist das dann erstmal ein Object (wenn Templating nicht geht) ansonsten spricht aber meines Wissens nach nix dagegen, oder?

Das das ganze mit Strings funktioniert, gefällt mir immer noch nicht (und dir wsl. auch nicht). Da anscheinend keine Interfaces, sondern nur konkrete Instanzen einer Klasse verwendet werden können: Mach doch eine Klasse TypeMapper, die als Parameter eine Funktion String -> Objekt nimmt. Dann ist das eine klare Klasse. Ggf. ist das dann erstmal ein Object (wenn Templating nicht geht) ansonsten spricht aber meines Wissens nach nix dagegen, oder?
Autor
Besitzer

Ich verstehe dein Vorschlag nicht ganz. Du willst, dass ich in der Annotation eine Object angebe, welches dann eine Function<String, Object> beinhaltet. Wie soll das das Mapper zeug lösen. Kannst du versuchen das nochmal etwas genauer zu beschreiben?

Ich verstehe dein Vorschlag nicht ganz. Du willst, dass ich in der Annotation eine Object angebe, welches dann eine Function\<String, Object> beinhaltet. Wie soll das das Mapper zeug lösen. Kannst du versuchen das nochmal etwas genauer zu beschreiben?
Autor
Besitzer

image

Das hier spricht dagegen (Allowed Types in Annotation):

  • primitive
  • String
  • an Enum
  • another Annotation
  • Class
  • an Array of the above

Multidimensional arrays are forbidden. Arrays of type Class are forbidden.

Hier warum letzteres verboten ist:
image

'Constant Expressions' ist das Stichwort

![image](/devlabs/attachments/3c90a023-f8d5-4ba7-827e-473af354ade4) Das hier spricht dagegen (Allowed Types in Annotation): - primitive - String - an Enum - another Annotation - Class - an Array of the above Multidimensional arrays are forbidden. Arrays of type Class are forbidden. Hier warum letzteres verboten ist: ![image](/devlabs/attachments/2081e223-2da1-4f23-96ca-2cd5b0101bd7) 'Constant Expressions' ist das Stichwort
@ -0,0 +31,4 @@
public abstract class SWCommand {
private boolean enabled = true;
Besitzer

Das ist nicht so das, was ich fürs FightSystem gemeint habe. Ich möchte eigentlich nicht, dass sich der Command merkt, ob er jetzt enabled oder disabled ist, sondern den Command einfach Registrieren und aber auch wieder Entregistrieren können. Dann kann ich nämlich auch bestimmen, wass der Command macht, wenn er "disabled" ist, oder gar komplexere State-Machines umsetzen.

Das ist nicht so das, was ich fürs FightSystem gemeint habe. Ich möchte eigentlich nicht, dass sich der Command merkt, ob er jetzt enabled oder disabled ist, sondern den Command einfach Registrieren und aber auch wieder Entregistrieren können. Dann kann ich nämlich auch bestimmen, wass der Command macht, wenn er "disabled" ist, oder gar komplexere State-Machines umsetzen.
Autor
Besitzer

Ok ich gucke, dass ich das eingebaut bekomme, an sich muss ich ja nur unregister können. Weril registerieren tust du ja mit einer Instanz erzeugen,

Ok ich gucke, dass ich das eingebaut bekomme, an sich muss ich ja nur unregister können. Weril registerieren tust du ja mit einer Instanz erzeugen,
Autor
Besitzer

Dies sollte nun möglich sein.

Dies sollte nun möglich sein.
@ -0,0 +32,4 @@
public abstract class SWCommand {
private boolean enabled = true;
private final Set<SubCommand> commandSet = new HashSet<>();
Besitzer

Da du glaube sowieso keinen Befehl doppelt einfügst und dann häufig drüberiterierst, wäre glaube ich eine ArrayList angebrachter.

Da du glaube sowieso keinen Befehl doppelt einfügst und dann häufig drüberiterierst, wäre glaube ich eine ArrayList angebrachter.
Autor
Besitzer

Ich glaube eher eine LinkedList, weil ich nur drüber iteriere oder?

Ich glaube eher eine LinkedList, weil ich nur drüber iteriere oder?
Besitzer

Nein, der Vorteil einer Linkedlist ist eher nur bei häufigem Entfernen aus der Mitte gegeben. Die ArrayList ist auch beim Iterieren schneller, weil da ja einfach nur der index um eins erhöht werden muss (bessere Speicherpositionierung)

Nein, der Vorteil einer Linkedlist ist eher nur bei häufigem Entfernen aus der Mitte gegeben. Die ArrayList ist auch beim Iterieren schneller, weil da ja einfach nur der index um eins erhöht werden muss (bessere Speicherpositionierung)
@ -0,0 +54,4 @@
};
static {
addMapper(boolean.class, Boolean.class, createMapper(Boolean::parseBoolean, s -> Arrays.asList("true", "false")));
Besitzer

Wird wirklich irgendwo als Parameter "Boolean" benötigt? Oder "Float"? Oder...

Wird wirklich irgendwo als Parameter "Boolean" benötigt? Oder "Float"? Oder...
Autor
Besitzer

Ich finde Boolean und Float ist benötigt, da man diese Mapper von außen nicht so schön erzeugen kann und wir sollten etwas Zukunftsicher an sich sache gehen, was benötigt wird.

Ich finde Boolean und Float ist benötigt, da man diese Mapper von außen nicht so schön erzeugen kann und wir sollten etwas Zukunftsicher an sich sache gehen, was benötigt wird.
@ -0,0 +97,4 @@
} catch (IllegalArgumentException | IllegalAccessException e) {
throw new SecurityException(e.getMessage(), e);
} catch (InvocationTargetException | RuntimeException e) {
Bukkit.getLogger().log(Level.INFO, e.getMessage(), e);
Besitzer

Ich denke mal, das throw new SecurityException aus der Zeile drüber wäre auch angebracht. Auf jeden Fall für "RuntimeException".

Ich denke mal, das throw new SecurityException aus der Zeile drüber wäre auch angebracht. Auf jeden Fall für "RuntimeException".
@ -0,0 +105,4 @@
List<String> tabComplete(CommandSender commandSender, String[] args) {
if (!varArgs && args.length < arguments.length - 1) {
return Collections.emptyList();
Besitzer

Entweder du behandelst im SWCommand nicht den Fall null, oder du returnst immer eine leere Liste. Bitte nicht beides zeitgleich.

Entweder du behandelst im SWCommand nicht den Fall null, oder du returnst immer eine leere Liste. Bitte nicht beides zeitgleich.
Autor
Besitzer

Denn fall null behandle ich eigentlich wegen unsauberen TabCompletern, die eigengeschrieben sind.

Denn fall null behandle ich eigentlich wegen unsauberen TabCompletern, die eigengeschrieben sind.
Besitzer

Dann nutze doch auch einfach immer null.

Dann nutze doch auch einfach immer null.
YoyoNow hat 1 Commit 2021-03-30 08:55:23 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 09:08:09 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 09:21:33 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 09:23:43 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 10:01:34 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 10:10:26 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 12:03:52 +02:00 hinzugefügt
Sort SWCommand.commandHelpSet by subCommand length
YoyoNow hat 1 Commit 2021-03-30 13:40:52 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 13:50:21 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 13:54:59 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 14:07:00 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 14:31:58 +02:00 hinzugefügt
Add SWCommandUtils varArg capabilities
YoyoNow hat 1 Commit 2021-03-30 16:08:57 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 16:14:34 +02:00 hinzugefügt
Add ignoreCase tabComplete filter
YoyoNow hat 1 Commit 2021-03-30 16:27:26 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 16:54:47 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 17:26:49 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 17:56:23 +02:00 hinzugefügt
YoyoNow hat 1 Commit 2021-03-30 18:05:34 +02:00 hinzugefügt
Zeanon hat den Titel von WIP: CommandFramework3 zu CommandFramework3 2021-03-30 20:37:23 +02:00 geändert
Zeanon hat sich das Issue 2021-03-30 20:37:41 +02:00 selbst zugewiesen
Zeanon hat die Änderungen 2021-03-30 20:38:19 +02:00 genehmigt
Zeanon hat einen Kommentar hinterlassen
Mitglied

Exzessiv getestet

Exzessiv getestet
Zeanon hat die Änderungen 2021-03-30 21:15:23 +02:00 genehmigt
Zeanon hat Commit 3de86209f7 in master 2021-03-30 21:15:40 +02:00 manuell gemerged
Mitglied

Der merge kam aufgrund eines Missverständnisses zwischen Yoyo und mir, sry D;
Kaputt gehen kann aber davon nix

Der merge kam aufgrund eines Missverständnisses zwischen Yoyo und mir, sry D; Kaputt gehen kann aber davon nix
Anmelden, um an der Diskussion teilzunehmen.
Keine Beschreibung angegeben.