ZweiDe
Übersicht

Gehe zu Seite Zurück 1, 2, 3 ... 12, 13, 14 ... 18, 19, 20 Weiter
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Die Steuerung ist sicherlich Geschmackssache, aber soweit ich das bisher sehen kann, ist sie nicht objektiv schlecht.. es gibt ja auch Leute, die sie gut finden oder gut damit klarkommen, darunter auch ich. Ich persönlich finde die Steuerung sehr eingängig und mit etwas Übung gut beherrschbar. Ich denke, es ist Übungssache.
Wenn es konkrete Punkte gibt, die ich verbessern kann, werde ich das gerne tun, aber von kaum jemandem, der sich über die Steuerung beklagt, habe ich bisher konkrete Vorschläge oder konkrete Kritik gehört, zumeist nur "Nicht so toll" oder "Komme damit nicht klar". Ich würde euch ehrlichgesagt gerne mal über die Schulter schauen, um herauszufinden, wo genau es hakt, das merkt man ja auch selbst nicht immer. Wenn ihr eine Idee habt, würde mir das sehr weiterhelfen; ich will die Steuerung auf jeden Fall für möglichst viele Leute zugänglich machen. (Kleiner Tip: haltet den Mauscursor nicht zu weit unten, denn je weiter unten er sich befindet, desto empfindlicher / schneller reagiert die Steuerung. Das ist bewusst so gehalten - falls es euch also zu hektisch wird, haltet den Cursor eher oben.) Ich würde mich freuen, noch ein paar konkretere Vorschläge / Anmerkungen zu hören! |
||
![]() |
ozzi789 |
![]() Antworten mit Zitat ![]() |
---|---|---|
Kann es drann liegen dass ich wahrscheinlich nur OGL 2.1 habe, btw wie finde ich das raus?
Sig @home danke ![]() |
||
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5 |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
OpenGL 2.1 reicht aus. Am besten findest du das mit nem Diagnosetool raus, was du mit deinem Grakatreiber installiert haben könntest.
Probiers aber erstmal mit der neuen glfw.dll, die ich hochgestellt hab, bei D2006 gings danach ![]() |
||
![]() |
ozzi789 |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ok werd ich, bin aber gerade anner Abreit, werds heute abend hier rein posten ![]() mfg |
||
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5 |
![]() |
Alfadur |
![]() Antworten mit Zitat ![]() |
---|---|---|
Logfile sagt
Entering gamestate MainMenu... System.NullReferenceException: Object reference not set to an instance of an object. at Tao.OpenGl.Gl.glGenFramebuffersEXT(Int32 n, Int32& framebuffers) at Fetze.Module.ZweiDe.Texture.CreateRenderBuffer(TexFlag flags, Boolean reqZBuffer, Boolean floatingpoint) at Fetze.Module.ZweiDe.TextHelper.SetText(String text) at Fetze.Module.ZweiDe.TextHelper..ctor(String text, Single xHandle, Single yHandle, TexFlag texFlags, Single aniso) at Fetze.Module.Fenster.Window..ctor(String title, Single x, Single y, Single w, Single h, Boolean locChildrenArea) at SteCore.SteApp.OnGameStateEnter(GameState newState) at StarTrade2.StarTrade2App.OnGameStateEnter(GameState newState) at SteCore.SteApp.PerformGameStateSwitch() at SteCore.SteApp.Run() |
||
A Cray is the only computer that runs an endless loop in less than four hours. |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Bist du sicher, dass du OpenGL 2.1 support hast? Was für ne Grafikkarte hast du, mit welchem (aktuellem?) Treiber? Mehr Informationen! Ein Logfile kann auch nicht zaubern ![]() |
||
![]() |
ozzi789 |
![]() Antworten mit Zitat ![]() |
---|---|---|
glfw.dll fix hat geholfen, auf jeden der Hammer ![]() |
||
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5 |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Meine alte Roadmap ist quasi abgeschlossen und wie die spielbare Techdemo gezeigt hat, ist der Core in den Grundzügen soweit einsatzbereit.
Baustellen, an denen ab jetzt noch gearbeitet werden muss / wird: ![]() ![]() ![]() ![]() Und, speziell für mich und alle, die eventuell später noch Mitarbeiten werden: ![]() |
||
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Habe heute mal wieder am Editor gearbeitet.
![]() ![]() Der ColShape-Editor war bereits vorher fertig, wurde aber glaube ich bisher noch nicht gezeigt. Das andere ist ein Blick aufs IngameWindow mit daneben arrangiertem ObjectBrowser - an letzterem bastele ich gerade herum. Der Editor ist modular aufgebaut und basiert auf einer Plugin-Architektur. Standardmäßig gibt es nur ein MainForm das Daten sowie Level laden und speichern kann, jedoch über keine Möglichkeiten zur Modifikation dieser verfügt - ebenfalls immer dabei ist das IngameWindow, welches einen WYSIWYG-Blick auf das Spiel ermöglicht. Alles andere ist in je eine separate PlugIn-Dll ausgelagert, so beispielsweise der ColShape-Editor oder auch, woran ich gerade bastele, verschiedene Editoren zur Objektmodifikation. Plugins müssen grundsätzlich alleine, nur auf Basis des Grund-Editors lauffähig sein, können jedoch über entsprechende Interfaces miteinander kommunizieren. Außerdem gibt es globale Editor-Events, an die sich jedes Plugin anhängen kann, so beispielsweise AfterLevelEnter oder BeforeLevelLeave. Was den Leveleditor-Part betrifft, an dem ich gerade arbeite: Der Objektbrowser ist noch nicht wirklich fertig, es fehlt noch an Übersicht / Gliederung und Funktionalität (Zentrieren auf, Umbenennen, Interaktion im IngameWindow). Anschließend wird ein Steuerelement für Objekteigenschaften hinzukommen, das auf das gerade gewählte Objekt reagiert und ein PropertyGrid zur Verfügung stellt. Mal schauen, wie lange ich dazu brauche. Ein Leveleditor ist definitiv notwendig; während Spielregeln und Objekttypen problemlos per Hand in Inidateien geschrieben werden können, würde das im Leveldesign einfach zu sehr ausbremsen. |
||
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Immernoch dabei, am Editor herumzubasteln. Ich möchte zumindest den Level-Part des Editors zu einem gewissen Grad lauffähig kriegen, bevor ich mich weiter dem Game Core widme, denn so kann meine Ein-Mann-Leveldesign-Crew parallel mit ihrer Arbeit beginnen.
Dennoch mache ich mir Gedanken über den nächsten ToDo-Punkt des Game Cores, denn bis vor kurzme hatte ich noch keinen Schimmer, wie der zu realisieren sei: Einer flexiblen, asynchronen Scripting-Engine, die dynamisch angelegte, objektlokale Variablen ("Tagging") unterstützt und sowohl für Levelscripte als auch Objekt-Sonderverhalten verwendet werden kann. Grundsätzlich habe ich in C# da zwei Möglichkeiten: 1. Den Traditionellen Ansatz, mir eine eigene Scriptsprache zu schreiben und schön Befehle als Klassen mit Ableitungshierarchie zu definieren, um alles flexibel und leicht erweiterbar zu machen. Sowas in der Art habe ich für die DeathSequences zusammengebastelt, aber die Anforderungen waren dort alles andere als hoch. Oder 2.: Ich kann mit DotNet zur Laufzeit C# Code kompilieren und einbinden. Man könnte also direkt in C# scripten, was von den Möglichkeiten her schon das Nonplusultra ist.. aber den entscheidenden Nachteil hat, dass asynchrone Scripte nicht oder nur sehr begrenzt möglich sind. Jeder kennt die Scripting-Situation, zu Zeitpunkt A etwas zu tun, dem Script dann zu sagen, dass es 10 Sekunden warten soll und dann die nächste Aktion ausführen. Genau das wäre hier kaum Möglich, es sei denn, ich packe jeden dieser Aktionsblöcke in eine eigene Funktion, was ziemliches rumgefrickel und enorm umständlich wäre. Aus diesem Grund wäre ich fast versucht gewesen entgegen aller Vorteile von #2 trotzdem #1 zu bevorzugen.. bis ich etwas herausfand, wozu ich ein wenig ausholen muss: In C# gibt es die folgende Möglichkeit, um durch "Collections", also alles, das eine Sammlung von Dingen enthält, zu iterieren: Code: [AUSKLAPPEN] foreach (string s in myStringArray) { ... } Nur so als Beispiel. In C++ nimmt man für sowas meist Iteratoren, zB. aus der STL, in BlitzMax.. weiß ich nicht mehr, obs da sowas gab. Eine solche COllection, das könnte zB. ein Array sein, [ generische ] Liste / Dictionary / Stack / ... oder aber auch ein eigener Collection-Typ. Prinzipiell kann man mit allem mittels foreach durchiterieren, was ein Objekt vom Typ IEnumerable<Datentyp> zurückliefert und entsprechend implementiert ist. So geht zB. auch folgendes: Code: [AUSKLAPPEN] foreach (string s in myStringList.Reverse) { ... } während Reverse im Beispiel mal ein Property sei, womit man die Liste rückwärts durchiterieren kann. Ich denke, damit das System dahinter klar wird, sollte ich weiter darauf eingehen. Wenn ich nun selbst eine Möglichkeit zur Verfügung stellen will, durch irgendetwas durchzuiterieren, brauche ich also ein Stück Code, das ein IEnumerable<DatenTyp> zurückliefert. Das kann prinzipiell auch ein isoliertes Stück Code sein. Wenn ich beispielsweise durch alle Potenzen von x bis zum Exponent y iterieren will, könnte ich das wie folgt implementieren: Code: [AUSKLAPPEN] public static IEnumerable<int> Power(int number, int exponent) { int counter = 0; int result = 1; while (counter++ < exponent) { result = result * number; yield return result; } } Code: [AUSKLAPPEN] foreach (int i in Power(2, 8)) { Console.WriteLine(i); } Ausgabe: Zitat: 2 4 8 16 32 64 128 256 Das eigentlich geniale hier ist das ominöse Schlüsselwort yield. Es ist der Schlüssel zum Iteratorensupport von C# und prinzipiell tut es nichts anderes als die Funktion an dieser Stelle zu unterbrechen, einen Rückgabewert zu liefern und die Möglichkeit offen zu halten, an genau dieser Stelle innerhalb der Funktion später weiterzumachen! In foreach wird über den Rückgabetyp IEnumerable<int> ein Objekt vom Typ IEnumerator<int> angefordert. Dieser speichert den aktuellen Wert, d.h. den letzten Rückgabewert und kann durch einen Funktionsaufruf "MoveNext" zum nächsten Wert iterieren. De factor wird dabei die Funktion aufgerufen bzw. fortgesetzt, die mittels des in-Statements im foreach angegeben wird, hier also "Power". Das ganze kann man auch manuell machen: Code: [AUSKLAPPEN] IEnumerator<int> it = Power(2, 8).GetEnumerator(); while (it.MoveNext()) { Console.WriteLine(it.Current); } Dieser Code hier ist identisch zu dem oben, aber mittels MoveNext() bestimmen wir jetzt selbst, wann wir den nächsten Rückgabewert haben wollen. So.. und jetzt wird es etwas "freaky". Wer bis hier hin nicht mitgekommen ist, kann sich den Rest des Beitrags vermutlich sparen, aber ich will niemanden Abschrecken - das Endergebnis ist, als Programmierer gesprochen, bildhübsch. Also: Wie missbraucht man dieses konzept nun für seine Zwecke, wenn das Übergeordnete Ziel ist, asynchrone Scripte in echtem C# Code zu haben? Ich denke, diejenigen von euch, die mitgekommen sind, ahnen es bereits. So könnte eine Scriptfunktion von uns also später aussehen: Code: [AUSKLAPPEN] public static IEnumerable<?> MyScript() { Console.WriteLine("Script begin"); yield return ?; Console.WriteLine("Script mid"); yield return ?; Console.WriteLine("Script end"); } Mit einem yield return markieren wir eine Position, an der das Script die Kontrolle zurück an das Hostprogramm, d.h. das Spiel zurückgibt. Der Clou an der Sache ist, dass wir so auch sehr lange und asynchrone Scripte problemlos mit einer Methode implementieren können, anstatt in unserem Script für jeden Aktionsblock eine eigene Methode zu schreiben und alle umständlich zu verketten. Ein anderes Gegenbeispiel: Man stelle sich vor, wir hätten versucht, eine Scriptfunktion stattdessen zwecks Asynchronizität in einem eigenen Thread auszuführen.. ein Albtraum! Hier sind wir hingegen in der Lage, auf einfache Art selbst zu bestimmen, welche Blöcke als Ganzes ausgeführt werden. Aber es geht noch weiter, schließlich haben wir die Möglichkeit, hier etwas zurückzuliefern. Ich denke, Code sage hier mehr als tausend Worte. Man verzeihe mir die aus Gewohnheit englisch gehaltenen Kommentare: Code: [AUSKLAPPEN] public abstract class ScriptContinueCondition { public abstract bool IsFulfulled(); } Code: [AUSKLAPPEN] public class Wait : ScriptContinueCondition { protected DateTime beginTime; protected TimeSpan time; public Wait(TimeSpan time) { this.beginTime = DateTime.Now; this.time = time; } public override bool IsFulfulled() { if (DateTime.Now - this.beginTime >= time) return true; return false; } } Ausführung eines Scripts vom Spiel aus, Beispiel: Code: [AUSKLAPPEN] // This is our script iterator, normally would be saved locally somewhere IEnumerator<ScriptContinueCondition> scriptPos = MyScript().GetEnumerator(); // This is our simulated game loop while (true) { // Check, if we can proceed if (scriptPos.Current == null || scriptPos.Current.IsFulfulled()) { // Process a script block scriptPos.MoveNext(); } // Print something to look busy. Console.WriteLine("."); // This simulates we're doing something else here System.Threading.Thread.Sleep(100); } Beispielscript: Code: [AUSKLAPPEN] public static IEnumerable<ScriptContinueCondition> MyScript() { Console.WriteLine("Script begin"); yield return new Wait(TimeSpan.FromMilliseconds(1000)); Console.WriteLine("Script mid"); yield return new Wait(TimeSpan.FromMilliseconds(1000)); Console.WriteLine("Script end"); } Ausgabe (in etwa): Zitat: Script begin . . . . . Script mid . . . . . Script end . . . . [...] Viel Code auf einmal. Zum Verständnis werde ich kurz umreißen, was er tut: Jeden Durchlauf des MainLoops wird ein Block des Scripts ausgeführt, sofern die mit dem letzten Rückgabewert definierte Bedingung erfüllt ist. Im Beispielscript wird der erste Block sofort bei Scriptbeginn ausgeführt, mit dem zweiten und dritten wird jeweils eine Sekunde gewartet. Durch die Abstraktion der "ScriptContinueCondition" wäre es auch denkbar, andere Bedingungen zu definieren, man könnte sogar vom Script aus eine anonyme Methode oder einen Delegaten / Funktionspointer übergeben, der bestimmt, wann die Bedingung erfüllt ist. Obwohl man damit absolute Freiheit bei der Definition der Fortführungsbedingung erhält, sollten das natürlich trotzdem bloß Fortführungsbedingungen bleiben. Das Triggern bestimmter Scriptereignisse durch Events wird die primäre Umsetzung dieses Scriptingsstems ein. Beispiel: Ein GameObject vom Typ "Area", das in seinem Script zu entsprechenden Zeitpunkten Methoden aufruft wie "OnGameObjectEnter" oder "OnGameObjectLeave", etc. Mal hoffen, ich hab jetzt mit diesem sehr C#-lastigen Exkurs niemanden vergrault. Ich für meinen Teil fühle mich ein wenig, als hätte ich damit den Heiligen Gral des C# Scripts in den Händen, vielleicht ist da einfach meine Begeisterung mit mir durchgegangen ![]() |
||
![]() |
Jo0oker |
![]() Antworten mit Zitat ![]() |
---|---|---|
Nur mal so aus Interesse,
nutzt du für dein Layout WeifenLuo? lg Jo0oker |
||
Tehadon, das kostenlose 3D RPG
www.tehadon.de http://www.blitzforum.de/worklogs/14/ Das Abenteuer wird beginnen! |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Jep. Hab selten ein geileres GUI-Submodul gesehen - lediglich ein wenig unterdokumentiert ![]() |
||
![]() |
peacemaker |
![]() Antworten mit Zitat ![]() |
---|---|---|
Interessanter Ansatz, ich würds genau gleich machen.
Die Vorteile die laufzeitkompilierter C#-Code bringt sind einfach viel zu gross um sie nicht zu nutzen. Enormer Speed, sehr mächtige OOP-Werkzeuge... das wäre ideal um Verhalten zu Skripten. Beispielsweise für Bots, einfach z.B. von Behaivour erben, verhalten implementieren, und schon läufts! mfG |
||
~Tehadon~
www.tehadon.de http://www.blitzforum.de/worklogs/14/ |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ich kämpfe gerade in er Reflectionhölle um mein Leben, jedenfalls fühlt es sich so an. Ich glaube aber, den Kampf so langsam zu gewinnen.
Es begann alles damit, dass man im Editor mittels eines PropertyGrids, das von DotNet zur Verfügung gestellt wird, Objekte bearbeiten können sollte. Es klang alles sehr einfach: Objekt reinstecken und Reflection macht den Rest. Ha! Von wegen! Das Ende vom Lied: ![]() ![]() ![]() ![]() Im Moment arbeite ich weiter an weiteren Convertern und Editoren fürs PropertyGrid. Man soll schließlich am Ende auch alle Properties eines Objekts bearbeiten können, wenn sie schon da sind. Danach werde ich eifrig Kategorieeinordnungen und Beschreibungen anhängen und dann, irgendwann, ist dieser Part des Editors endlich abgeschlossen. Nachdem ich die letzten Tage durchschnittlich 8 Stunden drangesessen hab, freue ich mich drauf. |
||
![]() |
ComNik |
![]() Antworten mit Zitat ![]() |
---|---|---|
Nur eine kurze Zwischenfrage: Da du ja sehr viel mit Reflection machst. Ist das nicht eigentlich langsam? Da ja alles per String Handle nunja gehandelt wird?
lg (wieder mal spannende Einträge etc.. ![]() ComNik |
||
WIP: Vorx.Engine |
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Reflection ist sicher nicht die schnellste Variante, etwas zu tun, aber bisher hatte ich nie ernsthaften Grund für Performance-Tests in dem Bereich - was hauptsächlich daran liegt, dass Reflection bei mir hauptsächlich zum Speichern, Laden und für Sonderaktionen im Editor zum Einsatz kommt. Ingame achte ich darauf, keine Reflection zu nutzen, da es hier wirklich auf die Performance ankommt.
Speicher, Laden und Sonderaktionen dürfen ruhig etwas länger dauern, da ich sie als einmalige, rechenintensive Prozesse verstehe. Wenn der Editor einen Level lädt, erwartet man als Nutzer von vornherein, dass es einen Moment dauern könnte (Auch wenn ich bisher noch gut unter der Sekunde bin ![]() ![]() Wenn es um Dinge wie das PropertyGrid geht: Reflection wird hier zwar genutzt, jedoch bloß einmalig beim Aufbau der Tabelle und dann nochmal beim Setzen und erneutem Holen von Einzelwerten. Selbst wenn es doppelt so langsam wäre, das ist einfach nur ein Tropfen auf dem heißen Stein. Weitaus mehr Zeit kostet es da, ein Control wie das PropertyGrid neu zu zeichnen, wenn der Cursor drauf herum fährt ![]() Trotzdem; das Argument zählt für mich nicht, wenns um Dinge geht, die sehr schnell oder sehr oft ausgeführt werden müssen, beispielsweise die KI-Statemachine der Raumschiffe. Zwecks Flexibilität und Einfachheit suche ich die für einen State zu nutzenden Methoden per Reflection heraus. Dies geschieht jedoch einmalig bei Initialisierung des Spiels: Ich speichere die so erlangten MethodInfo-Objekte zwischen, um sie nicht erneut heraussuchen zu müssen. Wird ein Schiff erstellt, verwende ich diese, um daraus ein für dieses Schiff angepasstes (Aufruf objektlokaler Methoden) Delegate-Array zu erstellen; der Aufruf eines Delegates ist kaum langsamer als der einer Methode, wie ich sie normalerweise definiere ![]() |
||
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Musste nochmal das gesamte System zur Erkennung von Objektreferenzen sowie das zum Umbenennen von string / Id - Referenzen auf umbenannte Objekte neu schreiben. Der Grund: Es funktionierte zwar, aber nicht in allen theoretisch möglichen Fällen - und ich bin erstens kein Fan von zusammengeschusterten Schnelllösungen und zweitens nicht auf unliebsame Überraschungen später in der Entwicklung aus.
Referenzen werden nun auch extrem verschachtelt erkannt, beispielsweise, wenn der Verweistyp nicht "Objekttyp" ist, sondern "Dictionary<Bla,List<Objecttyp>[]>" oder irgendwas ähnlich abgefahrenes. Auch wird der Verweis erkannt, wenn er sich innerhalb eines geschachtelten Objekts befindet - aber nur, wenn dieses geschachtelte Objekt selbst kein Verweis ist, sondern sich mitsamt seiner Description wiederum im Parentobjekt befindet. Beispiel: Code: [AUSKLAPPEN] class ObjectA : SteObject {...}; class ObjectADesc : SteObjectDesc {...} class ObjectB : SteObject { List<ObjectA> objRefList; // Nur Referenz, da desc. Objekte sich nicht ebenfalls in ObjectBDesc befinden ObjectA[] nestedObjects; // Echte, nested SteObjects, da auch ObjectADesc[] in ObjectBDesc enthalten. } class ObjectBDesc : SteObjectDesc { List<string> objRefList; ObjectADesc[] nestedObjects; } Eine solche Verweisprüfung ist nötig, da sich in der Rekursion sonst Schleifen ergeben können und durch Verweisrekursion die Ergebnisse verfälscht werden. Ein Item, das einen Verweis auf ein zu erzeugendes Projektil hat, sollte dieses nicht ebenfalls nach Verweisen scannen - das ist Sache des Projektils. Auf der anderen Seite muss es aber seine eigenen ActionSteps durchsuchen, denn diese gehören, als nested SteObjects, direkt zum Item dazu. Ich hoffe, ihr seht den Unterschied. Naja, jedenfalls war das alles ein Riesenstress, ich saß gestern wieder bis nachts um 2 dran und heute morgen auch schon drei Stunden. Aber jetzt bin ich damit endlich fertig und kann damit fortfahren, meine Objekte im PropertyGrid vernünftig editierbar zu machen. |
||
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Großes Update: Der Editor ist da! Genaugenommen die erste Version davon, mit der man halbwegs was anfangen kann.
StarTrade2: http://www.fetzenet.de/st2_cur..._build.zip Editor: http://www.fetzenet.de/st2_cur...editor.zip Installation: ![]() ![]() ![]() Verwendung: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() In der bisherigen Version sollte es mit dem Editor bereits möglich sein, auf Basis des Contents Level zu erstellen - in der Pre-Alpha-Testversion ist das Script, das Gegner erstellt allerdings noch hardcoded und wird ablaufen, wannimmer keine Feinde mehr herumschwirren. Den Content selbst kann man relativ einfach beareiten und erweitern, da er "wie immer" in .ini-Dateien im Content-Unterverzeichnis ausgelagert ist. Wäre cool, ein wenig Feedback zu bekommen, je mehr desto besser ![]() |
||
- Zuletzt bearbeitet von Fetze am Mi, März 17, 2010 0:56, insgesamt einmal bearbeitet
![]() |
Thorsten |
![]() Antworten mit Zitat ![]() |
---|---|---|
Bei der St2Editor.exe tut sich bei mir gar nichts. Die .exe läuft zwar mit 50% CPU Aulastung aber es kommt weder ein Fenste rnoch eine Meldung oder so.
mfG, Thorsten |
||
![]() |
Fetze |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ich hab mal Testweise den aktuellen Stable Build des Spiels geladen und dann den des Editors und wie in der Installationsanleitung beschrieben drüberkopiert: Bei mir gehts. Liegt also definitiv nicht am Package. Andere Erfahrungsberichte? | ||
Gehe zu Seite Zurück 1, 2, 3 ... 12, 13, 14 ... 18, 19, 20 Weiter
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group