Beiträge von Ssnake

Vermutung: A fuhr an der Spitze der Kolonne, wurde abgeschossen. Dadurch wurde der mittlere Panzer zu A (vorher A1?) instant-befördert, d.h. der Anführer von Alfa, welcher Panzer des Zuges es auch immer sein mag, wird immer als A bezeichnet.

Es mag auch sein, daß es eine Besonderheit speziell der dort verwendeten Callsign-Templates ist.

Da ein menschlicher Spieler nicht von Steel Beasts gezwungen wird, ständig bei einem einzigen Fahrzeug oder Zug zu bleiben, muß das grafische Benutzerinterface sicherstellen, daß ein Spieler, der längere Zeit nicht bei dem Zug geblieben ist, trotzdem schnell die Lage erfassen kann. Dazu muß das Führungsfahrzeug identifizierbar sein, ohne daß man erst eine Verlustliste konsultiert. Daß in der gelebten Praxis die Panzer im laufenden Gefecht nicht umbenannt werden mag durchaus sein; hier aber ist es aufgrund der "Spielregeln" (die Teleport erlauben und womöglich nur einen Zugführer für drei oder mehr Züge) eine erforderliche Künstlichkeit, so wie andere Ausbildungsmittel auch ihre Besonderheiten haben.

Drölvenfuffzig mal wäre schon angemessen.

Es ist natürlich richtig, daß die Delta-Karte nicht als neues Basispaket gespeichert werden müßte. Aber wenn man es tut, dann sollten auch alle Änderungen übernommen werden. Wenn das nicht funktioniert, sollte Steel Beasts die Option der Speicherung als neue Basiskarte gar nicht erst anbieten.

LoneWolf schrieb:

Es gibt aber durchaus ein paar Probleme für die ich noch keine Lösung gefunden habe. (Über-/Unterführungen in Delta-Karten vorhanden-dann gespeichert als neue Basis-Karte und alles ist wieder weg!)

Hast Du noch so eine Kombination aus Basis- und Delta-Paket, bei dessen Umwandlung solche Details verlorengehen? Kannst Du sie irgendwohin hochladen bzw. wenn das Basispaket Teil der Standardinstallation ist nur die Delta-Karte, so daß wir das untersuchen können?

Solche Fehler zu finden und sie zu beseitigen ist enorm wichtig. Wenn da etwas nicht richtig funktioniert, will ich das genau wissen.

Abraxas schrieb:

2. Häusergruppen der Ortschaft SIFFIG:

Ich hoffe, es gefällt Euch

Ich weiß nicht... wirkt mir nicht schmutzig genug.

Entweder hast Du eine veraltete Version der Karte (was nicht weitrer überraschend wäre, denn wir haben ja keine echte Versionskontrolle in den Kartendateien), oder Du müßtest die Kartendatei aus dem Szenario, das Du konvertieren willst, zunächst extrahieren und dann individuall konvertieren. Hier empfiehlt es sich, bei "Konvertierung von TER" die bestehende Fulda-Karte als Basiskarte auszuwählen. Dann wird der Speicherbedarf geringer.

Prima, dann ist ja zumindest diese Frage geklärt.

Ich denke auch, daß irgendwann die Zahl der neu hochzuladenden Geländepakete zurückgehen wird, sobald erst ein guter Bestand aufgebaut wurde.

Kommentar vom Programmierer:

Zitat

