5 Stunden zum Variablen löschen

In der "Maker's Mind" gab es mal einen Bericht wie man mit Hilfe des "Resource Hackers" die maximale Variablenanzahl des RPG-Makers auf über 5000 stellen kann - um genau zu sein auf 999.999 Variablen. Für mein Spiel ist eine solche Datenmenge auch notwendig, allerdings muss ich bei jedem Ändern der Database (OK, Apply, Exit) zehn Sekunden warten bis die Datenbank und die Variablen aktualisiert sind. Also wollt ich die maximalen Variablen während des Rumprogrammierens zwischenzeitlich wieder runterschrauben. Dummerweise hängt sich der PC dabei auf. Durch testen hab ich dann erfahren, dass selbst das Löschen (oder Verringern) von 1000 Variablen einige Sekunden in Anspruch nimmt und das Löschen der 999.999 Variablen umgerechnet fünf Stunden dauert würde.

---> Fazit: Das Warten beim Database schließen ist besser als fünf Stunden warten.


Frage 1: Kennt jetzt jemand eine Möglichkeit die Variablen schneller zu reduzieren (durch Dateiinhalte löschen oder sowas)?

Frage 2: Ist es überhaupt erlaubt das Variablenmaximum zu erhöhen, da der Resource Hacker benutzt wird?

Zu Frage 1: Du könntest das Problem vielleicht so lösen, das du den RPGMaker deinstallierst und dann wieder neuinstallieren...
Dein Projekt solltest du natürlich sichern.
Es könnte aber auch darauf ankommen welche Datei du mit dem Ressource Hacker verändert hast. Falls es die Datei RTP_RT.exe ist könntest du einfach ein neues Projekt machen und die RTP_RT.exe Datei kopieren und die "gehackte" Datei löschen und dafür die "normale" Datei einfügen.

Zu Frage 2: Ich glaube nicht das es verboten ist, wenn man bedenkt das man den RPGMaker nur noch illegal im Internet bekommen kann.

Du bekommst ihn auch legal!!

Zitat:

---

Zitat von CapSeb

Frage 1: Kennt jetzt jemand eine Möglichkeit die Variablen schneller zu reduzieren (durch Dateiinhalte löschen oder sowas)?

---

Das ist normal. Ich hab nen 2 GHz-PC und bei mir dauerts schon ne gute Sekunde, wenn der Maker die normale Maximalgrenze von 5000 Variablen aktualisiert. Ergo gibt es wohl keine Lösung. Nur, dass du dir nen schnelleren PC zulegst.

EDIT: Du kannst natürlich auch erstmal einfach nur die 999999 Variablen auf 10000 runterstellen, dann wirds auch schneller geladen. Je weniger Variablen desto schneller lädt er. Hast du nur eine Variable lädt's ruckzuck, hast du ne Mio. dauerts halt. Noch dazu: Du brauchst wirklich eine Million Variablen? Du musst ja was absolut riesiges vorhaben ;)

Zitat:

---

Frage 2: Ist es überhaupt erlaubt das Variablenmaximum zu erhöhen, da der Resource Hacker benutzt wird?

---

Ja, ist es, solange du dein Spiel damit nicht unspielbar machst, weil du zum Beispiel deine Ressourcen nicht ordentlich über die Importier-Funktion importierst.
Soll heissen: Solange du lediglich das Maximum hochstellst und das Spiel somit auch auf anderen Rechnern spiebar bleibt, solltest du keine Probleme haben, es hier auch online stellen zu können (vorher natürlich austesten, obs auf anderen Rechnern läuft).


EDIT: In welcher MakersMind stand das drin? Haste noch zufällig nen Link dazu? Ich bräuchte das doch auch dringend, zwecks der maximalen Picture-Anzahl *husthust*

EDIT: @Luki: Mist :\
Naja, dann hat sich das auch erledigt ;_;

maximale Pics kannst du zwar mit dem Maker hochstellen, machst damit aber das Spiel unspielbar, weil fuer die Pics kein Speicher alloziiert wird.

Zitat:

---

Zitat von CapSeb

- um genau zu sein auf 999.999 Variablen. Für mein Spiel ist eine solche Datenmenge auch notwendig,

---

JAHAHAHAHAHA XDDDDD
Spinn nicht rum, so viel wird niemand jemals brauchen und wenn doch soltest du dir mal Gedanken über deine Arbeitsweise machen.

Was wird denn das fürn extravagantes Project?
Ein nrmales RPG jedenfalls nicht.

Zitat:

---

Was wird denn das fürn extravagantes Project?
Ein normales RPG jedenfalls nicht.

---

Ich hab nicht vor 999.999 Variablen für geschichtliches zu verwenden. Es geht um ein Rennspiel mit Geisterdaten, die für jede Sekunde Replay 20 Bilder und damit 40 Variablen brauchen (x- und y-Achse). Bei 40 Geistern/Stecken mit je maximal sechs Minuten komm ich auf 960.000 Variablen... :D

Zitat:

---

Du könntest das Problem vielleicht so lösen, das du den RPGMaker deinstallierst und dann wieder neuinstallieren...
Dein Projekt solltest du natürlich sichern.
Es könnte aber auch darauf ankommen welche Datei du mit dem Ressource Hacker verändert hast. Falls es die Datei RTP_RT.exe ist könntest du einfach ein neues Projekt machen und die RTP_RT.exe Datei kopieren und die "gehackte" Datei löschen und dafür die "normale" Datei einfügen.

---

Wenn ich das Variablenmaximum erhöhe, gibt es nicht nur die theoretische Möglichkeit 999.999 Variablen zu benutzen, sondern es werden tatsächlich 999.999 Variablen angelegt - eben mit dem Wert null. Das Ganze steht jetzt dummerweise in der Datei "RPG_RT.ldb" des Projektes, in der quasi das komplette Spiel steckt. Datei ersetzen geht also nicht.

Hat denn jemand eine Idee, welcher Inhalt der Datei gelöscht/verändert werden muss, um wieder auf 5000 Variablen zu kommen?

Ja. Öffne das Spiel im Maker, mach ein neues Event oder benutz n Common Event, dann irgendwas, womit du die Variablen ändern kannst (z.B. den Befhel Set Variable) und dann setzt du das Maximum von 999999 auf 5000 und fertig o.o

Ansosnten kannst du natürlich nochmal den Ressource Hacker benutzen und die Variablen auf 5000 zurücksetzen.

