Input-Blocker? oO
Druckbare Version
Input-Blocker? oO
War das nicht der Grund, warum Fehler wie "Tastatur/Steuerung reagiert nicht" auftreten?Zitat:
Zitat von Cherry
Die Geschichte mit Alt/AltGr kann kein "Feature" von Windows sein, da man durch Einfädeln einer Tastenabfrage mit GetAsyncKeyState trotzdem Output für Alt/AltGr erhält.
Edit:
Ich nehme mal an, EB wollte bei Alt+Return kein DecisionKey_Hit resultieren lassen.
Edit²:
EndlessItems2k3
Switch[1006] ON und zurück auf die Map, wenn man Beenden drückt. (Falls man die Option nicht schon rausgepatcht hat.)
Mit dem Befehl <Open Menu> kann man anhand dem Inhalt von Var[3350]:
0 = Hauptmenü normal öffnen. Man wird auch nicht aus dem Menü rausgeworfen, wenn man Untermenüs schließt.
1 = Itemmenü öffnen. Verlässt man dieses, gelangt man wieder auf die Map zurück.
(1 bzw. alles darüber. Ich habe für die anderen Werte noch etwas vor...)
bekannte Inkompatibilitäten
Zitat:
Zitat von goldenroy
Da ich per PN eine Anfrage bekommen hab, den DirectItemEquipMenu-Patch auf das Skill-Menü zu erweitern, habe ich das einfach mal getan. Bin wohl doch noch nicht eingerostet.
DirectItemEquipSkillMenu-Patch (so in etwa)
https://dl.dropboxusercontent.com/u/...pSkillMenu.ips
HeldenIDs aus der Database, nicht Party.
Variable 3386 = HeldenID für Equip-Menü
Variable 3387 = HeldenID für Skill-Menü (3386 muss 0 sein)
Item-Menü: 3386 und 3387 auf 0 gesetzt
Es können auch Menüs für Helden aufgerufen werden, welche nicht in der Party sind.
Die Menüs werden über den normalen Call Menu Befehl aufgerufen.
Nice Work! Jetzt fehlt nur noch das Statusmenü, mal sehn wann das gewünscht wird :-D
Wunderschön. Perfekt für Leute, die sich wohl ein eigenes Menü machen wollen, aber aus Gründen das Item- oder Equipmenü nicht ersetzen möchten. :AZitat:
Zitat von elvissteinjr
..So und jetzt noch das Gleiche für Speichern, Beenden und Status! 8D
Ja normalerweise schon, aber wenn du das Hintergrundbild in die Grafik der Spielzeitanzeige reinschneidest, kannst duZitat:
Zitat von TwoFace
das System "überlisten".
So siehts bei mir aus:
http://share.cherrytree.at/showfile-11212/02menue.png
Hier das Bild dass die Grafik für die Spielzeitanzeige anzeigt:
http://share.cherrytree.at/showfile-...nu_time_fg.png
Und hier das Panorama:
http://share.cherrytree.at/showfile-11211/mountain.png
Ich denke über Bilder kann ichs besser erklären als in geschriebenen Worten.
Wär allerdings super wenn man das auch bei den Untermenüs machen könnte.
Edit: Wenn du möchtest fertige ich dir ein Template an, damit du weisst wo du das Spielzeit-Picture
transparent lassen musst um nicht alles zu verdecken.
Allerdings fällt mir gerade auf dass das Panorama eigentlich in der Hinsicht überflüssig ist, ausser als
Hintergrund für das Speichern-Menü. Aber für das Mainmenü ist es überflüssig.
Außer transparentWindowsEverywhere ist aktiviert weil dann die Fenster halbtransparent sind.
Sieht klasse aus! :eek:
Jo, so'n Template wär echt ganz geil.:AZitat:
Zitat von Mithra
Bitteschön:
http://share.cherrytree.at/showfile-...e_template.png
Da wo es Schwarz ist kannst du dein Hintergrundbild reinschneiden. Du kannst auch Leisten und Ränder
um die anderen farbigen Rechtecke einfügen. Alle farbigen Rechtecke müssen transparent sein, um nichts
zu verdecken. Ausser beim Menü wie Items, Fertigkeiten etc. kannst du Icons einfügen.
Grün = das Navigationsmenü
Rot = Spielzeitanzeige, da kannst du aber eine Grafik einfügen, so wie ich es z.b gemacht habe.
Gelb = Goldanzeige
Dunkelblau = Face
Helleres Blau = Ist das kurze Infofenster zu jedem Helden
Danke. :)
Das Plugin ist echt stark!Zitat:
Zitat von TwoFace
Besteht irgendwwie die Möglichkeit, Items, Waffen und Fertigkeiten mit Icons vor den Itemnamen darzustellen? Weil sonst lohnt es sich imo auch nicht unbedingt, vor die Menüpunkte im Standart-Menü Icons zu setzen.
Du kannst dir eigene Glyphen in die RPG_RT.exe reinhacken und diese per $a etc. anzeigen.
Hey Leute, ich wollte mal nachfragen ob es möglich wäre Bilder auch hinter dem Helden Anzeigen zu lassen?
Beim Destiny Patch gibt es ja diese Funktion, bei der man die Anzeige-Ebenen verschiedenster Dinge einstellen kann (u.a. auch der Pictures).
Leider aber nicht im Bezug auf den Hero. Natürlich müsste es irgendwie so funktionieren das die Bilder erst (z.B.) ab Bild 50 hinter dem Helden sind, alle anderen bleiben wie gehabt über ihm.
Ich habe bereits im Internet ein bisschen gesucht und habe gesehen, dass Cherry jemandem der danach gefragt hat, zum Patch der die Charaktergrösse aufhebt geraten hat.
Dieser wäre allerdings für meine Interessen unnütz...
Leider habe ich keine Ahnung von Programmieren usw. und ob dies überhaupt möglich wäre oder nicht, zu aufwändig oder nicht, oder vielleicht sogar schon besprochen wurde - Falls ja, tut mir leid :)
Was meinst du mit "Hinter dem Helden" ?
- Unter allen Charsets
- Direkt unter dem Heldencharset in der Rangliste der Anzeige in Y aufsteigend?
Ich erinnere mich daran, ich dachte eher an farbie Icons, so ähnlich wie auf den Beispielbildern fürs Menü weiter oben.Zitat:
Zitat von Corti
Oder geht das auch mit farbigen Icons, ich erinnere mich nur an einfarbige?
Geht nur für "einfarbig", also im Sinne von "Glpyhen sind weiss auf Schwarz und der weisse Teil wird mit Gradienten vor schwarzem Schatten in +1px in xy dahinter.
Den Namen wirkliche Farbicons verpassen geht nicht, da derzeit keine Möglichkeit zur Verfügung steht die Einträge in Auflistungen auszulesen.
Genau, ich meinte natürlich unter dem Helden (Charasets).
So das man halt auch Pictures in die Map einbinden kann, welche den Helden nicht verdecken. @Corti
Ok, dachte ich mir, danke trotzdem für die fixe Hilfe :)
Gibt es damit einen Weg, auch noch das normale Menü aufzurufen? Das bräuchte ich nämlich auch, und der EndlessItems-Patch von bugmenot haut mir ne Fehlermeldung raus (warscheinlich wegen anderen Plugins, die ich benutze).Zitat:
Zitat von elvissteinjr
Hast du zufällig noch elvis' DirectSubMenuPatch auf der RPG_RT gepatcht? Die Patches sind nämlich nicht kompatibel.Zitat:
Zitat von goldenroy
Ansonsten könnten noch die Zahlen der Fehlermeldung hilfreich sein.
Nein, hab ich nicht, die RPG_RT ist nur mit DynRPG gepatcht.Zitat:
Zitat von bugmenot
http://i.imgur.com/CPCgwsb.png
Fehlermeldung beim Drücken von ESC.
Folgendes Installiert, was mit dem Menü zu tun hat:
Patches: SaveSwitch (Stellt beim Anwählen der Saveoption einen Switch um), Endlessitems
Plugins: OrderSwitch (Wie bei Save, nur mit Order), QuitSwitch (Wie bei Save, nur mit Quit), MenuTweaks (Pfuscht etwas mit den Transitions rum, damits besser aussieht), InGameClock (Uhr im Menü und Custom Background)
Var[3350] wird fehlerhaft ausgelesen.
Ist die Var Array Size mindestens 3350? Schon vor dem Menüaufruf Var[3350] auf 0|1 gesetzt?
Ansonsten hier noch etwas zum Ändern der Var_ID von 3350 auf etwas selbst Festlegbares:
Einfach die beiden #3350 auf einen niedrigeren Wert setzen.Zitat:
Zitat von DynRPG.ini
P.S. (hat jetztnichtsdoch mit dem Fehler zu tun)
In EndlessItems ist schon ein QuitSwitch drin. (Switch[1006]) Weiß jetzt alsonicht, dass das Plugin verhindert, dass der Patch funktioniert.
Leider nein. Schon der originale DirectItemMenu Patch hat schon den Hauptmenü Code teilweise überschrieben. Und da der ganze Code etwas mehr Platz braucht, habe ich mich da weiter bedient.Zitat:
Zitat von goldenroy
Ich kann nicht sicher sagen, ob das an den MenuTweaks liegt, die Transistions sind aber ganz schön nah am veränderten Code(glaube ich aber nicht überschrieben). Mit DynRPG ist der Patch aber sicher kompatibel.
Hab die ID damit jetzt auf 1000 gesetzt und es nochmal versucht, klappt immernoch nicht. Und ja, 3350 war die ganze Zeit initialisiert und wurde auch vorher entsprechend auf 0 bzw. 1 gesetzt.Zitat:
Zitat von bugmenot
(Übrigens würde ich generell von Nr. 3350 als Default wegkommen, der BetterAEP Patch benutzt die schon Standardmäßig. 0: )
EDIT: Es war offenbar das QuitSwitch-Plugin, denn als ich das jetzt entfernt habe, gings. >>Hier<< der Link, kannst dir das ja mal angucken, wenn du willst.
Genau deswegen bietet sich die 3350 doch ganz gut als multifunktionelle SteuerVariable an (+kein Ausdenken noch unbenutzter IDs nötig). Muss man halt nur vor jedem EndEventProcessing / OpenMainMenu richtig belegen.Zitat:
Zitat von goldenroy
Und wegen der QuitSwitch_ID:
Zitat:
Zitat von DynRPG.ini
@elvissteinjr
Wegen dem Menüabbruch nach jedem SubMenü:
Vielleicht hilft's ja. Sitze momentan an anderen Dingen und habe für Menü-Angelegenheiten eher wenig Motivation.
Okay, Menüprobleme hab ich jetzt geklärt. Allerdings noch eine Sache - es gibt bestimmt einen relativ simplen Quickpatch, um folgende Anzeigen im Savemenü auszublenden, oder?
http://i.imgur.com/jqAZ2cM.png
Zitat:
Zitat von goldenroy
Zitat:
Zitat von DynRPG.ini
Danke! ^-^
Probier ich au glei mal.
Hat jemand zufällig ein paar Code-Fetzen zur Cursor-Navigation (horizontale Bewegung und Darstellung)?
Edit:
Und/oder eine Methode die ExFonts auszulesen + auszudrucken, ohne auf VocabStrings (das, was man in der Database angegeben hat) verweisen zu müssen?
P.S.
Wer sich jetzt fragt, was zur Hölle das sein soll: das ist die kommentierte LcfShopScene. (2k- und 2k3-Aufbau ist identisch, lediglich andere Adressverweise und Pointer)
Ich frage mich grad eher, wieso hier ständig blanke Codes gepostet werden. :O Muss man einfach entsprechendes im Hex-Editor umändern, bzw. reinkopieren? (wenn letzteres: woran merkt ein Laie, wohin es soll?)Zitat:
Zitat von bugmenot
Wohl eher mit nem Disassembler rangehen um editieren.
Falls irgendwann jemand nach ner kleinen Shopmodifkation fragt ist das für mich jedenfalls sehr hilfreich. Wobei der Shop auch wieder etwas ist, was man mit vorhanden Patches schon sehr gut mit Makercode selbst erstellen könnte.
Ohne wirklich viel selbst schreiben zu müssen:Zitat:
Zitat von G-Brothers
Farben!
Hier mal ein Beispiel:
Edit:
Zitat:
Zitat von DynRPG.ini
Und anderer Kleinkram: (kein halbierter Itempreis beim Verkaufen)
Edit:Zitat:
Zitat von DynRPG.ini
Wer den ShopEconomy Patch verwendet, sollte die oben genannten QuickPatches nicht verwenden.
Patch: Link to the Future
Oder wenn dir irgendwelche anderen Änderungen einfallen, können mindestens ein paar Leute weiterhelfen:
Wenn man mit dem 2k arbeitet, kann man sofort den HexEditor anwerfen und zu den oben angegebenen Adressen springen (4xxxxx minus 400C00). Farbzuweisungen sind im Format [6A xx], wobei man das xx ändern muss, Breiten-/Höhenangaben als [6A xx] bzw. [68 xx xx 00 00], x-/y-Positionen als [BA xx xx 00 00] bzw. [B9 xx xx 00 00]Zitat:
Zitat von elvissteinjr
...für den 2k3 muss man schon 2k_RT und 2k3_RT parallel im Disassembler offen haben. (Funktionsanfänge sind oben mit aufgeführt) Klingt schlimmer als es eigentlich ist. Man muss bloß etwas schauen und scrollen.
Ein bisschen aufwändiger wären Sachen wie +Liste geplanter Features rauskram+:Rabatt% beim Kaufen, Bonus% beim Verkaufen,begrenzte Anzahl kaufbarer Items (+durch Verkauf wieder aufstocken), begrenzte Anfrage des Shops (andere Bonus% beim Verkaufen, bis die Anfrage gedeckt ist... dann wieder normaler Verkaufspreis).
Noch aufwändiger wären Sachen, wie es sie im VX gibt: ausgerüstetes Item anzeigen, Stat-Änderung direkt im Shop anzeigen, etc.
Nur die Frage nach dem Cursor ließ den Post irgendwie leer wirken. (Die Frage stellte sich aufgrund des Shops.)Zitat:
Zitat von G-Brothers
Und: Pseudo-Brainstorming. Vielleicht hat ja jemand irgendwelche Ideen (Features oder whatever).
Das mit dem Adressen umrechnen ist ja klar. Derjenige muss dann aber in den meisten Fällen auch zwischen Befehlen und Werten zu unterscheiden wissen(wobei in deiner Auflistung doch viele Adressen für die Werte direkt angegeben sind).Zitat:
Wenn man mit dem 2k arbeitet, kann man sofort den HexEditor anwerfen und zu den oben angegebenen Adressen springen (4xxxxx minus 400C00). Farbzuweisungen sind im Format [6A xx], wobei man das xx ändern muss, Breiten-/Höhenangaben als [6A xx] bzw. [68 xx xx 00 00], x-/y-Positionen als [BA xx xx 00 00] bzw. [B9 xx xx 00 00]
Ist ja jetzt auch nicht wirklich für den "Laien" gedacht. Nen Hexeditor statt OllyDBG zu nutzen ist für mich bloß nen Krampf geworden.:D
Das Zeug hier reinzuposten kann ja nur helfen. Und wenn's nur darauf hinausläuft dass jemand die Idee kriegt dass das doch jemand für ihn anpassen könnte.
Für einen stark angepassten Shop kommt aber wieder die Frage auf, ob sich das überhaupt lohnt oder man sich nicht einfach einen eigenen skriptet.
Ich finds gut. Die Leute, die sich auskennen, können damit sicher was anfangen (ich zum Beispiel). Die anderen indirekt, indem sie Fragen stellen und irgendwer, der sich auskennt, bei der Beantwortung darauf zurückgreifen kann :)
Weil gerade in einem anderen Thread von etwas ähnlichem die Rede war(und es mir unglaublich weiterhelfen würde, höhö):
Wäre es möglich einen Patch zu bauen, der es erlaubt beim Abfragen von ausgerüsteten Items eine Variable anzugeben? Praktisch so ähnlich wie bei Kazesuis Dynamic-Variable-Pointer?
Ja. Die RPG::Actor-Klasse ermöglicht es, abzufragen welche Items auf den einzelnen Slots ausgerüstet sind.
http://rpg-maker.cherrytree.at/dynrp...1_1_actor.html
Okay, gut zu wissen. Jetzt muss ich von der Info bloß noch zu einem Plugin kommen. :hehe:
Sollte jemand Zeit und Lust haben sich dranzusetzen wäre ich überaus dankbar, ansonsten versuche ich mich solange selbst daran. Ich hab zwar keinen Schimmer von C++, aber man wächst ja an seinen Aufgaben!
EDIT:
Okay, ich geb's auf. So ganz ohne Grundlagen ist das doch etwas heftig. x_x
Funktioniert das Plugin etwa nicht (so wie du es haben willst)?Zitat:
Zitat von BDraw
Ansonsten lässt sich so ziemlich jedes Eingabefeld durch einen (noch nicht vorhandenen) PointerPatch anfunken. Das Problem ist nicht das ob, sondern das wohin mit dem ganzen Code?
Es funktioniert schon, aber es macht nunmal etwas anderes. Das Plugin lässt mich ja "nur" speichern, wie oft Item xy im Inventar/ausgerüstet ist. Dazu muss ich die ID angeben, aber gerade die suche ich ja.
Ich hab mir aber jetzt mithilfe des Dynamic Variable Pointers einen Umweg gebaut, der funktioniert. Ich schmeiße alle Helden außer dem, dessen Ausrüstung ich speichern will, aus der Party, frage jetzt mit dem Plugin bei jedem Item ab, wie oft es ausgerüstet ist, speichere die ID des Items wenn ich einen positiven Wert zurückbekomme und mache das solange bis ich entweder 5 ausgerüstete Items habe (die Obergrenze des Standardsystems) oder wenn alle Items durchgelaufen sind.
Verglichen mit der Abfrage, ob ein Char Item X ausrüsten kann also fast schon simpel, haha.
Mit deinem Code kann ich so leider nicht viel anfangen. Das ist sicher total nützlich und hilfreich, aber 90% davon ist für mich einfach zu hoch, weil ich von meinem Ausflug gestern Nachmittag abgesehen 0 Ahnung von C++ oder irgendeiner anderen Sprache derart habe. (Immerhin weiß ich jetzt, dass ich Variablen am Anfang definieren sollte. Oder so.)
Ich glaube, sein Code hatte mit dir wenig zu tun, daher auch die Bezeichnung "KrimsKrams". bugmenot postet nur in diesen Thread auch alles was er so herumanalysiert. Dieses Kauderwelsch ist nicht dafür gedacht, vom Otto-Normal-User verstanden zu werden, keine Sorge. ;)
Über VariableOperation -> [Hero][Weapon Number] (und Shield usw.) erhält man doch die Item_ID des ausgerüsteten Items im EquipSlot, oder nicht? Dafür brauchst du niemanden aus der Party zu werfen.Zitat:
Zitat von BDraw
Cherry sagte schon alles Relevante. Liegt vielleicht nur daran, dass der KrimsKrams zu 90% aus Pseudo-Quellcode des RM2k(3) und zu 10% aus Fragezeichen besteht.Zitat:
Zitat von BDraw
Über Variablen auf Item/Hero/Event_IDs und dazugehörige Parameter pointern zu können, sollte in Patch-Form möglich sein.
Ich schaue gerade, wie sich die Funktionen der Zuweisung von Str/Def/Int/Agi zusammenfassen lassen. Ein paar hundert Byte sollten da schon frei werden.
P.S.
Zugriffspunkte auf den Agi-Wert im Rm2k3-Code: 4ACEA2, 495911, 495B70, 495BB4, 495C5E, 49B0CD, 49B0F2, 49B106, 49B491, 49B49B, 49B4C0, 49B4D4, 49EB0A, 49EB22, 49EC1F, 49F469, 4A6928, 4AD25D, 4B7859, 4B8452, 4B8780, 4B8820, 4BEE16, 49C6E7, 49C6FB.
Da müssten irgendwo Funktionen des ATB-Systems mit bei sein.
... :| Du glaubst gar nicht, wie doof ich mir gerade vorkomme. Dankesehr. xDZitat:
Zitat von bugmenot
Mal ne "dumme" Frage... gibt es eine Möglichkeit die LÄNGE einer Screen-Transition irgendwo festzulegen (über ResHack, whatever)?
Man muss sie nicht einstellen können, ein globaler Hack, der es z.B. doppelt so schnell macht, würde mir reichen ^^°
Edit: Geht um Rm2k3 V 1.08
Redest du von Fade-In/Fade-Out (wie es der Maker für Systemmenüs und so verwendet) oder von den Effekt-Transitions (zoom, split, move, mosaic, etc.)? Sind nämlich intern zwei verschiedene Sachen.
Wenn es um Teleport/BattleStart/BattleEnd geht:
Show Screen darf hier nur nicht auf [Fade In] stehen. Man kann vor jedem Teleport oder ähnlichem per Tint Screen und dem wait darin die Länge der Transition selbst festlegen (oder Pictures für gemusterte Übergänge).Zitat:
Zitat von DynRPG.ini
Ging um den regulären Show Screen... und dummerweise Fade-In. Also nix mit den Kampf-Übergängen ^^
Die Sache ist die... ich nutze es in einem kleinen Technikscript, dass vielleicht später mal was größeres werden könnte, um etwas einzublenden, dass ich
auf andere Art und Weise nur mit viel Aufwand einblenden könnte. Nur war das reguläre ShowScreen (quasi als Überblendung ohne Schwarz dazwischen)
einfach zu lang um auf Dauer nicht nervig zu werden.
Quasi so:
> Änderung
> Show Screen
= Sanfte Überblendung, die an der Stelle anders kaum möglich wäre (aber halt noch zu lang ist)
Dass ich das mit Screentones selbst machen kann, dass weiß ich. Hab immerschon eine ganze Latte fertige Spiele hier zum DL bereitgestellt XD
I know.Zitat:
Zitat von Rosa Canina
Es gibt keine Möglichkeit die Wartezeit auf etwas anderes als das oben benannte instant zu setzen.
(Ich sage das jetzt nur, weil ich zu faul bin mich durch hunderte an Befehlszeilen zu klicken. sub_48D200 ist ziemlich groß)
Der QuickPatch (oder HexHack wenn du kein DynRPG verwendest) schmeißt den ganzen Grafik-Effekt aller Übergänge außerhalb von Standart-Menüs raus.
Deswegen kann man die Wartezeit der Übergänge nur über Tint Screen + wait oder eigene Picture-Überblenden kontrollieren.
Oder meinst du mit Show Screen das Grafikupdate bei einer Veränderung auf der momentanen Map (wie zB. das Panorama ändern -> ShowScreen blocky = Panorama baut sich Block für Block neu auf)?
Dafür kann man es unter anderem nutzen, ja.Zitat:
Oder meinst du mit Show Screen das Grafikupdate bei einer Veränderung auf der momentanen Map (wie zB. das Panorama ändern -> ShowScreen blocky = Panorama baut sich Block für Block neu auf)?
Aber wenn es nicht mit FadeIn geht, dann muss ich darauf verzichten oder das ganze eben auf die megaaufwendige Tour erledigen.
Es kann sein, dass wir aneinander vorbeireden. Vielleicht bin ich auch nur müde bzw. nicht müde genug.Zitat:
Zitat von Rosa Canina
Die Sequenz aller Ereignisse, die durch den InstaTransition-Patch abläuft:
Eventbefehl <Show Screen> (oder das Fade-In/Out bei Teleports und Battle)
[Bildschirm-Änderung instant anzeigen]
...deswegen muss man davor+danach eine Art Übergang einschieben:
[TintScreen black100% | wait x sec] -> [Bildschirm-Änderung instant anzeigen] -> [TintScreen normal | wait x sec]
Ähnliches beim <Hide Screen>. Du kannst auch gerne eine der Patchzeilen löschen und schauen, was passiert.
Edit:
Kann ich auch gerne parametrierbar machen. Also das instant per Switch/Variable an/ausschalten.
@bugmenot: Man kann durchaus die Geschwindigkeit regeln. Wenn die Fade-In/Fade-Out Subs aufgerufen werden, bekommen die einen Parameter, das ist die Geschwindigkeit. Das ist ein Gleitkommawert vom Double-Typ, also 8 Bytes, deshalb ist der in 2 push-Befehle aufgeteilt.
Z.B. ist der Parameter anders beim Titlescreen, beim Game-Over und bei den Logos am Anfang. Weil da das Fade ja länger sein soll.
Ah, mir geht ein Licht auf... glaube ich.Zitat:
Zitat von Cherry
Sind das die [68]Push + [6A 00] vor jedem call ShowScreen oder call ClearScreen?
Edit:
[08] ist der Default-Wert. Höher setzen = schneller.Zitat:
Zitat von DynRPG.ini
Bei [18] scheint es in etwa doppelt so schnell zu sein... oder eher dreifach.
Edit³:
Ist scheinbar nur der Teleport-Befehl.
Der InstaKram war irgendwie weniger "megaaufwendig". Ich schaue später mal in die anderen Eventbefehle hinein.
call Sleep
Ich dachte nicht, dass das so schwer verstehbar sei, anscheinend drücke ich mich nicht gut genug aus - oder wir waren alle wirklich zu müde.
Ich beschreibe es noch einmal gaaaaanz genau. :)
Es geht um den Event-Command SHOW SCREEN, welcher bei den Event-Commands auf Seite 2, linke Spalte, ganz unten steht.
Ich will den Spieler nicht teleportieren, keinen Kampf anfangen oder sonstige Dinge erledigen. Er bleibt einfach dort stehen, wo er eh schon
steht. Der Screen wird nicht gelöscht oder gefärbt und darf das auch nicht.
Der Show-Screen-Befehl wird daher ohne zuvorige Löschung des Bildschirms, ohne Ausblenden oder ähnliches benutzt. Dies hat den
Effekt, dass man den gesamten Screen fadet. So kann man z.B. sanfte Übergänge in ein Menü machen, ohne sämtliche variablen Werte
beim Einfaden schon berücksichtigen zu müssen.
Ich benutze es für eine riesige Grafikabfrage, welche mir bald 50 Bilder auf dem Screen verändert, die alle mit anderen Koordinaten laufen
und ich zu "faul" bin das alles über Move Pictures zu erledigen, da ich dann bald noch einmal so viele Bild IDs bräuchte, um wirklich jedes
auf dem Screen angezeigte Bild entsprechend gleichzeitig überblenden zu können.
Also wenn das irgendwie geht (soweit ich das jetzt richtig verstanden habe, wirkt der Code von bugmenot nur beim reinen Teleportbefehl, oder?),
dann wäre da sicherlich mehrere Stunden Arbeitserleichterung...
Und danke für die bisherige Hilfe ^^
Sorry. Ich sehe gerade, dass sich die angegebenen Zeiten nur auf Überblenden von normal <--> Schwarz auswirken. Für's Fade-In gibt es eine gesonderte Funktion (sub_48CE7C).Zitat:
Zitat von Rosa Canina
Unter 48D017 werden die Frames angegeben, innerhalb denen der Überblendeffekt auftreten soll (nur kann man hier nicht die Hälfte angeben, da dann nur die Hälfte des Transparenzüberganges abläuft und dann sofort 100% zeigt), davor ist ein Aufruf einer Sleep-Funktion.
Ich schaue mal, wie man diese nur jeden zweiten Frame aufruft. Praktisch ein Frame Skip. Nur weiß ich jetzt noch nicht, ob das dann ruckelig aussehen wird... Sagt mir also gleich, ob die Idee für den Eimer ist.
Un attimo per favore... ...
Als leicht ruckelig würde mir nichts ausmachen. Der Standardübergang ist ja seeehr flüssig. Selbst die Hälfte der Frames wäre daher sicherlich kein optischer Bruch ^^
Und nochmal Danke, dass du da deine Zeit für opferst ^^
FastFadeIn x2
Das Ergebnis scheint recht flüssig zu sein.
Falls das immernoch zu langsam ist, ändern zu x3:
0xBD12C = [02] set [03]
0xBD134 = [01 74] set [00 75]
Danke für die Geduld.
Danke für DEINE Geduld ^^
Läuft wesentlich angenehmer und schöner jetzt, hab Dank für deine Mühen. Werde bei Gelegenheit auch das x3 noch probieren :3
Könnte man vielleicht den Leistungsanspruch der RPG_RT aufpimpen, damit sie mehr pro Frame verarbeiten kann?
Mir geht es gewaltig auf den Keks, wenn bei mehr als 25 Loops mit etwas Zahlenschubsen und ein paar grafischen
Operationen ohne Framewaiter (die da einfach nicht hin DÜRFEN) schon ein obligatorisch blöder Halbsekunden-Lag
einsetzt, in dem die Anzeige erstmal schön stehen bleibt, nachdem es etwa genausolang halbwegs gut gegangen ist.
Die beiden Situationen wechseln sich ab. Bewegungen~>Stillstand~>Bewegungen~>Stillstand, relativ unspielbar.
[RPG2000 107+Des]
Ich halte es für realistischer und praktikabler deine Scripte anzupassen anstatt darauf zu hoffen, dass irgendwer auf wundersame Weise den Maker umzaubert.
Was ist das denn für ein komplexes System, dass 25 Loops benötigt? Ich würde empfehlen, verschiedene Dinge die in selben Zyklen passieren auch in einem parallelen Prozess aufzurufen.
25 ist noch das, was geradeso fliessend ohne Halbsekundentakt-Stillstand funktioniert, sind aber noch
längst nicht die gewünschte Menge.
Bei dem Event handelt es sich um eine Verwaltung von bis zu 100 spawnenden durch den Bildschirm
fliegenden Objekten, die alle jeden Frame mit neuen Anweisungen gefüttert werden möchten und das
benötigt einiges an Codeinhalt, von dem noch nichtmal alles integriert ist, gerademal der DeSpawn bei
Kollision mit einem festen Hindernis auf der Map oder dem Bildschirmrand ist vorhanden, heisst auch
im Klartext, dass der Verarbeitungsumfang auf bedeutend weniger im Endprodukt herabsinken wird
und der ist jetzt schon im Schmerzgrenzenjenseits.
Okay, wtf stellst du dort da?
Ich bastel an einer JnR-Basis, die nach einem halben Jahr in Ruhe lassen und nochmal durchschauen
auch halbwegs funktioniert (bis auf das regelmäßige Steckenbleiben in Decken bei Sprüngen), die aber
noch Shoot'n'Run-tauglich werden soll. Und das mit einem möglichst umfangreichen "Buffer" für Zeug,
das durch die Gegend geschossen wird, es sind noch nichtmal Gegner derzeit einbezogen.
Mal dran gedacht, einen PP als "Gameloop" zu benutzen und darin die zyklischen Sachen sequenziell zu machen?
Hallo, ich habe einen Wunsch!
In dem Revolution-Previewpatch in dem ATB rausgenommen wurde, sind die Anzeigen für HP und MP um ein Stück nach unten verlegt.
Ich würde dies gerne auch in meinem CortiCombatVisu-Plugin möglich machen, daher hätzte ich gerne die Adressen, der Y-Position von Helden-HP/MP/ATB, Leisten und Zahlen.
Die kurze Antwort:
49681D = PartyWindow_y-Pos
496820 = PartyWindow_x-Pos
4968C0 = GaugeInterface y-Correction (large windows)
4968CE = GaugeInterface y-Correction (small windows)
4968C5 = GaugeSegments delta-y (large windows)
4968D3 = GaugeSegments delta-y (small windows)
Die ausführliche Antwort:
Danke :-D
Btw. was sind diese 909090909090**** - Sachen?
9090 = x86 Tipp-ExZitat:
Zitat von Corti
Oder das, was da noch dahinter steht?
Direkte Vergabe von x|y-Positionen.
Und kleinere Fehler, die mir vielleicht noch vor dem Posten auffallen sollten.
Irgendwas ist immer...
Edit:
http://i.imgur.com/M1wNnSa.png
Der DynLoader will irgendwie nicht wie er soll/kann. Ist die Zeichenkette zu lang?
Edit²
Die Set#4Byte-Funktion scheint Probleme zu haben, wenn die zu überschreibenden Bytes 2-4 ungleich 00 sind. (Dyn v0.20)
Edit³
Es überschreibt die Bytes 2-4 gar nicht, wenn der Wert über 256 hinausgeht.
VertiGauge
Und: VisuGauge
Zu den QuickPatches und den bunten Farben:
Für % ist die maximal zulässige Zahl = 127. (Alles, was sich in dem Bereich befindet, schiebt die anderen Partymitglieder sowieso aus dem Bild)Für die x-Position der HP|MP-Zahlen wird in der RPG_RT zwischen 1|2|3|4-stelligen Zahlen unterschieden. Deswegen sollte man den 8 Pixel-Abstand einhalten (%40, %48, %56, %64).
x-Positionen im horizontalen Interface orientieren sich anhand des vordersten Heldens in der Party. (Wird im vertikalen Gauge umgedreht auf y-Positionen)
"NoShift" ignoriert das Hin- und Herscrollen, wenn man das Ding, was durch NoAutoBattle beseitigt wird, auf/zu macht.
Das %60 beim vertikalen Interface ist der y-Abstand zwischen den Helden.
Edit:
Das Problem mit den Farben der HP/MP/ATB-Leisten wieder beheben:
Angabe in Breite -1 (Und ja: man muss dafür HPB/MPB/ATB auf der selben Breite eingestellt haben)Zitat:
Zitat von DynRPG.ini
Und noch das Problem mit überlangen HP/MP/ATB-Leisten beheben:
Verzerrt die 16x16 Pixel großen Grafiksegmente in System2 (mittlerer Grafikabschnitt, x-Pos = 16) auf die eingestellte Breite.Zitat:
Zitat von DynRPG.ini
Stimmt...
http://share.cherrytree.at/showfile-12644/dynloader.dll << gefixter 0.20-Loader - der ist aber jetzt nicht mit dem alten Patch kompatibel, und das ist jetzt zu umständlich da zu fixen; es gibt sowieso bald 0.20 (in der Testversion gabs ja noch Probleme)
Also: Deine VertiGauge.ips baut die Anzeige um auf die vertikale Ausrichtung. Wenn man das getan hat, kann man die Quickpatch-Zeilen benutzen um sie zu konfigurieren. Right?
Und was tut VisuGauge.ips? Den Quickpatch-Zeilen nach ist die Ausrichtung noch immer wie sie war.
Richtig. Ist nur so ein Experiment, weil: man kann sowas machen... verdeckt nur leider zu viel vom Kampfgeschehen. (die Platzierung aller Battler ist sowieso seltsam)Zitat:
Zitat von Corti
Ausrichtung in der Horizontalen, mit etwas mehr Flexibilität im vertikalen Strecken/Stauchen. Ist auch unabhängig vom (unsichtbaren (noch weiter drunter ist übrigens das Fenster mit der Zielwahl...)) Party-Fenster unten. Also könnte man das HUD an den oberen Bildschirmrand packen.Zitat:
Zitat von Corti
Edit:
Wegen den Fenstern am oberen Bildschirmrand:
Edit²Zitat:
Zitat von DynRPG.ini
InfoDisloc
Damit kann man das Infofenster bei Items/Skills sowie Item-/Skillfenster im Kampf verschieben.
Zitat:
Zitat von DynRPG.ini
Klingt super. Ich werde das mal ausprobieren.
@bugmenot:Zitat:
Zitat von Corti
Dann frage ich mal bei dir an, wie aufwändig es wäre, die Menüpunkte Row & Aktiv-Passiv in Switches zu verwandeln. Wenn es zeitlich grad nicht passt machts auch nix, dann frag ich wie von Cherry vorgeschlagen den Pepsi-Otaku ;)
Row-ATB-Switch
Aufwändig? Vielleicht eine etwas längere Eintipp-Zeit als bei Plugins. (Vorausgesetzt man weiß, wo man den Kram einbinden muss.)Zitat:
Zitat von DynRPG.ini
Cool, danke dir =D
Kommentierter Code der gesamten MenuScene dekodiert. (2k RPG_RT v1.07 und 2k3 RPG_RT v1.08 )
91% Pseudo-Quellcode und 9% Fragezeichen.
Und Doppelpost.
Und Trippelpost. (Weil ich das Zeichenlimit zweimal überschritten habe)
Das ist der Unterschied zwischen drei Tage auf ein Plugin warten und drei Minuten Zahlen eintippen.
Wer mit diesen Informationen etwas anfangen will, kann seine RPG_RT (bitte vorher immer Backups anlegen) mit einem HexEditor öffnen und durch einen Disassembler jagen. (Wenn alles in kleinen Fenstern angezeigt wird: Rechtsklick -> "Text view")
Einfach die 4*****-Adressen kopieren -> im Disassembler G drücken -> Einfügen -> Enter. Unten im Fenster steht die Adresse für den HexEditor (generell 4***** - 400C00). Oder für den RM2k3 die 4*****-Adresse in die DynRPG.ini schieben. (Bitte vorher in das "Hex-View"Fenster schalten, um zu sehen was die genaue Adresse der zu verändernden Zahl ist.)
Für alle, die meinen: "Da stehen aber nicht durchgehend die ganzen blauen Adressen!" Öffnet eine 2k RPG_RT mit dem Disassembler und springt zu den jeweils angegebene Adressen am Kopfende der <>Funktionen. Von 2k zu 2k3 gab es eine Menge copy&paste, daher ist der Aufbau des Codes stellenweise gleich. Ein bisschen Scrollen und Vergleichen ist schon der ganze Trick an der Sache.
Wer sich wegen den Versionsnummern der RTs unsicher ist: betterAEP nutzt die 1.07/v1.08 (und DynRPG läuft auf der v1.08 )
Wem langweilig genug ist:
Kann man x86 essen?
Mehr als Disassembler, Papier, Taschenrechner, Musik und HexEditor (oder OllyDbg, falls es funktioniert) braucht man nicht.
x86Asm-to-Hex-Converter
288Dez -> Hex ergibt bei mir 120 laut Taschenrechner, wie kommt man auf 20 01 00 00?Zitat:
Wer damit rumspielen will, kann die Werte, welche größer als #256 sind in hexadecimal umrechnen (Bsp: 288 = 20 01 00 00) und anstelle des #*** diesen Wert eintippen.
Irgendwas wegen signed/unsigned integers auf HexEbene. Der Least Significant Byte liegt bei einer 4-Byte-Operation links.Zitat:
Zitat von Corti
[AA BB CC DD]:
AA = 256^0
BB = 256^1
CC = 256^3
DD = 256^4
Irgendwo bei 2147483648 (in HexDec: 00 00 00 80) flippt's ins Negative. (01 00 00 80 = -2147483647)
Und FF FF FF FF ist -1.
FE FF FF FF ist -2 etc.
Das Ergebnis vom Taschenrechner hat den LSB rechts, weswegen man die Zahl in Zweiergrüppchen aufteilen muss und quasi rückwärts eintippen muss:
11F = 00 00 01 1F (Rechner) -> 1F 01 00 00 (HexEditor)
Edit:
Soll das eine unterschwellige Botschaft sein, dass ich mir einen Assembler zulegen oder OllyDbg zum Laufen zu bringen soll?
Nein, ich wollte nur wissen wie das funktioniert, danke dir!Zitat:
Zitat von bugmenot