Hat er den package download service neu gestartet (entweder explizit oder via windows reboot). damit der die neue konfiguration ueberhaupt mitbekommt? Der service hat ja ein eigenes logfile ('serviceLog.txt', einen link zum verzeichnis gibt's im start menue ordner), das waere interessant zu sehen

Zumindest aktuell können wir das Hochladen per Deployment Manager nur für ftp garantieren. http (und speziell https) ist als Protokoll sehr viel schwieriger zu implementieren (da deutlich komplexer), speziell die Wiederaufnahme unterbrochener Up- und Downloads. Natürlich kannst Du die Map Packages mit dem Deployment Tool packen und dann von Hand auf einen http-Server hochladen. Nicht ganz so komfortabel, aber es sollte gehen.

Ein Tool mit grafischer Benutzeroberfläche ist in Entwicklung und wird vor Jahresende veröffentlicht werden.

Am Einfachsten ist natürlich die Einrichtung eines privaten ftp Servers.

Urgh... Sicher mit dem nächsten Patch wieder, sorry.

Das spiegelt definitiv nicht meine Idealvorstellung von Benutzerfreundlichkeit wieder. Soviel ist mal sicher.

Aber zumindest konnten wir erst einmal den unnötigen Kauf neuer Hardware verhindern.

Mit anderen Worten: Erstmal keine neue Hardware kaufen!

Ssnake schrieb:

- die neueste .mrf-Datei nach "mrf_old" umbenennen (oder ähnlich)

Dann Steel Beasts neu zu starten versuchen. Wenn's nicht hilft, die nächst-jüngste MRF-Datei umbenennen usw.

...bis Steel Beasts wieder startet, dann die vorher umbenannten MRF-Dateien zurückbenennen bis auf die zuletzt geänderte, die dann ja offenbar das Problemkind ist.

Bis der nächste Patch kommt, der das Problem beheben sollte.

Nee, da fallen mir noch andere Gründe ein.

Es kann sein, daß bei Dir ein bestimmter Suchprozeß ins Leere läuft, und das Timeout schlichtweg sehr lang ist. Ist mir vor zwei, drei Wochen auch passiert, der nächste Patch wird diese Suche nach etwa fünf Sekunden abbrechen. Es gibt weiterhin Fälle, in denen bei einem Geländepaket eine ungültige Kombination von Paketinhalten und Metadaten-Datei auftreten kann. Da die Fehlersuche sehr aufwendig ist, würde ich empfehlen, entwerde auf den nächsten Patch zu warten oder aber

- im Geländepaket-Ordner nach allen Dateien "metadata.mrf" suchen

- Suchergebinsliste nach Datum sortieren

- die neueste .mrf-Datei nach "mrf_old" umbenennen (oder ähnlich)

Dann Steel Beasts neu zu starten versuchen. Wenn's nicht hilft, die nächst-jüngste MRF-Datei umbenennen usw.

Danach sollte noch sichergestellt werden, daß der SB Pro Map Package Download Manager erfolgreich starten und sich verbinden kann. Ist das nicht der Fall (d.h. der "Connect"-Knopf ist nicht ausgegraut aber das Tray-Symbol ist kein vereinfachtes eSim-Logo (Mk IV-Panzersilhouette) auf grünem Hintergrund mit Häkchen sondern rot mit X drin), müssen wir noch weitere Maßnahmen durchführen.

Gut, wenn Du weißt, daß es an anderer Stelle Probleme macht, dann ist Deine Abwägung vollkommen vernünftig.

R-TEAM schrieb:

Würde da gerne einwerfen das es vlt. ne überlegung wert ist sich nen commerzielles game-engine anzuschauen

Fällt mir schwer, darauf nicht mit Sarkasmus zu antworten. Wenn's so einfach wär', hätten wir's schon längst gemacht. Lange Zeit gab's ja keine Engine, die konnte, was wir brauchen. Mittlerweile gibt es sie, aber eine über 20 Jahre gereifte SImulation kann man nicht eben mal umstricken, während zugleich ein Dutzend Armeen die Software im laufenden Trainingsbetrieb einsetzen und laufend Updates erwarten.

Egal, weiter im Text...:

Zitat

zu "...nur genau 150% macht ihn wohl unsichtbar..."

ist natürlich blöd - da das genau die von Windows "empfohlene" skalierung ist .... werd etz net, mein ansonsten gut funktionierenden und auch gut aussehenden desktop wegen ein prg/game ummodeln

149% kann man auch einstellen und es funktioniert bei mir prima. Natürlich kann ich nicht garantieren, daß es läuft, aber ich denke, bevor man den Vorschlag kritisiert, sollte man ihn vielleicht einfach mal ausprobieren. Vielleicht hilft's ja.

Die Anpassung an 4K ist in der Tat nicht der Brüller, weil es sie nicht gibt. Wir werden das GUI überarbeiten - dazu hab' ich extra Leute eingestellt - aber bis es soweit ist, wird noch eine gute Weile ins Land gehen.

1. , weil es viele Dialoge und Menüs gibt, die alle neu gemacht werden müssen.
2. , weil die Benutzeroberfläche definitionsgemäßt mit nahezu allem im Code verknüpft ist.
3. , weil wir nicht einfach den alten Mist in neuen Mist umwandeln wollen, sondern auch einige Dinge ganz grundlegend "neu denken" wollen. Kontextmenüs beispielsweise sind gut, wenn es weniger als ein Dutzend, besser noch nur eine Handvoll Optionen gibt. Demgegenüber haben einzelne Kontextmenüs schon mehr als 60 Einträge (Neue Einheit ... Schützenpanzer), das geht also gar nicht.

Bis dahin wird man sich entscheiden müssen, ob man 4K trotzdem nutzen will oder doch lieber 1920x1080. Bei 4K sollte der Mauszeiger wohl dennoch im Vollbild zu sehen sein, wenn man die Textskalierung 149 bzw. 124% anwählt, nur genau 150% macht ihn wohl unsichtbar; zumindest war das in wenigstens einem anderen Fall so.

Was den Fenstermodus angeht, gibt's den Parameter --fullscreenwindow, mit dem man Steel Beasts starten kann.

Im angehängten Bild ist allerdings das Anführungszeichen falsch gesetzt; es müßte hinter "...exe" stehen und darf NICHT den Kommandozeilenparameter einschließen!

Mit der PackageDeployment.exe muß das Paket nun erst einmal für den Steel Beasts Map Package Download Dienst in eine verwertbare Form umverpackt werden. Die Deployment.ese hat drei Kommandos, soweit ich das richtig verstehe. Eine davon dient dem Einpacken. Ich gflaube, am Ende kommt eine ZIP-Datei dabei heraus (oder etwas ähnliches), und die muß einfach auf den Map Server hochgeladen werden.

Danach sollte der Steel Beasts Pro Map Package Download Manager bei Kennnis der Map UID die ZIP-Datei auf dem Mapserver identifizieren und diese dann herunterladen.

Delta Maps und Basiskarten müssen separate eingepackt werden. Allerdings werden bei der Anforderung von Delta-Karten auch gleich die Basiskarten automatisch mit heruntergeladen, wenn sie nicht schon lokal vorhanden sind.

Pffff... keine Ahnung. Wenn's in der Anleitung nicht klar beschrieben ist, bitte mal die in Frage kommende Passage zitieren, dann leite ich das an den Programmierer weiter für eine Stellungnahme.

Ich sollte wohl darauf hinweisen, daß die SB Map Tools V.19 eine Anleitung enthalten, wie man einen eigenen Mapserver aufbauen kann.

C:\Programme\eSim Games\SB Map Tools enthält eine Datei "readme.html" ... das ist jetzt vielleicht besser versteckt, als es sein sollte. Aber da steht drin, wie ihr einen eigenen "911"-Map Server aufbauen könnt, so daß neu erstellte Karten direkt von Euch dorthin hochgeladen werden können. Dann müssen Eure Mitglieder noch die Server-Adresse in einer Konfigurationsdatei eintragen; das geht im Prinzip schon jetzt, wenn man eine XML-Datei direkt editiert, aber der nächste PE Patch wird wohl die Möglichkeit bieten, das direkt in Steel Beasts einzutragen anstatt sich erst XML-Kenntnisse aneignen zu müssen.