Zitat:

---

Zitat von CapSeb

Ich hab nicht vor 999.999 Variablen für geschichtliches zu verwenden. Es geht um ein Rennspiel mit Geisterdaten, die für jede Sekunde Replay 20 Bilder und damit 40 Variablen brauchen (x- und y-Achse). Bei 40 Geistern/Stecken mit je maximal sechs Minuten komm ich auf 960.000 Variablen... :D

---

Führ das mal näher aus, ich kapier nech genau, wieso du jede Variable nur einmal benutzen kannst

Zitat:

---

V-King:
Öffne das Spiel im Maker, mach ein neues Event oder benutz n Common Event, dann irgendwas, womit du die Variablen ändern kannst (z.B. den Befehl Set Variable) und dann setzt du das Maximum von 999999 auf 5000 und fertig o.o

---

Sorry, aber ich möchte wissen, wie man es in weniger als fünf Stunden -also in einer Minute- schafft und nicht wie man den Maker bedient.

Zitat:

---

Dhan:
Führ das mal näher aus, ich kapier nech genau, wieso du jede Variable nur einmal benutzen kannst

---

Mein Spiel soll aus 20 Bahnen bestehen, auf denen man unter Anderem auch Streckenrekorde aufstellen kann. Nun besitzt jede Bahn einen von mir vorgegeben Entwickler-Geist (Ein Abbild eines früheren Autos wie z.B. in Mario Kart) den man schlagen muss und zusätzlich den besten eigenen Geist, womit man auf 40 Geister kommt. Es ist vorgesehen, dass man für jede Bahn maximal 300 Sekunden braucht. Das macht insgesamt 12.000 Sekunden oder 120.000 Zehntel. Ein Bild wird jede zwanzigstel Sekunde dargestellt wodurch 240.000 Bilder entstehen. Da jetzt jede Bildposition aus drei Informationen besteht, nämlich x-Achse, y-Achse und Ausrichtung kommt man auf die sagenumwogenen 960.000 Variablen.
Das ganze muss jetzt in verschiedenen Variablen gespeichert werden, damit jeder Geist zu jeder Zeit verfügbar ist - wie eine Highscoreliste eben.

Aber die Frage steht immer noch: Wie schaffe ich es zwischendurch mal eben das Variablenmaximum wieder herunter zu setzen?
Oder anders gefragt: Wie ist die Datei "RTP_RT.ldb" aufgebaut und wie kann ich nur die Variablen löschen?

...also du willsts so machen, dass man, wenn die strecke neu
ist man gegen den computer geist fährt, und
wenn man den besiegt hat, gegen seinen eigenen geist...
hm... wenn du nur 20 strecken hast...
dann komm ich aber auch nur auf die hälfte...O.O
denn warum sollten die com-geister daten nicht überschrieben
werden, wenn man gewonnen hat???
und wenn man die eigenen geister löschen will,
kann man die ja wieder auf die com-geister setzen..

mfg
üH

und warum willst du wirklich jede 20stel sekunde speichern???
reicht es nicht aus, wenn du die koordinaten von jeder sec speicherst
und das da zwischen bisschen interpretierst???

Soll das bedeuten, du versuchst, mit Variablen eine KI zu ersetzen? Du brauchst doch wohl net mehr als x,y, dir und ein zwei andere Varis pro Geist?

Zitat:

---

Zitat von Dhan

Soll das bedeuten, du versuchst, mit Variablen eine KI zu ersetzen? Du brauchst doch wohl net mehr als x,y, dir und ein zwei andere Varis pro Geist?

---

Nein, denn den vorgegebenen "Programmierergeist" könnte man zwar über eine KI abspielen lassen, aber ich glaube eher, dass er da seine eigens erfahrene Bestzeit einbringen möchte.
Für den normalen Geist, der die Bestzeit des Spielers verkörpert, fällt eine KI sowieso flach.

Das Problem besteht einfach darin, die ganzen Informationen während des Spielens zu speichern, um diese dann wieder "on the fly" ^^'auswerten zu können.
Da man die Langsamkeit des RPG Makers bei dieser Variablenanzahl kaum umgehen kann, sollte man lieber wie Dhan es bestimmt vorhatte, das Problem bei der Wurzel packen und einfach versuchen weniger Variablen zu verbrauchen, denn mit geschickter Nutzung der vorhandenen Ressourcen kommt man bestimmt mit weit weniger Variablen aus.

Meine Idee wäre:
-die Position x und y und die Richtung (8 Unterscheidungen (Himmelsrichtungen) nehme ich als Bsp. an) in einer einzigen Variable speichern (rm2k3 bietet ja siebenstellige Varis, wenn man nun alle Stellen ausnutzt, hat man für die Koordinaten zB. jeweils die Möglichkeit von 0-999 zu unterscheiden, was bis zu einer Mapgröße von 62x62 (1000/16) gehen dürfte)
-> 960000/3 = 320000
-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)
-> 320000/10 = 32000

zwar immer noch recht viel, aber der RPG Maker dürfte nicht mehr total den Dienst verweigern

Moment, hab ichs jetz richtig verstanden, die Geister sind also quasi ein Replay der besten Zeiten, die bisher erzielt wurden und brauchen daher eine genaue Route?
D.h. du setzt einfach jede Sekunde eine Zeiger-Variable höher die dann zu einer immer neuen Variable führt? Hummmm.... wenn sowas unbedingt sein muss, ich halts für übertrieben, dann speicher doch net in "Pixelbewegung" sondern in Vektoren, das spart schoma extrem unter Umständen
Vor allem brauchst du für x/y nur den Startwert, der Rest errechnet sich dann ja. Direktion und Vektorlänge speicherst du in einer einzigen Variable und wenn der Geist lange Strecken gerade fährt, spart das massig Varis

Zitat:

---

wenn sowas unbedingt sein muss, ich halts für übertrieben, dann speicher doch net in "Pixelbewegung" sondern in Vektoren

---

Wenn man nur zB. 8 Richtungen zur Verfügung hat, in die man sich bewegen kann, dann ist die Idee wirklich nicht schlecht^.^
nur Sorgen mache ich mir um die Geschwindigkeit, wie lässt sich die Beschleunigung mit einem Vektor darstellen? (nehmen wir an, man beschleunigt nichtlinear über einen doch recht großen Zeitraum -> lange Gerade)

Zitat:

