Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

ach dieser 1.10c ist von R-PG? hehe, ehrlich gesagt, hab das nich gewusst.

~Variablen-im-Debugfenster:
Ich habs zwar schonmal geschafft, die Stellenzahl zu erhöhen, aber, und jetzt
kommts: ich konnte das Anzeigefenster nicht breiter machen und da konnte
er nicht alle anzeigen. Das selbe Problem ergibt sich in diesem Patch.

~"500 000 Variablen, Switches, Helden, Items, Monster, etc.":
Vorallem bei Variablen und Switches halte ich das für übertrieben, es ist
Schwachsinn und kostet beim Öffnen der Switch- bzw Variablen-Auswahl
zuviel Rechenzeit.

Zitat:

---

Um diesen Patch verwenden zu können, braucht man den ungepatchten, englischen Maker Version 1.05b

---

Habs auch mal mit 1.07b probiert, da hat er auch funktioniert :-.

~"10 000 Frames bei den Battle Animations":
Nunja, wer macht den solche "BattleAnimationMOVIIIIEEES" ?
Mir solls egal sein xD.

--------------------------------------------------------------------------

Habe noch beim RPG Maker Collegial Project was interessantes gefunden^^:

Zitat:

---

---RPG Maker LcfDataBase---

Introduction
Here it is, the 200+ kilobyte database that holds all that information you see when you hit F8. The smallest I’ve ever seen this monster is 5B; compare that to the smallest lmu file (2KB) or lmt file (1KB). Moreover, larger map or tree files repeat in an easy-to-specify pattern, whereas the database file has a whole lot of data that is very… particular. You’ll forgive me, then, if this document is nowhere near complete.


Locking Database?
Something you may wonder is if an .ldb file is, like some sites suggest, a locking data-base for Microsoft Access. Actually, it’s just following RPG Maker’s .lxx syntax (mt = map tree, mu = map unit, db = database, sd = save data). I can only guess that LCF are the initials of someone special, or some homebrew data storage methodology. It just so happens that .ldb doubles as the extension for Microsoft’s temporary locking file; you can’t, say, open it in Access.


Completeness
I haven’t even started, and already I know that there’ll be things I miss. So, please, drop me an email if you figure out anything in red, or any “undefined” imperials:
Sorlok_Reaves@yahoo.com


The Database File Format
<ldb_database_file> ::= <file_type><section>+
<file_type> ::= <str_len> <character>+
<section> ::= <section_imp> <num_bytes> <byte>+
<section imp ::=
0B -> “heros”
0C -> “skills”
0D -> “items”
0E -> “monster”
0F -> “monster party”
10 -> “terrain”
11 -> “attribute”
12 -> “conditions”
13 -> “battle_anims”
14 -> “chipsets”
15 -> “vocab”
16 -> “settings”
17 -> “switches”
18 -> “variables”
19 -> “common_events”


Moving On From Here
After lexing the file type, one can segment the remaining file very easily. In practice, this is quite useful. If, for instance, a map has an inordinate number of common events, someone searching only for the chipset specifications might be forced to wait way too long, or he might run out of memory. This lexer, then, will have flags that determine which segments to read. The following sections, then, will be out of order. Since I need chipset information post-haste, here we go:


Chipsets
<chipset_section> ::= <imp:14> <
Guess: chipsetid, XX, prop01:name, num_chars, name:char+, prop02:gfx_file, num_chars, gfx_file:char+, 03:? num_bytes, byte+, 04:?upper_tile_passability?, ???

---

Zitat:

---

---RPG Maker LcfMapUnit---

Introduction
Waah! I just totally deleted the 36-page file I was working on! And it’s all my fault! Oh well, time to start over. Brevity is now the soul of… this paper.


The Map File
The map file is composed of four sections, with a “size” seperator in between. This is beneficial; one can, say, skip straight to the events section using nothing more than a simple hand-coded lexer.
<lmu_map_file> ::= <file_type> <initial_properties> <size_hint_lower> <lower_map_tiles> <size_hint_upper> <upper_map_tiles> <size_hint_event> <event_section> <footer_section>


The File Type
The file type consists of a length hint, followed by an (ascii) string describing the content of that file. For .lmu files, this is “LcfMapUnit.” Consequently, this is one of the things Rast’s plugger modifies to “protect” a project.
<file_type> ::= <str_len><ascii>*


The Initial Properties
Initial properties of a map include its background, tileset, and scroll option. Anything with a “parent map” option (e.g. background music, teleport enable) are not represented here, neither is the map name. Since this section has no size_hint before it, we can’t skip it when parsing the map. Hence, RPG Maker takes several measures to ensure that this section is as small as possible. In particular, most commands have defaults that are simply not included in the file if they are not altered. Hence, some knowledge is implicit. (For the next few sections, imperials in italics are optional properies.) Of course, there are some dependencies here (autoscroll cannot appear without pan being checked), but since RPG Maker stores old values (i.e. speed) even when a box isn’t checked, it’d be more trouble than it’s worth to determine these, and far too inefficient to lex them. Note that, unless otherwise noted, productions/tokens undefined in a code box are assumed to be rpg_ints, which are described a few sections from now.
<initial_properties> ::= <long_property>+
<long_property> ::= <imperial><arg_len><arg_value>
<imperials> ::= (01,Chipset) , (02,Width) , (03,Height) , (0B,ScrollType) , (1F,UseParallelBkgrd?) , (20,BkgrdFileName) , (21,HorizPan?) , (22,VertPan?) , (23,HorizAuto?) , (24,HorizAutoSpd) , (25,VertAuto?) , (26,VertAutoSpd)


