Mission txt file format

Trying to fully understand what values and ranges are valid at the moment in mission commands (stored in the .txt file with save wp in planner) and with Arducopter 3.1 , I ran across this which I cant figure out…

from the firmware code it appears that the command structure is command id(byte), param1(byte),followed by param2-4 as double words…looking at the .txt output file from MP for the commands I routinely want to use, some commands dont look right…specifically the condition_delay and condition_yaw commands seem to have values located in wrong fields when compared to the firmware code for Arducopter 3.1…

what am I missing? I would have thought that the .txt file would be command independent and not require translation into different values of the command data array by the firmware…ie first field is always id, second is param 1, etc…fourth is always param4 (.alt)

I can understand the other blank fields in the file as placeholders for future expansion of the mavlink command fields but not the swapping of values for certain commands…

[attachment=0]mavlink commands.jpg[/attachment]

please see here
qgroundcontrol.org/mavlink/waypo … ile_format

I do not believe that this is solved for sure…the CONDITION_YAW does not work when loaded from MP but the firmware looks correct to me…

all Arducopter waypoint commands in the list are stored internally in this format:
Alt(Param 7)…dword

the CONDITION_YAW command use ALT for angle(since it must be larger than just a byte!), LONG for absolute/relative, LAT for turn rate, and in the future Param1 as CW/CCW…

here is the code:
static void do_yaw()
// get final angle, 1 = Relative, 0 = Absolute
if( command_cond_queue.lng == 0 ) {
// absolute angle
yaw_look_at_heading = wrap_360_cd(command_cond_queue.alt * 100);
// relative angle
yaw_look_at_heading = wrap_360_cd(control_yaw + command_cond_queue.alt * 100);

// get turn speed
if( command_cond_queue.lat == 0 ) {
    // default to regular auto slew rate
    yaw_look_at_heading_slew = AUTO_YAW_SLEW_RATE;
    int32_t turn_rate = (wrap_180_cd(yaw_look_at_heading - control_yaw) / 100) / command_cond_queue.lat;
    yaw_look_at_heading_slew = constrain_int32(turn_rate, 1, 360);    // deg / sec

// set yaw mode

// TO-DO: restore support for clockwise / counter clockwise rotation held in command_cond_queue.p1
// command_cond_queue.p1; // 0 = undefined, 1 = clockwise, -1 = counterclockwise


since every command uses this same structure,I would imagine its the waypoint file generators responsibility to put the command variables in the correct parameter for each command…that would be MP, tight?
or have I misunderstood something here…I am a newbie…

you need to look in gcs_mavlink.pde as well. to see the internal mapping of the params done buy the firmware