Druckbare Version
Das wäre tatsächlich eine mögliche Lösung. Nur leider muss ich da ziemlich viel kopieren:
- Alle Common Events
- Die Variablen-Namen
- Die Chipset-Einstellungen
...und sicher, das eine fremde Database kompatibel ist und alle anderen Einstellungen erhalten bleiben?
Falls sich herausstellen sollte, dass es keine Lösung für dein 5-Stunden Problem gibt, hätte ich noch eine Idee.
Dein Problem sind ja die 10-Sekunden Wartezeiten bei Veränderung der Database, weshalb du die Vari-Anzahl zwischenzeitlich runterschrauben willst.
Meine Idee ist allerdings, dass du zuerst dein Spiel komplett fertig makerst, ohne die Variablenanzahl auf 999999 zu erhöhen, sondern ersteinmal nur den ersten Geist für den ersten Kurs makerst, um zu sehen ob dein Code korrekt ist. Wenn dies der Fall ist, makerst du den Code für die restlichen Kurse, aber um die Variablen aufzurufen und zu setzen, die noch gar nicht existieren, benutzt du den "Variable No" Befehl. So kannst du zB. der 500000ten Variable einen Wert zuweisen, obwohl du in der Database nur 5000 Variablen maximal zur Verfügung hast. Wenn du nähmlich fertig bist, mit der Codingarbeit (und alles überprüft hast), dann erst erhöhst du die Variablenanzahl auf 999999.
Problem hierbei ist allerdings, dass Nachbesserungen am Code wieder sehr langsam währen.. hoffen wir, dass es eine einfachere Lösung gibt xD
Achja, was hälst du eigentlich von meiner zweiten Idee aus meinem ersten Post?
Ist dir dass zu ungenau, oder hast du schon mit ca. 64000 Variablen getestet und es für unzureichend befunden?Zitat:
-ich würde zweitens die Geistdaten nur einmal pro halber Sekunde speichern und die "Zwischenschritte" dann beim Abspielen des Replays "schätzen" bzw. per Formel errechnen "lassen" (dürfte immer noch genau genug sein)
Oh Sorry, hab ich jetzt garnicht mehr dran gedacht.
Ursprünglich wollte ich jede zehntel Sekunde speichern, hab dann aber gemerkt, dass selbst das hakelig aussieht und bin deshalb auf die doppelte Speicherfrequenz umgestiegen. Das Berechnen der Zwischenschritte einer Sekunde wäre erstens schwieriger und zweitens weiß ich nicht, ob das Replay (Der Geist) durch das zeitintensive Berechnen dann noch flüssig läuft. Ich hoffe jetzt allerdings, dass sich dieses Problem mit Hilfe den Vektoren klärt, was ich allerdings noch nicht ausprobiert habe.
Zu den "VariableNo.":
Kann man eine Variable ansteuern - und füllen - die oberhalb des Variablenmaximums liegt? In der "RTP_RT.ldb" werden meinen Beobachtungen zu Folge nämlich allen Variablen unterhalb des Variablenmaximums der Wert Null zugewiesen und ich weiß nicht, ob andere Variablen für den RPG-Maker überhaupt existieren. Aber eigentlich müsste es doch einen Zwischenspeicher geben, in dem die Variablen während des Spielens vorhanden sind. Fragt sich jetzt nur, wie der aufgebaut ist...
Wenn das ganze funktioniert, gibt es jetzt zwei Lösungen, die immer noch mit Zeitaufwand verbunden sind:
1. Databasetexte und VarNamen in neues Spiel kopieren und dessen komplette Database zurückkopieren (Dhan)
2. VarMax. runtersetzen und höhere Vars über VarNo. ansprechen (Ryo Saeba 1000)
Wer weiß noch was?
Naja, also schwierig ist die Berechnung nicht (vielleicht muss man die Zwischenschritte auch gar nicht berechnen o.o man kann doch mit Move Picture Befehlen arbeiten, um eine flüssige Bewegung zu erzeugen?) Aber das kommt natürlich auch auf dein Spiel an.. womöglich ist die Vektorgeschichte die bessere Lösung.Zitat:
Zitat von CapSeb
Oh, ich glaub da hast du mich falsch verstanden (ich hab mich auch etwas doof ausgedrückt, ich bin nicht besonders im Erklären^^').Zitat:
Zu den "VariableNo.":
Kann man eine Variable ansteuern - und füllen - die oberhalb des Variablenmaximums liegt? In der "RTP_RT.ldb" werden meinen Beobachtungen zu Folge nämlich allen Variablen unterhalb des Variablenmaximums der Wert Null zugewiesen und ich weiß nicht, ob andere Variablen für den RPG-Maker überhaupt existieren. Aber eigentlich müsste es doch einen Zwischenspeicher geben, in dem die Variablen während des Spielens vorhanden sind. Fragt sich jetzt nur, wie der aufgebaut ist...
Wer weiß noch was?
Man kann afaik keine Variable ansteuern und füllen, die oberhalb des Maximums liegt.
Also diese Varis, die dann später per Variable No belegt werden, können vorher (bevor du die Max Anzahl auf 999999 gesetzt hast) nicht angesprochen oder genutzt werden, da sie ja "noch nicht existieren". Du kannst den kompletten Code um sie später anzusprechen aber schon coden, ohne ihn dann theoretsich noch verändern zu müssen, bevor sie existieren.
Dein Spiel funktioniert dann aber erst, wenn du die Max-Anzahl auf 999999 hochgedreht hast.
Klick mal auf ein Chipset oder ein CE in der Database mit Rechtsklick drauf.Zitat:
Zitat von CapSeb
Da steht dann erstmal Copy, Paste und Clear und darunter Multicopy. Mutlicopy is das was du brauchst, du musst nur EINMAL Multicopy machen und hast damit ALLE CEs kopiert (oder alle Chipsets etc)
Kuckstu: http://dhan.de/multi.png
Das mit dem Multicopy ist mir auch neu, wie praktisch^^
Das "Dumme" ist eigentlich nur, dass alle Variablennamen futsch sind.. oder gibt's da 'ne Möglichkeit die mit rüberzubringen, ohne alle einzeln zu kopieren?
Du könntest die erste und die letzten Variable benennen (also sagen wir, du willst die Variablennamen 1-1000 beibehalten, dann würdest du den Namen der ersten und den Namen der tausendsten kopieren und in 1 und 1000 einsetzen)
Anschließend öffnest du den Texteditor, öffnest in ihm die Datenbankdatei des alten Projekts, suchst nach dem ersten Variablennamen und markierst den ganzen Text vom ersten Variablennamen bis zum Namen der tausendsten und kopierst ihn, anschließend öffnest du die Datenbank vom neuen, markierst das gleiche, löschst es und fpgst das von der alten ein
Allerdings, ich kenne nicht den Aufbau der Datenbank, ist riskant, ich weiß net, ob man so was kaputtmache kann, d.h. leg auf jeden Fall nen Backup an und wenn es klappt und du mit dem Projekt arbeitest, mach öfters nochmal Backups, könnte ja sein, dass ein Fehler erst später seinen Schaden zeigt
Move Picture geht leider nicht. Man kann zwar den Befehl an sich ersetzen, allerdings nur mit der Dauer von 0.0s. Denn: Bei "Show Picture" kann man ja den Haken bei "Move with Map" reinmachen (...oder wie man das nennt). Ohne Haken, "klebt" das Picture sozusagen am Bildschirm und verschiebt sich dadurch beim Scrollen mit der Map - schlecht. Aber mit dem Haken bezieht sich das Bild bei "Move Event" nicht auf die Koordinaten der Map, sondern auf die vorherige Position. "MovePicture to x=217, y=304" heißt also nicht zur Position (217|304), sondern 217 nach rechts und 304 nach unten bewegen - also irgendwo hin. Wenn ich die ganze Programmierung jetzt auf dieses System umstelle, bezieht sich die Bewegung nicht mehr auf das Koordinatensystem und damit nicht mehr auf die Map, wodurch es manchmal zu merkwürdigen Versetzungen kommt. Ich steh da also an manchen Stellen noch auf dem Schlauch.Zitat:
Zitat von Ryo Saeba 1000:
Naja, also schwierig ist die Berechnung nicht (vielleicht muss man die Zwischenschritte auch gar nicht berechnen o.o man kann doch mit Move Picture Befehlen arbeiten, um eine flüssige Bewegung zu erzeugen?) Aber das kommt natürlich auch auf dein Spiel an.. womöglich ist die Vektorgeschichte die bessere Lösung.
Du meinst also: runtersetzen, scripten, scripten, scripten, hochsetzen, spielen?Zitat:
Zitat von Ryo Saeba 1000:
Du kannst den kompletten Code um sie später anzusprechen aber schon coden, ohne ihn dann theoretisch noch verändern zu müssen, bevor sie existieren.
§doofZitat:
Zitat von Dhan:
Da steht dann erstmal Copy, Paste und Clear und darunter Multicopy.
Das heißt CEs und Chipsets gehen schon mal reibungslos.
Das hieße dann zusammengefasst:Zitat:
Zitat von Dhan:
Anschließend öffnest du den Texteditor, öffnest in ihm die Datenbankdatei des alten Projekts, suchst nach dem ersten Variablennamen und markierst den ganzen Text vom ersten Variablennamen bis zum Namen der tausendsten und kopierst ihn, anschließend öffnest du die Datenbank vom neuen, markierst das gleiche, löschst es und fügst das von der alten ein.
1. Neues Projekt (=Pr2) erstellen
2a. Commom Events aus eigentlichem Spiel (=Pr1) nach Pr2 kopieren
2b. Chipset-Einstellungen von Pr1 nach Pr2 kopieren
2c. Erste und letzte benannte Variable von Pr1 nach Pr2 kopieren
3. Bereich zwischen erster und letzter benannter Variable aus Database-Pr1 nach Database-Pr2 kopieren
4. Backup nicht vergessen
5. Database-Pr1 durch Database-Pr2 ersetzen
Fragen:
- Wenn ich auf "Move Picture" umstelle, was könnte es für Methoden geben, dass die Versetzungen vermieden werden?
- Hab ich "Ryo Saeba 1000" richtig verstanden?
- Stimmt die "Dhan-Zusammenfassung"?
- ...wie ist die "RTP_RT.ldb" aufgebaut?
Runtersetzen? Hast du keine Sicherheitskopie mehr von deinem Spiel, bevor du die Anzahl hochgesetzt hast? Runtersetzen ist dann nähmlich nicht nötig (wenn's 5h dauert, wär's auch 'nen echter Geduldstest)Zitat:
Du meinst also: runtersetzen, scripten, scripten, scripten, hochsetzen, spielen?
Aber ansonsten.. ja, genau so^^
Also wie du siehst, alles andere als eine Optimallösung, nimm am besten Dhan's Vorschlag. Der scheint mir etwas flexibler.
Also um mal noch ein paar Fragen zum Schluss zu beachten:
Was mich hier erst noch interessieren würde: geh ich richtig in der Annahme, dass du pixelgenaue Bewegungen verwendest, da du die Fahrzeuge ja als Pictures darstellst?Zitat:
- Wenn ich auf "Move Picture" umstelle, was könnte es für Methoden geben, dass die Versetzungen vermieden werden?
Jap.Zitat:
- Hab ich "Ryo Saeba 1000" richtig verstanden?
Das wird dir Dhan sicher sagen^.^Zitat:
- Stimmt die "Dhan-Zusammenfassung"?
Das würd ich allerdings auch gerne wissen.Zitat:
- ...wie ist die "RTP_RT.ldb" aufgebaut?
Tja, das is wieder so eine Sache, die ich am Maker nech mag, man kann keine relativen Angaben ins sowas wie Move Picture eintragen, in Graal ging das ^^
Ohne Vektorenvariablen funzt das nech, die Scenewerte des neuen Ortes MÜSSEN vorher errechnet werden.
Wie die Datenbank aufgebaut ist, weiß ich net genau aber das, was der Entwickler reinschreibt, also Variablennamen, Itemnamen, was bei einem Zauber im Standard KS als Text auftaucht etc steht direkt als Text in der Datenbankdatei (ansonsten ganz viele Kästchen die für verschiedenstes stehen können, das יהוה in meiner Sig wird da auch als 4 Kästchen angezeigt)
aber ich nehm ma an, die Variablennamen sind direkt nachfolgend aneinander, deshalb sagte ich ja, erste und tausendste benennen
Die Zusammenfassung stimmt so, nur der Texteditor is halt nech erwähnt, als Neueinsteiger in das Thema könnte ma das net verstehen aber wenn du es weißt, passts ja
Und nochmal, besonders auf das Backup größten Wert legen. Wenn du mit dem Texteditor in der Datenbank rumbastelst können eventuell Fehler auftreten, ich hab bisher so ein Experiment noch nicht erlebt, weiß also nicht, ob wirklich welche auftreten aber gerade deshalb immer auf Nummer sicher gehn
Einen Texteditor zu verwenden ist keine gute Idee, da in der Datenbank viele Steuerzeichen enthalten sind, die jeder Texteditor anders interpretieren würde. Da viele dieser Zeichen keine grafischen Symbole besitzen, welche sie repräsentieren, benutzt ein Texteditor in dem Fall Standardzeichen, was die Ausgabe selbstverständlich verfälschen würde.
Viel eher würde ich zu einem Hex Editor raten, um die Bytes korrekt einzulesen.
Generell ist eine "Tabelle" in der Maker DB folgendermaßen aufgebaut:
IDderTabelle AnzDerFolgendenBytes Inhalt
Für die Variablenmanagement Tabelle sieht das ganze noch so aus:
IDderTabelle AnzDerFolgendenBytes AnzVariablen Variablendeklarationen
(die IDderTabelle für das Variablenmanagement lautet 18, für Switches 17)
Eine Variablendeklaration ist dann auch wieder aufgeteilt in Variablennummer, einem Wert den ich bisher noch nicht entschlüsseln konnte(optional), einer Angabe, wieviele Zeichen für den Namen folgen(optional), den einzelnen Zeichen des Namens selbst(optional) und einem abschließenden NIL.
Die mit (optional) gekennzeichneten Angaben sind nur enthalten, sofern der Variablen ein Name zugeteilt wurde .
100%ig genau hab ich den Aufbau aber nichtmehr im Kopf, da müsste ich nochmal in meinen Unterlagen nachschauen, sofern ich sie wieder finde.
Witzig ist noch der Umstand, dass ein Byte nicht von 00 bis FF hochzählt. Stattdessen wird ab erreichen von 80 ein neues Byte vorangestellt, welches nicht mit 00, sondern mit 81 beginnt. Das andere Byte wird auf 00 zurückgesetzt.
81 kann allerdings nicht einfach mit dem anderen Byte addiert bzw. multipliziert werden, sondern muss folgendermaßen errechnet werden: 80 * 1 = 80. Der daraus resultierende Wert kann dann mit dem anderen Byte addiert werden und man erhält den eigentlichen Wert, den diese zwei Bytes zusammen repräsentieren.
Erreicht das zweite Byte wiederum den Wert 80, so wird das erste auf 82 erhöht. Die Berechnung sieht dann folgendermaßen aus: 80 * 2 = 100. Das Ergebnis wird wieder mit dem zweiten Byte addiert.
So geht das dann ne ganze Weile weiter, ich hatte an der Stelle damals auch schluss gemacht und nicht weiter getestet.
Es kann sein, dass es bei noch größeren Werten zu weiteren Besonderheiten kommt.
Wichtig ist eben, dass man nicht einfach mal ein paar Variablen aus der DB rauslöschen, hinzufügen oder umbenennen kann, sondern zusätzlich immer noch die Anzahl an Bytes pro Variable und für die gesamte Tabelle zählen und angeben muss. Diese kann man dann aber nicht einfach so eintragen, sondern muss sie erst noch in ein merkwürdig anmutendes System umrechnen.
(Es sei nochmal darauf hingewiesen, dass aller Werte hier im Hexadezimalsystem angegeben sind, auch bei Berechnungen.)
Leider nicht. Hätte ich eine, könnte ich fürs Testen das Spiel einfach kopieren und dort die Variablen hochsetzen...Zitat:
Zitat von Ryo Saeba 1000:
Hast du keine Sicherheitskopie mehr von deinem Spiel, bevor du die Anzahl hochgesetzt hast?
Genau. Sonst wär das ganze auch ein wenig eckig...Zitat:
Zitat von Ryo Saeba 1000:
geh ich richtig in der Annahme, dass du pixelgenaue Bewegungen verwendest, da du die Fahrzeuge ja als Pictures darstellst?
Hilfe. Ich probiers einfach mal aus, ansonsen gilt Folgendes: Finger weg.Zitat:
Zitat von Gekiganger
Es kann sein, dass es bei noch größeren Werten zu weiteren Besonderheiten kommt.
Eh, wo gibts nen gutes "Hexadezimal-umschreibe-Ding"?
Hallo erstmal, ich bin der Neue...
Ich hab` mir mal Dein Problem durchgelesen, schon mal daran gedacht, die KI-Werte (=Werte der Variablen) in einem Event zu speichern und bei Streckenauswahl einfach laden zu lassen?
Dadurch bräuchtest Du pro Strecke ja schließlich nur noch 240000... (mal 2)
Ist ja schon mal ein Anfang.
Theoretisch könntest Du mit Hilfe von Sprungmarken (=Labels) in diesem Event die Anzahl noch mal reduzieren.
Du unterteilst die Strecke einfach in mehrere Teilabschnitte und jeder diese Abschnitte bekommt ein Label(=Sprungmarke), wat weiß ich, alle 30 sec.
nach diesen 30 sec. einfach "go to label XX" und die Daten der Variablen werden geändert...
Zumindest theoretisch hättest Du dadurch die Variablen für die KI auf 600 in diesem Beispiel reduziert...Was in meinen Augen schon mal ein Schritt in die richtige Richtung wäre...
Die Daten des Spielers (=240000 Variablen) sind da ein bißchen komplizierter und im Moment fällt mir leider kein Weg ein diese effektiv zu reduzieren, kommt vielleicht noch...
Ich habe den DF HEXEditor verwendet, er ist schön schlank und reicht völlig aus. Parallel dazu habe ich mit dem Windows Taschenrechner immer mal wieder die Hex-Werte in das (verständlichere) Dezimalsystem umgewandelt.Zitat:
Zitat von CapSeb
Habe mich übrigens nochmal mit dem Thema auseinandergesetzt und nun auch das Zählsystem durchschaut. Es ist mir nun möglich, händisch in der DB beliebig viele Switches und Variablen anzulegen/ zu löschen und deren Namen zu ändern. Bis morgen sollte auch ein Programm stehen, welches dies automatisch verarbeitet. Wenn du mir also die DB via www.rapidshare.de zukommen lassen könntest, könnte ich dir dann die Anzahl der Variablen auf einen von dir gewünschten Wert bringen.
Dann hätte ich vielleicht eine Idee zu deinem Move Picture Problem (auch wenn's jetzt nicht direkt zum Thema gehört):Zitat:
Zitat von CapSeb
Du könntest die gesamte Umgebungsgrafik auch als Picture anzeigen lassen, und einfach die anderen Fahrzeuge und die Umgebung um den Spieler bewegen.
So hast du pixelgenaues Scrolling und befindest dich immer auf derselben Stelle auf der eigentlichen Map, während sich die Picturestrecke und die anderen Fahrzeuge pixelgenau um dich herum (mit Move Picture) bequem bewegen lassen dürften.
Ich glaube, du hast das Problem leider nicht ganz verstanden: Jede Variable kann nur einmal belegt werden und es müssen alle Geister gleichzeitig dargestellt werden können. Also, beschreib das Grundprinzip bitte noch einmal, vielleicht ist an der Idee ja doch was dran. :rolleyes:Zitat:
Zitat von White Knight
Erstmal danke für den Link. Das Schicken würde mir allerdings nicht viel bringen, denn stattdessen könnte ich auch genausogut fünf Stunden warten (...aber das hätte ich mittlerweile sowieso schon machen können). Es geht ja vielmehr darum schnell und ohne weiteren Aufwand die Variablen runter zu setzen. Wenn es dann tatsächlich ein selbstständiges Runtersetz-Programm gäbe, wäre das natürlich etwas anderes...Zitat:
Zitat von Gekiganger
Die Idee hatte ich auch schon, aber ich muss dich enttäuschen: Das ganze Spiel besitzt auch noch einen Multiplayermodus, bei dem bis zu vier Spieler auf einem Bildschirm (ohne Splitsreen) fahren. Bahn bewegen geht also nicht. Trotzdem weiter Ideen posten. Vielleicht ist ja mal was dabei, das zu meiner Technik passt.Zitat:
Zitat von Ryo Saeba 1000
Wieso sollte das nicht gehen? Die Frage ist zwar natürlich wie du das lösen willst, wenn sich die Spieler weiter als eine "Screenlänge" voneinander wegbewegen, aber ich nehme mal an, du willst es wie bei Micro Machines machen?Zitat:
Zitat von CapSeb
Dann würde ich dir diese Methode umso vehementer empfehlen, denn durch das pixelgenaue Scrolling der Strecke, kannst du das einfacher darstellen, als wenn du in Tilegrößen von 16 Pixeln scrollst. Besonders wenn du die Geschwindigkeiten der Fahrzeuge diffizil unterscheiden willst, ist es sehr praktisch, wenn du den sichtbaren Streckenbereich ebenso diffizil bestimmen kannst.
Du bewegst im Multiplayer also am besten alle Fahrzeuge und Strecke pixelgenau zueinander, indem du alles mit Pictures darstellst, ich sehe also ehrlichgesagt nicht, warum das nicht funktionieren sollte oO
Ja, das stimmt soweit...
Müsste ich dann alles halt umstellen. Zudem: Wie schafft man es am Einfachsten, dass die Kollision mit den Wänden funktioniert?
Weitere Ideen?
Wie siehts mit dem Runtersetzprogramm aus?
Terrain ID abforken, wenn ein neues Feld (Tile) betreten werden soll.Zitat:
Zitat von CapSeb
Bei Wänden einfach ne bestimmte Terrain ID festlegen, bei der dann der Code für die Kollision aufgerufen wird.
Das gleiche geht auch mit Event-ID's (die Events siehst du zwar nicht mehr, wenn du alles mit Pictures darstellst, aber nutzen kannst du sie theoretisch immer noch).
Achja, hab ich schon erwähnt, dass du dir da wirklich einen Haufen Arbeit aufgehalst hast? Pixelgenaue Systeme sind wirklich so ziemlich das schwierigste am RPG Maker. Respekt, falls du es zu einer gut spielbaren Veröffentlichung bringst ^_-
Wenn die gesamte Map n Picture ist, ist es UNMÖGLICH diese mit "Mauern" zu bephlastern, ohne dass man weitere Variablen abfragen müsste. Und genau das will CapSeb ja verhindern...