Beiträge von ronald drunk

Hast du mal den Link zu DockerHub. Ansonsten ist es prinzipiell sinnvoll, sich nach der Anzahl der Pulls zu richten.
Folgendes Image sieht z.B. ganz gut aus: https://hub.docker.com/r/gonzih/csgo-server/

Problem ist, dass du mit dem RUN-Befehl, also zur Zeit des Erstellen des Images (nicht Container!), den Home- und Serverordner erstellst und dann beim Erstellen des Containers nochmal versuchst das VOLUME darüber zu mounten, obwohl der Ordner im Container schon existiert. Das geht nicht.

Grundsätzlich ist die Idee von Docker außerdem, dass du die Anwendungsdateien von den eigentlichen Daten (z.B. Konfigurationsdateien) trennst, sodass du zum Updaten das Image austauschst, indem du den Container neu erstellst und dann die Konfigurationsdateien über das Volume übernimmst.

Konkret heißt das: Dein Volume ist sowas wie VOLUME ["/home/csgo/server/csgo/csgo/cfg"] (sofern die Configdateien permanent gespeichert werden sollen) und alles andere gehört fest zum Image.

Zudem ist ENTRYPOINT eher für Binaries (z.B. Shells) vorgesehen. Dementsprechend sollte "./csgo.sh" eher mit in den CMD-Befehl rein und die ENTRYPOINT-Anweisung weg.

So klar ist das 'Nein' dann doch nicht.

