makenshi
11.01.2008, 21:35
Ach, das Forum wieder.
Bitte.
Manches davon ist übrigens purer Blödsinn.
Ist mit großer Vorsicht zu genießen.
Die lustigen Messungen z.B. sind Blödsinn. Der einzige Weg etwas effektiv im Maker zu messen, wäre einen Debugger nebenbei laufen zu lassen der die Systemticks mißt. Daraus ließe sich dann entsprechend etwas ausrechnen. Immer diese Pseudowissenschaft. X_X Keine wirkliche Ahnung von der Materie, aber Messungen in so einem Programm anstellen. Oh gott.
Und Events sind Schleifen? Sie zeigen nur stellenweise die Arbeitsweise einer Schleife, weil seine Bedingung ununterbrochen erfüllt ist. Das kann man aber doch nicht Schleife nennen.
Tolles Profiwissen. Und ja, das waren nur zwei Beispiele daraus. Einzig und allein das wirklich fundierte Wissen von Unfixable. und ähnlichen Leuten scheint wirklich Sinn und Verstanden dahinter zu haben. Die haben nämlich nicht versucht auf die Art und Weise Schlüsse zu ziehen.
Wenn du es dennoch lesen willst:
Dieser Thread enthält Profi-Wissen, das über die letzten Jahre hinweg von RM2K(3)-Usern gesammelt wurde. Es ist nichts für Anfänger!
Liste der Mitwirkenden ist unten (einige sind mir entfallen).
Was sind "0.0"-Waits?
Die ersten Gedanken werden bringen: Das dauert keine Millisekunde.
Doch das ist falsch. Ein "0.0"-Wait braucht 0.016666...7 Sekunden, also etwa der 60. Teil einer ganzen Sekunde. Somit ist die minimalste Zeit, die ein Wait dauern kann, etwa 0.17 Sekunden und nicht kürzer. Wenn dazu einige andere Befehle wie "Set Variable" ausgeführt werden, kann das etwa 10 Millisekunden extra beansprungen. Entspricht dann etwa der Zeit, die ein "Graphics.update" beim RMXP braucht (~25 Millisekunden).
Das "0.0"-Wait wartet bis zum nächsten Frame und dann wird der Rest ausgeführt. Will man etwa 250 Millisekunden Wartezeit, nimmt man am besten zweimal "0.1" und dreimal "0.0".
--------------------------------------------------------------------------------------
Wie lange dauert ein Schritt?
+-----------+--------+----------+
| Tempo | Frames | Sekunden |
+-----------+--------+----------+
| 8x Slower | 64 | 1.07 |
| 4x Slower | 32 | 0.53 |
| 2x Slower | 16 | 0.26 |
| Normal | 8 | 0.13 |
| 2x Faster | 4 | 0.07 |
| 4x Faster | 2 | 0.03 |
+-----------+--------+----------+
In "Wait"-Zeiten:
8x Slower: "0.8" + 16x "0.0" (oder 64x 0.0)
4x Slower: "0.4" + 8x "0.0" (oder 32x 0.0)
2x Slower: "0.2" + 4x "0.0" (oder 16x 0.0)
Normal: "0.1" + 2x "0.0" (oder 8x 0.0)
2x Faster: 4x "0.0"
4x Faster: 2x "0.0"
--------------------------------------------------------------------------------------
Common Events im Kampf? (RM2003)
Natürlich kann man das hinbekommen, aber da ist man nicht immer gut beraten.
Message Options:
Style ausserhalb des Kampfes wird geändert, aber das im Kampf bleibt gleich.
Change System BGM:
Wenn man die Kampfmusik ändert, wird das erst im nächsten Kampf wirksam.
Call Event:
Läuft nur mit Common Events, denn im Kampf gibts keine Map-Events.
Enemy Encounter:
Die ganze RPG_RT hängt sich auf.
Diese Befehle werden komplett ignoriert:
- Flash Sprite
- Enter or Exit Vehicle
- Proceed with Movement
- Halt All Movement
- Show Battle Animation
Bei diesen Befehlen wird ein Teleport kurz angedeutet, ohne Erfolg:
- Teleport
- Recall to Memorized Position
Diese Befehle laufen Normal:
- Wait
- Key Input Processing (nur wenn "Wait until key is pressed" nicht aktiv ist)
Bei diesen Befehlen wird der Kampf beendet und die Musik läuft weiter:
- Open Shop Window
- Open Save Menu
- Open Main Menu
- Enter Hero Name
Diese Befehle werden nach dem Kampf ausgeführt:
- Show Picture
- Move Picture
- Erase Picture
- Pan Screen
- Play Movie
Die Map, auf der der Kampf gestartet wurde, kümmert sich nach dem Kampf um diese Befehle:
- Change Event Location
- Trade Two Event Locations
- Set Terrain ID
- Store Event ID
- Change Map Tileset
- Change Parallax Background
- Change Encounter Rate
- Tile Substitution
--------------------------------------------------------------------------------------
Über das Parallax-BG-Scolling:
+3 und -3 ist das gleiche wie 8xSlower bei Bewegungen
+4 und -4 ist das gleiche wie 4xSlower bei Bewegungen
+5 und -5 ist das gleiche wie 2xSlower bei Bewegungen
+6 und -6 ist das gleiche wie Normal bei Bewegungen
+7 und -7 ist das gleiche wie 2xFaster bei Bewegungen
+8 und -8 ist das gleiche wie 4xFaster bei Bewegungen
--------------------------------------------------------------------------------------
Habt ihr schon gewusst, dass...
...ein "Parallel Process" euer Spiel einfrieren kann, wenn ihr keine Waits benutzt? (nur bei schwachen Computern)
...ein "Auto-Start" nicht starten kann, wenn "Push-Key", "OnHeroTouch" oder "OnEventTouch" eintritt?
...ein "Parallel Process"-Common Event, das vorher unterbrochen wurde, später genau an der Stelle beim neuen Aufruf fprtgesetzt wird?
..."Auto-Start" auch weiterläuft, wenn ihr die Map wechselt?
..."Move-Events" aufeinander warten, wenn ihr "Move All" macht? Alle "Move-Events" warten, bis das letzte fertig ausgeführt wurde.
...ihr "Call Event" nur benutzen solltet, wenn ihr keine Sache vorher mit "this Event" auf das Event gerichtet habt, das callen soll? Wenn es ein Common Event ist, könnten Probleme auftauchen.
...wenn man bei einem Event (außer eines, das Parralel ist) während seiner Funktion (in der Mitte) per Switch die 2. Seite aktiviert, es sofort die Grafik der 2. Seite erhält und ALLE Move-Events usw. , die sich auf dieses Events beziehen und nach der Aktivierung des besagten Switches kommen mit den Einstellungen der 2. Seite durchgeführt werden? (z.B. MoveSpeed/Animation-Typ/Position[Over Hero, Below Hero usw.])
...auch Move-Events die bei der Aktivierung der 2. Seite, die noch am laufen sind, von diesem Zeitpunkt an, mit den Einstellungen der 2. Seite weiter geführt werden?
...mit ganz kurzen "Move-Events" des Helden ein "OnHeroTouch" ignoriert werden kann? Benutzt in diesem Fall "OnEventTouch".
...sich ein "Over Hero" und "Below Hero" im Weg stehen? Sie können nicht aneinander vorbei.
...man ein flüssiges Auflösen eines Events per "Move-Event" und "Transp.up" am besten dann hinbekommt, wenn man zwischen den "Transp.up" eine Move-Frequenz von 6 (oder 7 oder 5) einfügt?
...wenn ein Event mit 2 Seiten bei beiden exakt die gleiche "Route" im Movement Type "By its route" hat, nur das die 2. Seite trotzdem auf "Stay Still" steht, es beim aktivieren der 2. Seite dementsprechend stehen bleibt, aber bei Deaktivierung der 2. Seite dann wieder bei der 1. Seite mit der "Route" exakt dort anfängt, wo es unterbrochen wurde? (das passiert nur wenn beide Seiten die gleiche Route gespeichert haben und nur solange man auf der aktuellen Map bleibt)
...man mit der Funktion "Set Terrain ID" die "Terrain-ID" des Feldes unter dem "Hero" nehmen kann (was verdammt praktisch ist, wenn man z.B. es so machen will, das der Held nur auf Schneebelegten Untergrund Fußstampfen hinterlässt - Man gibt den Feldern mit Schnee einfach eine bestimmte "Terrain-ID", die dann mit besagter Funktion genommen wird...dann eben "Forks" usw.)?
--------------------------------------------------------------------------------------
Von Squall83:
Die Formel, nach der "Hit Chance" und "Mind Chance" den Effekt eines Skills beeinflusst:
Basis Effect = B
Hit Chance = H
Mind Chance = M
Angriffswert des Helden = A
Verteidigung des Monsters = V
Intelligenz des Helden = I
Intelligenz des Monsters = J
E = Ergebnis
E = B + (A-V/2) * H/20 + (I-J/2) * M/40
Das sieht am Anfang etwas kompliziert aus. Daher erkläre ich sie noch mal:
Die Formel besteht aus 3 Summanden:
1)Der Basis Effect
Das ist einfach die Zahl, die man unter "Basis Effect" eingeben kann.
2)Der zweite Summand
Von der Stärke des Helden wird die Hälfte der Verteidigung des Monsters abgezogen. Das Ganze wird mit dem Hit Chance Wert multipliziert (also der Wert, den man auf dem Balken einstellen kann) und durch 20 geteilt.
Wenn das Monster eine Defensive besitzt, die mehr als doppelt so hoch ist, wie die Stärke des Helden, so wird die Klammer negativ und das Ergebnis wird immer geringer, je höher der Hit Chance Wert wird.
3)Der dritte Summand
Das gleiche wie beim zweiten Summand, nur das hier statt der Stärke des Helden und der Verteidigung des Monsters die Intelligenzwerte von Beiden genommen werden, man mit dem Mind Chance Wert multipliziert und durch 40 teilt. Auch hier kann die Klammer negativ werden und das Ergebnis senken.
Bei Heilzaubern sieht die Formel nur etwas anders aus: Es wird vom Stärke- und/oder Intelligenzwert des Benutzers nichts abgezogen. Dann sieht das Ganze so aus:
E = B + A * H/20 + I * M/40
Probiert die Formeln ruhig aus. Bis auf +/- 1 (Rundungsfehler des Rpg Makers) stimmt das Ergebnis garantiert immer. Wenn nicht, dann nennt mir bitte die Werte.
Für Fragen mailt an Newcomer83@web.de
Hier noch die Formel für konventionelle Angriffe:
E= (A - V/2)/2 +/-(0-20%)
Auf Deutsch heißt das:
Schaden = Angriff des Helden - Verteidigung des Monsters/2, das Ergebnis durch 2 teilen und der Wert variiert maximal um 20%.
Bei dieser Formel hat mir Lachsen gesagt, dass man den Term A-V/2 noch durch 2 teilen muss (hatte ich aus Flüchtigkeit übersehen).
Ich erklär auch noch gerne allen, die es wissen und nicht wissen wollen, wie ich das herausgefunden habe. Aber es ist mir nicht gelungen, eine einfache Erkärung zu schreiben:
Zuerst habe ich durch testen herausgefunden, dass zum Basiswert etwas addiert und nicht multipliziert wird. Das war insofern wichtig, weil dann eine bestimmte Einstellung von Hit und Mind Chance den Effekt eines Skills gegen einen Gegner nicht Verfielfachen (z.B. verdoppeln). Es ist immer die gleiche Zahl, die dazuaddiert wird, egal ob der Basisschaden 10 oder 500 beträgt.
Ich habe die Tests mit Mind Chance angefangen.
Dann habe ich in meinem Rpg, das ausschließlich für Tests angelegt wurde, 11 Skills eingegeben, jeder den gleichen Basis Effekt und bei jedem einen anderen Wert der Mind Chance Skala. Der mit Mind Chance=0 war nur zur Kontrolle. Man weiß ja nie, was für Überaschungen der Rpg Maker bereit hält. Ich hab die Skills Feuer0 bis Feuer10 genannt.
Als nächstes habe ich die Schleimx2-Party auf einen gekürzt und dem Schleimmonster die Werte folgendermaßen verändert:
HP=9999, damit ich ordentlich Testreihen durchführen kann
Die anderen Werte hab ich so weit wie möglich runter geschraubt, damit die keinen "schädlichen" Einfluss auf meinen Skill haben.
Bei den Werten des Helden genauso. Dann habe getestet, Werte verändert und zuerst mal nur geschaut, wann sich der Effekt verändert.
Bei Mind Chance waren das die Intelligenzwerte von Beiden, bei Hit Chance die Stärke des Helden und die Verteidigung des Monsters.
Soviel zur Vorbereitung. Bis hierhin sollte jeder mitgekommen sein.
Jetzt kommt der interessante Teil:
1. Ich habe Excel zu Hilfe genommen und eine Tabelle aufgestellt, bei der links verschiedene Mind-Werte für den Helden stehen (100,110,120,....,200) und oben stehen die Mind Chance-Werte (0,1,2,.....,10). In die Mitte kam dann die Schadensveränderung (also Gesamtschaden minus Basisschaden).
Das ist auch noch nicht so schwer, aber jetzt kommts knüppeldick. Lest den folgenden Abschnitt lieber sehr langesam durch, ich habe auch eine Weile gebraucht, bis ich verstanden habe, was ich da eigentlich hingeschrieben habe.
2. Ich habe den Mittelwert aller Differenzen zwischen zwei benachbarten Feldern gebiltet. Erklärung: Bei 2 Feldern gibt es eine Differenz, die man bilden kann, bei 5 Feldern 4 und bei 11 Feldern (wie bei mir) 10 Differenzen. Das klingt viel komplizierter, als es ist, denn man muss nur den Wert aus dem 11.Feld (mit Mind Chance 10 drüber) durch 10 teilen, dann hat man den Mittelwert der Schadenszunahme. Erfreulich war: Die Schadenszunahme war von Feld zu Feld konstant (bis auf die Rundung des Rpg Makers).
3. Nachdem ich für 100,110,150 und 200 Mittelwerte gebildet hatte, ist mir ein System aufgefallen. Die Mittelwerte nahmen immer abwechselnd um 0,2 und 0,3 zu. Das hab ich auf 0,25 gemittelt und korrigierte Mittelwerte hinten dran geschrieben.
(Der Mittelwert der Zunahme der Mittelwerte der Differenzen der Schadenszunahmen. Lasst euch das mal auf der Zunge zergehen. )
Also: Wenn man die korrigierten Mittelwerte durch die dazugehörigen Intelligenzwerte des Helden teilt, kommt man immer auf 0,025 (das sind die 1/40 aus der Formel).
Anmerkung:
Der Mittelwert für Intelligenz=100 war 2,5.
Der Mittelwert für Intelligenz=110 war 2,7 (was ich auf 2,75 korrigiert hatte)
Der Mittelwert für Intelligenz=120 war 3,0 (hier war keine Korrektur nötig)
==> Es kommt immer 0,025 raus.
Wenn du jetzt bist, dann kann ich das gut verstehen, aber das Beste kommt erst noch.
4. Man muss sich darüber klar werden, was das eigentlich für ein Mittelwert ist. Ich habe diesen Mittelwert aus 10 Differenzen gebiltet. D.h. wenn man ihn z.B. 5mal zum Basisschaden addiert, muss der gleiche Gesamtschaden herauskommen, wie bei Mind Chance = 5 etc.
Also muss man den Mittelwert genau so oft zum Basisschaden addieren, wie es der Mind Chance-Wert vorschreibt (bei 7 7-mal, bei 3 3-mal etc.)
Also ist der Effekt = "Basis" + "Mind Chance" x "Mittelwert"
Aber kann man den Mittelwert einfach so in die Formel nehmen?
NEIN!! Denn er variiert ja je nach Intelligenzwert des Helden (der Intelligenzwert des Monsters ist immernoch vernachlässigbar, weil er 1 ist). Und zwar ist der Mittelwert immer der vierzigste Teil des Intelligenzwertes des Helden.
==> Effekt = "Basis" + "Mind Chance" x "Intelligenzwert"/40
Ab jetzt wird es wieder einfacher.
5. Als nächstes habe ich vermutet, dass der Intelligenzwert des Monsters von dem des Helden abgezogen wird.
Der Test, bei dem die Intelligenzwerte von beiden 100 war, zeigte mir nicht nur, dass die Vermutung falsch war, sondern auch, dass der zusätzliche Schaden (nicht der Gesamtschaden) auf genau die Hälfte zurück ging. Ich habe die Intelligenz des Monsters auf das Doppelte des Wertes des Helden gesetzt und gesehen, dass immer genau der Basisschaden herauskam, egal, wie Mind Chance eingestellt war. Als ich die Intelligenz des Monsters noch höher schraubte, ging der Schaden sogar unter den Basisschaden drunter.
Damit hatte ich alles für den Mind Chance-Teil der Formel. Ich habe sie getestet, in dem ich im Excel Willkürliche Werte für Mind Chance, Intelligenzwerte von Beiden und für den Basisschaden eingesetzt habe, in einem anderen Feld nach meiner Formel das Ergebnis ausrechnen lassen habe. Dann habe ich die gleichen Werte im Rpg Maker eingesetzt und im Kampf gegen ein Monster den Schaden ausgetestet.
Was erwartet ihr?
Genau! Es war immer der Schaden, den meine Formel anzeigte (+/-1, denn der Rpg Maker hat einen kleinen Rundungsfehler).
Als nächstes habe ich mich erstmal sehr gefreut.
Dann habe ich mich an die Hit Chance gemacht. Ich habe gleich richtig vermutet, dass die Hit Chance vom Stärke-Wert des Helden und dem Verteidigungswert des Monsters zusammenhängt.
Dieses Mal ging es schneller. Ich habe wieder eine Tabelle gemacht, Mittelwerte gebilet und gesehen, dass der Quotient dieses Mal 1/20 war. Dass der Verteidigungswert des Monsters nur zur Hälfte eingeht und vom Stärke-Wert des Helden abgezogen wird, ließ sich leicht und richtig vermuten.
Daraus folgte die Formel für Hit Chance:
Effekt = Basis + "Hit Chance" x Stärke/20, wobei von der Stärke natürlich noch die Hälfte des Verteidigungswertes des Monsters abgezogen werden muss.
Schließlich habe ich einfach mal ausprobiert, ob man beide Formeln zu der Formel kombinieren kann, die ich euch am Anfang dieses Threads kombinieren kann. Ratet mal, ob ich damit Erfolg hatte.
Ich muss in aller Bescheidenheit sagen, dass ich in der 13. Klasse bin und in wenigen Monaten Abitur in meinen LKs Mathe und Physik mache.
Aber trotzdem habe ich die Formel nicht einfach aus dem Ärmel geschüttelt. Ich war nur genervt, dass mir niemand genau sagen konnte, was Hit Chance und Mind Chance bewirkt. Und da habe ich mich mal einen Tag lang dran gesetzt.
Ich hoffe, alle, die sich durch dieses Monster von Text gekämpft haben, konnten wenigstens im Groben verstehen, was ich gemacht habe und sind jetzt nicht gefrustet.
Was man aus der Formel wichtiges herauslesen kann:
1)Man weiß, dass zum Basiswert etwas addiert und nicht multipliziert wird. D.h. ein Skill mit Basis 10, bei dem Hit Chance und Mind Chance 20 ergeben, ist der Schaden 30 (also das Dreifache), während ein Skill mit 100 Basiseffekt und den gleichen Einstellungen bei Hit und Mind Chance ergibt einen Schaden von 120 (also lange nicht das Dreifache)
2)Wenn man sie im Excel eingibt, dann kann man genau bestimmen, wie viel Schaden ein Skill einem Monster macht und um wie viel er maximal variiert, wenn man Hit und Mind Chance des Helden ändert.
Außerdem kann man dadurch die Verteidigung, Intelligenz, Stärke etc. des Monsters besser anpassen.
3)Wer von euch wusste bereits, dass Hit und Mind Chance den Effekt eines Skills auch negativ beeinflussen können? Bestimmt bei Weitem nicht alle.
--------------------------------------------------------------------------------------
Wie lange dauert ein "Jump"-Schritt im "Move-Event"?
Vergleich mit Wait-Zeiten:
8x Slower = 32x 0.0 (0.5 + 2x 0.0)
4x Slower = 22x 0.0 (0.3 + 4x 0.0)
2x Slower = 16x 0.0 (0.2 + 4x 0.0)
Normal = 11x 0.0 (0.1 + 5x 0.0)
2x Faster = 8x 0.0 (0.1 + 2x 0.0)
4x Faster = 4x 0.0
--------------------------------------------------------------------------------------
Kleine Infos von mehreren Personen:
- "Clear Timer" zeigt bei "Common Events" keine Wirkung.
- Der RPGMaker sieht die "Events" als "Cycles" an, also wird mit "Cycles" in "Events", also "Cycles" in "Cycles", die Rechnerleistung sehr stark gefordert.
- Man löscht "Events" mit "Clear Timer", was an einem Übersetzungsfehler liegt, eigentlich heisst es "Delete Event temporary"
- Man kann maximal 2 zu drückende Tasten gleichzeitig abfragen.
- 3 Animation-Frames brauchen 0.1 Sekunden, um abzulaufen
- Eine Animation kann wegen 99 Frames-Begrenzung nur bis zu 3.3 Sekunden dauern
- Der Maker erlaubt, sofern es der Computer schafft, 1000 Aufrufe gleichzeitig zu verarbeiten, Nummer 1001 führt zu einem Absturz.
- Ein "Call Event" kann als "Parallel Process"-Ersatz missbraucht werden.
- Um "Switches" für zerhackte Büsche zu sparen, können "Events" auch geklont werden.
- "Labels" sind schneller als "Cycles" (beim Daueraufruf weist ein Label 5000 Aufrufe nach 0.0167 Sekunden auf und ein "Cycle" nur 3333)
- Comments bremsen den Maker aus (lässt man 1 Sekunde lang eine Variable dauerhaft erhöhen, hat sie dann den Wert 305000, mit einem Comment drinist es nur noch 203333; 1 Comment bremst somit um 20%)
--------------------------------------------------------------------------------------
Debug-Modus:
STRG: Hebt die Passierbarkeiten auf
SHIFT: Zeigt Nachrichtentexte sofort vollständig
F9: Öffnet die Verwaltung für "Switches" und "Variables"
F10: "Parallel Processes" unterbinden
--------------------------------------------------------------------------------------
"RPG_RT.exe"-Parameter:
Man kann in der Kommandozeile oder in Verknüpfungen zur RPG_RT.exe jeweils 3 Parameter dazu angeben.
TestPlay: Debug-Modus
NormalPlay: Normal spielen
ShowTitle: Titelbildschirm normal
HideTitle: Titelbildschirm "leer"
FullScreen: Vollbild
Window: Fenster-Modus
Diese Parameter kann man sich auch im Maker einstellen, dafür gibt es in der Symbolleiste einige Buttons.
Im Normalfall wird RPG_RT.exe so gestartet:
"Laufwerk:\Pfad\Pfad\RPG_RT.exe" NormalPlay ShowTitle FullScreen
(Normal spielen, Titelbildschirm normal, Vollbild)
Mit den Parametern kann man den Spiess z.B. komplett umdrehen:
"Laufwerk:\Pfad\Pfad\RPG_RT.exe" TestPlay HideTitle Window
(Debug-Modus, Titelbildschirm "leer", Fenster-Modus)
--------------------------------------------------------------------------------------
Gekiganger deckt das Geheimnis des Fehlers "Division by the zero" auf:
Lange war es für mich ein Mysterium, doch nun ist mir endlich ein einfach gestricktes Projekt in die Finger gekommen, welches diesen Fehler verursachte. In einem eigens erstellten Projekt konnte ich diesen Fehler erstmals absichtlich und unendlich oft reproduzieren.
Die Ursache des Problems liegt, wie ich schon einige Zeit vermutet habe, an einem internen Fehler des Makers bei der Pictureverarbeitung.
Folgende Bedingungen rufen diesen hervor:
Die erste generelle Screenbewegung (sprich normales Movement oder Pan Screen) nach links oder nach oben, wenn zuvor ein Show Picture oder Move Picture stattgefunden hat, bei dem die Magnification (Bildgröße) auf 0% gestellt wurde.
.
Die erste generelle Screenbewegung nach links, wenn zuvor ein Show Picture oder Move Picture stattgefunden hat, bei dem die Magnification auf 1% gestellt wurde.
Screenbewegungen in eine andere, den beiden genannten Punkten entgegengesetzte Richtung, heben dieses Phänomen auf, und zwar solange, bis man die selbe Anzahl an Feldern, die man in die entgegengesetzte Richtung gelaufen ist, wieder zurück läuft und ein zusätzliches Feld weiter geht, dann kommt es erneut zu dem Fehler.
Teleports auf eine andere Map heben es ebenfalls auf.
Vorsicht, das Phänomen wird auch beim speichern übernommen!
Es könnte natürlich noch andere Situationen geben, die diesen Fehler hervorrufen, doch zumindest ein erster Anhaltspunkt wurde gesetzt.
--------------------------------------------------------------------------------------
Dinge, die Darktraveler herausgefunden hat:
Falls es für irgendjemanden interessant sein sollte ^^ meine ich zwei Formeln des SKS durch mehrfaches Ausprobieren etwa eingegrenzt zu haben...
1) Trefferwahrscheinlichkeit
Ich habe einige Versuche gemacht... unter anderem den Versuch Angreifer: 100 AGI und Verteidiger: 999 AGI...
Wenn die Trefferwahrscheinlichkeit einfach nur nach dem Verhältnisprinzip gehen würde.... müsste ja der Verteidiger immer treffen... (stimmt... zumindest in 99% der Fälle) und der Angreifer nur 1 von 10 mal....... Zu meiner Überraschung war es jedoch weitaus häufiger und ich glaube so viel.... Pech (oder ehe rGlück) habe ich nicht, dass ich soooooo falsch liege......
Da allgemein die Abweichungen nicht allzugroß sind (einer der halb so schnell is wie der gegner trifft aber nicht nur halb so oft) habe ich nach einer Formel gesucht die dies beinhaltet und trotzdem bei gleicher Geschwindigkeit und gleicher Grund-Trefferwahrscheinlichkeit (das habe ich mal als gegeben vorraus gesetzt) beiden auch die selbe Trefferwahrscheinlichkeit gibt.....
Naja lange Rede kurzer Sinn... meine These ist dass die Trefferwahrscheinlichkeitsformel schlicht und ergreifend:
Grundtrefferwahrscheinlichkeit * (Agilität Angreifer / Agilität Verteidiger)^1/2
Sozusagen die Grundtrefferwahrscheinlichkeit mal der Wurzel (falls jemandem nicht geläufig ist was hoch 1/2 zu sagen hat) von der Angreiferagilität durch die Verteidigeragilität......
Grundtrefferwahrscheinlichkeit ist in diesem Fall entweder die von der Waffe in der Item-Database festgelegte Wahrscheinlichkeit bzw. bei Monstern und unbewaffneten Helden 90% meines Wissens....
Ich hoffe IRGENDJEMAND kann mit dem was ich gerade palawert habe etwas anfangen ^^
achja...
2) Zugreihenfolge
Dieses Problem ist mir beim Spielen von Vampires Dawn aufgefallen o_O..... Größte Agilität ist nicht gleich erster Zug.... ^^ Alain war eindeutig die schnellste (also von der reinen Zahl her)... aber Asgar und Valnar kamen dennoch manchmal vor ihr zum Zug (dabei Valnar öfter da er schneller als Asgar war).....
Also habe ich es gleich ausprobiert.... und verschiedene Zufallsfaktoren an die Agilitäten der drei Charaktere in einem gesonderten SPiel gekoppelt und die Testergebnisse dann mit meinen "Alltagserfahrungen" mit den dreien verglichen...... Relativ endgültige Sicherheit bekam ich dann jedoch erst bei einem Test mit Grenzwerten, die dann entschieden ob sich jemals die Zugreihen folge zwischen den charakteren veränderte oder nur sehr selten bzw überhaupt.....
Dabei ist dann folgende "Formel" herumgekommen:
Vor jedem Zug wird folgende Rechnung mit der Agilität eines jeden Kampfteilnehmers vorgenommen:
Agilität * [Eine zufällige Zahl zwischen 0,9 und 1,1]
DANN wird verglichen und dementsprechend die Zugreihenfolge festgelegt... Bei einem Gleichstand würde ich spontan tippen dass eine 50:50 Chance besteht dass dann der eine... oder halt der andere bevorzugt wird.. Da man aber als Großteil der Makerschaft die Makerinternen Zahlen ohnehin nciht zu Gesicht bekommt, wird man dies als Benutzer eh nicht merken o_O
Das wars soweit von mir... probiert es ruhig aus..... berichtigt mich ^^ es hilft ja allen (wer auch immer das gebrauchen kann)
--------------------------------------------------------------------------------------
Credit to:
- unfixable/Lachsen
- Cherry
- Squall83
- MagicMaker (mich^^)
- Gekiganger
- Darktraveler
- viele andere, die mir entfallen sind und deshalb nicht genannt werden können.
Was die wenigsten wissen: mit
rpg_rt.exe !TestPlay ShowTitle Window (das "!" ist das wichtigste), kann man das Spiel im Fenster starten, OHNE ein TestPlay zu machen (also F9 und so gehen dann nicht).
Bilderbewegung pausieren oder rückwärts:
Und das geht so:
Als erstes braucht man den Resource Hacker, ist soweit ich weiß beim E-Book dabei.
Dann öffnet man die Exe-Datei des Makers (also rpg2000.exe oder auch rpg2003.exe)
Jetzt öffnet man den Ordner RCData und dann den Ordner TFORMVEPICTUREEX.
Nun fast ganz runter Scrollen, es tauchen die Wörter "Caption = 'Rotation'" und "Caption = 'Ripple'" auf, noch etwas weiter steht "object Slider5: TSlider".
Etwas weiter gibt es eine Zeile in der "Min = 1" und "Max = 9" steht, das sind die normalen Einstellungen, also minimal Speed/Rotation 1 und maximal 9.
Statt der 1 und 9 jetzt beliebige Zahlen eintragen, z.B. -10 für min und 10 für max.
Der negative Wert steht jetzt logischerweise für eine umgekehrte Drehung, außerdem kann man so die Geschwindigkeit der Drehungen erhöhen, was auch manchmal recht praktisch ist.
Weiterhin alle folgenden MaxValue bzw. MinValue und Max bzw. Min durch die gewünschten Zahlen ersetzen, dann auf Compile Script und Speichern.
Nun müsste man im Maker in beide Richtungen drehen können, außerdem kann man in zwei Richtungen den Ripple-Effekt einsetzen und die Geschwindigkeit von Drehung und Ripple lässt sich erhöhen.
Allerdings gab es bei mir ein paar Fehler, bei denen ich auch nicht weiß, woran es liegt, könnte auch die Maker Version sein.
Beispielweise ging das Drehen gar nicht mehr, einfach das Projekt beenden und nochmal starten, dann müsste es gehen.
Oder es wurde die niedrigste Zahl (in diesem Fall -10) als Anfangsdrehung ausgewählt, die dann in die gewählte Drehung im Maker übergegangen ist, wobei die Zeit, die man einstellt, bestimmt, wie schnell die Drehungen wechseln (bei 0.0 erscheint sofort die gewünschte Angabe).
Dieser Effekt kann natürlich auch praktisch sein, wenn man will, dass sich etwas immer schneller dreht oder es gegen den Uhrzeiger beginnen soll.
Wenn man Null als Wert eingibt, bleibt das zu drehende Bild übrigens stehen (wenn man es vorher gedreht hat), sicher auch ganz praktisch.
Aber probiert es am besten mal selbst aus.
mfG Cherry
mfG Cherry
Powered by vBulletin® Version 4.2.3 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.