---

Zitat von Ryo Saeba 1000

Wenn man nur zB. 8 Richtungen zur Verfügung hat, in die man sich bewegen kann, dann ist die Idee wirklich nicht schlecht^.^
nur Sorgen mache ich mir um die Geschwindigkeit, wie lässt sich die Beschleunigung mit einem Vektor darstellen? (nehmen wir an, man beschleunigt nichtlinear über einen doch recht großen Zeitraum -> lange Gerade)

---

kk, dann eben noch a(ccelaratio) in die var, ich glaub, auch damit müssts noch passen, muss ma halt einen Vektor in mehrere machen wenn innerhalb von ihm unterschiedlich beschleunigt wurde (aber in nem Rennspiel is ma doch meist eh Bleifuss), v brauchs mit a ja nech da man weiß, über welche Strecke a angewandt wurde, lässt sich das errechnen. (falls Cap das net weiß, kA wie weit der Kinetik kennt: a = vt und s=0,5at², aus den Formeln bekommst v raus wenn du a und s kennst wenn du nach t auflöst)

Um zu wissen, wie man die Variablenanzahl verringern kann, müsse man doch wohl erst ma wissen, wie du die geister überhaubt steuerst. (D.h wie und in welche Richtung sie wann fahren)

Zitat:

---

übelster Held:
wenn du nur 20 strecken hast... dann komm ich aber auch nur auf die hälfte...O.O denn warum sollten die com-geister daten nicht überschrieben
werden, wenn man gewonnen hat??? und wenn man die eigenen geister löschen will, kann man die ja wieder auf die com-geister setzen..

---

Das Problem bei der ganzen Sache ist, dass ich die Entwickler-Geister ja nicht mit der Hand eingeben kann (480.000 Variablen... ). Das heißt, ich muss meine Replays - genauso wie später die Spieler es machen - speichern lassen, nur eben in die anderen 480.000 Variablen. Die Variablen sind dann allerdings in der Save-Datei gespeichert und man kann sie deshalb nur über "Laden" im Titlescreen erreichen. Dashalb soll der Titelbildschirm die Drei Menüpunkte "Hilfe" (statt "Beginnen"), "Spielen" und "Beenden" erhalten. Um unter "Spielen" einen Speicherpunkt zu haben, bei dem das Spiel neu beginnt, kann man diesen von einem geladenen Spiel aus erstellen. Dieses Erstellen geht durch einen Menüpunkt im eigenen Menü. Im Grunde ist es das Gleiche wie normal speichern, nur dass direkt vor dem Speichen alles bis auf die Entwickler-Geister gelöscht wird, man speichert und dann zum Storyanfang teleportiert wird, wo das Spiel dann beginnt. Lädt man diesen Speicherpunkt beginnt das Spiel ganz normal - mit dem Unterschied, dass die Entwickler-Geister existieren. :)

Zitat:

---

Ryo Saeba 1000:
Meine Idee wäre die Position x und y und die Richtung (8 Unterscheidungen(Himmelsrichtungen) nehme ich als Bsp. an) in einer einzigen Variable speichern (rm2k3 bietet ja siebenstellige Varis, wenn man nun alle Stellen ausnutzt, hat man für die Koordinaten zB. jeweils die Möglichkeit von 0-999 zu unterscheiden, was bis zu einer Mapgröße von 62x62 (1000/16) gehen dürfte)
-> 960000/3 = 320000

---

Die Idee finde ich nicht schlecht. Allerdings benutze ich den "RPG Maker 2000" und der Gleiter besitzt 20 Richtungen (soll flüssig aussehen). Das heißt ich hätte nur 4 Stellen für die Koordinaten... Man könnte aber die x- und y-Achse zusammenschmeißen unter der Bedingung, dass die Map nicht größer als 64x64 Kästchen ist oder zumindest nicht mehr als ein 64 Felder großes Quadrat benutzt wird, da ich den Rand der Map eh nicht benutzten kann. Wenn ich größere Maps machen möchte, gäbe es immernoch die Notlösung eine Varible mit der x- Koordinate und dem Richtungs-Zehner zu bestücken und eine andere mit der y-Achse und dem Richtungs-Einer. Dann könnte ich durch die fünfstelligen Koordinaten 640 Felder große Maps bauen... Insgesamt spare ich dadurch 1/3 der Varibalen und käme auf 640.000 Variablen.
Also, auf jeden Fall vielen Dank für die Idee!

Zitat:

---

Dhan:
dann speicher doch net in "Pixelbewegung" sondern in Vektoren, das spart schoma extrem unter Umständen
Vor allem brauchst du für x/y nur den Startwert, der Rest errechnet sich dann ja. Direktion und Vektorlänge speicherst du in einer einzigen Variable und wenn der Geist lange Strecken gerade fährt, spart das massig Vari

---

Ich kann leider nicht darauf setzten, dass der Spieler lange Strecken geradeausfährt, denn jeder Geist belegt momentan 24.000 Variablen und damit 400s. Lange, gerade Strecken würden dann nur bedeuten, dass mehr als 400s zur Verfügung stehen, was nicht wirklich etwas bringt.
Statt der Pixel die Vektoren zu speichern, ist im Grunde eine Lösung, auf die ich schon gleich hätte kommen müssen. Denn im Gegensatz zu der "Aufnahme" der Fahrt durch das Speichern der Pixel, sind die Vektoren eine "Wiederholung" der Fahrt. Die ganze Physik basiert nämlich auf solchen Vektoren die nicht ganz der beschleunigten Bewegung oder Trägheit gehorchen. Dadurch ist diagonal fahren z.B. schneller, weil die x- und y-Richtung sich gegenseitig nicht beeinträchtigen.
Auch hier, vielen Dank für die Idee!

Leider löst das ganze aber nicht mein Problem. Deswegen: Wer weiß, ...

- ...ob das ganze funktioniert? :D
- ...welche Dateiinhalte der "RTP_RT.ldb" ich löschen muss, um mein 5-Stunden-Problem zu lösen?
- ...ob ihr meinen Text überhaupt gelesen habt...

Zitat:

---

- ...welche Dateiinhalte der "RTP_RT.ldb" ich löschen muss, um mein 5-Stunden-Problem zu lösen?

---

Dann schreibe doch ganz einfach dem Ineluki ne PN.
Der müsste sich doch mit "sowas" (RTP_RT.ldb) ausgennen.

