join anytime #359
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/FightSystem#359
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "joinAnytime" 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?
Signed-off-by: Lixfel agga-games@gmx.de
WIP: join anytimezu join anytime@ -141,4 +142,2 @@
new TBCommand();
new DeclineCommand();
new GamemodeCommand();
new InviteCommand();
Warum wird das ganze Invite System entfernt?
Finde, es hat immer noch seinen nutzen und sollte parallel zu den Requests bestehen.
Das Invite-System wurde entfernt, da es nochmal deutlich aufwändiger ist, beide Varianten zu unterstützen.
Die genannten Beispiele halte ich für ungeeignet, da eh meistens die Spieler erstmal mit "inv" um Beitritt betteln müssen (was sie jetzt direkt anfragen können). Auch bei Massenfights ändert sich kaum etwas, außer, dass Zuschauer nicht mehr ständig Beitrittsanfragen ablehnen müssen. Massenannahmen sollten vonseiten des Leaders aus problemlos möglich sein.
@ -247,0 +250,4 @@
JOIN_REQUEST=§7Request join
JOIN_REQUEST_TITLE=Request join
JOIN_REQUEST_ALREADY=§cYou have already sent a join request
JOIN_REQUEST_TEAM=§eJoin {0}
§7Join §e{0}
?Colorcode vor dem Parameter macht keinen Sinn, da der gefärbte Teamname eingesetzt wird.
@ -247,0 +252,4 @@
JOIN_REQUEST_ALREADY=§cYou have already sent a join request
JOIN_REQUEST_TEAM=§eJoin {0}
JOIN_REQUEST_CONFIRMATION=§7Join request submitted
JOIN_REQUEST_NOTIFICATION=§e{0} §7requests joining team {1}§8. §7Accept or decline using §8/§erequests
...requests joining your team?
Nein, kann auch das andere Team sein (nach Kampfbeginn)
@ -247,0 +257,4 @@
REQUESTS=§7Open join requests
REQUESTS_TITLE=Open join requests
REQUEST_DECLINED=§cJoin of {0} declined
YOUR_REQUEST_DECLINED=§cYour join request was declined
Die Keys sollten ziemlich gleich anfangen, um sie namentlich gruppiert zu haben.
@ -50,4 +50,0 @@
private static FightTeam checkGetInvitedTeam(Player p){
FightTeam fightTeam = Fight.getInvitedTeam(p);
if(fightTeam == null){
FightSystem.getMessage().sendPrefixless("NO_INVITATION", p, ChatMessageType.ACTION_BAR);
Wenn man die Invitation Sachen wirklich entfernen möchte, sollte man auch die Nachrichten dann auch aus den .properties Datein löschen
@ -67,0 +60,4 @@
return;
}
SWInventory inv = new SWInventory(p, 9, msg.parse("JOIN_REQUEST_TITLE", p));
Würde hier eher ein Hopper Inventar nehmen, ist nicht so viel leerer platz im Inventar.
Geht nicht ohne aufwändigerer API, ist mMn. nicht soo wichtig.
@ -67,0 +63,4 @@
SWInventory inv = new SWInventory(p, 9, msg.parse("JOIN_REQUEST_TITLE", p));
if(!Fight.getRedTeam().isPlayerInTeam(p))
addTeamRequest(p, inv, 0, Fight.getBlueTeam());
if(!Fight.getBlueTeam().isPlayerInTeam(p))
Vllt. die Knöpfe ausgrauen, anstatt die gar nicht anzuzeigen?
@ -69,0 +78,4 @@
Player bukkit = Bukkit.getPlayer(uuid);
if(bukkit != null)
player = bukkit;
return player;
Weiß nicht, ob es so geil ist, das Interface des geleavten Spielers immer noch herauszugeben.
Das ist zwingend notwendig für das korrekte Funktionieren des Kampfsystems und war auch bislang immer so, nur dass beim Rejoin des Spielers der dann halt nichts mehr mit dem alten Spieler zu tun hatte (was mit diesem PR dann allerdings katastrophal wäre).
@ -45,6 +48,12 @@ import java.util.function.Consumer;
public class HotbarKit extends Kit {
public static final HotbarKit spectatorKit = new HotbarKit();
Konstanten im SCREAMING_SNAKE_CASE
@ -14,3 +14,2 @@
ak:
accept:
decline:
request:
Die sind doch mit dem CommandFramework garnicht nötig?
Das FightSystem nutzt das CommandFramework aufgrund der komplexeren (De-)Aktivierungs- und Initialisierungsbedingungen nicht.