YARCC für BF3 - Unsere Battlefield3 Serversteuerung

[Fussballgott]

2 Gruppen in Form von "User" (darf nur Player und Mapchanges verwalten) und "Administrator" (darf alles) sollte ausreichen, oder was meint ihr?

Für FTN definitiv. Sind dann aber ja eher virtuelle Gruppen, oder? (user.isAdmin = true)

[Pionic]

Was sind denn die genauen Berechtigungen der User-Gruppe? Dürfen die auch

• bannen
• Spambot bedienen
• VIP-Playerlist editieren
• Servername + Serverpasswort editieren
• Presets ändern
• Mapvariablen ändern?

Wäre es viel Arbeit, die einzelnen Berechtigungen in Gruppen (ähnlich wie in der Liste oberhalb) zusammenzufassen, so dass die Admin-Gruppe dann die Berechtigungen für die User-Gruppe freischalten kann?
Die User-Gruppe hätte dann als Grundberechtigung die von dir genannten Optionen und - je nach Admin-/Communityentscheidung - zusätzlich freigeschaltene Optionen.

Fände ich eine schöne Lösung, bei der es in meinen Augen dann auch die zwei Gruppen tun würden, allerdings mit optionalem Berechtigungsumfang.

[BlackSoul]

Als ich diese Funktionalitäten damals mit David besprach, war es natürlich auch angedacht dass diese Funktionen variabel sein müssten. Nicht unbedingt für uns. Aber da ja seitens David auch eine Verbreitung des Programms angedacht ist, gerade in Bezug auch auf BF4. Um vom Start an dabei sein zu können. Und um mit einem sehr schlanken und kompakten Programm punkten zu können.
Gerade deswegen sind variable Rechtevergaben einfach auch notwendig.

Die genauen Rechtevergaben sind meines Wissens nach allerdings noch nicht wirklich festgelegt, Pio. Oder wie schaut es da aus, David?

[Fussballgott]

Gruppen sind ja nicht grundsätzlich an bestimmte Berechtigungen gebunden, sondern nur Organisationseinheiten. Insofern wird es bestimmt konfigurierbar werden, was die einzelnen Gruppen so dürfen.

Aber wenn ich Blacky Post so angucke sollte man doch mehr als 2 Gruppen vorsehen um mehr Szenarien abdecken zu können (z.B. Serveradmins aka Superuser, Clanleader, Clanmember, Publics).

[Pionic]

Die genauen Rechtevergaben sind meines Wissens nach allerdings noch nicht wirklich festgelegt, Pio.

Mir ist das ja relativ egal.

Mein Post war nur darauf bezogen, was ich mir wünschen würde, wenn ich dürfte.

edit:

Aber wenn ich Blacky Post so angucke sollte man doch mehr als 2 Gruppen vorsehen um mehr Szenarien abdecken zu können (z.B. Serveradmins aka Superuser, Clanleader, Clanmember, Publics).

Warum sollten Publics einen Serverzugang erhalten? Und wo liegt bei YARCC der Unterschied in einem Clanmember und -leader?

[ManiacAndy]

edit:

Aber wenn ich Blacky Post so angucke sollte man doch mehr als 2 Gruppen vorsehen um mehr Szenarien abdecken zu können (z.B. Serveradmins aka Superuser, Clanleader, Clanmember, Publics).

Warum sollten Publics einen Serverzugang erhalten? Und wo liegt bei YARCC der Unterschied in einem Clanmember und -leader?

Hierarchie, denke mal puplic wäre so eine sache wie das man irgend einen code in den chat eingibt und der server dann eine bestimmte nachricht ausspuckt, oder einen vote ausführt und wertet etc. wobei ich mir grad nicht sicher bin ob das was mit yarcc zu tun hat^^

aber ansonsten wäre es ne tolle sache, dann könnten so "normal" zocker wie ich auch mal ne kleinigkeit administrieren ohne vollen zugang zu benötigen bzw. andere admins zu nötigen "hey mach mal das und das, aber zackig"

[JDZ]