The Lower Tiles
The Lower tiles consist of the size_hint, followed by that many bytes. Two bytes comprise one map tile. The lower tiles are a bit complex, as the data for the derived tile is shown, not the logical tile. This causes no problems for the lower tiles that aren’t dynamic (i.e., rocks, wood, or any of the upper tiles.) However, for tiles such as grass, sand, and water, the logical tile (the one you select in RPG Maker’s map editor) differs greatly from the physical one (the actual 16x16 square shown to you in the editor screen.) Hence, whilst placing a table tile in the middle of a set of rug tiles will only change that tile’s value, placing it in the middle of a patch of ocean tiles will change its value and the values of the 9 adjacent tiles. (Note, again, that the grammar I’m producing allows maps that cannot possibly be created in RPG Maker. For instance, <tile>* in the grammar below is completely impossible; no map can have fewer than 20x15=600 tiles.)
<size_hint_lower> ::= <imperial:47><value>
<lower_tiles> ::= <tile>*
<tile> ::= <byte><byte //e.g. “05 3F”


RPG Maker’s Integer Datatype (≥ 0)
rpg_int binary* actual_value
1E 00011110 30
14 00010100 20
7F 01111111 127
81 00 10000001 00000000 128
84 58 10000100 01011000 600
FF 7F 11111111 01111111 16383
81 80 00 10000001 10000000 00000000 16384
81 AE 10 10000001 10101110 00010000 22288
BD 84 3F 10111101 10000100 00111111 999999

* black values are directly converted to decimals. (1=1, 10=2, etc.)
red values are flags denoting “multiply by 128” if true.
blue values start counting at 128 (1=128, 10=129, etc.)
green values are flags indicating, if true, to “multiply by 16384”
purple values start counting at 16384.
Note that the size_hint above has no length_hint. This is because RPG Maker uses the first bit of each integer to designate if that integer will continue. This allows one to create arbitrarily long integers without explicitly stating their length from the get-go. In all honesty, I’m not sure why .lmu files provide length_hints at all; size_hints for strings make sense, and num_arg_hints for functions are a must, but the so-called “rpg_int”s provide their own built-in length hints. It’s a compact system, for positive numbers at least. Enough theory, here’s some examples:


The Upper Tiles
The upper tiles are stored in a manner similar to the lower ones, except without the complication of derived versus logical tiles. The two sections even have the same size_hint, although the imperial is different.
<size_hint_upper> ::= <imperial:48><value>
<upper_tiles> ::= <tile>*


The Event Settings
Here’s where it gets a bit finnicky. The events section basically consists of a size_hint, followed by a number of events. Going down the line, events have their own settings, and a number of pages. Each page has its own settings, and a number of event_commands. These in turn have settings, and two (move and shop) have item or route lists. A few also allow event commands to be placed inside themselves! Size_hints are useful here, as are depth_hints. But we’re getting ahead of ourselves.
<size_hint_events> ::= <imperial:51><value>
<event_section> ::= <num_hint><event>*


Events
Each event consists of an id number, followed by some properties of the same form as map events. Following this, there are an arbitrary number of pages.
<event> ::= <id> <long_property>+ <page_bytes> <num_pages> <page>+
<imperials> ::= (01,EventName) , (02,posX) , (03,posY) , (05,size_hint_pages)
<page_bytes> = <size_hint_pages> <rpg_int>


