Currently, as soon as the tenth-or-later client joins, we just assert, at shared/message_infrastructure.py#83:
assert len(words) == self.count
That assert is probably invalid, because if self.count == 1 then words should just be a single word. But if you make that change:
def encode(self, arg):
words = self.encodeFunc(arg)
- assert len(words) == self.count
+ if self.count == 1:
+ assert type(words) == str
+ else:
+ assert type(words) in [tuple, list]
+ assert len(words) == self.count
return words
then you get much weirder problems. The ids start getting sent as multiple numbers, so when client number 11 joins, you start getting messages like:
your_id_is 1 1
set_pos 1 1 0.188845717919 0.982006769235
which have too many arguments. Worse, somehow we aren't just crashing because the arities are wrong; instead, we read the number of arguments that we expect and ignore the extra ones. So, for example, movement is constrained to a single axis, and if another client joins then they both crash because they think both obelisks have id 1.
Currently, as soon as the tenth-or-later client joins, we just assert, at shared/message_infrastructure.py#83:
That assert is probably invalid, because if self.count == 1 then words should just be a single word. But if you make that change:
then you get much weirder problems. The ids start getting sent as multiple numbers, so when client number 11 joins, you start getting messages like:
your_id_is 1 1set_pos 1 1 0.188845717919 0.982006769235which have too many arguments. Worse, somehow we aren't just crashing because the arities are wrong; instead, we read the number of arguments that we expect and ignore the extra ones. So, for example, movement is constrained to a single axis, and if another client joins then they both crash because they think both obelisks have id 1.