Zudem hat der Kundendienst nichts mit den Servern oder etwaiger Zusammenlegung zu tun.

Was für eine Flagge stellst du auf???

Offenbar hast du noch nie von "CCU" (concurrent user) gehört. Die Zahl, die sich zur gleichen Zeit weltweit auf den Servern tummelt ist verschwindend gering im Vergleich zu den aktiven Spielern. Im Falle eines sehr stark gespielten WoWs tummeln sich zwischen 250 und 400.000 Spielern gleichzeitig weltweit auf den Servern - und das auch nur zur EU PrimeTime. Warum nur zur EU-PT? Weil EU die einzige "Zone" mit "nur" 3 Zeitzonen ist und demnach die PT in allen Ländern fast gleich ausfällt, wohingegen in US in 6 Zeitzonen eingeteilt ist und somit permanent eine solide Masse an Spielern online ist, anstatt einen Ausschlag wie in EU zu zeigen. Die CCU, welche die gleichzeitig eingeloggten Spieler in allen verfügbaren Zonen definiert, ist immer bedeutend geringer als die aktiven Spieler (=Möglichkeit am Spiel teilzunehmen) eines Spieles. Im Falle von SW:TOR wären das sicherlich maximal 100.000 Spieler weltweit.

Die 8 Stunden auf die Patchnotes wirst du ja wohl noch warten können. :/ Stört mich in der deutschen Version ebenfalls, aber naja, dafür gibt es schließlich die englische Version.

Der "DAoC Nachfolger", Dominus, wurde aufgrund mangelnder Liquidität aufgegeben. Sehr traurig.

Das Problem ist, dass diese Items sich meist von den Werten der "normalen" Items stark abheben und somit zu einem "must have" werden, da nach und nach immer mehr Spieler diese haben wollen. Anstatt der Item Spirale ein Ende zu setzen, kommen immer stärkere und stärkere Gegenstände heraus, sodass irgendwann die ursprünglichen Gegenstände 2x in das neue reinpassen würden (von den Stats). Damit ensteht eine immer größere Lücke zwischen Viel- und Gelegenheitsspielern. Anstatt dieses Problem wie andere, ältere, MMOGs zu lösen, nämlich hardcaps einzubauen bei den Werten, die man auch mit normalem Equip erreichen kann (*), oder einfach diese "ultra rare" Scheiße mit einem "ultra rare" skin versieht, aber mit fast identischen stats, erschließt sich mir nicht. Der Sinn dahinter, sich von anderen "Normalen" abzuheben existiert noch immer, nur entsteht dadurch keine balancing Lücke. * In einigen Spielen gibt es eine Klassen Questchain, ähnlich der von SW:TOR, welche am Ende einen Großteil an Ausrüstung gibt. Diese Ausrüstung ist von den Werten her sehr gut als Startequip für den Endcontent und hat kaum einen Unterschied von den Werten der "Raid Gegenstände" - Raid Gegenstände wären als kein "must have", da es nur ein Unterschied von ein paar Prozenten sind.

Ist doch egal. Die sinnvollste Methode wäre nach den Modifikationen zu suchen. Und da die betroffenen Spieler vermutlich garantiert diese aus- und woanders eingebaut haben, sind die definitiv in einem Log und können gefunden werden - und damit auch wohin sie gewandert sind usw. Wie bereits gesagt, wenn ein derartiger Vorfall nicht direkt per Datenbank-Skript geregelt wird, läuft was falsch. :/

Ich denke eher, dass dieser "1 Fall" der aktuell einzig zu 100% bestätigte Fall ist, bzw. der, den sie sich bisher genau angeschaut haben. Wenn man weiß wonach man suchen musst, ist der Rest für die Datenbank-"Heinis" kein Problem mehr. Ist doch vollkommen egal. Denkst du "verkauft und weg ist sie vom Server"? Dafür gibt es Logdateien und Skripte um diese zu durchsuchen... wird einfach nach der internen ID des Gegenstandes gesucht und gut ist.

Ich würde mal sagen da wollte jemand einen zerstörten Gegenstand wiederherstellen lassen... nur hat der Support den falschen Gegenstand "wiederhergestellt". Das lässt sich aus den Antworten von unseren 'gelben Engeln' rauslesen, da es ja offenbar der Fehler eines Support Mitarbeiters war, welcher unbeabsichtigt erfolgte.