Pages
Pages are composed of a number (similar to an id), some conditions which this event must satisfy, some graphical, activation, and other properties of the event, a route that it moves by, two (similar) size_hints, and some commands. It terminates with a page_end character. Presumably, this was included origionally to test map files; the size_hint renders this token unneccessary (although it would help a simple lexer search for, say, the number of event_commands without extending the lexer. Note that there are other ways of interpreting the data in .lmu files. In general, I have treated these map files as imperial-based data structures. This viewpoint, together with size hints, has helped to clarify a lot of “lost” bytes that would otherwise make no sense. Moreover, using this method, imperial numbers line up nicely. It was quite obvious when many of my initial guesses started at 02 that I was doing something wrong. The main contestable area which remains is that some length_hints could be construed as num_arg_hints. In general, though, this makes little sense. What kinds of imperials would express multiple properties. The obvious answer is “event_commands”; thus, num_arg_hints are used for these cases. A few other cases (one’s route) also require this distinction.
<page> ::= <number> <size_hint_ec> <event_conditions> <event_properties> <route> <size_hint_long_ecmd> <size_hint_short_ecmd> <event_command>* <page_end:00 00 00 00 00>
<size_hint_ec> ::= <imp:02><size_bytes>
<event_conditions> ::= <long_property>+ <end_ec>
<imperials> ::= (01,BoxesChecked) , (02,valSwitchA) , (03,valSwitchB) , (04,valVariable) , (05,valVarCmp) , (06,valItemCmp) , (07,valHeroCmp) , (08,valTimerCmp)
<end_ec> ::= 00
<event_properties> ::= <long_property>+
<imperials> ::= (15,pageGrahpic) , (16,pageGraphicTile) , (17,unknown*) , (19,semi-transparent) , (1F,moveType) , (20,moveFrequency) , (21,startConditions) , (22,layer) , (23,parallel) , (24,animType) , (25,moveSpeed)
<route> ::= <imp:29> <size_hint_r> <num_moves_long>? <num_moves_short> <move>* <repeat_moves>? <ignore_illegal_moves>? <null>
/* Note: num_moves tell you how many moves there are, so the <null> isn’t included. Size_hint_r, however, tells you how many bytes are left in <route>, so it includes the final <null>. Logically, they should be lexed like the global map file is. We lex them together because it is unlikely that this section will ever need to be skipped. */
<num_moves_long> ::= <imp:0B><length_hint><value>
<num_moves_short> ::= <imp:0C><value>
<move> ::= // See next paragraph.
<size_hint_long_ecmd> ::= <imp:33><length_hint><value>
<size_hint_short_ecmd> ::= <imp:34><value>
<repeat_moves> ::= <imp:15><length><value>
<ignore_illegal_moves> ::= <imp:16><length><value>
* Note: I’m still trying to figure out what this does. Also, does anyone know what happened to imperial 18? This isn’t so worrisome; the developers may have dropped a feature further into development. And thoughts on this can be sent to:
Sorlok_Reaves@yahoo.com

Route Commands
These commands are actually duplicated in the “move event” event_command; not surprising, since RPG Maker pulls up that very window to set an event’s route. Most consist of a one-byte imperial, but some may have additional arguments. Check the lmu.sable file provided for a full specification; several examples are given below.
<step_up> ::= 00
<turn_quarter_right> ::= 10
<move_frequency_down> ::= 1F
<transparency_up> ::= 28
<switch_on> ::= 20 <switch_ref>
<switch_off> ::= 21 <switch_ref>
<chage_grapihc> ::= 22 <length_hint> <ascii>+ <rpg_int: chip_id>
<play_sound> ::= 23 <length_hint> <ascii>+ <rpg_int: volume> <rpg_int: tempo> <rpg_int: balance>


Event Commands
This is where things get a bit confusing. First of all, the long_property values you’ve seen so far are no longer used. Rather, each value now takes the general form:
<event_command> ::= <imp> <depth> <str_len> <ascii>* <num_args> <rpg_int>* <extra_stuff>?
In this scheme, the imperial serves the same identification purpose it did for long_properties —except that it consists of two bytes. The depth of an argument is its nesting level; most depths are usually 00 (the default) or 01 (for, say, a “Show Choice”’s alternatives, or elements in a “Cycle.”) With Cycles within Forks, Show Choices within “Successful” branches of Inns, and other nonsense, a command’s nesting level increases linearly. The string length argument is generally 00, but can be set if certain commands (“Set hero name”, “Show picture”, etc.) require an outside reference or string input. Next comes a num_args_hint, followed by (surprise surprise) a number of arguments. This is almost redundant, since no “compression” of arguments takes place —any event_command will always have the same number of arguments. The exceptions are the “Move Event” and “Call Shop” commands, both of which take a varying number of moves/items. Finally, some extra_stuff may appear tacked onto the end of this command for, say, multiple-line message boxes, or anything with a branch. These aren’t of uniform structure for all event commands, so they need to be dealt with on a case-by-case basis. And, since we’re lexing all ec’s into their own unique nodes on the AST, we’ll do just that!



Sample Event Commands
There are a lot of event commands, and listing them all here is pointless (many are similar in style and differ only in their imperials.) Rather, we shall merely list several standard and non-intuitive ones.

<show_message> ::= <imp:CE,7E> <depth> <str_len> [line1]:<ascii>* <num_args> <additional_line>*
<additional_line> = 81 9D 0E <depth> <str_len> <ascii>* <null>

<select_face> ::= <imp:CF,12> <depth> <str_len> [gfx_file]:<ascii>+ <num_args:3> <chip> <side> <flipped>

<show_choice> ::= <imp:CF,1C> <depth> <str_len> [full_title]:<ascii>* <num_args> <default_choice> <choice_opt>*
<choice_opt> ::= <imp:81,9D> <type(2C|2D)> <depth> <str_len> [case_title]:<ascii>* <num_args> <choice_num>? <event_command>* <continue>? <case_closed:00,00>
<continue> ::= <imp:0A> <value>

<input_number> ::= <imp:CF,26> <depth> <str_len> <num_args:2> <num_digits> <variable_num>

<change_variable> ::= <imp:CF,6C> <depth> <str_len> <num_args:7> <referrent> <range_low> <range_high> <set_option> <reference> <value> <misc_option>
/* The “referrent” option shows up quite often. Here, it denotes {00:one, 01:range, 02:variable} */

<take_damage> ::= <imp:D2,04> <depth> <str_len> <num_args:8> <target_reference> <target_id> <attack> <def%> <mind%> <variance> <get_opt> <get_value>

<start_combat> ::= <imp:D3,56> <depth> <str_len> <background_file>? <num_args> <enemy_group_reference> <enemy_group_id> <battle_bkgrd_opt> <escape_case_opt> <defeat_case_opt> <first_strike_opt> <general_branch>*

<general_branch> ::= <imp:81:A1> <type> <depth> <str_len> <num_args> <event_condition>* <continue>? <case_closed>?

<call_shop> ::= <imp:D3,60> <depth> <str_len> <num_args> <shop_type> <deal_success_opt> <msg_style> <item_id>* <general_branch>?

<move_event> ::= <imp:DB,42> <depth> <str_len> <num_args> <eventID> <frequency> <repeat?> <ignore_impossible?> <move>*

<fork_event> ::= <imp:DD,6A> <depth> <str_len> [argument_string]:<ascii>* <num_args:06> <fork_conditions> <else_opt> <fork_branch>+
<fork_conditions> ::= <fcond_switch> | <fcond_variable> | <fcond_timer> | <fcond_money> | <fcond_item> | <fcond_hero> | <fcond_event> | <fcond_vehicle> | <fcond_decision_key> | <fcond_bgm_done>
<fork_branch> ::= (<imp:81,AB><type><depth><str_len><num_args>)? <event_command>* <continue>? <case_closed>?
<case_continue> ::= <imp:0A 01> <nulls: 00 00>


<cycle> ::= <imp:DF,32> <depth> <str_len> <num_args:0> <cycle_branch>+
<cycle_branch> ::= (<imp:81,AD><type><depth><str_len><num_args>)? <event_command>* <continue>? <case_closed>?


<comment> ::= <imp:E0,7A> <dpeth> <str_len> [line1]:ascii+ <num_args:0> <comment_line>*
<additional_line> ::= <imp:81,AF> <type> <depth> <str_len> [text]:ascii+ <num_args:00>


A note about event IDs:
These babies use the special character “CE”, followed by another byte, to designate the “special” map events: {11:Hero, 12:Boat, 13:Ship, 14:Airship 15:this_event}. This begs the question, then, of why we have “Set Vehicle Place” and “Goto Memorized Place” as commands at all, especially since “Set Event Place” had to specifically disable the Hero, Boat, Ship, and Airship options. On a slightly related note, this means that you can’t have more than 10,000 events on any one map. Rast, I’m sure, ran into this problem quite often in Dragon Destinies I and II. Oh, and while we’re at cutoff points, the highest integer RPG Maker can recgnize (with three digits) is 2,097,151. Fortunately for us, numbers don’t go that high, so this, also, isn’t a major issue.


A Possible Inadequacy?
One could make the argument that, technically, the imperial of “scope” is 81, and that AB, AD, etc. denotes the “kind” (fork, cycle, etc.), followed by the “type” (for “Show Choice” events, mainly.) We, however, will gloss over this, since it’s not such a big deal.


Fork Conditions
Fork conditions are a bit messy, since variables are multiplexed.
<fcond_switch> ::= <imp:00> <switch_number> <switch_value> <garbage> <garbage>
<fcond_variable> ::= <imp:01> <variable_number> <reference> <compare_to> <compare_by>
<fcond_timer> ::= <imp:02> <time_sec> <compare_by> <garbage> <garbage>
<fcond_money> ::= <imp:03> <money_amt> <compare_by> <garbage> <garbage>
<fcond_item> ::= <imp:04> <item_ID> <has_opt> <garbage> <garbage>
<fcond_hero> ::= <imp:05> <hero_ID> <hero_check>
<hero_check> ::= <hc_in_party> | <hc_name_is> | <hc_level_abv> | <hc_hp_abv> | <hc_skill_has> | <hc_equipped_with> | <hc_cond_is>
<hc_in_party> ::= <imp:00> <garbage>
<hc_name_is> ::= <imp:01> <garbage>
<hc_level_abv> ::= <imp:02> <value>
<hc_hp_abv> ::= <imp:03> <value>
<hc_skill_has> ::= <imp:04> <skill_ID>
<hc_equipped_with> ::= <imp:05> <item_ID>
<hc_cond_is> ::= <imp:06> <cond_ID>
<fcond_event> ::= <imp:06> <event_id> <face_dir> <garbage> <garbage>
<fcond_vehicle> ::= <imp:07> <vehicle_id> <garbage> <garbage> <garbage>
<fcond_decision> ::= <imp:08> <garbage> <garbage> <garbage> <garbage>
<fcond_bgm_done> ::= <imp:08> <garbage> <garbage> <garbage> <garbage>


A Second Possible Inadequacy?
Another thing you might have noticed is how stand-alone the “additional_line” tag for comments looks. One might even conclude that, since it has its own pseudo-imperial, that it should be parsed as its own command. I think it should not, mainly because:
1) It has a type, and no other event_commands do.
2) You can’t have a stand-alone “line 2” of a comment —it must follow a traiditonal comment command.
3) This cannot be done with similar event_commands such as “Fork”, which don’t have the imperial for the first case.


