Jede Grafik hat einen z Wert, der die Zeichenreihenfolge bestimmt. Wenn das HUD-Fenster einen höheren z-Wert hat als der Cursor, so wird der Cursor dahinter angezeigt. Fenster (die von Window_Base erben) haben immer den z-Wert 100. Du musst den Z-Wert deines Cursors also nur entsprechend erhöhen.


Neben dem z-Wert ist auch noch der Viewport entscheidend. Jede Grafik wird in einem Viewport angezeigt, der selbst wiederum einen z-Wert hat. Werden zwei Grafiken in verschiedenen Viewports angezeigt, so entscheidet der z-Wert der Viewports, nicht der der Grafiken. Wenn also das Verstellen des z-Werts nicht funktioniert, dann liegt dein Cursor evtl. in einem Viewport, der hinter den Fenstern angezeigt wird.

(Die beiden Screens sehen btw. ziemlich stylisch aus =D)

Das heisst im Klartext, dein Cursor is ein Actor und kein Cursor aus einem Mausscript?
Wenn ja, dann versuch mal ob du in dem move_route event-befehl sowas findest wie "allways on Top",
wenn das auch nich funktioniert, dann musst du die entsprechenden scripts durchschaun, ich weis jetzt auch
nicht in welchem das genau is, ich würde aber mal in game_actor und scene_map schaun, ich weis jetzt leider
gerade nich auswendig welche Klasse aus dem RGSS für die grafische darstellung des Helden da is, aber eigentlich
müsste in scene_map ne Instanz dazu da sein, wenn auch etwas verschachtelt.

gruß agy

Der Held gehört zum Viewport der Map und wird daher auf derselben Höhe wie die Map angezeigt. Und die wird unter den Fenstern angezeigt - sonst würdest du die Fenster gar nicht sehen können. Was du machen kannst, ist den Helden auf einen höheren Viewport zu versetzen. Dafür musst du die Zeile

in Spriteset_Map durch die Zeile

ersetzen. Dann liegt der Held im selben Viewport wie die Pictures und wird daher über den einfachen Fenstern angezeigt.

Ausnahme: MessageFenster, die liegen so ziemlich über allen. Wenn der Held auch über den MessageFenstern liegen soll, so musst du schreiben:


Allerdings haben all diese Eingriffe weitere Auswirkungen: So funktionieren manche Befehle wie das Flashen des Heldencharacters u.ä. nicht mehr. Wenn du dich etwas mit Ruby auskennst, würde ich eher dazu raten eine eigene Cursor-Klasse zu schreiben (und evtl. noch mit einem Mausscript zu verbinden, damit die Bedienung etwas komfortabler wird).

naja, maus-scripts mit cursor gibt es ja zu genüge, also warum das rad neu erfinden ^^'
aber mir wären da die ganzen koordinaten-abfragen zu stressig, ich mach das eig.
nur in menüs ^^' (vor allem bei dem was ich den screens entnehme, da wären die
ganzen range-abfragen ja ein fürchterliches gefiesel ^^')
und nachdem das ja momentan weitestgehend mit events gelöst zu sein scheint
denke ich mal, dass es eine komplett-umstellung wäre ^^

wie dem auch sei, in einem punkt muss ich ka(m)i recht geben, für den spieler
wäre maussteuerung wahrscheinlich die angenehmste lösung ^^
schau einfach mal in itzamna rein, evtl. findeste ja n script, dass das macht,
was du dir vorstellst.

gruß agy

Naja, es wäre, denke ich, nicht ein so großer Aufwand das Mausscript so zu schreiben, dass auch Events per Mausklick aktiviert werden können. Dann kann das gegenwärtige System sogar beibehalten werden.
evtl. gibt es sogar schon Mausscripte, die das so handhaben.

hmmm... müsste das maus-script dann nicht in jeder main-iteration prüfen ob sich das maus_rect mit einem von allen ranges aller event-rects (position...width/height) schneidet?
in meinen augen wäre das massiev inperformant ._. vor allem: je mehr events desto mehr geht dann die performance in keller ._.

keine ursache, aber ich hab nicht viel getan ^^' wie immer war unser programmier-lexikon ka(m)i die lösung auf die frage ^^'

Zitat

hmmm... müsste das maus-script dann nicht in jeder main-iteration prüfen ob sich das maus_rect mit einem von allen ranges aller event-rects (position...width/height) schneidet?
in meinen augen wäre das massiev inperformant ._. vor allem: je mehr events desto mehr geht dann die performance in keller ._.

Du packst einfach alle Events, die sich innerhalb des Bildschirms befinden, in einen Array und iterierst nur noch über diesen Array. Immer wenn ein Event sich bewegt (was ja nur alle paar Frames passiert) muss es selbst prüfen, ob es den Bildschirm verlässt oder nicht. Noch effizienter geht es, wenn du die Events in eine Art Gitternetz fallen lässt, so dass du in konstanter Zeit prüfen kannst, welche Events in welchem Quadrat der Map stehen. Dann brauchst du nur noch ein Quadrat (was z.B. aus 4*4 Feldern bestehen könnte) abfragen.
Also ein ähnliches Prinzip wie die Anti-Lag Scripte. Ließe sich auch mit einem davon kombinieren.

ja, aber das wäre für meinen geschmack ein epischer aufwand ^^' potentiell gibt es in der programmierung schier unendlich viele möglichkeiten jedes problem zu lösen, blos nutze-aufwand mit einberechnet...

in dem fall würde ich einfach sagen, es wäre ideal generell von events weg zu gehn und es komplett zu schreiben, das wäre in meinen augen die beste lösung.

gruß agy

Zitat von »agenty«

ja, aber das wäre für meinen geschmack ein epischer aufwand ^^'

In Aborakon wird so ein System auch genutzt. Der Aufwand hält sich da eigentlich sehr in Grenzen. Es sind nur die moveto, move_up, move_down etc. Methoden in Game_Character, die überschrieben werden müssen. Das Gitternetz ist dann einfach ein Array, dessen Index sich aus (mapbreite * y + x)/blockgröße berechnet. Ich find nicht, dass das mehr Aufwand ist als ein eigenes Point&Click-System zu schreiben. Immerhin könnte er danach seinen Eventcode beibehalten.

ich denke, bevor wir noch länger off-topic bleiben resigniere ich hier an dieser stelle besser ^^'
du bist eh der bessere programmierer von uns beiden und früher mein ruby-mentor gewesen ^^'
dann sag ich danke für deine bemühungen und deine belehrungen ^^

gruß agy