Die Leute vom mono-Projekt haben irgendwann mal gesagt, dass sie WPF niemals unterstützen werden. Core 3 soll tatsächlich WPF können, bleib abzuwarten.

Und nur als Wink mit dem Zaunpfahl: Der W-Client wurde ebenfalls mit WPF gebaut.

Wie wäre es damit?

Avalonia UI Framework

Wenn ich das eben richtig überflogen habe, ist das keine Runtime - die also WPF unter *nix ausführen kann - sondern ein eigenes UI-Framework, dass ebenso wie WPF auf XAML basiert. Ich müsste große Teile des Clients dafür neu bauen.

Die Leute vom mono-Projekt haben irgendwann mal gesagt, dass sie WPF niemals unterstützen werden. Core 3 soll tatsächlich WPF können, bleib abzuwarten.

Und nur als Wink mit dem Zaunpfahl: Der W-Client wurde ebenfalls mit WPF gebaut.

Wie wäre es damit?

Avalonia UI Framework

Wenn ich das eben richtig überflogen habe, ist das keine Runtime - die also WPF unter *nix ausführen kann - sondern ein eigenes UI-Framework, dass ebenso wie WPF auf XAML basiert. Ich müsste große Teile des Clients dafür neu bauen.

Ich erspare dir das Suchen:

Avalonia for WPF Developers

Die Leute vom mono-Projekt haben irgendwann mal gesagt, dass sie WPF niemals unterstützen werden. Core 3 soll tatsächlich WPF können, bleib abzuwarten.

Und nur als Wink mit dem Zaunpfahl: Der W-Client wurde ebenfalls mit WPF gebaut.

Wie wäre es damit?

Avalonia UI Framework

Wenn ich das eben richtig überflogen habe, ist das keine Runtime - die also WPF unter *nix ausführen kann - sondern ein eigenes UI-Framework, dass ebenso wie WPF auf XAML basiert. Ich müsste große Teile des Clients dafür neu bauen.

Ich erspare dir das Suchen:

Avalonia for WPF Developers

Schon gesehen :)

Es ist eben ein grundlegend anderes Framework - mal eben portieren ist da anscheinend nicht drin.

Die Leute vom mono-Projekt haben irgendwann mal gesagt, dass sie WPF niemals unterstützen werden. Core 3 soll tatsächlich WPF können, bleib abzuwarten.

Und nur als Wink mit dem Zaunpfahl: Der W-Client wurde ebenfalls mit WPF gebaut.

Wie wäre es damit?

Avalonia UI Framework

Wenn ich das eben richtig überflogen habe, ist das keine Runtime - die also WPF unter *nix ausführen kann - sondern ein eigenes UI-Framework, dass ebenso wie WPF auf XAML basiert. Ich müsste große Teile des Clients dafür neu bauen.

Ich erspare dir das Suchen:

Avalonia for WPF Developers

Schon gesehen

Es ist eben ein grundlegend anderes Framework - mal eben portieren ist da anscheinend nicht drin.

Außerdem ist gerade eine andere Lösung in der Schmiede, ich will aber noch nichts versprechen

Da ich gerade wenig Zeit habe, jedoch mal ein Update zwischen schieben wollte, hab ich den OP aktualisiert.

MfG 9L

Bekam grade ein Video empfohlen, wo jemand darüber redet das BattlEye Linux user mit wine in Battlecrap 5 gebannt hat.
Lang leben "false-positives", 100% genau und ohne Fehler.

YouTube Video


Dachte das interessiert paar von euch vlt.
Nicht wundern das er über EA redet, wie soll er denn sonst seine Clicks machen, EA ist ja immer das pure böse mittlerweile.

Kleines SITREP

Aktuell (schon länger) gibt es selsame Regressionen mit BattleEye. Einige Server funktionieren, andere nicht. BattleEye arbeitet mit Steam zusammen damit BattleEye unter Proton besser funktioniert.

Ansonsten Status Quo, Rest siehe OP

________________________________________________________

Zu Bans ist mir unter Arma nichts bekannt. False Positives haben wenn ich das richtig mitbekommen habe meistens nicht mit Linux zu tun, da ich mehr Fälle kenne das diese unter Windows vorkamen

Battlecrap nutzte früher nur Punkbuster, kein BE, nun aber ein Witz von Namenloser Eigenkreation. Gerüchten zufolge sind die sich auch zu fein etwas Geld für BE zu blechen

9L

Ich verstehe das jetzt nicht so ganz:
Ist "Battlecrap" jetzt eine Verballhornung von Battleeye und soll eben dieses Programm humoristisch diskreditieren oder ist damit etwas anderes gemeint?
Weil du, ninelore, schriebst:

Battlecrap nutzte früher nur Punkbuster, kein BE, nun aber ein Witz von Namenloser Eigenkreation.