Improvements
This particular grammar is very, very space in-efficient. Essentially, we're saving as much information as possible, useful or otherwise. As soon as this parser is fully debugged, one will be provided which takes efficiency into consideration and saves the bare-bones minimum for each production. This includes trashing all length hints and unneccesary options, such that a production contains other (sub) productions only when the number of sub_productions is indeterminate. For example:
<map_properties> ::= <chipset>? <width>? <height>? <scroll_type> ...,
with these custom tokens picked out by our custom lexer. Note that we'd need to introduce a new token, list_end, for the "call shop" and "move event" commands.
So, basically, this parser creates a concrete syntax tree, but a future parser
will utilize our custom lexer to bulid an abstract syntax tree. The first
is more accurate to how .lmu files appear; the second is faster and takes up
less memory to store (and brain power to think about.) It is a bit uncommon for a lexer to influence how the abstract syntax tree is formed, but in this case the simplicity of RPG Maker’s map files allows for this small optimization.


A note on EBNF-RS
This should really have gone at the start of the report, but things lined up so nicely and, besides, if I’d tidied up my grammar I wouldn’t have needed this paragraph. Basically, the syntax used here is a very informal variant of EBNF notation. The main things you may not have already figured out are:
1) <random> ::= <chipset>? <ec>* <footer>+ means that the “random” production consists of zero or one chipsets, zero or more ec’s, and one or more footers.
2) <random2> ::= <opt> | <nop> means that the “random2” production contains either an “opt” or a “nop” token/production.
3) <imp:05,BC> is just a convenient way of saying “imp is the hex string 05BC”
4) <random3> ::= [options]:<list_item>+ The only thing you might not recognize here is the [options]: tag. This means that the result of list_item is referred to as “options.” I use this notation when it’s not clear what, say, “ascii+” should be considered.

