Forge Mod detection #292
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/BungeeCore#292
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "ModDetection1.13+" 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?
TODO: Mods schön aus dem Binär-blob rausholen und handeln.
@ -0,0 +1,44 @@
package de.steamwar.bungeecore.listeners.mods;
Fehlender License-Header
@ -0,0 +33,4 @@
public void handle(LoginPayloadResponse response){
if(response.getData() == null) {
System.out.println("Data is null with id: " + response.getId() + " , which means Client has no installed mods!");
Diese Zeile bitte in der Production-Fassung entfernen.
@ -0,0 +37,4 @@
event.completeIntent(BungeeCore.get());
return;
}
Noch fehlende Modprüfung :)
@ -0,0 +38,4 @@
return;
}
Ich finde es hier gefährlich, dass du hier den PacketHandler nicht zurück auf den InitialHandler setzt (deshalb hat es wahrscheinlich auch nicht mit dem PreLoginEvent geklappt).
Es dürfte aber durch dadurch, dass LoginEvent.completeIntent dazu führt, dass es dann entweder einen Disconnect oder direkt den PlayHandler gibt, egal sein. Daher entweder den Packethandler zurücksetzen oder sich gar nicht hier den Wrapper merken (wozu brauchst du den sonst hier).
@ -0,0 +1,48 @@
package de.steamwar.bungeecore.listeners.mods;
Fehlender License-Header
@ -41,3 +48,4 @@
private static final String FMLHS13 = "fml:handshake";
private static final String WRAPPER = "fml:loginwrapper";
private static final byte[] REGISTER;
private static final byte[] REGISTER13;
Bitte nicht vergessen, den alten 1.13 Forge-Support auszubauen :) (Aber bitte den 1.12- Support drin lassen!)
Du kannst dann auch ich glaube im Fabric-Modhandler? den Arenenblock für Forge-Spieler ausbauen.
@ -61,0 +70,4 @@
public void onServerConnected(LoginEvent event){
//Wir senden Packet ID 1
//Wir wollen empfangen Packet ID 2
//(FMLHS13, new byte[]{4, 1, 0, 0, 0});
Die Kommentarzeile (und ggf. noch die Zeilen drüber) können weg.
@ -61,0 +72,4 @@
//Wir wollen empfangen Packet ID 2
//(FMLHS13, new byte[]{4, 1, 0, 0, 0});
//13,102,109,108,58,104,97,110,100,115,104,97,107,101 = 13 + "fml:handshake"
event.getConnection().unsafe().sendPacket(new LoginPayloadRequest(1,WRAPPER, new byte[]{13,102,109,108,58,104,97,110,100,115,104,97,107,101,4,1,0,0,0}));
Hier vorher noch eine Prüfung, dass der Client 1.13 oder höhere Version hat (in dem Fall einfach return). 1.12 und niedriger kennt nämlich keine LoginPayloadRequests.
@ -61,0 +86,4 @@
ch.setAccessible(true);
wrapper = (ChannelWrapper) ch.get(handler);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
Ach ja, hier einen ordentlichen Logger benutzen, so wie BungeeCore.get().getLogger().log(Level.SEVERE, "Could not get Channel", e);
Und danach returnen.
Und vllt. auch erst nach der Reflection den Intent registrieren...
Schaut ansonsten (bis auf die Packetzerlegung) schon richtig gut aus!
@ -0,0 +32,4 @@
}
@Override
public String toString() {
Besteht hier wirklich die Notwendigkeit, toString zu überschreiben?
ja, ansonsten meckert intellij rum.
@ -0,0 +24,4 @@
import java.util.List;
public class FMLPing extends ServerPing {
private final ForgeData forgeData = new ForgeData();
Man könnte noch argumentieren, dass es äußerst schade ist, dass wir hier für jeden Ping die ForeData neu erstellen und danach wieder verwerfen, aber das ist so schon in Ordnung.
Könnte man das nicht einfach mit einem 'static' beheben?
wird morgn als erledigt markiert.
@ -0,0 +25,4 @@
public class FMLPing extends ServerPing {
static {
Also von einem static block war nicht die rede nur den static modifier. Also sowas wie 'private static ForgeData forgeData = new ForgeData();'.
Wo wird das überhaupt genutzt?
GSON-Serializer des ServerListPings.
Anmerkung meinerseits: Ob das korrekt serialisiert wird, wenn die ForgeData als static final deklariert wird, muss getestet werden.
Naja es ist static also gar nicht serializiert? Ansonsten mach halt mit einem instance ansatz, im ForgeData selber.
Ist unbekannt ob, muss daher getestet werden.
static mact hier in diesem Falle nur probleme
@ -0,0 +25,4 @@
public class FMLPing extends ServerPing {
private static final ForgeData data = new ForgeData();
Ich glaube, das muss weiterhin forgeData heißen, ansonsten erkennt Forge die Modliste nicht... du solltest auch mal probieren, mit Minecraft-Versionen anders als 1.15.2, ob dann immer noch die Kompatibilität gemeldet wird (da wir ja minecraft 1.15.2 als Mod drin haben...
Kompatibilität wird verneint. Forge 1.16.5
WIP: Primitive Versionzu Forge Mod detection@zOnlyKroks Habe jetzt mal das Parsing mit implementiert, du musst einmal testen, ob die Mods korrekt erkannt werden. Und du musst noch die Kompatibilität mit Forge-Versionen anders als 1.15.2 einbauen.
@ -0,0 +80,4 @@
}
public String toString() {
return name().replace("MINECRAFT_", "").replace("_", ".");
Wäre es nicht einfacher, statt dem Enum einfach direkt eine HashMap<Integer, String> zu machen?
Schaut soweit gut aus.
@YoyoNow könntest du auch nochmal drübergucken (nachdem ich einen nicht vernachlässigbaren Teil selbst zusammengepfuscht habe)?
@ -0,0 +33,4 @@
private static class ForgeData {
private final List<ForgeChannel> channels = new ArrayList<>();
private final List<ForgeMod> mods = new ArrayList<>();
Style?