Ich verstehe das jetzt nicht so ganz:
Ist "Battlecrap" jetzt eine Verballhornung von Battleeye und soll eben dieses Programm humoristisch diskreditieren oder ist damit etwas anderes gemeint?
Weil du, ninelore, schriebst:

Battlecrap nutzte früher nur Punkbuster, kein BE, nun aber ein Witz von Namenloser Eigenkreation.

Die "5" in "Battlecrap 5" lässt mich vermuten, dass hier "Battlefield" gemeint ist.

BattlEye wurde ursprünglich als externes Third-Party AC für Battlefield Vietnam entwickelt, die Namensähnlichkeit ist deswegen kein Zufall.

Zwar war es nie "offiziell", aber du warst schon fast genötigt BattlEye laufen zu haben wenn du auf einen Community Server spielen wolltest, was gefühlt fast jeder machte.

Dachte die offizielle Implementierung von BattlEye in der BF Serie zusammen mit PB und FairFight wäre seit Battlefield 4 Standard gewesen, da lag ich wohl falsch, so wies aussieht haben sich DICE und EA viel lieber Gedanken über Lootboxen statt einen ausreichenden AC System gemacht.

BattleCrap > Call of Failure

Status Quo bis hier.

Des weiteren gab es einige kleine Änderungen am OP

MfG 9L

Genau heute vor 2 Jahren hat Valve eine neue Version von Steam Play angekündigt, welche auf Basis von Proton läuft. Einige Tage später hab ich meinen Traum erfüllt, den ich seid meiner ersten Linux Erfahrung mit 7 Jungen Jahren alter schon hatte und bin au Linux als mein Hauptsystem umgestiegen.

Seid dem sind mittlerweile 85% meiner Spielbibliothek innerhalb wie außerhalb von Steam sehr gut auf Linux spielbar. Im Moment boote ich nur noch Linux für Arma unter W (ACRE), DCS World, Destiny 2 und andere Spiele die ich seltener spiele.

Eine kurze Chronik
August 2018: Ankündigung und Wechsel. Das spielen von einigen spielen, darunter Arma, gelang nicht durch eine kleine aber wichtige Kinderkrankheit: Die fehlende Möglichkeit, bei Spielen mit Linux depot Steam Play zu erzwingen. Arma hat ja den outdated Port by VP und z. b. Squad hatte ein sog. leeres Linux Depot.
Ende Januar 2019: Steam Play erzwingen wurde im Steam Client eingefügt. Erstmals war Arma stabil spielbar
Feb 2019 bis dto.: Viele neue Wine, Proton und DXVK Verbesserungen und einige Optimierungen am Wineprefix führten zu einem immer besseren Spielerlebnis. Mods sind bis auf wenige Ausnahmen voll funktionsfähig.



Aber genug Geschichte. Kommen wir zu nem
SITREP Hab aufgehört zu zählen

Nachdem ich mit Jokoho und danach mit ein paar anderen von ArmaOnUnix and ACRE herum experimentiert haben, kann ich mitteilen, das an Linux Support für ACRE langsam aber sicher gearbeitet wird. Den Anfang macht dieser Pull Request

Um BattleEye ist es still geworden. Bisher gilt hier immer noch Status Quo. Allerdings gibt es kollaborative Fortschritte bei EAC und einige Spiele, die EAC nutzen, funktionieren teilweise schon länger einwandfrei.

9L

Passend zur Diskussion im anderen Thread:

Wine 5.11 (Juni 2020)
- Wine Mono engine updated to 5.1.0, with WpfGfx library support

Im gleichen Release gibt es einen Bugfix für Arma1.

Da scheint es zumindest in die richtige Richtung zu gehen.

Habt ihr schonmal versucht, bei Wine direkt einen Bugreport wegen des Launchers zu platzieren?

SITREP mit neuem Durchbruch!!!

Ich habe die Ursache des ACRE Problems gefunden. Dies war der letzte große Stein der im Weg war, um Events bei W mit Linux zu spielen

Der neue Guide (WIP) und dieser Thread wird ins Armaworld Forum umziehen.
Allerdings werde ich hier vielleicht noch W-spezifische Dinge posten (wie Modsetangelegenheiten)

Bei Fragen DM oder Discord: ninelore#9823

MfG 9L

Ach ja....


Edit: @Wetzer
Ich weiß nicht ob das überhaupt noch nötig ist, da es mittlerweile 3rd Party launcher von ArmaOnUnix gibt, die alles und mehr können als der offizielle.
Aber ja, das könnte dennoch sinnvoll sein

Der neue Thread ist offen!

MfG 9L o/

Der Armaworld Guide ist nun komplett inklusive ACRE Guide

klick mich

MfG 9L o/