Rouzi, в видео этот момент пошагово описывается.
Сопоставляешь каждой вершине информацию - как быстро её можно достичь (назовём это вес), и из какой вершины (шаг пути).
Поначалу для всех вершин вес будет +бесконечность, а шаг пути будет отсутствовать. Для стартовой будет вес 0.
Потом перебираешь все вершины, у которых вес не +бесконечность. Назовём их "известными".
Для каждой такой вершины перебираешь соседние вершины, т.е. те, которые с ней связаны напрямую ребром графа. Как их определить - зависит от того, как ты хранишь граф. Так что дальше вложенный цикл.
Для каждой соседней вершины проверяешь условие: вес текущей известной вершины + вес ребра от текущей известной к текущей соседней должны быть меньше, чем вес соседней вершины. Если условие выполняется, то для текущей соседней вершины запоминаешь её новый вес (сумма весов из условия) и её шаг пути (текущую известную вершину). Также взводишь логический флаг - было изменение веса.
Эти два вложенных цикла повторяешь до тех пор, пока логический флаг взведён, т.е. пока в рамках цикла ты обновил хоть одну вершину. Когда обновлений не произошло - ты просчитал весь граф, можно строить путь.
После этого путь строить просто. Начинаешь из вершины-пункта назначения, и смотришь, какая вершина сохранена для неё как "шаг пути". Идёшь туда, смотришь для той вершины шаг пути. И так пока не придёшь в точку отправления.
MegaEdwards, очень просто. У тебя же где-то хранится список открытых тикетов? В БД, или еще в каком хранилище. Если нет, то стоит сделать, иначе при перезапуске бота открытые тикеты потеряются.
Ну так просто для каждого тикета храни ID ассоциированного с ним сообщения. Тогда, получив on_raw_reaction_add, ищешь тикет с таким ID сообщения в хранилище. Если нашёлся - обслуживаем этот тикет согласно его состоянию и поставленной реакции. Если нет - молча игнорируем, или ещё что делаем.
s4q, ну так я на то и намекаю. Пока ты не сформулируешь критерий оптимальности маршрута, ничего не попишешь.
Самый короткий маршрут всегда будет прямой A -> B.
Если брать самый "жадный" маршрут (т.е. ехать всегда в ближайшее к текущему отделение), то можно, как это ни смешно, начать выписывать вензеля по карте.
Минимальный вариант я привёл выше - если ты сможешь для каждой точки определить те, с которыми она может быть связана, то у тебя получится взвешенный граф, в котором можно искать кратчайший путь алгоритмом Дейкстры. Простейший способ это сделать - наложить ограничение на длину одного переезда.
А если у тебя задача практическая, то тут вообще убиться можно, потому что ещё есть такие вещи как пропускная способность дорог, вместимость и пропускная способность отделений, и так далее, и так далее. Т.е. если многие оптимальные маршруты ведут через одно и то же отделение, это может замедлить дело, так как отделение будет перегружено.
s4q, этих сведений мало. Почему в твоём примере нельзя сразу сделать прыжок A -> B? Какие точки считаются "соседними"? А вообще есть классический алгоритм дейкстры.
MIHUTKA, так. А оригинальный запрос тоже post? Или всё же GET?
Ну а так, отвечает тебе даже не сам сайт, а его CDN, и скорее всего ему не нравится твой бот. Маскируйся лучше, заголовки запроса там, куки...
MIHUTKA, ну опять-таки, подробности.
Как выяснял структуру запроса, какие заголовки передавал, что сервер отвечает ...
Телепаты все релоцировались, угадывать некому.
SerdarAD, искать в пакете заголовок HTTP запроса. Только нужно иметь ввиду:
1. сайтов на голом HTTP всё меньше и меньше, все популярные уже перешли на HTTPS.
2. заголовок, по идее, не обязан целиком находиться в одном пакете, он может быть разорван по двум или более последовательным.
В общем, тут проще поискать готовые DPI решения...
Valmond257, значит, не выйдет бота на Telethon на этой площадке развернуть. Или пробуй другую бибилотеку, которая умеет работать через чистый HTTP прокси, или ищи другую площадку.
SerdarAD, ну да, делов-то - обойти основной механизм безопасного соединения, специально созданный для осложнения мониторинга/вмешательства в трафик, и используемый по всему миру...
Без солидного вмешательства в работу клиентской машины (установка своего корневого сертификата) - нет.
Короче, почитай, как TLS работает.
Сколько всего таких методов, и как часто их приходится писать?
Можно изобразить обобщённый метод, который во втором if вызывает переданную лямбду, но есть ли смысл?
Сопоставляешь каждой вершине информацию - как быстро её можно достичь (назовём это вес), и из какой вершины (шаг пути).
Поначалу для всех вершин вес будет +бесконечность, а шаг пути будет отсутствовать. Для стартовой будет вес 0.
Потом перебираешь все вершины, у которых вес не +бесконечность. Назовём их "известными".
Для каждой такой вершины перебираешь соседние вершины, т.е. те, которые с ней связаны напрямую ребром графа. Как их определить - зависит от того, как ты хранишь граф. Так что дальше вложенный цикл.
Для каждой соседней вершины проверяешь условие: вес текущей известной вершины + вес ребра от текущей известной к текущей соседней должны быть меньше, чем вес соседней вершины. Если условие выполняется, то для текущей соседней вершины запоминаешь её новый вес (сумма весов из условия) и её шаг пути (текущую известную вершину). Также взводишь логический флаг - было изменение веса.
Эти два вложенных цикла повторяешь до тех пор, пока логический флаг взведён, т.е. пока в рамках цикла ты обновил хоть одну вершину. Когда обновлений не произошло - ты просчитал весь граф, можно строить путь.
После этого путь строить просто. Начинаешь из вершины-пункта назначения, и смотришь, какая вершина сохранена для неё как "шаг пути". Идёшь туда, смотришь для той вершины шаг пути. И так пока не придёшь в точку отправления.