---

Zitat:

---

---RPG Maker LcfMapTree---

Introduction
Rather than try to lex the database next (which doesn’t look fun at all), I’ll attempt to lex the map tree next. See the RPG_Maker_Map_Grammar_Guide for an explanation of RPG Integers, the syntax used in this guide, and other particulars.


Properties not in the lmt file
The following properties do not appear in the lmt file, but in the respective lmu files for each map:
Chipset
Width
Height
ScrollType
UseParallelBkgrd?
BkgrdFileName
HorizPan?
VertPan?
HorizAuto?
HorizAutoSpd
VertAuto?
VertAutoSpd


A word about the map tree file
The map tree file is a lot simpler than the individual maps’ files. However, there’s a few things in it that remain a myster to me. As always, if you can decipher the “unknown” imperials (even if they turn out to be size hints) send me an email:
Sorlok_Reaves@yahoo.com


The Map Tree File Format
<lmt_map_tree_file> ::= <file_type> <tree_node>+ <map_end>
<file_type> ::= <str_len> <character>+


The end of the file
I haven’t fully figured out what all that junk at the end of the map tree file means. For lexing purposes, you’ll basically just detect a map number followed immediately by a null terminal, and then a handful of digits (which varies depending on the map, but seems to increase in length as the number of nodes increases.) For now, we will lex it as a node, and cut off program execution at that point.


The Tree Nodes
Every map has at least one tree node; the root node. This is the folder icon at the top of the RPG Maker’s map tree viewer. Following this, a number of other nodes are listed in ascending order. These are either maps or areas, and they form a tree structure through the use of a “parent” reference.
As an aside, we will lex all tree properties and interpret them in the lexer itself. I realize now the foolishness of ignoring size hints in the lmu parser. We will also lex all numbers as rpg_bytes, and convert to integers in the lexer. This avoids potential lexing bugs that plague the lmu lexer.
<tree_node> ::= <tree_node_id> <end_of_file: 00>? <tree_property>+ <area_layout> <null: 00>
<tree_property> ::= <long_property> | <background_music> | <monster_encounters>
<long_property> ::= <imperial> <size_hint> <byte>+
<imperials> ::= (01,Map Name) , (02,Parent) , (03,Tree Depth) , (04,Type of Node) , (05,Unknown Property 1) , (06,Unknown Area Property) , (07,Has Children) , (0B,BGM Options) , (15,Battle Background) , (16,Battle Background File) , (1F,Teleport Option) , (20,Escape Option) , (21,Save Option) , (2C,Encounter Steps) (Italics denote optional properties)
<background_music> ::= <imp:0C> <size_hint> <sub_imp:01> <str_len> <character>* <null:00>
<monster_encounters> ::= <imp:29> <size_hint> (<none:00> | <monsters>)
<monsters> ::= <
<area_layout> ::= <imp:33><size_hint><x_min_byte>4 <y_min_byte>4 <x_max+1_byte>4 <y_max+1_byte>4


A note on byte order
The size of the area_layout is fixed at 0x10. Each value (x_min, y_max+1, etc.) is made of four bytes, arranged in reverse order.


(0C,BGM File Name) ,


0A – Length Hint
“LcfMapTree”
09 — Number of maps, areas, and root nodes(1)


End:
09 00 -- 01 03 08 02 04 05 06 07 08 01 01 23 00
11 00 02 01 03 0A 0C 0D 0E 0F 10 04 05 06 07 08 09 0B 10 01 01 10 02 01 0A 03 01 0B 00

---

Diese Dokumente, ein weiteres Dokument, ein Readme und ein Programm, das
"RPG Hex Strings" zu Integern und Hex-Werten macht, und was-weis-ich-
was-noch-alles...:

http://sourceforge.net/project/showf...roup_id=144960

Zitat:

---

Zitat von MagicMaker

Habs auch mal mit 1.07b probiert, da hat er auch funktioniert :-.

---

Ich habe ihn auch ausprobiert.
Wenn man nun ein Pic > 20 macht kommt folgende Fehlermeldung:

?????'Map0000.lmu'?????00403B48?????0000001????Writing?????????

Hab noch eine Seltsamheit am RM2003 gesehen die Dr. Sophie gefunden hat:

Zitat:

---

Dr. Sophie hat bei rpg-elite folgendes geschrieben:

Vielleicht wäre es mal eine ganz nette Idee, seltsames Verhalten des Makers (oder nicht ganz offentsichtliche Funktionen/etc.) irgendwo niederzuschreiben, vielleicht ist es für den einen oder anderen ganz interessant oder sogar hilfreich

Ich fange mal an, mit etwas, was ich neulich herausgefunden habe:

Wenn man einem Hero keine Grafik zuweist (also wenn die Vorschau bei dem Herocharset in der Datenbank schwarz ist), dann läuft man mit dem 1. Tile (ganz oben links) des Upper Layer-Tilesets herum.
Da die meisten Tilesets an dieser Stelle keine Grafik haben (wie es ja auch eigentlich sein sollte), fällt das aber nicht wirklich auf.. ist aber trotzdem ein interessantes Verhalten.
(Getestet in 2003, weiß nicht, ob es in 2000 auch so ist)

---

Ob das auch so ist? Ich denke mal schon, wieso sollte Dr. Sophie auch Mist erzählen xD...


@netwarrior: Ist schon seltsam, vielleicht nicht die richtige RPG_RT? Was anderes fällt mir nicht ein ~ nunja, keine Software ist perfekt.

@MagicMaker: ich glaube, du verwechselst da was. Der erste Download in meinem Post, das mit den 500000 Varis ist von mir. Der 2. Download ganz unten, mit dem Tasten, Picture und Startmenüpatch ist von r-pg!
achja, in deinem Post steht, dass unbekannt ist, wofür das Lcf steht - es steht für Lucifer, einem der Programmier des Makers

Ich hab mal etwas mit Pictures rumprobiert, insbesondere mit der Dreh-Funktion. Ich hab irgendwann den Powermode 2003 ausprobiert, weil mich es interessiert hat, dass man Pictures in beide Richtungen drehen kann.
Ich hab mal geguckt, wie lange eine Umdrehung für die einzelnen Zeiten benötigt, sowie die Gradzahl pro 0.0 Sec ausgerechnet. Ich hab folgende Ergebnisse rausbekommen (Leider noch nicht vollständig):

Code:

---

Geschwingigkeit= 1x
Dauer für 1 Umdrehung= 4,2 S. + 3x 0,0= 255x 0,0  (pro 0.0 1,4°)
Dauer für 1/4 Umdrehung= 63,75x 0,0~ 1,0 S. + 4x 0,0

Geschwindigkeit= 2x
Dauer für 1 Umdrehung= (4,2 S. +3x 0,0)/2= 2,1 S. +2x 0,0 (pro 0.0 2,8°)
Dauer für 1/4 Umdrehung= (1,0 S. + 4x 0,0)/2 = 0,5 S. + 2x 0,0

Geschwindigkeit= 3x
Dauer für 1 Umdrehung= 1,4 S. + 1x 0,0

Geschwindigkeit= 4x
Dauer für 1 Umdrehung= (Geschw. 2x)/2

usw.

---

Wir ihr seht, werden die Zeiten für 2x zu 4x verdoppelt. Für 4x zu 8x wirds auch verdoppelt. Für die anderen Zeiten müsst ihr die Zeiten von 8x * die Geschwindigkeit zum ausrechnen. Ich werds demnächst noch vervollständigen.
Achja! Wenn jemand herausfinden sollte, dass hier irgendwas nicht stimmt oder falsch ist, kann dieser gerne Bescheid sagen, damit ichs ändern kann!

hey leute ich bin seit langer zeit nicht mehr hier gewesen und wollt mal wieder hallo sagen und ne frage stellen^^
weiß jemand wie der rm2k3 die kämpfe vom standard ks berechnet? sorry wenn das schonmal kam

Zitat:

---

weiß jemand wie der rm2k3 die kämpfe vom standard ks berechnet?

---

Meinst du zB die Schadensberechnung und wann wer dran ist? Also beim
RM2K stands in der Hilfe, schau mal in deiner RPG2003.hlp genau nach,
müsstest du finden.

--------------------------------------------------------------------------

Hier ist nochmal der XYZ-Dateiaufbau, diesmal von Janus.
Ich nehme an es müsste komplett sein.

Zitat:

---

RM2k XYZ Graphics Format
Simple documentation file v1.0 by Janus (janusfury@citlink.net)

Header:
4 bytes: XYZ1
2 bytes, unsigned int: Width
2 bytes, unsigned int: Height

Data:
ZLib-compressed. Use ZLib.dll uncompress to decompress it...
The output size of the data is (image and palette):
(Width * Height) + (256 * 3)
The input size of the data is:
FileSize - 8
In english, the data starts after the header and ends at the end of the file, and the image, when decompressed, is just a palette and then image data.
The palette is simply a series of colors in RGB order, no 4th byte for the palette entries.
The data is just a bunch of palette indexes, in standard x,y order.

Enjoy! :)

---

Gefunden auf Wotsit.org ("what's it?")