Die Gruppen sind rein virtuell. User.Admin=true ist da etwas zu Oberflächlich für diesen Anwendungsfall. Ich gehe da noch tiefer. Explizite Rechtevergabe für jeden Befehl ist natürlich Vorgesehen. Das was ich meinte diente nur als Beispiel. Die Frage war eher wie viele unterschiedliche Gruppen werden benötigt. Pro Gruppe kann man dann wählen welche Befehle zugelassen sind. Kommt ein Paket mit einem Befehl an was nicht zur Berechtigung gehört wird es verworfen. Dies funktionierte bei unserem LFS Dedilink hervorragend. Ich stehe schon den ganzen Tag mit einem befreundeten Entwickler in Kontakt und wir Fachsimpeln über die technischen Hintergründe. Heute Nacht werde ich den Tunnel zum BF3 Server für jede Verbindung fertigschreiben. Es steht noch ein haufen Arbeit an. Aber ich
denke dass es wirklich gut wird.

Blacky, die Verbreitung ist eher Nebensache. Viel wichtiger ist es das wir eine gute Serversteuerung bekommen, ich mir dabei eine Referenz schaffen kann, um endlich mal eine gescheite Arbeit zu bekommen und nicht mehr in meinem jetzigen Betrieb arbeiten muss und einfach aus Spass daran.

[JDZ]

Der Tunnel funktioniert. Ich kann bereits mit YARCC auf den Serverlayer connecten und erhalte eine saubere Paketweiterleitung in beide Richtungen

[JDZ]

Nach einer Debug Session bis in die frühen Morgenstunden mit unserem Yoman läuft der Serverlayer nun in allen Lebenslagen fehlerfrei. War ne schwere Geburt aber Jan brachte den entscheidenden Tip!
Wäre schön wenn wir heute Abend mal einen Realtestlauf machen könnten.

ToDo Liste:
- Benutzerkontenverwaltung
- Rechteverwaltung
- Synchronisation
- AutoAdmin: Teambalance, Rules,Welcome Messages, Kill on forbidden Weapons/Vehicles.

[Fussballgott]

Hoffentlich lässt sich ein Teil der ganzen Arbeit ohne große Umstellungen auch bei BF4 nutzen!

[JDZ]

Aus diesem Grund hab ich YARCC so modular wie nur möglich aufgebaut. So wie ich die Lage einschätze wird die Einbindung wie bei einem neuen DLC verlaufen - Dauer ~30min.
Definitiv wird BF4 ebenfalls über das Rcon Protokoll verfügen was ja bereits vollständig implementiert wurde. Schrauben die Jungs am Protokoll herum dauert es dann leider etwas länger.
Der größte Nachteil im Faktor Zeit ist das ich alleine bin.
Ich schreibe den verantwortlichen Dice Entwickler Kalms mal an ob ich eine Chance habe in den Admin Tool Developer Pool zu kommen um das BF4 Protokoll schon vor release zu erhalten.

[JDZ]

So schauts bisher aus. Die Rechtevergabe habe ich bewusst so klein gehalten wie nur möglich. In den Servervariablen einzelne Berechtigungen zu vergeben ist unfug da diese eine logische Einheit bilden. Diese sind als Servervariablen global unter "Edit server variables" zusammengefasst. Der Testlauf heute zeigte, dass die interne Verbindungsverwaltung sehr gut funktioniert. Das User Management ist auch schon implementiert sowie die nötigen GUI Elemente.

[tequilio]

Wie schwer ist es ingame Kommandos zu implementieren? Sprich /kick /ban /move?

[Licherkette]

Nach einer Debug Session bis in die frühen Morgenstunden mit unserem Yoman läuft der Serverlayer nun in allen Lebenslagen fehlerfrei. War ne schwere Geburt aber Jan brachte den entscheidenden Tip!
Wäre schön wenn wir heute Abend mal einen Realtestlauf machen könnten.

MEIN NEFFE

Übrigens David: Der Joman studiert Informatik, der kann da mit einsteigen!!
Ich glaube sogar, das würde ihm sehr viel Spass machen, frag ihn doch mal

[JDZ]

Wie schwer ist es ingame Kommandos zu implementieren? Sprich /kick /ban /move?

Wie meinst du das genau? Falls du die Chat Zeile meinst ist es nicht schwer. Allerdings ist ein ALT+Tab -> YARCC -> Kick,Ban,etc schneller als das geschreibsel

@Lichi: Yoman hat leider noch keinerlei Erfahrung mit der VCL (Visual Component Library) worauf YARCC aufbaut.

Btw: Die User Account Verwaltung is fick un fertik