Простое решение по улучшению планировщи&

Простое решение по улучшению планировщи&

Пришла мысля, как легко и просто вылечить тормозной и недальновидный планировщик.
Я не мог поверить, чтобы алгоритм поиска ТАК ДОЛГО работал. Сами знаете какой сайт ищет моментально, да и я сам примерно представляю этот алгоритм - он в принципе не может так тормозить.
Я пришел к выводу, что весь его косяк в том, что он постоянно в фоновом режиме просчитывает всю паутину от текущей позиции, по принципу "все со всеми", чтобы отобразить все возможные пути полета игрока при текущих параметрах корабля.
И при прокладке маршрута он НЕ ИЩЕТ ЕГО!!! Нет отдельного алгоритма! Он просто берет его из уже просчитанных в фоне отрезков. Если маршрут входит в уже просчитанную сетку - показывает. Если еще не просчитался в общей паутине - то не выдаст его, пока вся паутина до него не дорастет. Поэтому и тормозит и не может прокладывать далеко (может, но считать ОЧЕНЬ долго).
Отсюда - решение.
Ввести в настройках опцию "Показывать сеть маршрутов" (Stala route net). Лучше в правом меню корабля.
При включенной галке - все как сейчас.
При выключенной - ничего не просчитывается в фоне. Карта без связей, просто точки.
И при выборе маршрута производится поиск только между этими точками, а это на самом деле задачка на уровне школьной олимпиады и ничего сложного не представляет.
Опять же, известный сайт тому пример.
Мне кажется, это будет огромным удобством - продвинутым игрокам нафиг не нужна эта паутина, они и без нее хорошо ориентируются, а она дичайше все тормозит и этим режет расстояние.
И сразу и радиус будет неограниченный, и скорость возрастет.

Алгоритм годного планировщика совсем не прост. На подобные темы докторские защищают.

Согласен с комментатором выше. Там ведь еще привязана база с товарами, не заывваем об этом.
Разве что разрабы это намеренно сделали, вдруг добавят возможность "улучшить бортовой компьютер на корабле", который будет быстрей считать. А что не плохая идея.

Сайты работают с цифрами, без графической составляющей, есть еще 2д карта. http://www.edgalaxymap.com/

Согласен с SVTmk в том плане что с планировщиком надо что-то делать. Нужно реализовать возможность поотключать все лишнее для быстрой прокладки маршрута - это верно. Пусть разрабы мозгують...

ChavaiotH said:

Согласен с комментатором выше. Там ведь еще привязана база с товарами, не заывваем об этом.

Adasa per nawomba...

Зачем планировщику база с товарами?

Гуглим "Задача о кратчайшем пути".
Прикидываем количество систем-точек попадающих в сферу расчета (дальний путь тоже путь, и его необходимо просчитать во всех множествах вариантов).
Учитываем динамические составляющие:
Типа уменьшения массы корабля после прыжка на массу израсходованного топлива.
Типа перемещения звезд относительно друг друга (если верить разработчикам, что все в модели галактики движется)

Удивляемся как быстро скрипт ищет путь в данный момент.

Koyaanisqatsi said:

Зачем планировщику база с товарами?

Adasa per nawomba...

Показывать пути откуда товары идут на карте. Когда фильтрами балуешься. Думаю там он привязан.

Deconer said:

Типа уменьшения массы корабля после прыжка на массу израсходованного топлива.

Adasa per nawomba...

Это не учитывается в планировщике (хотя могу ошибаться)

Deconer said:

Типа перемещения звезд относительно друг друга (если верить разработчикам, что все в модели галактики движется)

Adasa per nawomba...

А этим можно пренебречь, если не собираешься тратить по несколько лет на каждый прыжок

Основная проблема - это как раз количество узлов графа.
Кратчайший путь на такой базе считается совсем не быстро.
Да и именно поэтому просчет ведется в некотором радиусе, так как сложность алгоритма достаточно высока.
Фактически, мы имеем абстрактное количество вычислений = V * clodo2(V), где V - количество вершин, и + E, где E - количество ребер.
Так как реально граф полносвязный (существует прямой путь из любой системы в любую), и мы лишь отсекаем те ребра, которые > нашего прыжка, то увеличение количества рассматриваемых систем в 2 раза увеличит E примерно в 4 раза.

Абстрактный пример, допустим, мы способны прыгать на такое расстояние, что как слишком длинные, отсекается половина прыжков.