Warum vordefiniert? Ich sehe den Sinn dahinter nicht. Für gewöhnlich ist die Desktop Auflösung auch dei InGame Auflösung und zugleich die Beste - das sollte für 99% der Fälle zutreffen. Für das 1%, zu denen du offenbar gehörst, kannst du simple die ausgelesene Auflösung in das Seitenverhältnis umwandeln - wenn 16:10, dann z.B. eine InputBox anzeigen lassen für den user. In derartigen Dingen sollte man möglichst alles automatisieren, da es zu viele Fehlerquellen für den Nutzer offen lässt. Niemand redet hier von einer langsamen While-Schleife... Das Problem ist, dass deine "kleinen Funktionen" statisch sind und auf globale Variablen zugreifen. Normal regelt man es bei derartigen Programmen mit einen gewissen, festen Ablauf alles über eine "Hauptfunktion", welche die nötigen lokalen Variablen hat und an die aufgerufenen Funktionen übergeben wird. Damit gewahrt man zum Einen den Überblick über den Ablauf und ist auf der sicheren Seite (im wahrste Sinne - geringeres Sicherheitsrisiko, denn globale können leicht überschrieben werden). Der Unterschied ist, wie gesagt, die Performance und bei komplexen Prüfungen die Fehleranfälligkeit. Bei Select-Case wird nur 1 Wert geprüft und es gibt auch - rein von der Kernfunktion - keine Folgeprüfung (außer man baut in dem perk noch weitere ein). Bei If-Else-ElseIf wird jede einzelne If Anweisung nacheinander geprüft. Je komplexer es wird, also je mehr Überprüfungen, desto genauer muss die Sache durchdacht werden (in welcher Reihenfolge man was überprüft um keine Prüfung zu überspringen, weil irgendwo TRUE rauskommt, es in dem TRUE-perk dann jedoch ein Wert fehlt, weil der nicht vorher überprüft wurde sonderst im If-Else-ElseIf perk erst nach dem vorherigen TRUE überprüft werden würde ; das wäre dann ein Design flaw mit unbekanntem Ergebnis (was sich auch nicht abfangen lässt ohne exzessiv viele exception handler einzubauen). Beispiel: Das 1. If-Beispiel ist mit Select identisch. Der Unterschied wird jedoch bereits deutlich. Bei If, wird erst geprüft ob $i = 1, dann $I = 2 usw. Bei Select wird einfach zu Case $i = 2 gesprungen. Ein "komplexes, fehlerhaftes" If-Beispiel zu skripten ist schwer... aber sowas passiert einfach bei Verschachtelung (ist mir selbst schon zu häufig passiert und am Ende kamen absurde Werte raus, weil die Prüf-Reihenfolge falsch war - Wert Z wurde vor X überprüft und sowas). Bei Select hast du ein derartiges nicht, da man alles direkt sieht und die Reihenfolge egal ist - abgesehen von einer Ausnahme: Überprüfung mehrere Variablen pro perk, da muss dann immer die Prüfung mit den meisten variablen nach oben. Nun, du erwartest gewisse Informationen. Sind diese nicht gegeben (auslesbar), musst du über einen einzigen exception handler filtern woran der Fehler liegt (Verbindung, Daten, Datei, Libaries, usw.) und entweder über eine definierte Prozedur reagieren (z.B. durch Überschreiben mit Standardwerten) oder aber eine sinnvolle Fehlermeldung ausgeben (die es bei heutigen Programmen auch viel zu selten gibt). Da man dafür nur eine einzelne Prüfung braucht, ist If Not IsArray($Array) then... die einfachste und schnellste Methode. Da man nur wissen muss, wenn es kein Array ist, braucht man kein Else - man beendet If einfach, sodass die Funktion weiter ausgeführt wird - entweder mit dem korrekten oder dem durch If-Then korrigierten Array. "Advanced" Beispiel Das würde dem Programm erlauben n-Versuche zu unternehmen das Array zu laden und zugleich dem Nutzer anbieten das Programm oder den Datenaufruf zu beenden. Was man dann macht bleibt einem natürlich selbst überlassen. Du könntest sogar anstatt $Type auch $iError übergeben (als 1. Parameter), sodass bei dem Array-Laden immer ein anderer Case-Perk verwendet wird (und somit andere Daten geladen werden). Das ginge dann schon in eine gewisse dynamische Richtung mit Nutzerinteraktion.

SW:TOR Auflösungen (verfügbar) = Windows Auflösungen (verfügbar) = vom Monitor unterstützte Auflösung Und da SW:TOR = Windows Auflösung ist - oder sein sollte - ist eine "Liste" Schwachsinn, zumal meine deutliche effektivere Methode ebenfalls eine manuelle Eingabe erlaubt, falls ein Fehler auftritt (InputBox übersehen?). Einfache Controls ohne Grafiken, Objekte oder dynamische Inhalte (Web Content) bzw. Zugriff/Implementierung von Bibliotheken verbrauchen keine Ressourcen (die paar KB nenn ich "keine"). Ohne die genannten Dinge wirst du nie mehr als 1mb verbrauchen, solange das GUI entsprechend konzipiert ist - 1 GUI Schleife für alle Fenster und nicht 1 pro GUI. AutoIt unterstützt beide Möglichkeiten, also ist eines so gut wie das andere. Ich nicht von While und OnEvent, sondern dass man - egal welchen GUI-Modus - keine 2-zeiligen Funktionen erstellt, so wie du unzählige hast. Nein, eben nicht. If-Else wird für einfache Abfragen verwendet, denn je komplexer, desto langsamer. Select-Case wird für komplexe Überprüfungen verwendet bei denen erwartet wird, dass unbekannte/unerwartete Werte auftreten können, da n-viele Bedingungen unterstützt werden und es einen integrierten Exception Handler hat. Es läuft zudem weit performanter als If-Else, da direkt zum Ziel gesprungen wird, anstatt X If-Prüfungen zu stellen (ähnliche Funktionsweise wie aus einer INI zu lesen). While wird nicht für Überprüfungen verwendet, sondern dient dazu Wert/Zustand X abzuwarten. Bei Select-Case kannst du nichts übersehen, denn sobald du Case Else verwendest hast du den Fehler bzw. den "vergessenen Wert" automatisch aufgefangen - nur mit dem Unterschied, dass das Programm in diesem Fall nicht abstürzt oder falsche Werte verursacht. Schon einmal was von boolean'schen Werten gehört? If prüft ohne Angabe eines Vergleichwertes auf einen booleanischen Wert mit gegebenen Logik Operator. Je nachdem was du dort für eine Funktion aufrufst und wie dessen Rückgabewert aussieht, funktioniert es natürlich nicht - AutoIt Hilfe ftw. Select-Case hingegen verlangt einen Vergleichsparameter, dennoch funktioniert boolean ebenfalls. ... ich hab es am Anfang auch so wie du gemacht, aber irgendwann wird bei dir ebenfalls der Groschen fallen; spätestens, wenn du anfängst umfangreichere Programme zu machen bei denen viel "under the hood" gearbeitet wird oder ein dynamischen GUI von Nöten ist. Hast du schon mal einen Updater programmiert? Also nicht so einen seltsamen wie SW:TOR hat, sondern einen Richtigen der sich auf jede Gegebenheit einstellt und den Client tatsächlich repariert anstatt nur festgelegte Dateien zu prüfen und den Rest zu ignorieren, wie es die meisten Patcher von Spielen heutzutage machen. Du glaubst gar nicht was das für Arbeit ist. Am Anfang musst du dir wirklich viele Fragen stellen - zu den möglichen Szenarien die auftreten können (und das sind 'ne Menge) -, Gedanken zur logischen Umsetzung machen (Struktur und Ablauf), GUI Output, Logerstellung (wie, was, wann, in welcher Form), logische Abgrenzung der einzelnen Funktion (um Dynamik untereinander zu gewährleisten), ... Und alle Funktionen müssen dynamische Daten verarbeiten können (nicht solche statischen Dinger wie du in deinem Skript verwendest). Mit dynamisch meine ich in diesem Fall unbekannte Daten. Keine der Informationen die ausgelesen, bearbeitet oder ausgegeben werden sind vorher bekannt; die werden alle dynamisch aus verschiedenen Quellen zur Laufzeit abgerufen - falls die Quelle nicht verfügbar ist, was macht man dann (usw.),

