diäitsch's Problem Sammelthread (Xp) :D

[Todu]

Ist bei einige der Klassen, die die Enterbrain-Leute als Kern des RGSS gesehen haben so. GLücklicherweise ist in der Hilfedatei zu allein nicht-Ruby-RGSS-Klassen der Sourcecode und gute Kommentierung zu finden.

[diäitsch]

Hallo Community,
ich hätte eine Frage bzgl. des KS des Makers.
Wenn ich während eines Kampfes ein Picture anzeigen lasse, legt sich dieses über den Windowskin, wenn ich z.B. Techniken auswählen will.
Was muss ich wo umschreiben, das sich der Windowskin über das Picture legt?
Meine zweite Frage wäre, wie ich es vermeiden kann, das nach dem Kampf das Fenster erscheint in dem drinsteht wieviel EP und Geld man gewonnen hat.
Ich hoffe jemand kann mir helfen.

MfG, diäitsch

[Cornix]

Das mit den Picturen ist ein wenig kompliziert. Es ist so, dass alle Arten von Grafiken welche auf dem Bildschirm dargestellt werden sollen in einen Viewport gepackt werden müssen.
Im Kampf sind zum Beispiel das Hintergrundbild und die Feinde in einem Viewport. In einem zweiten sind die Charaktersprites. In einem nächsten sind dann die Pictures. Und so weiter.
Die Fenster werden allerdings im RPG-Maker XP standardmäßig in keinen Viewport gepackt, demnach also in einen generischen standardviewport auf welchen du keinen Einfluss nehmen kannst.
Die Z-Position der Grafiken, also welche Grafik über einer anderen dargestellt wird, ist aber auch von ihrem Viewport abhängig. Viewports besitzen ebenfalls eine Z-Koordinate und falls ein Viewport über einem anderen liegt so liegen gleichzeitig auch alle Sprites innerhalb dieses Viewports über allen aus dem anderen.

Um die Pictures nun also unter die Fenster zu schieben müsstest du den Fenstern einen Viewport geben und das wäre ein wenig mehr Arbeit, es würde vor allem gutes Verständnis von dem was man machen will erfordern.

Eine einfachere Lösung könnte natürlich für dich sein einfach die Höhe des Viewports auf welchem die Pictures gelegt werden zu beschränken insofern dieser garnichtmehr bis zu den Fenstern am unteren Bildschirmrand reichen wird.

In dem Script: "Spriteset_Battle" findest du dafür in Zeile 21 die Anweisung:

Code:

@viewport3 = Viewport.new(0, 0, 640, 480)

[Anmerkung: Parameter für einen Viewport sind: (x, y, width, height).]

Dieser Viewport ist derjenige welcher die Pictures umfasst. Wenn du die Höhe, also die "480" in dieser Zeile nun variierst werden die Pictures garnichtmehr bis zu den Fenstern reichen dürfen.
Versuche es einmal diese Zeile mit folgender auszutauschen:

Code:

@viewport3 = Viewport.new(0, 0, 640, 320)

Für dein zweites Problem versuche einmal folgendes:
In dem Script: "Scene_Battle 2" tauscht du die Zeilen 191 bis 194 welche lauten:

Code:

# Make battle result window
    @result_window = Window_BattleResult.new(exp, gold, treasures)
    # Set wait count
    @phase5_wait_count = 100

gegen diese Zeilen aus:

Code:

@status_window.refresh
    battle_end(0)

Das sollte eigentlich bereits alles sein was zu tun ist.

[diäitsch]

Danke, Cornix. Das zweite Problem hat sich somit gelöst. Mit der Lösung des ersten Problems bin ich noch unzufrieden.
Das ganze sieht nämlich so aus:

Das Picture muss an dieser Stelle stehen, damit die Battler nicht plötzlich auf den Bäumen stehen.

[Cornix]

