Beiträge von Ssnake

    Na wir hatten ja in Verbindung mit der v3.019BETA die Schwierigkeit, dass die 64-bit Server Exe für Win Server OS mit Win7 Core (2008R2 64-bit) ausgelegt war


    Ich meine, das traf nur auf 3.017 Beta zu.
    Wie auch immer, wir haben die Minimalanforderungen abgesenkt, so daß Windows 2008 ("R1") uneingeschränkt kompatibel ist.


    Zitat

    In Deiner obigen Liste steht bei unterstützten 64-bit Server-OS einfach "2008".


    Strenggenommen gibt's kein "R1" sondern nur Server 2008 - oder Server 2008 R2. Aber egal, R2 wird NICHT zwingend vorausgesetzt.

    Rein interessenshalber... Wird es für diese neue Version eine Vista Core Server-Exe übergangsweise geben, oder beschränkt sich das auf eine Win7 Core Exe?


    Hmmm. Ich glaube, die Antwort lautet "Keine Sorge". Allerdings bin ich mirt nicht sicher, was Du mit "Vista Core Server" meinst; mir ist dieses Produkt (zumindest unter diesem Namen) nicht bekannt. Aber vielleicht helfen Dir die weiteren Ausführungen weiter...:




    Die von uns unterstützen Minimalversionen von Windows sind:


    32bit
    - Desktop: XP mit mind. SP2
    - Server: 2003 mit mind. SP1


    64bit:
    - Desktop: Vista
    - Server: 2008



    Einen Abhängigkeit von "Windows Sever" zu "SB Server" gibt es nicht; die "SB Server"-Versionen laufen ebenso auf Desktop Windows.


    Die "normalen" SB-Editionen benötigen einen vollwertige Hardware-Direct3D-Implementierung der Grafikkarte, inklusive Pixel-Shader Version 3.
    Die "Server" SB-Editionen benötigen ebenfalls eine vollwertige Hardware-Direct3D-Implementierung der Grafikkarte, allerdings kann diese uralt oder minimal sein, es wird keine spezielle Version von Pixel-Shadern vorausgesetzt.


    Soweit, so einfach.



    Jetzt wird's interessant:


    Bei den Windows Server-Versionen gibt es (für alle Varianten) eine sog. "Web Edition", welche bei Hostern auf virtuellen Maschinen bereitgestellt wird. Ob diese "Web Editions" eine vollwertige Hardware-Direct3D-Implementierung der Grafikkarte besitzen, hängt ausschließlich davon ab, was der Hoster in der virtuellen Maschine eingestellt hat. Manche fahren moderne Systeme, in denen Hardware-Direct3D bereitgestellt wird, aber nicht alle.


    Mit einer Software-Direct3D-Implementierung fallen ALLE unsere Steel Beasts-Varianten beim Starten auf die Nase, da wir im Code nicht für jeden einzelnen Aufruf an Direct3D prüfen können/wollen, ob dieser nur in Hardware, oder auch in Software existiert. Ist also ein "Selbstschutz" unsererseits. Ich denke aber, daß Ihr das schon wißt, insoweit ist das also nichts Neues.


    Damit schließt sich nun der Kreis ... ob SB "normal" oder SB "Server" auf verschiedenen Windows-Server-Varianten läuft oder nicht, hat nichts mit der benutzen Windows Variante zu tun, sondern ausschließlich damit, ob auf der Maschine Hardware-Direct3D-Unterstützung existiert oder nicht. Das ist bei Euch ja wohl der Fall (sonst würde ja auch der egegnwärtige PE Server nicht laufen), insoweit gilt also Entwarnung.


    Schlußbemerkung: ich habe zwar nur von den "Web Editions" gesprochen, als ich die Abhängigkeit zu Hardware-Direct3D erklärt habe. Prinzipiell gilt das auch für die "vollwertigen" Versionen von Windows Server. Jedoch tritt das Problem typischerweise bei den "Web Editions" auf, da die Hoster dort extrem auf die laufenden Kosten achten.

    Ich habe einen Entwurf zu den Release Notes, aber das Dokument kann erst abgeschlossen werden, sobald die letzten Änderungen feststehen. Ich möchte vermeiden, mehrere Versionen des Dokuments zirkulieren zu lassen, daher veröffentliche ich keine Vorabversionen. Zusammenfassend kann ich aber auflisten:


    • Natürlich enthält 3.02x alle Änderungen, wie sie im Verlauf des öffentlichen Betatests vorgenommen wurden (sowohl in der X86- wie X64-Version.
    • Enthalten ist auch der Umstieg auf CodeMeter Laufzeitumgebung 5.20d (damit wird der "Chrome-Bug" bei der Lizenzaktivierung beseitigt (tatsächlich handelt es sich um einen Bug in der CM-Runtime, der durch Chrome aufgedeckt wurde)).
    • Alle Schätzungen der Durchschlagsleistung von großkalibrigen APFSDS-Munitionstypen wurden überprüft; dabei konnten zum Teil deutliche Diskrepanzen beseitigt werden, die sich z.T. auf bessere Datengrundlage zurückführen lassen, z.T aber auch auf unterschiedliche Interpretation der mathematischen Verfahren, die nun also vereinheitlicht wurden.
      Um mehr als 5% mußte die Durchschlagsleistung reduziert werden bei 120mm DM53 (und vier weiteren com Kaliber 120mm) sowie bei zahlreichen russischen Geschossen, sowohl 115mm als auch 125mm.
      Zu den "Gewinnern" der Überprüfung gehören einige 100mm-Geschosse, relativ viele vom Kaliber 105mm, sowie v.a. die britischen 120mm-Projektile. Die Kritik der britischen Nutzer war also berechtigt und läßt sich auf einen Methodenfehler zurückführen. Dafür trage ich die volle Verantwortung.
    • Ein paar Verbesserungen für die Arbeit mit dem Karteneditor
    • Ein paar Verbesserungen für die Arbeit mit dem Szenarioeditor
    • Verbesserungen im Feuerkampf-Verhalten von aufgesessenen PzGren
    • Detailverbesserungen bei
      ASCOD Pizarro
      BRDM-2
      BTR-80
      Centauro
      Challenger 2
      Zivilpersonen
      CV90
      CV9030
      CV9035
      Infanterie
      PARS-Trupps
      PzF-Schützen
      PARS Javelin
      Leo 1A5
      Leo 2A4
      Leo 2A5
      Leo 2E
      M1
      M1A2 SEP
      M2/M3
      M113-G4
      T-62
      T-72
      UAV
      Wisent


      Zivilfahrzeuge
      Helikopter
      Technicals

    • Sechs Seiten mit Bugfixes

    Das Datum hat dir sowieso niemand geglaubt.;)


    Von erfahrenen Kunden habe ich das auch nicht anders erwartet. ;)


    Wir stehen halt immer wieder vor der Frage, ob "dieser eine nervige Bug" noch beseitigt werden soll. Wenn dann bei dessen Beseitgung was schiefgeht, ist das angepeilte Datum nicht mehr zu halten. Naja, ich denke, die Bugbeseitigung ist am Ende doch wichtiger als die Einhaltung eines willkürlich gesetzten Termins. Wenn die Programmierer unbedingt an einem Adventswochenende durcharbeiten wollen, kann ich sie zu ihrem Glück nicht zwingen.

    Ich habe noch Steel Beasts 3.011, gibt es schon eine neuere Version, damit ich mich updaten kann?


    Du kommst gerade rechtzeitig: Wir wollen es dieses Wochendende veröffentlichen. 3.02x wird nicht als Update angeboten werden, sondern nur als "full installer".

    Es IST ja auch gewollt - nur nicht, daß man das "blind" entfernen kann. Eigentlich sollte sich der Status überhaupt nicht ändern lassen.


    DASS die Teile alle blind sind, hat man, wie bereits erwähnt, denjenigen zu verdanken, die diese Einheiten als Aufklärer eingesetzt haben, weil sie durch die Genfer Konvention geschützt sind. Das ist natürlich ein Mißbrauch, der auch die GK verletzt, also mußten wir irgendwie reagieren.

    Kannst Du in den Treiber-Einstellungen den Analogstick für den Daumen zur primären Achse für Steuerbewegungen machen, oder das womöglich sogar zur Laufzeit umschalten, je nachdem ob Du auf dem Richtschützen- oder Kommandantenplatz bist?


    Das könnte vielleicht die Lösung sein.

    Ein Großteil des Pionierwesens hat ein dynamisches Gelände mit (sehr viel) höherer Auflösung zur Voraussetzung. Daran arbeiten wir seit über einem Jahr. Die höhere Auflösung benötigt viel mehr Speicherplatz, also müssen wir einerseits auf 64 Bit umstellen (das ist quasi abgeschlossen), andererseits können wir auch dann nicht mehr den Ansatz fahren, die Geländedaten komplett im Speicher zu halten. Hier warten die nächsten großen Herausforderungen (wie finden computergesteuerte Kräfte ihren Weg im Gelände, wenn das Gelände gar nicht im Speicher gehalten wird? Gar nicht, natürlich. Das Gelände muß also in unterschiedlichen Detailstufen vorgehalten werden).


    Sobald diese Grundsatzfragen beantwortet sind, geht's ans Eingemachte: Die bestehende Software, die vom Design her an jeder Stelle implizit oder explizit annimmt, daß die notwendigen Geländedaten "vorhanden" sind, muß so umgeschrieben werden, daß alles weiterhin funktioniert, obwohl sich die Verhandlungsgrundlage radikal geändert hat.


    Sobald das alles abgeschlossen ist, funktioniert SB Pro so, wie schon jetzt auch. Es ist also scheinbar ein Riesenaufriß ohne sichtbares Ergebnis. Aber er schafft eben die Voraussetzungen für die nächsten Schritte:
    Wenn das Gelände dynamisch veränderbar werden soll, müssen auch die Wegfindung und die Sichtlinienberechnungen dynamisch angepaßt werden. Dynamische Geländeveränderung ist entscheidend, um bestimmte Pioniertätigkeiten zur Laufzeit zu ermöglichen (z.B. Stellung schieben, PzSperrgraben, ...) - das werden wir dann Schritt um Schritt einführen. Es ist aber insgesamt eine ziemlich komplexe Aufgabe, wie man sich vielleicht vorstellen kann - als ob man einen gigantischen Mikadohaufen hätte, bei dem die Stäbe allesamt ersetzt statt einfach nur weggenommen werden müssen.

    Trotz wiederholter Versuche ist es mir noch nicht gelungen den LFK Spike LR so zu nutzen, dass ich einen Zielwechsel durchführen kann, bzw ein Nichtfahrzeugziel bekämpfen kann. Die /den Javelin bekomme ich ebenfalls nicht gehandelt, da scheitert es bereits am Auslösen!


    Zunächst muß das Ziel aufgeschaltet werden (simuliert durch Benutzen des Laser-Knopfs). Sobald das Target Lock da ist kann man ggf. noch das Flugprofil festlegen (Hi/Lo), die Leertaste feuert dann die Rakete ab.


    Zielwechsel mit Spike ist anspruchsvoll; es bedarf schneller Reaktion, funktioniert in SB auch nur bei stehenden Zielen, und man braucht viel Übung. Der Freiflugmodus ist nahezu unmöglich zu bedienen, aber das ist beim echten System wohl ganz ähnlich.

    Dann geb ich jetzt auch mal meinen Senf dazu^^


    Hab mir gestern die V.3019 runterladen.
    Entpackt und so. Verschieben bringt ja nichts, wenn ich keine Lizenz habe - gelle?


    Also versucht die Lizenz zu bekommen - aber Fehlanzeige


    Das Lizenzkontingent für die Betaversion ist erschöpft. In Einzelfällen bin ich durchaus bereit, noch ein Ticket auszustellen (eMail, bitte). Da wir für jede Lizenz, die wir ausstellen, einen gewissen Betrag bezahlen müssen, und die Betalizenzen kostenlos waren, haben wir uns eine Obergrenze gesetzt, was uns der Spaß kosten darf.

    Entscheidend wäre, die Log-Datei sowohl vom Host also auch von denjenigen Clients zu bekommen, bei denen das Problem aufgetreten ist; idealerweise mit einem Hinweis zum ungefähren Zeitpunkt, zu dem es erstmalig aufgetreten ist sowie dem Callsign der betroffenen EInheiten. Die Logdateien existieren wahrscheinlich noch; immerhin werden die jeweils letzten elf Stück aufbewahrt.

    Schwer zu sagen.


    Schau Dir mal den Ordner C:\ProgramData\CodeMeter\CmAct an hinsichtlich Schreib- und Leseberechtigungen und der Dateien, die darin gespeichert sind. Wenn es da Einschränkungen gibt, könnte es erklären, warum die Lizenz nicht länger nutzbar ist.


    Oder vielleicht ist die Systemzeit geändert worden durch Vor- oder Zurückstellen? CodeMeter hat Sicherungen dagegen. Wenn also beispielsweise ein Virus damit herumspielt?
    CodeMeter wird sich NORMALERWEISE mit einem Zeitserver wieder synchronisieren ... wenn die Verbindung zum Zeitserver nicht unterbunden wird.


    Ansonsten mal CmDUST laufen lassen wenn die Lizenz funktioniert, und dann nochmal, wenn sie nicht mehr funktioniert. Vielleicht fördert der Vergleich zwischen den Ergebnissen eine Erkenntnis zutage. Ich denke, man sollte auch begleitend den Support @ CodeMeter.de in Anspruch nehmen.