Ergebnis 1 bis 20 von 215

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

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    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.

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

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

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

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

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

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

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

  9. #9
    Das hängt damit zusammen, dass der Maker nicht ordentlich cacht. Die Fogs werden jedes Mal neu aus der Datei geladen. Im Scripteditor ab Zeile 108 findest du
    Code:
    if @fog.bitmap != nil
      @fog.bitmap.dispose
      @fog.bitmap = nil
    end
    Hier die Zeile mit dem Dispose auskommentieren (# davor schreiben), so dass da steht
    Code:
    if @fog.bitmap != nil
    #  @fog.bitmap.dispose
      @fog.bitmap = nil
    end
    Aber Achtung: Wenn du viele verschiedene Fogs einsetzt und die nie gelöscht werden, kann das auf Dauer den Speicher belasten. Ein Kompromiss wäre, Fogs pro Map zu cachen. Das sieht
    dann so aus:
    Code:
    if @fog.bitmap != nil
            #  @fog.bitmap.dispose
            (@used_fogs ||= {})[@fog.bitmap] = true
            @fog.bitmap = nil
          end
    Und dann bei dispose (ab Zeile 58)
    Code:
     def dispose
        # Dispose of tilemap
        @tilemap.tileset.dispose
        for i in 0..6
          @tilemap.autotiles[i].dispose
        end
        @tilemap.dispose
        # Dispose of panorama plane
        @panorama.dispose
        # Dispose of fog plane
    
        # edit
        if @used_fogs
          @used_fogs.each_key {|fog| fog.dispose unless fog.disposed?}
          @used_fogs.clear
        end
    
        # Dispose of character sprites
        for sprite in @character_sprites
          sprite.dispose
        end

    Geändert von -KD- (19.07.2012 um 17:48 Uhr)

  10. #10
    Genial! Velen Dank für deine schnelle Hilfe.

  11. #11
    Guten Morgen,
    ich habe eine Frage und zwar habe ich die Schriftfarbe meines Projekts von weiß in schwarz geändert, jedoch gibt es noch zwei Dinge,
    die noch immer in weißer Schrift angezeigt werden und bei denen ich im Script-Editor nichts finde. Dies sind zum einen die Auswahlmöglichkeiten
    des Shop processing (Buy, Sell, Quit), zum anderen ist das die Anzeige "miss" im Kampfsystem. Kann mir jemand sagen wo ich das ebenfalls
    ändern kann?

  12. #12
    Wo genau hast du die Font.color in deinem Projekt geändert?
    Für diverse Fenster werden im XP fest vordefinierte Farben verwendet welche du in der Klasse "Window_Base" ändern kannst.
    Für die Schrift im Kampfsystem musst du die Klasse "RPG::Sprite" ändern welche jedoch nicht im Script-Editor vorhanden ist sondern versteckt im RGSS.
    Du kannst den Quellcode der Klasse in der Hilfedatei des Makers betrachten und musst ihn im Script-Editor überschreiben um die Schriftfarbe ändern zu können.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •