Z.Priorität eines Pictures

Hi Zusammen,

ich habe folgendes Problem und gleich einhergehend auch eine große Bitte,
ich erstelle ein eigenes Menü mit Pics, da ich kein geübter Scripter bin habe ich das Menü bisher auf 2 Bilder (HG und Cursor) beschränkt; die anzuzeigenden Items möchte ich über ein kleines Script als Sprites - Bitmaps anzeigen lassen
um nicht die Übersicht mit den Pictures zu verlieren.

In dem Script "Icons Anzeigen" sind die Vorgänge zu finden. Jeweils Switches, dann falls true das und das bitmap - wird angezeigt.
Sehr simpel.

Nun hat der "Icon Hud" die z.Priorität 201, da diese über der Picture Priorität 36 liegt.
Das ist das Problem. Ich möchte dass die Icons die das Script anzeigt über dem Bild des Hintergrundes jedoch unter dem Cursor-Bild liegen.
Das heißt Unterste Ebene : Bild 35 Hintergrund, dann Icon Hud (z = 201), und dann Bild 36 (Cursor).
Ich habe mir überlegt, dass man den Pictures doch auch eine Z = Priorität zuweisen können müsste, bin jedoch bis jetzt scripttechnisch ohne Erfolg geblieben und hab bereits in einem anderen Forum nachgefragt, in welchem mir mit sehr viel Enthusiamus leider jedoch ebenfalls
erfolglos "geholfen" wurde.

Daher hier die Frage kann man den z Wert eines Pictures seperat ändern? Über $screen.game_pictures(36).z = 8000 und wenn möglich auch mit erläutertem Ergebnis,

Jeder Scripter fasst sich bestimmt an den Kopf, warum ich den Cursor nicht Scripte, aber wie gesagt ich bin ein absolut ungeübter Scripter und würde meinen "Workflow" um extrem unterbrechen müssen.

Ich werde das Projekt in den Anhang hängen um das Problem genauer erfassbar zu machen...

(Erst die Fledermaus anklicken, dann Esc drücken, dann müsste das Problem erkannt werden)

Ich danke schonmal im Vorraus und würde mich sehr über eine Antwort freuen.

Gruß Suirat

Ohne es jetzt runtergeladen zu haben, warum möchtest du es so "kompliziert" lösen? Ich finde es wesentlich einfacher, das ganze einfach in einem simplen Event zu bauen, da hast du auch absolut keine Probleme mit dem Z-Wert.

Du erstellt ein Event mit Parallel Process-Trigger und lässt es den Hintergrund (Picture 1) des Menüs anzeigen. Hinter dem Show-Picture befehl packst du ein 10 Frame langen Wait-Befehl, damit der Maker das Event nicht ununterbrochen durchrasselt. Danach kommen die Menüpunkte. Nehmen wir jetzt einach mal an du hast drei davon auf der Map und alle untereinander angeordnet:

Alle 3 bekommen den Event Touch Trigger. Danach legst du drei Schalter an (nennst du z.b. Menüpunkt 1, 2 &3). Auf der ersten Seite der drei Events aktivierst du nun den Schalter, der zu dem Event gehört, auf dem du gerade "stehst".

Sieht beim ersten Menüpunkt-Event dann so aus:
Show Picture 4: Curser [x300, y100]
Control Switch: Menüpunkt 1 AN
Control Switch Menüpunkt 2-3 AUS

Bei Menüpunkt 2:
Show Picture 4: Cursor [x300, y150]
Con. Swi.: Menüpunkt 1 AUS
Con. Swi.: Menüpunkt 2 AN
Con. Swi.: Menüpunkt 3 AUS

usw.

Anschließend bekommt jedes der drei Events eine zweite Seite mit Action Button-Trigger und als Condition den dazugehörigen Menüpunkt-Schalter. Dadurch hast du garkeine Probleme mit Z, denn das Bild mit der höchsten Nummer ist immer oben. Hintergrund wäre hier eben Bild 1, der Cursor Bild 4. Im Content-Fenster der zweiten Seite kannst du dann den gewünschten Inhalt eintragen (z.b. Teleport usw.)

So mache ich das jedenfalls. Sicherlich gibts auch noch elegantere Möglichkeiten.

Edit: Du kannst unter dem Show Picture: Cursor natürlich auch noch einfache Töne abspielen, damit es auch klick macht wenn du später durch das Menü navigierst.