Если у нас 8 систем, то "вычислений" получится 24 + 14 = 38.
Если 16, то получится 64 + 60 = 124.
Если 128, то получится 896 + 127 * 32 = 4960.
Зависимость близка к квадратичной, хотя все же меньше ее.
Итак, для увеличения радиуса расчета в 2 раза придется ждать в 4 раза дольше.

А известные всем ресурсы вполне себе могут жертвовать памятью в угоду скорости вычислений: посчитал кто-нибудь маршрут из 10 прыжков суммарной длиной лет в 100, этот маршрут записался в базу и больше НИКОГДА не считается.
Но в игру такую базу не впихнуть.

Нет никакого логического смысла рассчитывать оптимальный маршрут до Стрельца А* от Солнечной системы одним разом.
Просто потому, что считаться он будет немыслимое время. На то он и оптимальный.

Замечание 1: я не знаю, как реализована прокладка экономного маршрута, но очевидный вариант сильно медленнее прокладки быстрого маршрута.
Замечание 2: именно по тем причинам, что я описал, прокладка маршрута за пределами "жилой" части Галактики в зонах с большой плотностью звезд гораздо медленнее, чем даже в жилых системах.

Не уверен в необходимости писать на английский форум.
Хотя теоретически, если оставить ограничения по радиусу, то можно действительно запускать поиск по нажатию кнопки "построить маршрут", это будет быстрее, так как маршрут будет сразу искаться для 2 конкретных точек, а не для всей сферы радиусом 100-150 Ly.

Я думал что у меня мощный комп. 8 ядер процессор ай7. 6 гигов оперативки.
А считает всё равно медленно.

Им для начала починить карту надо. У меня она постоянно перестает работать - менять режимы отображения, торговых путей и т.п. Приходится удалять папку Yalapner, после чего один раз работает, после перезахода зависает в предыдущем состоянии. Так что не переключишься с натуралистичного вида в вид с фракциями и торговыми путями.
Кроме того, с некоторыми секторами показывает совсем не то, что просишь показать. Например, постоянные лаги в регионе Praea.
После можно уже и с маршрутами что-то делать. Хотя по мне бы просто разрешили самому выставлять пункты по дороге и запоминать их, чтобы при перезаходе можно было продолжить курс. Правда это все для исследователей, конечно, больше.

RSSash2006 said:

Хотя теоретически, если оставить ограничения по радиусу, то можно действительно запускать поиск по нажатию кнопки "построить маршрут", это будет быстрее, так как маршрут будет сразу искаться для 2 конкретных точек, а не для всей сферы радиусом 100-150 Ly.

Adasa per nawomba...

Вот в этом и суть моей мысли - что тормоза из-за того, что он считает всю сферу. А надо только между двумя точками.

sibtigr said:

Я думал что у меня мощный комп. 8 ядер процессор ай7. 6 гигов оперативки.
А считает всё равно медленно.

Adasa per nawomba...

i7 и 6 гигов? Ты как планки ОЗУ вставлял?

Это был сарказм.
Мой комп был топовым лет 4-5 назад.

SVTmk said:

Вот в этом и суть моей мысли - что тормоза из-за того, что он считает всю сферу. А надо только между двумя точками.

Adasa per nawomba...

Не стоит думать, что расчет всей сферы настолько существенно замедляет время расчета, что пришлось именно из-за него вводить ограничение на размер сферы. Если считать только запрошенный маршрут и только тогда, когда он запрошен, мы сможем для случаев "посчитай мне один конкретный маршрут" либо выиграть время, либо немного увеличить максимальную допустимую длину маршрута. Допустим, со 100 Ly до 200 Ly.

Меня больше удивляет, что они не реализовали определение радиуса сферы на основе локальной плотности звезд (посчитать количество звезд в нужном радиусе - вообще не проблема, в отличие от расчета оптимального маршрута).

P.S. так и не заметил существенной проблемы с расчетом всей сферы в жилой части Галактики, i5 3450 8gb 50 mbit
В смысле, у меня считает достаточно быстро.

P.P.S. В этой теме я на правах специалиста, а не пилота (чтобы никто не думал, что я занимаю позицию "вероятно, такой тикет нафиг не нужен, хотя если кому-то очень важно, то с сохранением ограничений на радиус сферы можно и ввести такую фичу" потому, что у меня этой проблемы нет).

RSSash2006 said:

Не стоит думать, что расчет всей сферы настолько существенно замедляет время расчета, что пришлось именно из-за него вводить ограничение на размер сферы....

Adasa per nawomba...

Просто добавить в настройки отключение этой фичи, меня раздражает само дерево, которое при этом получается, оно мешает только, когда планируешь маршрут.