So wie es aussieht hast du dann keine andere Wahl als das Kampfsystem zu einem gewissen Grad neu zu scripten. Dieses Problem kann man leider nicht so einfach mit einer "kleinen" Copy-And-Paste Aktion lösen.
Das Hauptproblem ist einfach wie die Windowklassen und die übrigen Grafiken in den Standardsystemen des Makers getrennt werden.
Alle Pictures, der Hintergrund, die Charaktere und das drum und dran sind in der Spriteset_Battle Klasse untergebracht, genauso wie auch die Viewports.
Während alle Windows direkt in der Scene eingebunden sind und deswegen nicht auf die Viewports zugreifen können.

Was du natürlich versuchen kannst ist einen Viewport in die Scene zu setzen und die Windows daraufhin umzuschreiben diesen Viewport zu verwenden. Das wäre ziemlich hässlich (aus Programmierersicht gesehen) und auch generell ein schlechter Stil aber es wäre wahrscheinlich vergleichsweise einfach und schnell erledigt.

Was man dabei allerdings erwähnen sollte, ist, dass es dir danach sehr viel schwerer fallen wird in der Zukunft noch Erweiterungen oder Veränderungen am Kampfsystem durchzuführen weil wir nicht wissen wie dein Kampfsystemscript aussieht und bei wachsender Unordnung wegen vieler kleiner Änderungen auch nicht den Nerv aufbringen werden uns den gesamten Code durchzulesen und ihn zu analisieren.

Hier nocheinmal eine Zusammenfassung wie es relativ schnell gelöst werden könnte.
Window_Base und Sub-Klassen erweitern sodass man im Konstruktor einen Viewport angeben kann. Für die Kompatibilität mit anderen Scripten natürlich für den default Viewport "nil" angeben im Konstruktor.
Also als Beispiel:

Code:

class Window_Base
  def initialize(x,y,width,height,viewport = nil)
    super(viewport)
    [...übriger code...]
   end
[...]
end

Dann die passenden Window-Klassen welche du im Kampfmenü verwendest (und deren Oberklassen falls vorhanden) finden und auch deren Konstruktoren anpassen um ebenfalls einen Viewport übergeben zu bekommen. Analog zum Base-Window.
Dann in der Scene_Battle einen Viewport erschaffen, diesem Viewport einen Z-Wert unterhalb des @viewport_3 im Spriteset_Battle geben, also "@scene_battle_viewport.z = 150" zum Beispiel da der Viewport 3 standardmäßig den Z-Wert 201 hat wenn ich mich recht errinere.
Und natürlich allen Windows in der Scene diesen Viewport im Konstruktor zuweisen.

Ist relativ gesehen wenig aufwand, bringt aber die oben angegebenen Nachteile. Es würde sich vielleicht direkt anbieten ein eigenes Kampfsystem zu scripten.

[Fatalis]

Ich weiß nicht ob es bei den Fenstern vom KS irgendwelche Besonderheiten gibt, aber würde es nicht reichen, z-Koordinate von Fenster und Picture entsprechend anzupassen?
Game_Picture hat zwar von sich aus kein z-Attribut, aber da man ja den kompletten Code von Game_Picture und Sprite_Picture hat könnte man recht einfach ein z Attribut hinzufügen. Eventuell würde es schon reichen, z vom Window ausreichend hochzusetzen, damit es über dem Picture liegt.
Ich hab mit dem Standard-KS gar nicht gearbeitet, deshalb weiß ich nicht was es da noch für Probleme geben könnte, aber ich würd einfach an der Stelle, wo das Fenster erzeugt wird, window.z = 1000 (nicht sicher welchen z-Wert Pictures standardgemäß haben) einfügen.
Ich arbeite jedenfalls auf der normalem Map mit Pictures, Windows und eigenen Sprites und über den z-Wert allein ließ sich eigentlich immer kontrollieren was wo oben ist, ohne mit Viewports zu arbeiten.

Ist so keine vollständige Lösung, ich weiß nicht sicher ob es so funktioniert, aber es wäre zumindest ein Ansatz.

[Cornix]

Die Z-Koordinaten kann man hier nicht nutzen aus dem grund da die einzelnen Grafiken, in diesem Fall Pictures und Fenster, auf einzelnen Viewports liegen und diese Viewports unterschiedliche Z-Werte besitzen. Viewports besitzen eine höhere Priorität wenn es um Z-Werte geht.
Besitzt ein Viewport A einen höheren Z-Wert als Viewport B dann besitzen alle Grafiken aus Viewport A immer einen höheren Z-Wert als jede Grafik aus Viewport B unabhängig davon wie man mit den einzelnen Z-Werten der Grafiken herumspielt.