Ich glaube kaum das den Spielern eine Wahl gelassen wird bzw. die werden gar nicht erst groß gefragt. Ausgetauscht, E-Mail hinterher geschickt und damit hat sich die Sache. Bei Verdacht auf Missbrauch, Bann. Für sowas gibt es Datenbank-Spezialisten. "Kurz" ein Script geschrieben, welches alle Charaktere aller Server nach Item X, Y, n .. durchsucht und falls gefunden in einer Tabelle gelistet wird. "Simpelstes" SQL, solange das Script die Gegenstände nicht auch noch automatisch austauschen soll.

Erst einmal: Das Script ist sauber. Keine "bösen" Funktionen drin. Auch wenn das Script nun 'funktioniert' mal ein paar Anmerkungen dazu: Wozu Func _verify_resolutions_file()? Du kannst mit @DesktopHeight und @DesktopWidth die aktuelle Windows Auflösung sowie per IniRead die SW:TOR Auflösung auslesen. (Nicht getestet, einfach so grad mal geschrieben, sollte aber funktionieren; natürlich angepasst an dein Script mit den Variablennamen) ------- Desweiteren erstellt man keine GUIs innerhalb von Funktionen. GUIs werden am Anfang des Skriptes erstellt - alle. Man deaktiviert, versteckt und aktiviert sie bei Bedarf (per GUIWinSetState(@sw_show, $WinHwndX). ------- Auch erstellt man keine einzelnen Events pro OnClick Control, sondern verweist alle auf die gleiche Funktion, in der dann per @GUI_CtrlId das aktivierte Control ausgelesen und entsprechend gearbeitet wird (per Select-Case). Sollten die Funktionen pro Control-Event Anzahlmäßig recht groß sein, wird dort einfach auf eine andere Funktion verlinkt, ansonsten können dort ruhig 3, 4 Befehle stehen. Das hat den Vorteil, dass du alle GUI-Events an einem Ort hast und kannst somit diese leichter überschauen und Fehler finden. Du baust dir deine eigenen Exception Handler. Man vermeidet die Verwendung von If-Else Anweisungen und verwendet stattdessen wann immer möglich Select-Case-Case Else. Case Else ist in dem Fall der Exception Handler (undefinierter Zustand) bei dem du den Fehler auffängst und etwas ausgeben lässt oder alternativ einen Standardwert setzen kannst um den Fehler versuchen zu beheben. Siehe dazu mein Beispiel mit den GUI-Controls oben.

Wenn ich Daheim bin, schau ich mal über dein Script drüber... ich bastelt schon seit Jahren mit AutoIt für derart simple Dinge rum, aber weitaus komplexer und 'ausfallsicherer' (exception handler - falls dir das was sagt). Ich bin sicher ich finde den Fehler recht fix.

?? Ich zähl mal die Fehler auf, die deutlich gegen ein "Promo Video" sprechen. kein HD Intro- oder Promo Videos sind für gewöhnlich Akustik-only von der Hintergrundmusik Track ist zwar schön, passt aber nur sehr beschränkt zu den Szenen Video nicht an Audio angepasst titles sind versetzt / nicht mittig / nicht im selben Abstand zueinander Wechsel des Hintergrundes bei titles seltsame 0815 WMM-Effekte ... das ist mir jetzt spontan bei einmaligem Durchschauen aufgefallen. 'Vernichtende Kritik', ich weiß, aber da ich selbst Videos mit professionellen Tools erstelle kann ich das beurteilen. Aber letztendlich haben die aufgezählten Punkte bis auf den Letzten nichts mit den verwendeten Tools zu tun, sondern sind grundlegende Videobearbeitungs-Kenntnisse bzw. Skills. Eine Zusammenschneiden mit Audiospur drunter und rendern schafft jeder, ja dafür gibt es mittlerweile sogar automatisierte Tools, dass hat nichts mit Videobearbeitung zu tun.

Zum Glück spiele ich die meisten Spiele ohne Sounds... gehen mir nach 'ner Weile auf auf den Sender.