Es gibt unter den Standardressourcen eine Ressource namens "amx" (siehe https://github.com/multitheftauto…es%5D/%5Bamx%5D), die SA:MP-Skripte so wie sie vorliegen direkt laden kann. Problem ist allerdings, dass das Teil schon länger nicht mehr gewartet wurde und dementsprechend einiges an Zeit investiert werden müsste, um es auf den aktuellen Stand zu bringen.
Prinzipiell sollte es aber möglich sein, den Großteil der Funktionen auf diesem Weg zum Laufen zu bekommen.

Ob es hier sinnvoll ist, bleibt jedoch eine andere Frage. Sofern neue Features entwickelt werden sollen und der Umfang des Gamemodes überschaubar ist, macht ein manuelles Übersetzen wahrscheinlich mehr Sinn.

Du kannst den Browser so verwenden wie eine Textur.

Konkret z.B. so:

function loadGifAnimation(url, sizeX, sizeY)
  local browser = createBrowser(sizeX, sizeY, false)


  addEventHandler("onClientBrowserCreated", browser,
    function()
      loadBrowserURL(browser, url)
    end
  )
end


local gifAnimation = loadGifAnimation("http://my.tld/animation.gif", 400, 300)
addEventHandler("onClientRender", root,
  function()
    dxDrawImage(100, 100, 400, 300, gifAnimation)
  end
)

...ohje - das ist gefühlt ein halbes Jahr her, dass ich Lua für MTA geschrieben habe.

Für den ersten Frame müsstest du dir wohl irgendwas mit Javascript basteln (ggf. einfach per executeBrowserJavascript laden, nachdem die Seite geladen wurde per onClientBrowserDocumentReady).

Zitat von Sam@ke

wenn ich mir von "Offset" bis "Streaming size" nun den Bytes-Block ziehe, erhalte ich dann die Datei?

Von Offset bis Offset + Streaming Size. Aber ja, dann solltest du die Datei erhalten. Binäre IPL Dateien beginnen immer mit dem String "bnry" (siehe https://www.gtamodding.com/wiki/Item_Placement#Header) - ob deine Ausgabe korrekt ist, kannst du also so leicht überprüfen.
Eine Frage wäre noch, ob Offset vom Anfang des IMG Archivs ausgeht oder nach dem Header ab dem ersten Eintrag. Im Zweifel einfach durch Ausprobieren überprüfen.

Es kann ebenso sein, dass ein Teil der Bäume zur Laufzeit generiert werden (insbesondere, wenn sie regelmäßig als Straßendeko auftreten). Das ist so z.B. auch bei Straßenlaternen entlang der Straßen der Fall.

Relativ leicht überprüfen könnst du das, indem du die Map mit MEd öffnest und schaust, ob die Bäume dort existieren. Damit würdest du auch gleich sehen, zu welcher IPL der jeweilige Baum gehört.

klar, dies das

Ob es sich für MTA lohnt, musst du selbst entscheiden: Obwohl die Spielerzahlen in der Tendenz noch steigen, ist der relative Anteil der deutschsprachigen Spieler deutlich zurückgegangen. Als ich das letzte Mal vor ein paar Tagen geguckt habe, lag der Anteil der deutsprachigen Spieler bei 0,9% - im Vergleich dazu waren es im 1. Quartal 2017 noch ca. 1,4%.
Ich persönlich würde es nicht davon abhängig machen wie viele Leute es noch spielen, sondern wie viel Spaß ich damit habe.

Ansonsten allgemein Lua zu lernen lohnt sich auf jeden Fall. Lua als Sprache gewinnt zum Einbetten in andere Programme weiterhin an Beliebtheit, ist als Einstieg leicht zu erlernen, beinhaltet aber alle wichtigen Konzepte einer Programmiersprache, sodass darauf aufbauend leicht weitere Sprachen erlernt werden können.

Zitat von Bonus

Wird nur Lua möglich sein oder kommen auch andere Sprachen rein (wie z.B. C++, JS, C#, Java o.ä.)?

Zunächst nur Lua. Das hat zum einen den Hintergrund, dass die entsprechende Framework-Komponente (nanos::scripting) zunächst Unterstützung für Lua bekommt und zum anderen, dass wir Lua für einfacher als Javascript halten. Da das Framework aber auch Unterstützung für Javascript erhalten wird, ist es durchaus möglich, dass wir Javascript als Zweitsprache einführen (auch wenn die damit verbundene Fragmentierung vorher zu diskutieren ist).

Sicher kann ich aber sagen, dass es für das Scripting keine Unterstützung für C++, C# und Java geben wird. Aus Sicherheitsgründen könnten die genannten Sprachen sowieso nur auf dem Server angeboten werden - unterschiedliche Sprachen auf Server und Client wollen wir jedoch vermeiden. Eine nennenswerte Alternative wäre hier wohl Typescript, falls es um die statische Typisierung geht.

Zitat von Krox

Auf welchen Plattformen wird denn das Projekt veröffentlicht? Wird es auch die Möglichkeit geben per Crossplay über Konsolen Server´n beizutreten?

Zunächst erstmal nur für Windows. Langfristig ist eine Erweiterung um Mac und ggf. auch Linux geplant. Konsolen stehen derzeit nicht auf der Liste. Der Hintergrund ist gar nicht unbedingt, dass es technisch zu aufwendig wäre, sondern mehr, dass die Bedienung mit Controller statt Maus+Tastatur zu unterschiedlich ist. Man stelle sich dafür einen Server (aka "Welt) vor, bei dem die GUIs layoutmäßig so wie bei MTA sind - das lässt sich schlicht und weg nicht komfortabel mit einem Controller bedienen. Daher macht Crossplay keinen Sinn. Falls es irgendwann kommt (wovon wir derzeit nicht ausgehen), wird es technisch ein eigenes Spiel sein.

Zitat von Krox

Was wird denn alles vorgegeben? Soweit ich sehe gerade nur die Map, aber wie sieht es denn z.B mit Fahrzeugen oder Charakteren aus?

"Vorgebenem" soll prinzipiell so gut wie gar nichts. Das passendere Wort wäre "angeboten". Das heißt: Es gibt eine Sammlung von Assets und Maps in Assetpaketen, die genutzt werden können - oder auch nicht.
Das trifft ebenso auf Fahrzeuge und Charaktere zu. Es ist jedoch nicht davon auszugehen, das alles das im ersten Release schon verfügbar ist.

Zitat von Krox

Werden denn Fahrzeuge von euch Konfiguriert oder wird es dazu ein Tool von euch geben, womit man das Fahrzeug vom Handling etc.. beliebig anpassen kann?

Aktuell ist unser Ziel erst einmal, alle Handlingparameter, die Unreal Engine für Fahrzeuge bereitstellt, per Script erreichbar zu machen. Welche das genau sind, kannst du herausfinden, indem du in UE4 ein Projekt aus der Vorlage "Vehicle Advanced" erstellst.

Zitat von Krox

Wie sieht es denn Grafisch aus, werden wir die Möglichkeit haben eigene Einstellungen zu treffen, oder wird diese von euch fest vorgegeben?

Einstellungen im Sinne von Grafikqualität werden wie bei jedem anderen Spiel auch in globalen Einstellungen getroffen. Was Benutzerdefinierbarkeit im Sinne von zusätzlichen Shadern o.ä. betrifft, kann ich derzeit noch keine verlässliche Auskunft geben. Mit Einschränkungen vermutlich, ja.

Zitat von Krox

Wie wird denn die Benutzeroberfläche genau gestaltet?

Zunächst haben wir vor CEF (Chromium Embedded Framework) als Hauptsystem für die Benutzeroberfläche zu benutzen. Die konkrete Implementierung wird allerdings etwas einfacher zu benutzen sein als es bei MTA aktuell der Fall ist.

Zitat von Krox

Ist es moddern einfach möglich Modelle zu Konvertieren und diese dann beliebig in die Szene zu integrieren?
Und wie sieht es denn mit einem LOD System, Kollision etc.. aus?

Wenn die Modelle im passenden Format vorliegen, ist das das Ziel.

Zitat von Krox

Wird das ganze wie in der normalen Unreal Engine ablaufen, oder wird es dafür ein weiteres Tool von euch geben, dass das ganze nochmal vereinfacht?

Das ist zurzeit noch nicht voll absehbar. Im Wesentlichen ist das Problem, dass wir Unreal Assets (*.umap, *.uasset) nicht direkt laden können, weil die potenziell darin enthaltenen Blueprints so mächtig sind, dass sie zum Sicherheitsproblem werden können. Wenn wir es schaffen die Dateien sicher zu laden, wird es möglich sein den UE Editor als Haupttool zu benutzen. Wenn nicht, werden wir ein weiteres Tool mit einem ggf. eigenen Dateiformat bereitstellen müssen.

Zitat von https://forum.mtasa.com/topic/101334-bluescreen-when-i-want-join-to-server/?do=findComment&comment=887932

1) Please enable Small Memory dump by following these instructions:
http://mywindowshub.com/how-to-configu…-files-on-bsod/
*Important: Change 'Automatic Memory Dump' to 'Small Memory dump' in the final step*

2) Start MTA and cause a BSOD

3) Find C:\Windows\MEMORY.DMP and upload to https://upload.mtasa.com/ and give link here.

Mit Boardmitteln ist das derzeit nicht ohne Weiteres möglich. Du kannst aber das Modell (also die zugehörige DFF-Datei) mit einem IMG Editor wie Spark aus der gta3.img extrahieren, anschließend mit einem Modellierungstool wie 3ds Max entsprechend bearbeiten und dann per engineLoadDFF/engineReplaceModel wieder in MTA importieren.

Zitat von Flatliner_

Nein. Einfach nein.

Tolle Antwort

Möglicherweise ist mta-server bei dir ein Link, der ab einem bestimmten Punkt wieder auf sich selbst verweist und damit zu einer Endlosschleife führt.

Um das zu prüfen, führe z.B. mal tree --noreport -fp -L2 . aus (ggf. tree noch per apt-get install tree installieren) und schicke uns die Ausgabe.

Dann lade mal bitte MTADiag herunter, entpacke und start es. Nachdem es durchgelaufen ist, hast du einen Link in der Zwischenablage, den du dann bitte hier postest.

Deine Audiodateien sind kaputt. Eine Neuinstallation von GTA von der Original-CD/Steam/o.ä. sollte den Fehler beheben.

Wenn du außerdem willst, dass dir beim nächsten Mal noch geholfen wird, solltest du in der Zukunft einen anderen Betreff wählen.

Zitat von Black

dachte Android basiert auf einem linux kernel...

Das stimmt zwar, Problem ist aber weniger das Betriebssystem (irgendwie zwar schon, weil Android reativ stark isoliert ist, aber das würde man wahrscheinlich irgendwie - notfalls mit Root - hinbekomen), sondern eher die Tatsache, dass fast alle Handys die ARM-Architektur nutzen, auf der aber nicht ohne weiteres Programme für die x86-Architektur (für die auch GTA:SA für den PC ist) gestartet werden können. Nötig wäre dazu ein Emulator, der aber nicht in der Qualität verfügbar ist, die solche Programme flüssig ausführen kann.
Soweit ich weiß basierte der Ansatz von BlechBoX darauf, dass er ein Handy wie das Asus ZenFone mit Intel Atom Prozessor hatte, welcher die x86-Architektur realisiert, und somit Wine nutzen konnte.

Kurz:
Um dich zu zitieren: Die Idee ist eher verrückt als realistisch lang.

Lang:
Zunächst muss man sagen, dass die Android-Version von SA eine andere ist als für den PC, die nicht nur neu kompiliert wurde, sondern auch leicht andere Features hat und für die ARM-Architektur kompiliert ist.
Demzufolge müsste man zum einen den ganzen lowlevel-Teil, der die Anbindung an SA darstellt, neu schreiben und überlegen, ob bei Sachen wie der Steuerung größeres geändert werden muss.
Weiterhin kommt erschwerend dazu, dass Android im Vergleich zu Windows Apps wesentlich stärker von einander isoliert, sodass zum einen das Debugging (was für den lowlevel-Teil essenziell ist) und zum anderen den Weg wie MTA mit GTA interagiert deutlich komplexer macht.

Dementsprechend: Es ist sicherlich nicht unmöglich sowas umzusetzen, aber den Aufwand ist es, meiner Meinung nach, im Vergleich zum wirklichen Nutzen nicht wert (so gut wie kein Server wäre aktuell außerdem von der Steuerung her auf dem Handy spielbar).

Zitat von Noneatme

Mich würde es interessieren, ob sich das auch mit PhpStorm oder andere IDE's verknüpfen lässt, sodass man ein eigenen File Watcher definieren kann der automatisch die Dateien übersetzt.

Es gibt für eine Reihe von Editoren/IDEs Plugins, darunter auch eins für IntelliJ aus dem Jetbrains-Universum: https://haxe.org/documentation/…s-and-ides.html
Ich kenne mich nicht wirklich mit IntelliJ/PhpStorm aus, aber wenn die File Watcher von der IDE als solches bereitgestellt werden, gehe ich davon aus, dass es möglich ist.

Ansonsten entwickelt jemand aus der internationalen Community gerade ein Tool, um den ganzen Kram (einschließlich Export einer passenden meta.xml) zu vereinfachen: https://github.com/pawel-miczka/luxe

Zitat von sbx320

Wie gut lässt sich das eigentlich debuggen? Wenn ich im Lua Code einen Fehler habe, weiß ich ja direkt in welcher Zeile es steckt. Jetzt aber zurück auf die Haxe Datei zu kommen um den Fehler zu beheben stelle ich mir etwas Umständlich vor.

Aktuell gibt es in Haxe eine trace-Funktion, die in den Code eingebettete Metadaten à la Reflection nutzt, um einen Stacktrace mit korrekten Haxe-Dateinamen und Zeilennummern auszugeben.
Ich gebe aber zu, dass das nach wie vor noch etwas kompliziert ist. Deswegen habe ich auf GitHub ein Issue erstellt und darum gebeten, die Sourcemaps, die bereits für Javascript und PHP7 generiert werden können, auch für Lua zu generieren. Die Resonanz dazu war recht positiv, weswegen ich davon ausgehe, dass das Feature bald kommt.
Anschließend denke ich, dass man on(Client)DebugMessage nutzen kann, um die Fehlermeldungen abzufangen, anhand der Sourcemaps umzuschreiben und wieder auszugeben.

Zitat von Hadrev

aber kann man durch Haxe eventuell Bug's/Probleme ausschließen, die man vielleicht Standardmäßig bei MTA hat bzw. manche Dinge sind in MTA ja nicht möglich, aber könnte man dadurch gewissen "Hintertüren" öffnen um bestimmte Probleme zu umgehen oder fungiert Haxe da tatsächlich, so wie ich es verstanden habe, nur als Vereinfachung?

Es können viele Tippfehler ausgeschlossen werden (z.B. das Vertippen bei einem Variablennamen). Auch wird die Entwicklung durch eine gut-funktionierende Autovervollständigung schneller und einfacher.
Mächtiger im Sinne von MTA-Features ist Haxe nicht, da es schlussendlich auch "nur" zu Lua-Code wird und keine Änderungen am MTA-Server an sich einschließt.

Ansonsten generall als Update: Mit der Hilfe von 2 Leuten aus dem offiziellen Forum, sind wir nun bald soweit alle Typdeklarationen erstellt zu haben, sodass bald ein funktionsfähiges Release erwartet werden kann.

Ich habe dazu eine etwas gespaltene Meinung. Zum einen gibt es eine Chance, dass es die Qualität verbessert - das ist gut, zum anderen muss ich aber ehrlicherweise auch sagen: Seriöse Projekte brauchen keine solche Vorlagen (und würden sie ohnehin nicht benutzen) und bei unseriösen Projekten bin ich manchmal froh, dass ich die Vorstellungen direkt erkenne und mir die Zeit sparen kann sie durchzulesen.

Ich glaube, um vernünftige Reflexionen/Schatten zu bekommen, reicht eine naive Implementierung von dxRenderScene nicht, da dann die Szene mit allen Details (inkl. Texturen, eigener Belichtung etc.), die gar nicht nötig sind, pro Licht berechnet werden würde, was den Client bei mehreren Lichtern dann doch ziemlich in die Knie zwingen könnte.

Dementsprechend bräuchte man eigentlich zusätzlich noch Optionen für dxRenderScene, um den Detailgrad zu steuern, womit der Aufwand für solch eine Funktion stark ansteigt. Ich gebe aber zu, dass dxRenderScene in der einfachen Variante ein guter Anfang wäre.