Box IDs/Order/General insanity

[timecop]

https://code.google.com/p/multiwii/sour ... Wii.cpp#97
https://code.google.com/p/multiwii/sour ... ol.cpp#373
https://code.google.com/p/multiwii/sour ... types.h#33

Guys, what the actual fuck?
Why do you have "permanent" box IDs, and then go ahead and shift the box statuses by a number that CHANGES EACH TIME YOU ENABLE/DISABLE SOME FEATURE.

This makes no fucking sense, especially on proper platforms that don't #ifdef shit like you do.
Because when you have a bitfield status, you want same feature to always be in SAME POSITION ( = your idea of "permanent ID") but too bad it's not actually implemented????

So I recommend before you even bother releasing 2.3 to freaking fix this.

Fix is super easy - tmp |= 1 << boxids[BOXITEM];

THANKS!!!!!!!!

P.S. looks like multiwiiconf doesn't even use BOXIDS MSP, which means this crap will need to be fixed there, but sorry, I'm not touching THAT stuff.

[Alexinparis]

Hi,

At the beginning, we had only MSP_BOXNAMES.
It's used by multiwiiconf to display the box which are configurable.
Each box table is identified its position order in the name request.

There is however a drawback: requesting all the name in the same request could be huge, especially for OSD. (the need comes from here)

So MSP_BOXIDS was defined, and the purpose is to give a unique id for a BOX whatever the #ifdef feature choice.

Now your question: why not use tmp |= 1 << boxids[BOXITEM]; in the boxID request?
flag is a 32 bit variable and we can imagine one day to have more than 32 possible BOX
So, instead of transmitting the status identified by its unique BOXID identifier, we choose to still transmit the status identified by its position order in the BOXID request.
Advantage: we can have much more than 32 possible BOX, and up to 32 configured BOX.

So no insanity here just another logic
A proper platform should request once MSP_BOXIDS to know what to do after, like ez-gui or minimOSD for instance

[timecop]

You're still missing the point.
The order of the transmitted stuff changes depending on what stuff is defined or not, it does NOT solve the problem of "having more than 32 boxes" (it would need to be handled in your bit packing case as well), but instead it makes actually keeping track of boxes that much more stupid.

[Alexinparis]

take the table:
const uint8_t boxids[] PROGMEM = {
and imagine one day, we have a new need for a BOX
BOX_FOR_MAKE_COFFEE with unique id = 32 or more

how do you transmit its status ?
not possible with this way: tmp |= 1 << boxids[BOXITEM];

[timecop]

I think by the time you reach 32 boxitems, you'll have much more important problems to deal with, like why it doesn't fit into tarduino pro mini 328.

But ok, I get it.
You don't give a fuck that you're passing around variable length-meaning-order-etc bitfield, and don't plan to do anything about correcting it. That's fine. I fixed it in my code to work around this stupidity, with a couple-line change if you do ever decide to make it sane.

I'm pretty sure as soon as there's a multiwii fork that doesn't #ifdef every feature, you'll notice just how silly the current implementation is.

[copterrichie]

What happened to Keeping it SIMPLE? If my memory is correct, Mavlink was avoided because it was too complicated and the overhead was too much as that time. Seems this new protocol is following the same path and reinventing the wheel.