MultiServer: Add slot to SetReply packets

[NewSoupVi]

Alternative / generic solution for #3117

Upside of this one being that clients do not need to change to support the new EnergyLink protocol.

Tested: Ran MultiServer.py --log_network, connected with a client that sends datastorage Set operations, verified that outgoing SetReply packets contain slot: 1

[Jarno458]

That would indeed simplify #3117 a lot and could also be useful for other scenario's but, maybe there is a case to be made to keep some set packets anonymous? well i do be in favour of this change

[NewSoupVi]

maybe there is a case to be made to keep some set packets anonymous

Actually, in my opinion, clients should be required to expose themselves - I don't really see the value in slot-anonymous packets in the AP ecosystem (other than to save space maybe)

[Jarno458]

One more thing to consider, while i don't think its a problem, this would technically be a breaking change, as currently clients can add any arguments they want to the set packet to be received in the reply, and some might already use the field slot that your than overriding

[NewSoupVi]

One more thing to consider, while i don't think its a problem, this would technically be a breaking change, as currently clients can add any arguments they want to the set packet to be received in the reply, and some might already use the field slot that your than overriding

That's true. I would imagine they would simply be filling it with the same thing I'm currently overriding it with though. Either way, if it's an issue, I could

1. Use setdefault
2. Use a more explicit name that's less likely to already be in use (e.g. originating_slot_number)

But I don't really like 1, because then it's not reliable, and I kinda don't like 2. because it's nice that slot is a really short, memory efficient word :D

[Jarno458]

Agreed, i do like the simplicity of slot, (inb4 someone asks for team)

[agilbert1412]

I can't speak for if this is better than #3117, but the code looks good to me