Die Variablen müssten in der Datenbank gespeichert sein. (weiß ich jetz net weil ichs nie gehabt hab das Problem)
Leg doch ein neues Projekt an, kopiere alles aus der Datenbank außer die Variablen versteht sich und ersetze die Datenbank des alten Projekt mit der des neuen (Backup der alten Datenbank nicht vergessen)
Dauert halt ein bißchen weil man für jede Datenbankseite zwischen den Projekten herspringen muss (mit Copy All zum Glück nur einmal pro Seite) aber wohl keine 5 Stunden ^^

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?

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)

---

Ist dir dass zu ungenau, oder hast du schon mit ca. 64000 Variablen getestet und es für unzureichend befunden?

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?

Zitat:

---

Zitat von CapSeb

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.

---

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:

---

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?

---

Oh, ich glaub da hast du mich falsch verstanden (ich hab mich auch etwas doof ausgedrückt, ich bin nicht besonders im Erklären^^').
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.

Zitat:

---

Zitat von CapSeb

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?

---

Klick mal auf ein Chipset oder ein CE in der Database mit Rechtsklick drauf.
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

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.

---

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:
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.

---

Du meinst also: runtersetzen, scripten, scripten, scripten, hochsetzen, spielen?

Zitat:

---

Zitat von Dhan:
Da steht dann erstmal Copy, Paste und Clear und darunter Multicopy.

---

§doof
Das heißt CEs und Chipsets gehen schon mal reibungslos.

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.

---

Das hieße dann zusammengefasst:
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?

Zitat:

---

Du meinst also: runtersetzen, scripten, scripten, scripten, hochsetzen, spielen?

---

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)
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:

Zitat:

---

- Wenn ich auf "Move Picture" umstelle, was könnte es für Methoden geben, dass die Versetzungen vermieden werden?

---

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:

---

- Hab ich "Ryo Saeba 1000" richtig verstanden?

---

Jap.

Zitat:

---

- Stimmt die "Dhan-Zusammenfassung"?

---

Das wird dir Dhan sicher sagen^.^

Zitat:

---

- ...wie ist die "RTP_RT.ldb" aufgebaut?

---

Das würd ich allerdings auch gerne wissen.

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.)

Zitat:

---

Zitat von Ryo Saeba 1000:
Hast du keine Sicherheitskopie mehr von deinem Spiel, bevor du die Anzahl hochgesetzt hast?

---

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:
geh ich richtig in der Annahme, dass du pixelgenaue Bewegungen verwendest, da du die Fahrzeuge ja als Pictures darstellst?

---

Genau. Sonst wär das ganze auch ein wenig eckig...

Zitat:

---

Zitat von Gekiganger
Es kann sein, dass es bei noch größeren Werten zu weiteren Besonderheiten kommt.

---

Hilfe. Ich probiers einfach mal aus, ansonsen gilt Folgendes: Finger weg.


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...

Zitat:

---

Zitat von CapSeb

Hilfe. Ich probiers einfach mal aus, ansonsen gilt Folgendes: Finger weg.
Eh, wo gibts nen gutes "Hexadezimal-umschreibe-Ding"?

---

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.

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.

Zitat:

---

Zitat von CapSeb

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?

---

Genau. Sonst wär das ganze auch ein wenig eckig...

---

