Conversation Between BluRose and Blah
16 to 19 of 19
  1. Blah
    November 30th, 2015 3:44 PM
    Blah
    Yeah, 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: 0x0000
    So 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.
  2. BluRose
    November 30th, 2015 1:23 PM
    BluRose
    Yes, 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?
  3. Blah
    November 29th, 2015 9:09 PM
    Blah
    Let 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?
  4. BluRose
    November 29th, 2015 7:00 PM
    BluRose
    I'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"?