[diäitsch]

Bevor ich zu meiner nächsten Frage komme, muss ich mal loswerden, dass ich es super finde, wie verlässlich diese Community doch ist,
wenn es um Problemlösungen geht.
Nun zu meiner Frage: Im Kampfbildschirm hat man neben den aktuellen Lebens- und Magiepunkte ja auch noch den Status stehen, welcher
normalerweise "[Normal]" ist. In meinem neuen Projekt werden Statusveränderungen keine Rolle spielen, daher kann diese Anzeige auch
weg, bloß wie? habe in der Library nichts gefunden... Natürlich kann man das Ganze auch via Picture überdecken, aber das lässt sich
doch bestimmt auch eleganter lösen, oder?

MfG, diäitsch

[Cornix]

In der Klasse "Window_BattleStatus" suchst du in Zeile 33 die Methode:

Code:

def refresh
    self.contents.clear
    @item_max = $game_party.actors.size
    for i in 0...$game_party.actors.size
      actor = $game_party.actors[i]
      actor_x = i * 160 + 4
      draw_actor_name(actor, actor_x, 0)
      draw_actor_hp(actor, actor_x, 32, 120)
      draw_actor_sp(actor, actor_x, 64, 120)
      if @level_up_flags[i]
        self.contents.font.color = normal_color
        self.contents.draw_text(actor_x, 96, 120, 32, "LEVEL UP!")
      else
        draw_actor_state(actor, actor_x, 96)
      end
    end
  end

dort löscht du die Zeilen:

Code:

      else
        draw_actor_state(actor, actor_x, 96)

Sodass die Methode im Nachhinein nurnoch wie folgt aussieht:

Code:

def refresh
    self.contents.clear
    @item_max = $game_party.actors.size
    for i in 0...$game_party.actors.size
      actor = $game_party.actors[i]
      actor_x = i * 160 + 4
      draw_actor_name(actor, actor_x, 0)
      draw_actor_hp(actor, actor_x, 32, 120)
      draw_actor_sp(actor, actor_x, 64, 120)
      if @level_up_flags[i]
        self.contents.font.color = normal_color
        self.contents.draw_text(actor_x, 96, 120, 32, "LEVEL UP!")
      end
    end
  end

Und nun sollte es eigentlich geschehen sein.

[diäitsch]

Oh, dachte das stände, wie auch vieles andere in lilaner Schrift irgendwo.
Vielen Dank, Cornix.^^

[Cornix]

Die Purpurne Syntax-Färbung ist lediglich für konstante Strings, also Zeichenfolgen die bereits fest im Programm stehen. Hierbei handelt es sich jedoch um einen Funktionsaufruf.

[diäitsch]

Hallo Community,
momentan arbeite ich an einem kleinen Projekt und habe ein sehr ärgerliches Problem.
Es geht um eine 49x45 Tiles große Map, welche Fackeln an den Wänden aufweist, insgesamt sind es 32.
Jedenfalls soll jede dieser Fackeln auch brennen. Nun wollte ich es umgehen, diese Map mit 32 zusätzlichen
Events zu belasten, also habe ich einen großen Fog erstellt, der die Flammen enthält. Dieser sollte sich alle 5 Frames
ändern, da die Flammen 4-fach animiert sind. Das Problem ist nur, dass das Spiel dann alle 5 Frames stockt...
Habe gerade mal probiert das ganze in ein riesiges (6272x5760 Pixel großes) Charset zu packen, dieses jedoch lässt
sich nicht in das Projekt importieren (von wegen unbegrenzte Charset Größen im Rpg maker Xp).
Zwar könnte ich diese 32 Events in weitaus weniger Charsets zusammenfassen, aber vielleicht weiß jemand von euch
eine bessere Lösung, würde das ganze eigentlich sehr gerne über den Fog regeln.

MfG, diäitsch