YARCC für BF3 - Unsere Battlefield3 Serversteuerung
Moderatoren: JDZ, Moderatoren
- ManiacAndy
- Geschäftsmodell
- Beiträge: 898
- Registriert: 23.01.2010, 14:48
- Wohnort: Eifel
- Kontaktdaten:
- ManiacAndy
- Geschäftsmodell
- Beiträge: 898
- Registriert: 23.01.2010, 14:48
- Wohnort: Eifel
- Kontaktdaten:
die icons aus diesem beitrag ware 14x12
http://www.fragthe.net/viewtopic.php?p=324290#324290
aber ich mach dir gerne auch neue ^^ wunderte mich nur weil ich ja schon passende erstellt hatte
http://www.fragthe.net/viewtopic.php?p=324290#324290
aber ich mach dir gerne auch neue ^^ wunderte mich nur weil ich ja schon passende erstellt hatte
- ManiacAndy
- Geschäftsmodell
- Beiträge: 898
- Registriert: 23.01.2010, 14:48
- Wohnort: Eifel
- Kontaktdaten:
- ManiacAndy
- Geschäftsmodell
- Beiträge: 898
- Registriert: 23.01.2010, 14:48
- Wohnort: Eifel
- Kontaktdaten:
Immer gerneJDZ hat geschrieben:Einfach spitze! Danke Andy
Mir ging neulich eine idee durch den kopf, bei der ich mir nicht sicher bin ob diese umsetzbar oder allgemein sinn macht, aber ich schlag trotzdem mal vor: Ist es möglich eine art "Server Watch"- Mode einzubauen, bei dem man quasi nur die Server IP eingibt und dann sieht was auf dem server so abgeht, inkl sehen wie die einstellungen dort sind? vielleicht sagt dir das tool HLSW etwas, das konnte das damals, kann mir aber gut vorstellen das es bei den Battlefield servern etwas komplizierter wäre.
Für was soll das gut sein?
Wenn YARCC einheloggt ist sieht man doch was
Sache ist und für alles andere gibts doch Battlelog.
Btw: ich werde den Serverlayer in YARCC integrieren und keine duale Lösung programmieren. Ich bin heil froh den gespendeten Laptop für die Entwicklung zu haben.
Folgende 2 features wird das Programm bald können:
- Auto team balance.
- Punish for forbidden weapons.
Wenn YARCC einheloggt ist sieht man doch was
Sache ist und für alles andere gibts doch Battlelog.
Btw: ich werde den Serverlayer in YARCC integrieren und keine duale Lösung programmieren. Ich bin heil froh den gespendeten Laptop für die Entwicklung zu haben.
Folgende 2 features wird das Programm bald können:
- Auto team balance.
- Punish for forbidden weapons.
Zuletzt geändert von JDZ am 13.03.2013, 22:25, insgesamt 1-mal geändert.
- ManiacAndy
- Geschäftsmodell
- Beiträge: 898
- Registriert: 23.01.2010, 14:48
- Wohnort: Eifel
- Kontaktdaten:
Stand der Entwicklung
Gestern Nacht habe ich den gesammten Quelltext von
YARCC Relay genommen und gelöscht. Der erste Lösungsversuch war mit einem Single threaded Serversocket und dieser ist kläglich gescheitert. Es traten
verschiedene Zuordnungprobleme auf und eine Umgehung dieser wäre von hinten durchs Knie.
Heute Nacht werde ich anfangen den Server Layer im Multithreading Verfahren zu programmieren. D.h. jeder
verbundene YARCC Client bekommt seinen eigenen ServerThread zur Abarbeitung aller Aufgaben und einen eigenen Empfangs- und Sendepuffer. Jeder Thread ist voll in sich gekapselt und kann die Rechteverwaltung einfacher implementieren.
Der YARCC Client hat Andys neue Icons erhalten und das Programmverhalten bei einem Socket Fehler wurde überarbeitet.
YARCC Relay genommen und gelöscht. Der erste Lösungsversuch war mit einem Single threaded Serversocket und dieser ist kläglich gescheitert. Es traten
verschiedene Zuordnungprobleme auf und eine Umgehung dieser wäre von hinten durchs Knie.
Heute Nacht werde ich anfangen den Server Layer im Multithreading Verfahren zu programmieren. D.h. jeder
verbundene YARCC Client bekommt seinen eigenen ServerThread zur Abarbeitung aller Aufgaben und einen eigenen Empfangs- und Sendepuffer. Jeder Thread ist voll in sich gekapselt und kann die Rechteverwaltung einfacher implementieren.
Der YARCC Client hat Andys neue Icons erhalten und das Programmverhalten bei einem Socket Fehler wurde überarbeitet.
Zwischenstand YARCC Relay
Jungs, der Groschen ist endlich gefallen. Da das Vorhaben mit dem Serverlayer ein klein wenig komplexer ist, habe ich eigens dafür eine tolle Klasse geschrieben die alle benötigten Membervariablen, Sende- und Empfangspuffer und die dazu gehörigen Objekte kapselt. Bei jedem Verbindungsaufbau erstelle/allokiere ich explizit für das verbundene Socket eine Kopie dieser Klasse und verwalte sie in dem Thread der explizit für jede Clientverbindung läuft.
Somit sind alle Zuordnungsprobleme im Keim erstickt.
Ergebis: Funktioniert wirklich toll und ist m.e. sehr sauber gelöst
Nächster Schritt ist die Authentifizierung per User/PW zu implementieren (da bin ich mal Faul und nehme ne fertige Indy Komponente) und die Rechteverwaltung für die verbundenen Clients. 2 Gruppen in Form von "User" (darf nur Player und Mapchanges verwalten) und "Administrator" (darf alles) sollte ausreichen, oder was meint ihr?
Neben der Rechteverwaltung die ohnehin intern jedes Datenpaket überprüft ob es den Bestimmungen entspricht, werde ich auch ein kleines Magic Paket direkt nach dem Login an den Client senden um damit die Funtionen zu deaktivieren, die dem Userkonto nicht zugänglich sind. So sieht man direkt was man darf und was nicht...
Somit sind alle Zuordnungsprobleme im Keim erstickt.
Ergebis: Funktioniert wirklich toll und ist m.e. sehr sauber gelöst
Nächster Schritt ist die Authentifizierung per User/PW zu implementieren (da bin ich mal Faul und nehme ne fertige Indy Komponente) und die Rechteverwaltung für die verbundenen Clients. 2 Gruppen in Form von "User" (darf nur Player und Mapchanges verwalten) und "Administrator" (darf alles) sollte ausreichen, oder was meint ihr?
Neben der Rechteverwaltung die ohnehin intern jedes Datenpaket überprüft ob es den Bestimmungen entspricht, werde ich auch ein kleines Magic Paket direkt nach dem Login an den Client senden um damit die Funtionen zu deaktivieren, die dem Userkonto nicht zugänglich sind. So sieht man direkt was man darf und was nicht...