Фикс проверки столкновений при 0 длине шлейфа + Рефакторинги #314
Conversation
update from original
…е шлейфа (оба на своей территории) = get_forward_center_position + get_backward_center_position, они же для определения смерти от заливки (is_head_pawned, переименованный is_ate) * другие рефакторинги (переименоваения, переносы)
…ent и FileClient от базового класса)
update from base
| # both will be killed (1st - now, 2nd - later) | ||
| if player.get_forward_center_position() == p.get_backward_center_position() and \ | ||
| player.get_backward_center_position() == p.get_forward_center_position(): | ||
| self.append_event('faced with other player ([move] 1 <-> 2 [move])', player, p) |
There was a problem hiding this comment.
А если они бегут с разной скоростью, не справедливей будет убить только того, кто бежит быстрей (т.е. больше вылез со своей территории)? Хотя, коллизия, конечно, произойдёт сразу при начале движения.
Ну и неплохо было бы как-то в README отразить изменения.
There was a problem hiding this comment.
если они бежали с разной скоростью - один из них дойдет до центра клетки раньше и это отработается 2м кейзом, т.е. 2й человек еще движется в свою клетку, а 1й уже до него дошел - и вот кто дошел и повернул во врага (2го) только и помрет, а тот кто в свою идет - не помрет
There was a problem hiding this comment.
Откуда это следует? https://aicups.ru/session/541806/ Тик 549, у жёлтого закончилась скорость и он оказался в центре, а красный рядом - нет. Ещё у них у обоих могут быть разные бонусы, либо одинаковые, но у одного только что кончился, либо наоборот только подобрал. Короче, куча вариаций. Но вопрос один - должна ли скорость влиять на исход лобового столкновения с соседних территорий. Т.е. считаем мы что быстрый "вылазит" чуть больше со своей или нет?
There was a problem hiding this comment.
когда я говорил про 2й кейз я имел ввиду не этот блок кода, а следующий
elif not player.is_in_cell_center() and player.get_forward_center_position() == p.pos(): self.append_event('faced with other player ([move] 1 -> 2 [stop])', player, p)
| # 1st move to 2nd, 2nd stay in center | ||
| # 1st will be killed now, 2nd will survive (will no be killed - later) | ||
| elif not player.is_in_cell_center() and player.get_forward_center_position() == p.pos(): | ||
| self.append_event('faced with other player ([move] 1 -> 2 [stop])', player, p) |
There was a problem hiding this comment.
Слово 'stop' с толку сбивает, роботы же стоят только в начале и при глюках.
Может вместо move/stop использовать что-то вроде 'leaving home', 'at home' или с подобным смыслом?
There was a problem hiding this comment.
"stop" это "остановка" т.е он находится в центре, я думал очевидно, к тому же это для отладки чисто
There was a problem hiding this comment.
Да, я понимаю, что отладка. Просто как раз неочевидно, что у одного бота может быть состояние move, а у другого stop :)
There was a problem hiding this comment.
(из другой ветки)
Но вопрос один - должна ли скорость влиять на исход лобового столкновения с соседних территорий. Т.е. считаем мы что быстрый "вылазит" чуть больше со своей или нет?
Если 1й подобрал скорость, а 2й без скорости:
1й дойдет из точки [A] до центра клетки [B] на тик 100 (условно) и пойдет в направлении точки [C]
на тик 101 он будет по направлению [B] -> [C] и forward у него будет == [C]
а 2й дойдет из [D] до своего центра точки [C] в момент 101 (условно)(но всяко больше 100), и в момент когда 2й дойдет до центра [C] - сработает эта проверка: 1й уже идет в точку [C], а 2й находится в центре [C] - значит 1й идет в него - и надо 1го убить
2й еще никуда не идет т.к у него не успела вызваться программа опроса
| return '{}\n'.format(json.dumps(msg)).encode() | ||
|
|
||
| def begin_measure_time(self): | ||
| self.started_measure_time = datetime.datetime.now() |
There was a problem hiding this comment.
Я понимаю, что это пришло из старого кода, но не лучше тогда уж time.perf_counter() использовать, раз такое масштабное причёсывание делается?
| if self.execution_time > self.EXECUTION_LIMIT: | ||
| raise Exception('sum timeout error') | ||
| # | ||
| self.end_measure_time() |
There was a problem hiding this comment.
По-хорошему должно быть внутри finally, мало ли кто для отладки захочет время посмотреть.
| if self.get_backward_center_position() in captured and self.get_forward_center_position() in captured: | ||
| return True, p | ||
| else: | ||
| if self.get_backward_center_position() in captured: |
There was a problem hiding this comment.
Я так понимаю раньше погиб бы и приближаясь извне к центру захваченной клетки (но не зайдя в центр), а теперь только если предыдущее положение лежит в захваченной зоне. Это так и задумано? Новый вариант вроде логичней. Но вот что делать тем, кто не смотрит все merge requests, а только читает доки? :)
There was a problem hiding this comment.
этот кусок идентичен старому, там было сделано неочевидно, но проверялось в точности тоже что и сейчас
|
Не баг изначально. Возможно стоит понятнее расписать в правилах. |
check_loss_head_intersection = для проверки столкновений при 0 длине шлейфа (оба на своей территории) = get_forward_center_position + get_backward_center_position, они же для определения смерти от заливки (is_head_pawned, переименованный is_ate)
другие рефакторинги (переименоваения, переносы)