Weiß ich schon lang. Das stammt nämlich in WIRKLICHKEIT von >>>da<<<, da sind auch die anderen Datenspezifikationen nochmal.

ja meinte das mit der berechnung und wer wann dran ist. aber hab keine hlp datei bei rm2k3 weiß jemand ne seite wos die gibt?

RM2k(3)-Clipboard-Formate:

560 - ???
561 - ???
562 - Map-Ausschnitte
563 - Events
564 - Event-Seiten
565 - ???
566 - Event-Befehle
567 - Move Event-Befehle
568 - Maps/Areas
569 - Monster-Aktionen
570 - BA-Effekt-Elemente
571 - ???
572 - ???
573 - BA-Bild-Elemente
574 - Helden
575 - Items
576 - Skills
577 - Monster
578 - Monstergruppen
579 - Terrains
580 - Attribute
581 - Zustände
582 - BAs
583 - Tilesets
584 - Common Events
585 - ???
586 - ???
587 - Klassen (2k3)
588 - Battle Sprites (2k3)
589 - Battle Commands (2k3)

mfG Cherry

Was?
(wäre für eine Erklärung durch Edit, dann kann ich den Post hier löschen)

EDIT:

@Cherry unter mir:
Clipboard ist englisch für Zwischenablage. Also sind Clipboard-Format-IDs "Zwischenablage-Format-Identifikatoren".
Also scheinbar die Nummer der Formatart für Copy&Paste-Vorgänge.
Und was genau bringt es mir jetzt zu wissen, dass Monstergruppen intern die Kopiernummer 578 haben?

Das sind die Clipboard-Format-IDs, die die verschiedenen Daten haben, die man beim RM2k(3) in die Zwischenablage kopieren kann.

Auch ganz nett:

- Eventmodus-> Großes Spin Around-Objekt bestehend aus den Tiles eines einzigen Charsets (6 Felder).
- Switch "Pose" on.
- Nun wird die zweite Seite aller 6 Felder angezeigt, 5 haben eine fixierte Charsetgrafik, das sechste Feld jedoch nur das Transparenztile vom Chipset.
- Nach 0,5 Sek. wird der Switch ausgeschaltet.
- Alle Felder harmonieren wieder miteinander und bewegen sich im gleichen Abstand, nur das sechste Feld mit der vorherigen Grafik des Chipsets bockt rum und bewegt sich asynchron.

Anscheinend besitzt der Maker eine jeweils andere Zugriffszeit bei Chip-/Charset-Tiles in Bezug auf das Zurücksetzen von Switches.

Da ich gerade viel damit zu tun hatte, habe mich ich mal damit beschäftigt, wie der Maker denn die Statuskurven berechnet.
Dabei ist mir folgendes aufgefallen: (HP-Angaben beziehen sich auf den RM2k3)

-Der Wert um den die HP steigt schwankt generell zwischen 33-46.
-Der Wert ist abhängig von der Einstellung "Early-Normal-Later"
-Die Eintellung gibt soweit ich das sehen kann nur einen Punkt dazu, bzw zieht einen ab.
-Der Grundwert (33-46) könnte man abhängig von den Charas machen und so eine eigen Kurve generieren udn sich von den Levels "lösen" (Rm2k)

Im Grunde könnte man also bei einem Level-Up so berechnen: (einfache Form)

Neue HP = Aktuelle HP+((Grundwert+Random(1-2))*2)

Das Random hier steht noch für den Zusatz an HP, den der Maker manchmal zugibt.
Ich weiß noch nicht, wie es genau berechnet wird, aber das hier kommt schonmal nahe herran^^
Das Gleiche kann man jetzt auch für MP machen. Oder für Angriff (Hier sind die Grundwert nur entsprechend kleiner).
Den Grundwert kann man ja beliebig einem Chara anpassen. Zb ein Magier mit eher weniger HP bekommt den Grundwert 30 und hat damit gleich weniger HP als ein Krieger.
Vllt hilft es ja einigen, die gerne mit dem rm2k Level 50 knacken wollen (so wie ich D: )

MfG R.D.

Rechtschreibfehler sind beabsichtigt! :>

Würd ich nicht wirklich als Wissen über den Maker bezeichnen deine Formel.
Deine Formel ist schließlich praktisch linear (bis auf den kleinen Zufall) während eine vom Maker erzeugte "Early"-Kurve logarithmisch und eine "Late"-Kurve exponentiell aussieht.
Wirklich über den Maker was rausgefunden hast du also nicht.

Spontan würd ich als These aufstellen, dass der Maker die Formel a * Level^b + c aufstellt und für a, b und c etwas einsetzt, was zu den eingegebenen Level 1 und Level 50-Werten passt, Early/Later bestimmt dabei stark den Wert von b (Normal bedeutet dann wahrscheinlich, dass b 1 oder um 1 rum ist, Early dass b zwischen 0 und 1 liegt und Late dass b über 1 liegt). Probier mal was in die Richtung.

Oder wenns dir tatsächlich nur um ein eigenes Level-System geht, ignorier die Standardkurven des Makers und mach was eigenes. Ist letztendlich eh alles eine Frage des Balancierens.

Ja, vllt hätt ich das noch mehr hervorheben sollen, es ist nicht wie beim Maker kommt aber ungefähr hin.
Deine These is gut, ich probiere das und zum Thema "was eigenes machen", ja das mach ich ja XD
Ich will nur nicht dem Spieler sagen:
"Da haste 5 Statuspunkte,verteil die wie du willst"