Dann hätte ich vielleicht eine Idee zu deinem Move Picture Problem (auch wenn's jetzt nicht direkt zum Thema gehört):
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.

Zitat:

---

Zitat von White Knight

Was in meinen Augen schon mal ein Schritt in die richtige Richtung wäre...

---

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 Gekiganger

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.

---

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 Ryo Saeba 1000

Du könntest die gesamte Umgebungsgrafik auch als Picture anzeigen lassen, und einfach die anderen Fahrzeuge und die Umgebung um den Spieler bewegen.

---

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 CapSeb

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.

---

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?
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?

Zitat:

---

Zitat von CapSeb

Zudem: Wie schafft man es am Einfachsten, dass die Kollision mit den Wänden funktioniert?

---

Terrain ID abforken, wenn ein neues Feld (Tile) betreten werden soll.
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...

@Mr.Hunz: Rrrrrrrichtig!

Zitat:

---

Zitat von Ryo Saeba 1000

Terrain ID abforken, wenn ein neues Feld (Tile) betreten werden soll.

---

Die Tiles gibts bei der Move-Technik nicht mehr...
Aber im Grunde bist du schon auf der richtigen Spur. Denn genau die Technik hab ich angewenden. Dass ich mir Arbeit aufhalse hab ich schon erfahren, denn wenn man sich mal "Battle Versus" hier im Atelier unter "Sonstiges" anguckt, sieht man, dass ich das ganze schon mal hingegriegt hab - nur eben auf einem sehr niedrigen Niveau. Wenn ihr euch das Spiel antut, bitte nicht mit meinem jetzigen Spiel vergleichen - außer dem Kollisionssystem, dass ich beim momentaten Projekt aber auch als Terrain ID laufen lasse.

Zum Kollissions-Problem: Bei einer "One-Picture-Bahn" :rolleyes: hätte man den Vorteil sich nicht auf ein Chipset beschränken zu müssen, sondern könnte frei malen. Soweit ich weiß, kann man ein Picture aber nur bis zu einer gewissen Größe importieren. Zudem entspricht die Bahnposition nicht mehr dem Chipset. Man müsste Die Rennstrecke also drotzdem - wie ein Editor sozusagen - für den Spieler unsichtbar als Chipset erstellen.


Fragen:
- Gibt es eine Größenbeschränkung von Pictures?
- Neue Ideen zum Thema Kollision und Picture?
- Was ist mit dem Variablen-Runtersetzprogramm?

Zitat:

---

Die Tiles gibts bei der Move-Technik nicht mehr...

---

Wieso das? Klar kann man die noch nehmen..
Du kannst sehr wohl Tiles nutzen^^ ich glaube du begehst den Fehler und nimmst an, nur weil sich das Pic des Spielerchars "eigentlich" nur auf demselben Bildschirmausschnitt bewegt, während die anderen Objekte sich um ihn herum bewegen, dass seine Koordinaten dann nicht mehr für die Tileabfragen zu gebrauchen sind..
Aber das ist falsch, du kannst ganz einfach zwei Koordinatenpaare "erstellen". Einmal die Koordinaten im Bildschirmausschnitt und einmal die Koordinaten in Relation zur Gesamtmap, so kannst du die Map normal mappen, mit dem Chipset und musst es dann einfach nur "screenshoten" um ein Map-Picture rauszukriegen.

Gleiches gilt für Events... die kannst du ganz normal auf jeder Position deiner Map platzieren.. und obwohl das Bild des Spielerchars diesen Events "eigentlich" nicht mal nahe kommt, wenn sie nicht auf dem anfänglichen Bildschirmausschnitt des Spielerchars sind, funktioniert die Kollision mit denen problemlos.

Glaub mir, ich habe mir das auch durchdacht.. ich habe selber schon merehre funktionierende Scripte zum Thema Pixelmovement geschrieben.
Die Abfrage der Tiles über die Koordinaten des Pictures, mit dessen relativen Koordinaten auf der Map, ist imho die beste Lösung dafür.

Zitat:

---

- Gibt es eine Größenbeschränkung von Pictures?

---

Ja, die gibt es. 640*480 Pixel dürften das gewesen sein. Aber bevor du jetzt das Handtuch wirfst, es gibt eine Methode diese Grenze zu übergehen. Damit lassen sich dann locker Pics in der Größe von 800*600 oder 1280*1024 importieren. Wie das genau funktioniert, steht in einer Makersmind Ausgabe, du wirst aber sicher auch schnell im Forum fündig, denn das Thema kam schon oft auf. Im Prinzip musste man nachdem man ein klneineres Pic importierte, dieses dann durch das größere ersetzen, aber schlag das lieber nocheinmal nach, ich weiß es nicht mehr genau. Bin mir auch nicht sicher, wie weit man das treiben kann -> ob 1280*1024 das Maximum ist. Außerdem kann man, wenn einem das noch nicht reicht, zur Not auch mehrere Pics verwenden und den Kurs sousagen in mehrere Pictures einteilen.

Zitat:

---

- Neue Ideen zum Thema Kollision und Picture?

---

Wenn du auf die Tilekollision verzichten willst, kannst du sicher noch Kollisionsmasken für den Kurs nehmen. Aber ehrlichgesagt habe ich mir darüber nocht nicht intensiv den Kopf zerbrochen, da man da wieder extrem viele Informationen speichern und während des Spiels abforken müsste. Ich glaube die Tileabfrage ist die praktischere Methode. Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16..

Zitat:

---

Zitat von CapSeb

Man müsste Die Rennstrecke also drotzdem - wie ein Editor sozusagen - für den Spieler unsichtbar als Chipset erstellen.

---

Zitat:

---

Zitat von Ryo Saeba 1000

so kannst du die Map normal mappen, mit dem Chipset und musst es dann einfach nur "screenshoten" um ein Map-Picture rauszukriegen.

---

Ich denke wir meinen da das Gleiche. Das ganze sieht nach einem vernünftigen Pinzip aus. Denächst werde ichs mal testen.

Zitat:

---

Zitat von Ryo Saeba 1000

Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16...

---

Auf welches System beziehst du dich hierbei? Wie sollte man denn die Tiles unterteilen können?

Ich würde, wenn ich Kollisionsmasken machen würde, diese ebenfalls mit der Terrain-ID koppeln

Jede Terrain-ID bekäme eine bestimmte Maske, z.B. bekäme Terrain-ID 5 die Maske "Schräge Fläche die Nordwestlich blockt"
Zuerst wird dann immer abgefragt, welche ID das Tile hat, in dem man sich gerade befindet und dann wird abgefragt, auf welchem Pixel innerhalb des Tiles man sich befindet und wo man hinwill und dann mit der Kollision Mask des Tiles verglichen, ob das möglich ist und ob eine schräge Bewegung möglich wäre
Die Frage is nur, lohnt sich das oder geht man gleich aufn XP wenn man Pixelmovement will

Irgendwie haben wir alle die gleichen Ideen...

Zitat:

---

Zitat von Dhan

bekäme Terrain-ID 5 die Maske "Schräge Fläche die Nordwestlich blockt"

---

So hab ichs gemacht nur eben ohne pixelgenaue Bestimmung. Das brauch man aber auch nicht unbedingt und spart viel Arbeit.

Zitat:

---

Zitat:

---

Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16...

---

Auf welches System beziehst du dich hierbei? Wie sollte man denn die Tiles unterteilen können?

---

Dhan hat eine wunderbare Möglichkeit genannt, so hätte ich's mir auch ungefähr vorgestellt xD
Also um noch mal ein bisl in's Detail zu gehen: ich würde dann bei jedem Durchlauf des "Kollisionsfeststellevents" die Koordinaten des Fahrzeugs einlesen und durch 8 teilen, wenn's nen Rest gibt, dann passiert nix, wenn der Rest Null ist (um herauszufinden ob man gerade dabei ist ein neues Tile, bzw. die zweite Hälfte eines Tiles zu betreten), wird weiter abgeforkt um was es sich für eine Terrain ID bei dem Tile handelt und ob der Held bereits in der Mitte draufsteht oder es erst betritt.

Zitat:

---

Zitat von Dhan

Die Frage is nur, lohnt sich das oder geht man gleich aufn XP wenn man Pixelmovement will

---

Ich zweifle ja immer noch stark daran, dass das mit dem XP besser ist. Gut, mit Ruby kann man die Spielfigur pixelgenau gehen lassen, aber der Rest sollte ja ebenfalls in Ruby gescripted werden, und ich denke das kostet selbst damit ordentlich Performance. Die viel höheren Systemanforderungen des XP's tuen ihr übriges.. ich bin mir also mehr als unischer ob's nicht zu einer Ruckelorgie verkommen würde?

Also wenn wechseln, dann bei diesem Projekt doch definitiv zum Gamemaker anstatt zum XP.
Der ist wahrscheinlich noch einfacher zu lernen als Ruby, und bietet weit mehr bei solchen arcadelastigen 2D Spielen.
Wenn man so ein Projekt mit dem RPG Maker 2k/2k3 ernsthaft in Angriff nimmt, geht's mMn eigentlich nur darum sich selbst was zu beweisen, oder anderen zu zeigen, was alles mit diesem Spielzeug möglich ist.

Ruckeln tutet beim Maker ja wegen der schlechten Verarbeitung der Scripte, ich glaub, das liegt nicht generell am Interpretieren.
Mein Computer schafft ohne weiteres Warcraft III, d.h. er kann größte Mengen an Polygondaten in kürzester Zeit in ein Bild verwandeln aber er scheitert am Maker... das kann einfach nicht an der Leistung liegen sondern muss einfach am Maker liegen
Von daher könnte ich mir vorstellen, dass Ruby für sowas sogar schneller sein könnte wenn der XP besser geschrieben ist (weiß ich aber nech, net soviel damit geschafft bisher ^^)

Naabend!

@CapSeb
Sorry, war in letzter Zeit ziemlich beschäftigt, habe die letzten Einträge gelesen und jetzt kann es losgehen...

Also fassen wir zusammen:

Deine Anforderungen:

- Du willst 4( +Spieler =5?) Spirites darstellen

- Die Bewegungen der Spirits soll über Variabelen kontrolliert/gesteuert werden; bzw. eine Analyse der Position x/y abs. (= absolut auf dem Bildschirm und nicht in Realition zur Umgebung) des Spielers alle 0,1 sek.

(Wenn ich irgendwas vergessen oder falsch verstanden habe, bitte melden! ;) )

