Den RPG:ache kannst du immer noch benutzen. Schreib einfach das Unterverzeichnis vor den Dateinamen:
Das Problem ist eher, dass du diese Pictures nicht über die normalen Event-Befehle verwenden kannst. Von der Rubyseite aus gibts da aber keine Probleme. Es kann außerdem noch sein, dass beim Verschlüsseln des Projekts (falls du das denn vor hast) die Unterordner nicht mit verschlüsselt werden. Zudem wird beim Importieren bei alpha-channel freien Bildern die Transparenz vom Maker gesetzt. Das kannst du aber auch mit einem geeignetem Grafikprogramm manuell machen.
Zur Wahrscheinlichkeitsrechnung: Cornix hat es imo richtig erklärt. Eine Steigerung der Trefferchance um 50% ist dasselbe wie eine Verringerung der gegnerischen Ausweichsrate um 50%. Lässt sich einfach über 1.0 - (1.0 - Trefferrate) * 0.5 berechnen und liefert imo auch ein sinnvolles Ergebnis.
Gut, bei Unterordnern geht das. Was nicht geht ist extra-Ordner via RPG:ache abrufen, ist was ich meinte. Ala Graphics/NeuerOrdner/
...
Das geht auch, du müsstest nur die Cache-Klasse ein wenig umschreiben.
Diese ist im RPG-Maker XP zwar versteckt aber du kannst sie auch aus dem RPG-Maker VX kopieren da diese dort beinahe identisch realisiert worden ist.
So, kleines Problem mit den Window-Klassen:
Ich hätte gerne Fensterinhalt, der nicht mitscrollt. also quasi ein Headerbereich, der immer stehen bleibt, und darunter ein Bereich, der normal über ox/oy scrollen kann.
Ich würde am ehesten die Funktionsweise von content ändern und content2 hinzufügen, sodass ich einmal scrollenden und einmal stehenden content habe. Problem ist, dass ich keinerlei Code der Klasse Window habe und aus der Dokumentation ich keinen Ansatz finde, wie ich da was ändern könnte. Ich wäre schon glücklich, wenn ich Position vom content ändern könnte, sodass dieser nicht immer 16 Pixel Abstand zum Rand hat.
Alternative Lösung wäre natürlich, zwei Windows übereinander zu legen, eins für den statischen und eins für den scrollenden Bereich, aber wenn ich die Funktionsweise vom Window content ändern könnte, fände ich das schöner.
Content ist ein Bitmap-Objekt. Du könntest eine weitere Window-Klasse machen, die z.B. von Window_Base erbt und darin ein zweites Bitmap-Objekt (content2 oder wie auch immer) instanzieren:
Content ist ein Bitmap-Objekt. Du könntest eine weitere Window-Klasse machen, die z.B. von Window_Base erbt und darin ein zweites Bitmap-Objekt (content2 oder wie auch immer) instanzieren:
...
Das würde so nicht funktionieren. Ein Bitmap kann man nicht sehen auf dem Bildschirm. Ein Bitmap enthält nur Daten.
Was man braucht um eine Grafik anzuzeigen ist ein Sprite. Einen sprite setzt man in einen Viewport, in diesem Fall den gleichen wie das Fenster, und übergibt dem Sprite ein Bitmap welches er darstellen soll.
Wie ich oben bereits geschrieben habe, erstelle einen Sprite und lege diesen an die richtige Stelle. Die Window Contents sind ebenfalls nichts anderes.
Mmhm danke für die Antworten, wird wohl auf ne zusätzliche Klasse / Sprite hinauslaufen - Ich hätts halt am saubersten (und wohl auch für andere Vorhaben potentiell hilfreich) gefunden,wenn ich irgendwie den sprite vom content-Bitmap modifizieren könnte und nicht nur das Bitmap selbst,
Wenn du etwas scrollen willst dann musst du ganze Sprites scrollen. Anders würde es auch garkeinen Sinn machen.
Jedes separates Element sollte sowieso ein eigener Sprite sein sofern du größere Möglichkeiten offen halten willst.
@Cornix Nicht ganz richtig, contents ist zumindest in den Windowklassen der Standardskripts ein Bitmap-Objekt, kein Sprite-Objekt. Für die Anzeige von reinem Text genügt eine Bitmap, alle anderen Window-Klassen kommen auch damit aus, sieh nach
Das Objekt ".contents" ist zwar ein Bitmap, ein Bitmap kann aber ohne sprite nicht dargestellt werden.
Der Sprite ist in dieser Hinsicht das Window selbst dessen Bitmap nunmal das ".contents" Objekt ist.
Du kannst mir gerne ein Script schreiben mit welchem du ein Bitmap ohne einen Sprite darstellst um mich von dem Gegenteil zu überzeugen.
Hab ich auch nie behauptet, aber er hat ja bereits eine Windowsklasse. Und dass er sich darin um die Anzeige, das Aktualisieren, usw. des Textes kümmern muss sollte klar sein.
Ich hab was ähnliches gemacht, ich weiss allerdings nicht genau, ob sich das auch auf Scrollbare Windows anwenden lässt, wobei es Window_Command mit ner Headline ist und daher eh eine Subklasse von Selectable.
Ich persönlich hab mir ne zweite Klasse erstellt, also in meinem Fall Window_Command_Headline, Klasse redefinieren oder von ihr Ableiten dürfte aber mit leicht anderer Herangehensweise auch funktionieren.
In Window_Command findest du übrigens auch eine Standard-Contents-Erstellungsanweisung afaik, kannst dich daran ja Orientieren und das passend Semantisch auf Fenstergröße umstellen.
Der Trick ist jetzt, einfach alle an relevanten Operationen die Koordinaten zu modifizieren - in den meissten Fällen wird das also y+Interger(Headgröße) sein - bzw +AnzahlAnZeilenVomHeader - je nachdem was passiert
Ich weiß nicht 100%ig ob das ein Ansatz ist, der auch für Selectable funktioniert, aber für Command hat die herangehensweise wunderbar funktioniert.
Mich plagt eigentlich schon die ganze Zeit das Laden von Musik im RPGXP. Bei der Suche hab ich nichts dazu gefunden, daher scheint es kein generelles Problem zu sein. Die Sache ist jedenfalls:
Wenn das erste Mal eine BGM oder ME abgespielt werden soll, hängt das Spiel für 5 Sekunden. Die Musik wird noch nicht abgespielt, aber auch alles an Grafik friert ein. Erstes Mal heißt dabei jedes Mal, wenn das Spiel geöffnet wird. So dauert es 5 Sekunden, bis der Titelbildschirm angezeigt wird. Wenn ich die BGM für den Titel abstelle, häng tes stattdessen bei der ersten Map mit BGM usw. Mit den MEs genau das Gleiche.
Die Ladezeit gibt es immer nur beim ersten Mal, wenn z.B. beim Titel BGM1 gespielt wird und bei der ersten Map BGM2 lädt es nur beim Titelbildschirm und alle weiteren BGMs werden sofort abgespielt. Es ist dabei anscheinend egal, was für eine BGM beim ersten Mal gespielt wird, importiert oder aus der RTP, kleine oder große Datei, kein Unterschied. Das Problem tritt auch in jedem Projekt auf, auch in einem neu gestarteten Projekt ohne Inhalt / Imports.
Ist das Problem bekannt und gibt es Lösungen um die Ladezeit wegzukriegen? Beim Testen ist es doch ziemlich nervig wenn man jedes Mal, auch wenn man Kleinigkeiten testet, erstmal die Verzögerung abzuwarten.
Ich habe zwar noch nie etwas dergleichen gemerkt aber ich würde sagen das klingt stark danach, dass einfach die Bibliotheken und Scripte zum Abspielen von Musik geladen und initialisiert werden müssen.
Das kannst du nicht umgehen.
Das selbe Problem habe ich auch. Zumindest bei mir tritt das Problem aber nur bei MIDI-Dateien auf. Ist übrigens auch im Editor so. Wenn ich dort das erste Mal eine MIDI-Datei abspielen will, hängt das ganze kurz. In Winamp/Mediaplayer/etc habe ich dieses Problem aber nicht, dürfte also ein Problem der Engine sein, und keines von meinem PC.
Das Problem scheint eines vom RPG Maker selbst zu sein, und zwar in jeweils Kombination von bestimmten Dingen. Dabei können sowohl Projekte als auch der diverse Soft- und Hardwaregründe sein.
Ich hab die Erfahrung gemacht, dass ich bei den meissten MEINER Projekte Probleme hab, mit extrernen aber nur bei manchen, während Freunde von mir bei meinem Projekt wo es bei mir hakt keine Probleme haben.
Ich habe eine behelfsmässige Lösung für das Problem gefunden, die alle Lieder mit einem Schlag einlädt und danach nicht mehr Laden muss. D.h. auf betroffenen PCs würde einmal dieser Hänger 5 Sekunden bei jedem Spielstart auftreten, danach nicht wieder bis zum Neustart der exe.
(Zum Testen von Scripten empfehle ich allerdings eher, entsprechende BGMs einfach auszumachen, und auch das Script rauszukommentieren, wenn man das Spiel häufig startet) (oder ihr fragt drumherum ein unless $DEBUG ab). Eigentlich würd ich gern halb-Credit dafür wem geben, da ich darauf über ein Script (Scene_MusicPlayer), welches ich im rpg-studio gefunden hab drauf gekommen bin und die Lösung nur copy/paste/edited hab, leider ist kein Name im Script selbst und der Link den ich mir dazu aufgeschrieben hab ist tot.
Dies wäre in Scene_Title, direkt unter der if $BTEST abfrage, also direkt über dem Laden der Daten dann, wenn ihrs mögt.
Das führt zwar zu einer knapp längeren Ladezeit im Title, dafür danach nicht mehr. Gut fürs Release (Leute die die Hänger nicht haben merkens garnicht, Leute die es haben, merken es wesentlich seltener, was angenehmer sein sollte) oder das Testen bestimmter Szenen.
Ach? Okay, ich hab die Variante, dass beim ersten Laden JEDES Files das Problem auftritt, deshalb hatte ich es so interpretiert. File einmal geladen, gut, aber es hängt für Title BGM, Battle BGM, Map BGMs, BattleEnd-BGS - Vorausgesetzt, diese unterscheiden sich natürlich. Alles nur einmal. Für ebd. hilft die Lösung. Nur einmal hängen am Start find ich persönlich halb so wild ehlich gesagt.
ache kannst du immer noch benutzen. Schreib einfach das Unterverzeichnis vor den Dateinamen:
Zitieren