Danke für deine Antwort, aber ich denke du hast das Problem falsch verstanden.
Das Menü ist schon komplett fertig, was die Navigation betrifft, ich habe zudem noch einige Huds die Pictures verbrauchen, das erste Picture was ich, ohne in die Hud Picture eingreifen zu müssen benutzen kann ist das Pic Nr. 35.
Ich denke wenn man das Projekt downloadet ist schnell erkennbar was das eigentliche Problem ist.

Ich lasse es Picturebasiert, da so im Hintergrund ein Teil der Map zu sehen ist und ich diesen Effekt einfach angenehmer finde. Die Cursor-Bewegung findet über Loops und Lables statt, da ich keine Variablen oder Switches unnötiger Weise verschwenden wollte, und das ist meiner Meinung nach auch die einfachste, übersichtlichste und nachvollziehbarste Methode.

Wie gesagt einfach mal das Projekt anschauen um einen besseren Überblick zu erhalten.

Ich hoffe es findet sich jemand, der sich mit dem seltsamen und meiner Meinung nach auch komplizierten Problem ausseiandersetzten kann.

Gruss Suirat

Hallo Suirat,
Suche im Sprite_Picture nach der Zeile 62.
Diese ersetzt du durch diesen Code:

Code:

---

self.z = @picture.number + 201
if @picture.name == "cursor"
self.z = 5000
end

---

Wenn du jetzt noch den Bildnamen deines Cursors auf "cursor" änderst, sollte das ganze funktionieren, wie du es willst, auch wenn ich dir ernstlich empfehlen würde, dir einen anderen Workflow zuzulegen.

Entschuldigung bereits im Vorhinein dafür, dass ich einen derart alten Thread wieder pushe. (Um das Problem geht s mir gar nicht mehr). Was ich jedcoh sehr interessant fand und gerade eben zum ersten mal gelesen habe, war der Hinweis mit dem Workflow - mittlerweile hat das Projekt einen großen Schritt nach vorn gemacht, was die technischen Komponenten anbelangt und ich merke wie viel Preformance das ganze Game zieht. Bei meiner vollen und mit allen Features vollgepadkten (80x80 großen) Testmap ist es unmöglich ohne Ruckler zu spielen. Ich muss nun das Ace-Engine Xp Update von Terv implementieren um zumindest noch einigermaßen Preformance zu sichern.

Was genau meinst du mit Workflow (Die Event basierten Funktionen - hab ich falsch 'evented') oder allgemein dass ich das alles ohne Scripts mache?

Gruß Suirat

Ich glaub es ging eher darum, dass es nicht sonderlich elegant ist Eventcode und Rubycode so zu vermischen. Es lässt sich schwerer lesen, verstehen und warten. Und ein Menü kann man auch genauso gut komplett in Ruby oder komplett über Events lösen.

Zitat:

---

Bei meiner vollen und mit allen Features vollgepadkten (80x80 großen) Testmap ist es unmöglich ohne Ruckler zu spielen.

---

Viele RGSS Scripte sind schlecht gecodet und verbraten unnötig viel Performance. Oder aber sie sind einfach nicht optimiert, weil es für ein einzelnes Script auch oftmals nicht erforderlich ist. Es hat aber vermutlich auch keiner Lust alle deine Scripte durchzusehen und zu optimieren. Wenn du ungefähr sagen kannst, welches Script so sehr an der Performance zieht, kann man dir schon eher weiterhelfen.
Prinzipiell lässt sich auch ein featurereiches Spiel ohne Performanceprobleme umsetzen.
Der Umstieg auf die VX Ace Engine könnte tatsächlich helfen, weil dort auch Rubyscripte deutlich schneller ausgeführt werden. Allerdings hat der VX Ace eine andere Map-Engine. D.h. du musst eine eigene Map-Engine schreiben, die wiederum eine Menge Rechenzeit frisst. Wie viel du also am Ende an Performance rausbekommst ist ungewiss.

Zitat:

---

Zitat von -KD-

Ich glaub es ging eher darum, dass es nicht sonderlich elegant ist Eventcode und Rubycode so zu vermischen.

---

Genau das meinte ich.
Wenn man ein Menü auf einer Map haben will, sollte man entweder mit Picturebefehlen arbeiten oder aber komplett scripten und ein Bild der Map im Hintergrund halten.
Hier gibt es genug talentierte Leute, die dir dabei helfen können. :)

Grüße,
Dr. Stein.