Conversation Between BluRose and Blah
Showing Visitor Messages 16 to 19 of 19
-
November 30th, 2015 3:44 PMBlahYeah, the bit are in reverse. My bad, pound was a bad example since it was a palindromic bit field. Keep the values for each of the fields equivalent to current gen games (You can find those values in bulbapedia). For things like spikes, I'll handle it differently :)
Finally, for the python script. You can just make something like this:
Pound, script_id :0x00 ,base_power: 0x28, type: 0x00, Effect accuracy: 0x64, PP: 0x23, Affected targets: 0x00, Priority: 0x00, Flags: 0x00, Bitfield: 0x33, is_special : 0x00, move ID: 0x0000So keeping the formatting the same is important. All move data in one line, where each field is seperated by a comma. Then for the next move, you'd put it on the next line.
I don't care if you don't use hex, and use decimal instead. But please don't mix and match bases. After you create this reference file, it's up to you whether or not you can write a python script to create the hex table (those 12 bytes) from it. Otherwise just post it in the thread (or better yet, send me a PR on github) and I'll make the script. -
November 30th, 2015 1:23 PMBluRoseYes, everything makes sense, but just a few "just to make sure" questions:
So, basically, just the same values as Vanilla FR for the most part?
And, what about Spikes if "opponent_field" is never going to be selected? Or will it be covered differently, by some arbitrary coding?
For the bit field, would it then actually be 11001100 instead of 110011 because of the last two values? Otherwise, it seems like it would be reading literally everything the opposite (00110011 translates to every single bit being reversed from your example), which would then make the value 0xCC?
EDIT: Oh, and you'd then just want it in the 12 bytes form? Or do you want a .txt file giving you the information (1 byte per line) to write the Python script for?
EDIT EDIT: Oh, wow, it looks like that, at the rate that this is really going, it's going to be done shortly, haha...
Is it also going to handle graphics, text and the whole nine miles? -
November 29th, 2015 9:09 PMBlahLet me give you an example.
This is the structure of a move in the move table:
Spoiler:
struct move_table {
u8 script_id;
u8 base_power;
u8 type;
u8 accuracy;
u8 PP;
u8 effect_accuracy;
u8 affected_targets;
u8 priority;
u8 contact : 1;
u8 protect : 1;
u8 magic_coat : 1;
u8 snatch : 1;
u8 mirror_move : 1;
u8 kings_2,k : 1;
u8 crit_chance : 1;
u8 padding_field : 1;
u8 is_special;
u16 move_id;
};
This is what I'd look like for Pound:
00 28 00 64 23 00 00 00 33 00 00 00 translating to:
Spoiler:
Pound:
script_id :0x00 // leave as 0 for all moves
base_power: 0x28 // Pound is 40 power, hence 0x28
type: 0x00 // 0x0 is normal type. Pound is a normal type move
Effect accuracy: 0x64 // 100% accuracy
PP: 0x23 //Pound is 35 PP
Affected targets: 0x00 // 0x0 = affects selected target.
Priority: 0x00 // has no priority - uses speed stat
Flags: 0x00 // leave as 0x0 for all moves
Bitfield: 0x33 // will explain at bottom
is_special : 0x00 // 0x0 means pound is a physical move. Set to 0x1 to be special
move ID: 0x0000 // pound is ID 0. It's the first move. See moves.h in my github for IDs
For the affect targets field use:
0x00 Selected target
0x01 Depends on the attack
0x02 Unused
0x04 Random target
0x08 Both foes
0x10 User
0x20 Both foes and partner
0x40 Opponent field
0x40 will never be used for this engine - so ignore it.
For the bit field:
Pound's bit field was 0x33. So convert that to binary (your window's calculator can do that) : 110011
Those bits translate to:
contact = 1; // pound makes contact (1), 0 for a move that didn't make contact (i.e grass knot)
protect = 1; // protect blocks this move (1), 0 if protect can't block it
magic_coat = 0; // reflected by magic coat
snatch : 0; // can be stolen by the move snatch
mirror_move : 1; // can be copied by the move mirror move
kings_rock : 1; // kings rock boosts this attack
crit_chance : 0; // crit_chance = 1 means the move has high chance to crit
padding_field : 0; //padding is always 0
Does that all make sense? -
November 29th, 2015 7:00 PMBluRoseI'm really sorry for bothering you, but, when making tables for the moves for the Battle System, you gave a structure. I would love to start on that, but don't really understand some of the structure...
I have a few question, most regarding my cluelessness on C and how it interprets the tables...
Part of your structure:
Spoiler:struct move_table {
u8 script_id;
u8 base_power;
Given these lines, what exactly would I want to replace? The "u8" (denoting size, right?) or the word directly after it (in the example, would I want to replace "script_id" and "base_power" with a value?)? In Hex or Decimal? Do we want updated Gen VI moves (for base power/PP/Accuracy changes and the like)? And, finally, what exactly is the "padding_field"?