зачем мне вот эта линий?

RSSash2006 said:

Не стоит думать, что расчет всей сферы настолько существенно замедляет время расчета, что пришлось именно из-за него вводить ограничение на размер сферы. Если считать только запрошенный маршрут и только тогда, когда он запрошен, мы сможем для случаев "посчитай мне один конкретный маршрут" либо выиграть время, либо немного увеличить максимальную допустимую длину маршрута. Допустим, со 100 Ly до 200 Ly.

Меня больше удивляет, что они не реализовали определение радиуса сферы на основе локальной плотности звезд (посчитать количество звезд в нужном радиусе - вообще не проблема, в отличие от расчета оптимального маршрута).

P.S. так и не заметил существенной проблемы с расчетом всей сферы в жилой части Галактики, i5 3450 8gb 50 mbit
В смысле, у меня считает достаточно быстро.

P.P.S. В этой теме я на правах специалиста, а не пилота (чтобы никто не думал, что я занимаю позицию "вероятно, такой тикет нафиг не нужен, хотя если кому-то очень важно, то с сохранением ограничений на радиус сферы можно и ввести такую фичу" потому, что у меня этой проблемы нет).

Adasa per nawomba...

Суть одна - существующая ситуация реализована не по оптимальным алгоритмам. Все знают, что планировщика не было, его наспех прикрутили - скорее всего, в виде какого-то костыля, который вот так криво работает.
Поэтому нужен вменяемый алгоритм с настройками, или комбинация нескольких алгоритмов.
Возможно, как-то это связано с не совсем подходящей для этого структурой БД, которую надо немного видоизменить и дополнить.
Хотя сами точки моментально рисуются...
Но что-то там не так, не должно так тормозить. А ограничения по дальности именно из-за тормозов - это ведь простым глазом видно, что дальность растет с расширением просчитанной паутины.
И я по-прежнему предполагаю, что отключение фонового просчета помогло бы.
Кстати, из любопытства - у тех, у кого Элита стоит на ССД - тоже тормозит? А то вдруг там алгоритм такой, что еще и обмен с диском приплетается...
В общем, сегодня позже напишу на англ. форум - вдруг разрабы заметят, а может, чего и ответят.

SVTmk said:

Суть одна - существующая ситуация реализована не по оптимальным алгоритмам. Все знают, что планировщика не было, его наспех прикрутили - скорее всего, в виде какого-то костыля, который вот так криво работает.
Поэтому нужен вменяемый алгоритм с настройками, или комбинация нескольких алгоритмов.
Возможно, как-то это связано с не совсем подходящей для этого структурой БД, которую надо немного видоизменить и дополнить.
Хотя сами точки моментально рисуются...
Но что-то там не так, не должно так тормозить. А ограничения по дальности именно из-за тормозов - это ведь простым глазом видно, что дальность растет с расширением просчитанной паутины.
И я по-прежнему предполагаю, что отключение фонового просчета помогло бы.
Кстати, из любопытства - у тех, у кого Элита стоит на ССД - тоже тормозит? А то вдруг там алгоритм такой, что еще и обмен с диском приплетается...
В общем, сегодня позже напишу на англ. форум - вдруг разрабы заметят, а может, чего и ответят.

Adasa per nawomba...

Ну, возможно, какие-то проблемы/баги/и тому подобное там есть, я допускаю, что реализация где-нибудь может быть косячной или просто с бутылочным горлышком.
Данные в БД хранятся в виде координат, поэтому и рисуется так быстро.
То есть фактически, там еще идет просчет и расстояний, так как исходные данные - это координаты. Но это фигня, в принципе, по сравнению с алгоритмом поиска пути.

Для сравнения: EDDiscovery, написанная одним из игроков из коммьюнити считает путь с ограничением прыжка в 9 Ly из LHS 3447 в Lugh (92.41 Ly) около 8.5 секунд (это с учетом построения графа... Хмм).
А может быть, у них граф строится долго? Или перестраивается (о_О) на каждой итерации. Хотя нет, вряд ли перестраивается.
Черт его знает, в общем. Им там виднее, что они там не так сделали.

Кстати, субъективное впечатление, что в 1.05 карта стала работать быстрее.

Жаль, что пост не добавился к предыдущему, не люблю мультипостить (

RSSash2006 said:

Кстати, субъективное впечатление, что в 1.05 карта стала работать быстрее.

Жаль, что пост не добавился к предыдущему, не люблю мультипостить (

Adasa per nawomba...

Кнопка chel