Massive Universe Online

[Bergmann89]

Hey,

ich hoffe ich habs gefixt. Bei Shadern ist das von Grafikkarte zu Grafikkarte bisl unterschiedlich
Datei hab ich als Anhang mit hochgeladen. Die muss nach ".\MassiveUniverseOnline\data\shader".

MfG Bergmann.

[jaenicke]

Schade ist, dass das Programm sang- und klanglos abschmiert, wenn es seine Log-Datei nicht schreiben kann...

Denn logischerweise hatte es beim Ausführen keine Schreibrechte im Ordner... Dass es daran lag, hat mir aber erst der Process Monitor verraten.

Zumindest in dem Fall wäre es sinnvoll die Datei an einen günstigeren Ort zu legen oder zumindest eine Meldung anzuzeigen, dass man seine Rechte verbiegen muss.

[Bergmann89]

Hey,

das log-File ist so ziemlich das erste was erstellt wird, denn da landen eig. auch die Fehler drin. Ich finde, dass der Ordner der EXE genau der richtige Ordner für das log ist, da das Programm später auch an Leute ausgeliefert wird, die nicht so bewandert mit PCs sind, und die bei einem Fehler die log-Datei an uns schicken sollen. Wenn die erst nach %APPDATA% müssen, dann blicken die nich mehr durch Ne ordentliche Fehlermeldung wenn das Log nicht erstellt werden kann fehlt, da geb ich dir Recht. Das pack ich gleich mal auf die ToDo-Liste

MfG Bergmann.

[pustekuchen]

Das ist aber nicht wirklich toll.. Macht es doch so:

Log in %appdata%\MUO erstellen und bei der "Installation" eine Verknüpfung hinzufügen.

[jaenicke]

Zitat von Bergmann89:

Ich finde, dass der Ordner der EXE genau der richtige Ordner für das log ist, da das Programm später auch an Leute ausgeliefert wird, die nicht so bewandert mit PCs sind, und die bei einem Fehler die log-Datei an uns schicken sollen. Wenn die erst nach %APPDATA% müssen, dann blicken die nich mehr durch

Deshalb meine ich ja:
Kann die Datei nicht erstellt werden, pack sie doch einfach an den richtigen Ort. Wenn die Schreibrechte da sind, kann sie ja meinetwegen im eigenen Ordner landen, das ist bei mir eh nie der Fall.

[BUG]

Klappt immer noch nicht.
Außerdem habe ich es geschafft eine Access-Violation zu provozieren, in dem ich mehrfach zwischen Smooth und Normal umgeschaltet habe und das Programm dann beende.

Ich würde vorschlagen, Hashes aller geladener Dateien in die Log-Datei zu packen. Da ihr sowieso Git benutzt:

• http://stackoverflow.com/questions/5...1s-without-git
• http://stackoverflow.com/questions/2...-has-this-blob

Außerdem könntet ihr darüber nachdenken, Log- und Config-Dateien (auf Wunsch des Users) über ein Tool auf euren Server zu Laden. Dann kann dem User egal sein, wo die Datei liegt und welche er genau braucht. Er klickt auf einen Button und alle nötigen Informationen werden hochgeladen, heraus kommt evtl. noch eine URL, die er in Foren und Problemberichten nutzen kann.

[Bergmann89]

Okay überredet, ich packs nach %APPDATA%, für die Demos ist die Lösung mit der Verknüpfung ja ausreichend. Das mit dem Upload is ne gute Idee. Das brauchen wir dann aber erst in der eigentlichen Anwendung zum Game. Sowas ähnliches wie die Hashes hatten wir auch geplant, weil wir dann darüber unsere Updates fahren wollten.
Bei dem Fehler bin ich grad mal ratlos. Im Netz findet man dazu auch nich wirklich was. Normalerweise ist das ein einfacher inditzierter Zugriff auf ein Matrix-Element, aber aus irgend einem Grund will das deine Karte nicht

[Bergmann89]

Hey Leute,

es gibt mal wieder was Neues zu berichten. Im aktuellen Post dreht sich alles um das neue GUI Design und das Netzwerkprotokol des Games. Alle Informationen gibt es HIER

Bis bald, euer BitSpace-Team.

[BUG]

Zitat von Bergmann89:

Alle Informationen gibt es HIER

Es sieht so aus, als könnte fast Abfragen direkt an einen Datenbankserver(/-cluster) gehen ohne erst durch den Session-Server zu laufen.
Zudem könnte man die wichtigen Teile des Spielerzustands direkt in die Session-Informationen einbinden (wie ein Cookie). Damit der Spieler nicht herum manipuliert, gibt es noch eine Signatur (Hash mit teilweise geheimen Salt) dazu.

Wenn die Kommunikationsserver dieses Cookie setzt, könntet ihr direkt auf den Session-Server ganz verzichten und gleich auf eine vernünftige Datenbank setzen.



Freud mich das ihr immer noch durchhaltet

[Bergmann89]

Hey,

der Client kan eigentlich nichts manipulieren, weil die Daten vom Server immer noch einmal geprüft werden, bevor sie als gültig übernommen werden. Die Daten bekommt der Client nur, das er etwas hat, mit dem er sich beim Communication-/GameServer anmelden kann. Oder um dem User einige Informationen anzuzeigen.
Das Ganze in eine normale Datenbank zu packen hatten wir auch schon überlegt, aber den Gedanken hatten wir dasnn aus irgend einem Grund verworfen^^ Es ist durchaus Möglich den SessionServer und die CommunicationServer als eine Komponente zu gestalten, aber so lässt sich das Ganze später bessser verteilen, fals die Last auf dem Server zu hoch wird. Am Anfang werden SessionServer und CommunicationServer sowieso auf einer Maschine laufen. (Wenn ich es mir recht überlege läuft am Anfang eig. alles auf einem Rechner )

MfG Bergmann.