[Gelöst] Variable im Kampf und im Menü anzeigen lassen
Hallo zusammen,
ich habe eine ganz einfache Frage:
Wie kann ich im Kampf neben der Statusinfo des ersten Helden eine Variable anzeigen lassen, die nach jeder Aktion aktualisiert wird? Neben den restlichen Helden bräuchte ich auch jeweils eine Variable, aber nicht die gleiche.
Die gleiche Variable bräuchte ich auch noch im Menü - Für jeden Helden eine.
Danke schon mal im Vorraus!
ich habe eine ganz einfache Frage:
Wie kann ich im Kampf neben der Statusinfo des ersten Helden eine Variable anzeigen lassen, die nach jeder Aktion aktualisiert wird? Neben den restlichen Helden bräuchte ich auch jeweils eine Variable, aber nicht die gleiche.
Die gleiche Variable bräuchte ich auch noch im Menü - Für jeden Helden eine.
Danke schon mal im Vorraus!
hmm... erstmal natürlich die variable haben... willste sie in nem textfeld, einfach messagescripts, wie zb hermes laden. wenn ohne, einfach den RGSS-Textbefehl schreiben, und als string "#{@variable}" tippen, z.B. "HP: #{@HP}/#{@maxHP}". die position des textes kannste dann abhängig von den koordinaten des players/events machen. zum aktualisieren der daten erstellste eine "update" funktion, und ggf auch eine "dispose" funktion, sowie "initialize". in spriteset_map kannste dann in entsprechenden stellen (leicht zu erkennen am namen) diese funktionen aufrufen lassen, und die variablen werden so jeden frame aktualisiert 
Greetings,
Evrey

Greetings,
Evrey
-
Werbung -
1plus3
-
Nuuuhminaaah
-
compétences(Dieser Tab ist rein satirisch.)mes compétences
max.
Maps machen
Musik machen
Scripts machen
Story ausdenken
Pixeln und so
Events proggen
-
mes projets-
Silentium
Name: Silentium
Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)
Story
NPCs
Scripts
Ressis
Maps
Gesamt(3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²
(Die Tabelle erfüllt lediglich satirische Zwecke.) -
OnyxEine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.
Warnung!
Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:- Compiler - Das Drachenbuch [978-3-8273-7097-6]
Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.
- Computerarchitektur [3-8273-7016-7]
Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.
Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3). - Compiler - Das Drachenbuch [978-3-8273-7097-6]
-
-
enfinJe ne peux pas parler français.
C'est tout ce que Goodle et les restes de cours de français.
also erstmal ersetze in Window Base, zeile 184, den abschnitt, der mit draw actor bezeichnet ist, ich glaub 184 bis 196, durch das hier:
so nun kannst du in jedem script, wo du diese zeile findest,
die durch diese ersetzen:
die 1 bei 'i + 1', kannst du durch die variable festlegen, die verwendet werden soll.
also für 15:
variable 15, erster actor
variable 16, zweiter actor
...
variable 18, vierter actor
also die zahl 1, die du ersetzt gibt die variable und die 3 folgenden variablen an. also 4 variablen, für jeden actor eine.
ich habs jetzt so gemacht, weil mir dein kampfsystem nicht bekannt ist!
im standart-kampfsystem findest du die besagte zeile in Window Battle_Status zeile 46
im standart-menü findust du sie Window_MenuStatus zeile 32
hoff ich hab mich verständlich genug ausgedrückt.
cow
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#-------------------------------------------------------------------------- # * Draw State # actor : actor # x : draw spot x-coordinate # y : draw spot y-coordinate # width : draw spot width #-------------------------------------------------------------------------- def draw_actor_state(actor, x, y, variable = 0, width = 120) text = make_battler_state_text(actor, width, true) self.contents.font.color = actor.hp == 0 ? knockout_color : normal_color unless variable <= 0 self.contents.draw_text(x, y, width, 32, $game_variables[variable].to_s + " " + text) else self.contents.draw_text(x, y, width, 32, text) end end |
so nun kannst du in jedem script, wo du diese zeile findest,
|
|
Quellcode |
1 |
draw_actor_state(actor, actor_x, 96) |
die durch diese ersetzen:
|
|
Quellcode |
1 |
draw_actor_state(actor, actor_x, 96, i + 1) |
die 1 bei 'i + 1', kannst du durch die variable festlegen, die verwendet werden soll.
also für 15:
variable 15, erster actor
variable 16, zweiter actor
...
variable 18, vierter actor
also die zahl 1, die du ersetzt gibt die variable und die 3 folgenden variablen an. also 4 variablen, für jeden actor eine.
ich habs jetzt so gemacht, weil mir dein kampfsystem nicht bekannt ist!
im standart-kampfsystem findest du die besagte zeile in Window Battle_Status zeile 46
im standart-menü findust du sie Window_MenuStatus zeile 32
hoff ich hab mich verständlich genug ausgedrückt.
cow
zum Lesen den Text mit der Maus markieren



!