Mein Ansatz:

- Die Position der KI-Spirits erfolgt durch Skript (=Common Event) und einer Schleife(= ebenfalls Common Event), in der die Position "abgerackert" wird. ([KlugscheißModus]Verabschiede Dich an dieser Stelle von dem Gedanken, dass Variablen nur mit einem Wert belegt werden können..., man kann sie verändern, daher der Name! [/KlugscheißModus] ;) )

- Die Schleife ist im Grunde eine Art "Zwischenspeicher" und die Variablen in ihr geben den X/Y-Wert, Ausrichtung für die KI-Spirits an und einen Zeitindex! ( <- ganz wichtig, ich gehe später darauf ein...)

- Die Werte für diesen "Zwischenspeicher" hinterlege ich in einem Common Event, der mit einzelnen Sprungmarken ( =Labels) gespickt ist

- Der Schleife sage ich, dass sie, nach Erledigung ihrer Arbeit, sich neue Werte für die KI holen soll (= Call Common Event) und einen Schalter betätigt (<- wieder ganz wichtig!)

- Der Schalter entscheidet in einer vorgeschalteten if-Handeling welcher Datensatz der KI geladen werden soll. Also: if schalter "xy" = 1, goto Label "1", if schalter"xy" = 2 gotoLabel "2", usw...

- Ein weiterer Common Event:
Der weiter oben erwähnte "Zeitindex" wird mit dem Zeitindex des Spielers verglichen, weicht er um einen bestimmten Wert ab, so wird das entsprechende Spirit größer (= näher) oder kleiner (= iss janz weit wech) dargestellt, bzw. ab einer gewissen Toleranz wird es auf dem momentanen Bild nicht dargestellt (= außer Sichtweite)

Lediglich für den Spieler brauche ich auch weiterhin die volle Anzahl der Variablen(= 240k), um im Replay-Modus die "erfahrene" Leistung aufzuzeichnen. Mit Hilfe eines intelligenten Speichersystems können wir es noch evtl. so drehen, dass Du sämtliche Bestzeiten des Spielers auf einen Schlag speichern kannst (also für alle Strecken), ist allerdings ein bißchen komplizierter...
Zu den genauen Größenordnungen(= Anzahl der Variablen) kann ich an dieser Stelle leider keine genaueren Angaben machen... Sorry, musst Du einfach ausprobieren.

So, ich hoffe damit alle Klarheiten beseitigt zu haben... :rolleyes:

Viel Spaß beim programmieren! :D

Die "One-Picture-Bahn-Methode" scheint funktionieren zu können. Ich bin den Quelltext durchgegangen und es scheint einsetzbar zu sein, habs bisher aber noch nicht umgeschrieben. Nur habt ihr schon mal versucht eine Rennstrecke ohne Chipset frei Hand am Computer zu zeichen, die dann auch mit dem "Kollisions-Chipset" übereinstimmt und ohne Objekte überhalb des Wagens auskommt? :hehe: Egal...

Zitat:

---

Zitat von White Knight

Wenn ich irgendwas vergessen oder falsch verstanden habe, bitte melden!

---

Dann mal los...

Zitat:

---

- Du willst 4( +Spieler =5?) Spirites darstellen

---

Der Geist gilt und erscheint nur in "Time Attack" oder wie man den Einzelspielermodus der Bestzeiten nennen will. Die vier Spieler gleichzeitig haben mit diesem Geist nichts zu tun und werden deswegen nicht gespeichert.

Zitat:

---

eine Analyse der Position x/y abs. (= absolut auf dem Bildschirm und nicht in Realition zur Umgebung) des Spielers alle 0,1 sek.

---

Der Geist soll alle 0,05 Sekunden angezeigt werden um sich den 24fps zu nähern. Dafür muss er im Verhältnis zu Map und nicht zum Bildschirm gespeichert bzw. dargestellt werden.

Zitat:

---

Lediglich für den Spieler brauche ich auch weiterhin die volle Anzahl der Variablen(= 240k), um im Replay-Modus die "erfahrene" Leistung aufzuzeichnen.

---

Leider ist der Entwickler nichts anderes als ebenfalls ein Spieler - nämlich ich. Und auch ich muss mit der gleichen Methode wie der Spieler die Variablen speichern lassen und kann sie nicht per Hand in ein Common Event schreiben. Dazu verweise ich auf meinen Post auf Seite1 vom 14.02.2006, um 11:40 Uhr

Es steht jetzt aber immer noch die Frage offen, was mit einem "Variablen-Runtersetz-Programm" oder einer anderen Zeitsparmethode ist. ^w^

Also ich würd sagen, das mit der "Picture-Bahn" sollte man lassen. das bringt nur mehr Probleme als Lösungen...:o
Als du noch mit Chips arbeiten wolltest hattes du doch vor, den Gleiter als Pic zu basteln und darunter den hero zu setzen. Da war aber das Prob mit dem Picture und den zusätzlichen Variablen.
Dann würde ich doch einfach sagen, du machts die Mauern einfach als Event (mit "Same Level As Hero"), oder?


PS.: Deine neue Sig is klasse...:D - :o - :rolleyes: - :eek: - http://www.multimediaxis.de/images/s...old/1/keks.gif - http://www.multimediaxis.de/images/s...old/3/errr.gif - http://www.multimediaxis.de/images/s...old/3/grrr.gif