In einem Klassik-RPG wie meinem möchte ich dem Spieler lieber verschiedene Charaktere mit verschiedenen Fähigkeiten geben, nach die sich der Spieler dann richten muss, so das alles einen Vorteil und Nachteil hat :D
Wenn du lustig bist, kannst du mir ja helfen ne gute Idee/Berechnung für eine Kurve zu machen, ansonsten werd ich deins testen und je nachdem, meine Rechnung nutzen (Die ja nun nich schlecht ist...oder o-O) oder eben deine^^

Cheating-Schutz und mehr
Wie jeder weiß, kann man im RPG Maker eine Anzahl an Variablen einstellen, die man nutzen möchte. Im Maker kann man dann nur diese Variablen auswählen, im F9-Menü sind auch nur diese Variablen sichtbar (z.B. 0001-5000).

Diese Begrenzung ist aber nur kosmetisch. Sie existiert hauptsächlich deshalb, weil das Array, was die Variablen-Namen fasst, eine fixe Länge haben muss. Tatsächlich können aber jegliche Variablen-IDs im Spiel verwendet werden.

Der RPG Maker reserviert immer nur Speicher für die Variablen bis zu jener, die die höchste in diesem Spiel verwendete ist. Soll heißen: Wenn noch keine Variablen verwendet wurden, ist auch kein Speicher reserviert. Wird der Variable 10 nun ein Wert zugewiesen, wird Speicher für 1-10 reserviert, etc.

Es gibt dabei aber keine Überprüfung auf einen Maximalwert! Man kann also beliebig hohe Variablen verwenden, auch jene weit über dem Maximum, das in der Database eingestellt ist. Diese kann man natürlich nicht im Maker auswählen.

Nun aber der Trick: Der Option "Variable No."/"Variable Refernce" (je nach Übersetzung) bei "Change Variable". Damit kann man ja Variablen anpointern, also sagen "Greif auf jene Variable zu, dessen Nummer in der Variable soundso steckt".

Um nun auf die Variable 123456 zuzugreifen (egal, welches Limit im Maker eingestellt ist), verwendet man folgendes:

Code:

---

<> Change Variable: [0001] = 123456
<> Change Variable: [V[0001]] = 999
<> Message: Wert von Variable 123456: \v[123456] (hier sollte 999 stehen)

---

Man braucht also immer eine Hilfsvariable, in die man die ID der gewünschten "unsichtbaren" Variable schreibt.

Da die Option "Variable No."/"Variable Reference" bei Forks nicht verfügbar ist, braucht man hier 2 Hilfsvariablen: in die zweite lässt man den Wert der angepointerten "unsichtbaren" Variablen schreiben und fragt sie dann in der Fork ab.

Das schöne daran: Nachdem sich die Anzeige im F9-Menü ja nach dem im Maker eingestellten Limit richtet, sind höhere Variablen dort nicht sichtbar! Cheater sind von diesen Variablen also ausgesperrt (außer sie durchschauen das System und ändern was in den Events).

Die Namen der "unsichtbaren" Variablen kann man dann natürlich nicht mehr im Maker einstellen, sondern muss sie sich wo anders aufschreiben.

Viel Spaß damit :)

mfG Cherry

Zitat:

---

Zitat von unfixable.

... dass, wenn ein Paralleles Common-Event unterbrochen wird, es beim wieder aktivieren genau DORT anfängt, wo es unterbrochen wurde?

---

Das hab ich heute am eigenen Leib zu spüren bekommen, hätte einer von euch ne Idee wie man das umgehen kann? Hab n common event auf parallel process und mit einem switch als Bedingung.
Wenn der Switch deaktiviert wird, stoppt das Event, doch sobald ich ihn wieder aktiviere, soll das Event wieder von vorne starten, was es jedoch leider nicht tut, es läuft genau da weiter wo es angefangen hat.
Ideen?
Mit Cycle und Break cycle lässt es sich leider nicht lösen, da es möglich sein muss das Event in jedem Moment zu stoppen und wieder neuzustarten.
Auch Forks die alle 0,1 Sekunden den Switch abfragen gehen nicht da das Event extrem lang ist (24 minuten)

Bin hier grade regelrecht am verzweifeln.

edit: Bin das ganze völlig falsch angegangen, hat sich erledigt :D

eine Möglichkeit ist, den Switch nicht als Startbedingung zu setzen, sondern das Event mit einer Fork einzurahmen. Dann wird es immer zuende ausgeführt.

Setzt man hinter Befehle, die irgendwas Grafisches ändern, einen Show Screen-Befehl, wird die Änderung überblendet!

z.B.:

<> Change Chipset
<> Show Screen

...

<> Change Panorama
<> Show Screen

...

<> Set Event Place
<> Show Screen

...

<> Move Event: Change Graphic
<> Show Screen

...

<> Change Switch (bei Events, wo sich dann die Grafik ändert)
<> Show Screen

...

<> Change Hero Charset
<> Show Screen

...

<> Show Picture
<> Show Screen

...

Der Fantasie sind keine Grenzen gesetzt!

Damit lassen sich sicher tolle Effekte machen.

mfG Cherry