Naabend!
@CapSeb
Sorry, dass ich beim letztem Mal ein bißchen am Ziel vorbei geschossen bin...

Zitat:

---

Zitat von CapSeb

Der Geist gilt und erscheint nur in "Time Attack" oder wie man den Einzelspielermodus der Bestzeiten nennen will. Die vier Spieler gleichzeitig haben mit diesem Geist nichts zu tun und werden deswegen nicht gespeichert. Der Geist soll alle 0,05 Sekunden angezeigt werden um sich den 24fps zu nähern. Dafür muss er im Verhältnis zu Map und nicht zum Bildschirm gespeichert bzw. dargestellt werden.
Leider ist der Entwickler nichts anderes als ebenfalls ein Spieler - nämlich ich. Und auch ich muss mit der gleichen Methode wie der Spieler die Variablen speichern lassen und kann sie nicht per Hand in ein Common Event schreiben.

---

Also; dieses Problem lässt sich theoretisch lösen... :rolleyes:
Schraub erstmal Deine Strecke (mit ca. 370k Variablen) zusammen, löse das Kollisionsproblem und dann vollführe ein paar Testfahrten. Wenn Du dann ein Gefühl für die Strecke hast, bau ein automatisches Speichern am Ende der Strecke ein (für alle Fälle) und anschließend lässt Du Dir über eine Textbox (= Message) beim Testspielen noch die Werte der Variablen anzeigen (nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...

Falls Du es gerade nicht zur Hand hast: \v[0000000] bis \v[370000]

Die Werte schreibst Du Dir auf einen Zettel und anschließend hast Du dann doch alles was Du brauchst, oder nicht? (Ich habe nicht behauptet, dass es einfach wird...)

Zitat:

---

Zitat von CapSeb

Es steht jetzt aber immer noch die Frage offen, was mit einem "Variablen-Runtersetz-Programm" oder einer anderen Zeitsparmethode ist. ^w^

---

Ohne Dir zu nahe treten zu wollen, aber Du weißt schon, dass Du mit einem RPG-Maker arbeitest? Ich betone das deshalb so explizit, weil die Engine sich zwar im gewissen Maße verbiegen lässt, aber irgendwo hat es seine Grenzen...

Meiner Meinung nach könnte es immer noch klappen, aber muss die Ausrichtung unbedingt auch in einer Variable gespeichert werden?
Auch dafür würde ich eher eine Lösung mit Switches in Betracht ziehen (je nach Länge des Tastendrucks anderes Bild anzeigen lassen...-> Anzahl im Extremfall 360, aber 16 sollten es auch tun, bei Drehern halt mit Bildern improvisieren).

Sölltest Du das Projekt also ernsthaft in Erwägung ziehen, kommst Du an einem Skripten der "Geister-KI" sowieso nicht dran vorbei (Wie es gehen könnte steht ja weiter oben), schließlich hast Du ja mehrere Strecken, alle mit eigener KI und mit den eigenen vielen, vielen wunderbaren und ach so einzigartigen Datensätzen...

Was mir jedoch immer noch Bauchschmerzen bereitet sind die vielen Variablen für den Spieler, irgendwie scheint da kein Weg dran vorbei zu führen, es sei denn:
Framerate runtersetzen oder den Replaymode/ Streckenaufzeichnung komplett zu canceln...

Momentaner Zwischenstand wäre also irgendwas bei 250k (370k im Entwicklermodus wegen der Ausrichtung)Variablen und einen Berg an Schaltern, richtig?
Effektiv hieße das eine Wartezeit von nur noch etwas bei die 2 h
Ist ja schon mal ein Anfang und Du hättest theoretisch ja auch schon ein Gegnerfeld, statt einem Geist der nur alle paar Sekunden aufblinkt echte Gegner die die Strecke mit Dir abfahren. Die Idee mit 4 Spielern gleichzeitig schiebst Du am Besten erstmal auf die unterste Position der "TO-DO-Liste", wird auf jeden Fall eine "interessante" Herausforderung wenn das euch noch im Replay realisiert werden soll, von dem Gedrämge am Klimperkasten (= Tastatur) ganz zu schweigen...

Einige Sachen und ein paar coole Gimmicks wie Sektoren-Bestzeit, eine "halbwegs" realisierbare KI und ein autom. Speichern der Bestzeit beim Timetrial sind also in greifbarer Nähe.
Als Krone könntest Du sogar noch einen Zufallswert einbinden, indem Du unterschiedliche KI-Schwierigkeitsgrade an die gegnerischen Fahrzeuge verteilst, so dass jedes Rennen aufs Neue spannend wird.

Also das Projekt noch nicht komplett in die Tonne treten (vielleicht wäre es mit dem XP-Maker einfacher (->Ruby-Interface), weiß ich aber auch nicht so genau), früher oder später kommt garantiert die zündende Idee ...

Hoffe ich konnte Dir heute mehr weiterhelfen

Zitat:

---

Zitat von CapSeb

Die "One-Picture-Bahn-Methode" scheint funktionieren zu können. Ich bin den Quelltext durchgegangen und es scheint einsetzbar zu sein, habs bisher aber noch nicht umgeschrieben. Nur habt ihr schon mal versucht eine Rennstrecke ohne Chipset frei Hand am Computer zu zeichen, die dann auch mit dem "Kollisions-Chipset" übereinstimmt und ohne Objekte überhalb des Wagens auskommt? :hehe: Egal...

---

Da hab ich doch noch mal ein paar Fragen an dich:
Was meinst du mit "One-Picture-Bahn-Methode"? Meinst du meinen Vorschlag, die Strecke mit Pictures darzustellen und um den Helden herumzubewegen?
Dann versteh ich nähmlich nicht, warum du die Rennstrecke ohne Chipset "frei Hand" zeichnen willst o.O
Kein Chipset zu verwenden ist da doch viel zu aufwendig und unpraktisch, das ergibt keinen Sinn. Du kannst die strecke mit einem stinknormalen Chipset zeichnen, musst nur bei Terrain ID die entsprechenden Einstellungen vornehmen (meinetwegen bei Hindernis-> Kollision nimmst du ID=1).
Wenn du deine Map im Maker erstellt hast, "screenshotest" du sie einfach und schon hast du dein Picture.
Und wieso willst du ohne Objekte überhalb des Wagens auskommen? Dafür kannst du wunderbar den Upper Layer im RPG Maker verwenden, dann die Map kopieren, den unteren Layer "löschen" (mit einer ziemlich hervorstechenden Farbe) und wieder "screenshoten" und schon hast du ein zweites Picture.. deinen Upper Layer. Die Picture ID's der Fahrzeuge müssen dann natürlich über dem ersten und unter dem zweiten Map-Picture liegen.

Halt, halt, haaaaaalt... http://www.multimediaxis.de/images/s...rinundwech.gif
Allmählich gerät das ganze hier aus den Fugen. Ich hab nach meinem letzten Post auf Picture+Chipset Bahn umgestellt und es funktioniert. Aber erstmal zu euch:

Zitat:

---

Zitat von Mr.Hunz

Dann würde ich doch einfach sagen, du machts die Mauern einfach als Event (mit "Same Level As Hero"), oder?

---

Die Events hab ich schon seit längerem abgeschafft, da sie stark auf die Performance wirken. Die Terrain-ID funktioniert da viel besser.

Zitat:

---

Zitat von White Knight

nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...

---

Jetzt Neu! Freie Abende dank E-Book... :rolleyes:
Die ganzen Werte aufzuschreiben wäre natürlich das gleiche. Aber darauf habe ich ehrlich gesagt keine Lust. Zudem ist das Aktualisieren bei späteren Verbesserungen (oder Vereinfachungen) der Entwicklergeister äußerst nervig.

Zitat:

---

Zitat von White Knight

Meiner Meinung nach könnte es immer noch klappen, aber muss die Ausrichtung unbedingt auch in einer Variable gespeichert werden?

---

Eh, nein. Die könnte ich tatsächlich durch das x- und y-Achsen-Verhältnis berechnen, wie es beim Fahren selbst ja auch der Fall ist.

Zitat:

---

Zitat von White Knight

Sölltest Du das Projekt also ernsthaft in Erwägung ziehen

---

Ja.

Zitat:

---

Zitat von White Knight

Framerate runtersetzen oder den Replaymode/ Streckenaufzeichnung komplett zu canceln...

---

Bei der Framerate könnte es "Komprimierungs"-Verfahren geben und die Streckenaufzeichnung funktioniert ja schon.

Zitat:

---

Zitat von White Knight

eine "halbwegs" realisierbare KI

---

Gut, das ist wieder ein ganz anderes Them a, mit dem ich mich bisher aber noch nicht beschäftigt habe. Vielleicht werde ich einen neuen Thread öffnen, wenn ich soweit bin.

Zitat:

---

Zitat von White Knight

Hoffe ich konnte Dir heute mehr weiterhelfen

---

Ich denke schon. Und auf jeden Fall vielen Dank für die Ideen!

Zitat:

---

Zitat von Ryo Saeba 1000

Dann versteh ich nähmlich nicht, warum du die Rennstrecke ohne Chipset "frei Hand" zeichnen willst o.O

---

Die Verständnissprobleme sind meine Schuld. Ich meinte das ganze nicht so ernst und wollte nur betonen, dass es mit dem Screenshoten nicht getan ist. Aber egal, wie gesagt funktioniert es.

Zitat von White Knight
nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...
Jetzt Neu! Freie Abende dank E-Book...
zitat von cabseb:
Die ganzen Werte aufzuschreiben wäre natürlich das gleiche. Aber darauf habe ich ehrlich gesagt keine Lust. Zudem ist das Aktualisieren bei späteren Verbesserungen (oder Vereinfachungen) der Entwicklergeister äußerst nervig.

daran wirst du aber nicht vorbeikommen... du musst entweder deine entwickler geister per hand eingeben... oder die spieler (die das spiel mal später spielen dürfen)müssen ein bereits gespielten spielstand als neuanfang nehmen, denn irgendwie müssen die daten ja im maker rein...oO
dh. du musst erst fahren, strecken-entwickler-zeit speichern, game speichern
und der spieler muss dann die save datei laden, damit er in den genuss
der entwickler zeit kommen kann...

...und genau das ist die Methode, die ich am 14.02.2006 um 11:40 auf Seite 1 dieses Threads geposted habe.
Aber wie schon gesagt, führt kein Weg daran vorbei. Und damit jeder das auch versteht, hier das Prinzip zusammengefasst:

1. Man steuert einen Koordinatenpunkt
2. Der Koordinatenpunkt geteilt durch 16 ergibt die Chara-Posi auf dem Chipset für die Kollisionsabfrage
3. Das "gescreenshotete" Chipset wird als bemaltes Picture (2000x2000 Pixel)unterhalb des Fahrzeugs bewegt ohne Chipsetscrollen
4. Das "gescreenshotete" Chipset wird als zweites bemaltes Picture (2000x2000 Pixel) oberhalb des Fahrzeugs bewegt ohne Chipsetscrollen
5. Die Koordinate wird als Picture dargestellt (Fahrzeugposi minus Bildschirmposi)
6. Die Entwicklerbestzeit (oder wenn besser die Spielerbestzeit) wird alle 0,05 Sekunden dargestellt
7. Die Koordinatenposition wird alle 0,05 Sekunden als Geist gespeichert bei besserer Bestzeit

Zitat:

---

Zitat von CapSeb

4. Das "gescreenshotete" Chipset wird als zweites bemaltes Picture (2000x2000 Pixel) oberhalb des Fahrzeugs bewegt ohne Chipsetscrollen

---

Ääääm: Wieso sollte die gesamte Map nochmal über dem Fahrzeug erscheinen? Dann sieht man das Fahrzeug doch gar nicht mehr...:confused:

Zitat:

---

Zitat von CapSeb

6. Die Entwicklerbestzeit (oder wenn besser die Spielerbestzeit) wird alle 0,05 Sekunden dargestellt

---

Wieso, wie und warum ( :D ) DAS denn?

Zitat:

---

Zitat von Mr.Hunz

Ääääm: Wieso sollte die gesamte Map nochmal über dem Fahrzeug erscheinen? Dann sieht man das Fahrzeug doch gar nicht mehr...

---

Das hat den gleichen Effekt wie der Upper-Layer: Nur an Stellen wo Bäume oder sonst welche "höheren" Objekte stehen hat das Picture Farbe. An allen anderen Stellen ist es natürlich durchsichtig...

Zu Punkt 6: Ja, eh nicht die Zeit wird angezeigt sondern natürlich das dazugehörige Picture auf der Picturebahn.