Например, Адриан Чайковски "Дети Времени". В научной фантастике нестандартные образы мышления часто исследуются с разных сторон. Оно есть, оно требует кропотливой работы и недюжинного ума. Даже просто написать историю о людях, которые мыслят действительно по-разному, не каждый автор может. А люди у нас в мире очень разные, не нужно даже инопланетян придумывать, чтобы удивляться.
Имхо, углубляться во что угодно нестандартное было бы странно при создании развлекательного продукта. Одно дело сделать сюжет про инопланетянина, который спасает дочку и производит понятные условному большинству действия в небудничном антураже. И совсем другое, экспериментировать с устройством общества этих инопланетян. Вы же первый скажете, что "прикольная попытка, но должно быть не так".
У Mass Effect идея о том, что объединились расы, у которых похожие проблемы. А у которых не похожие, не объединились. Что жизнь, это неизбежность и не эти, так другие, но снова пойдут этим путем когда-то однажды. Ну и на культуру рас сильно влияет федерация, тысячи лет членства это ощутимо.
С крайностями понятно, потому что они очевидные. Когда линейная рутина и просто устанавливаем нужное состояние, то резать ее на куски излишне. А когда из алгоритма легко можно выделить библиотечный примитив, то не выделять его, это сбивать фокус у читателя.
Но давайте поговорим о чем-то среднем. Сегодня разбирал класс, у него в основе несколько списков (to_update, to_create) и пара хэш таблиц, в которые по ключам расставляются данные. Сам класс пытается сравнить две последовательности: то, что пользователь пытался заказать и то, что поставщик в итоге в посылку положил. Если чего-то нет, то отметить, если что-то разделили на товары из разных партий, разделить это и в заказе. И т.п., логики много, есть позиции с дочерними позициями, есть виртуальные позиции.
Так этот класс аккуратно порезан на функции, функции какими-то флагами обмениваются между собой, но все обращаются к общим переменным, постоянно туда что-то добавляя. Оформлено тщательно и хорошо, а читать тяжело, 600 строк туго переплетенного месива на python: хоровод с циклами, списками и словарями. Было бы дерево в основе, было бы куда его растить.
И вот имхо, даже если бы этот код написали плохо, но в том же стиле, сильно хуже он читаться не стал бы. А если бы двое разработчиков сели и потратили день-два, чтобы перетасовать методы класса, не переписывая начисто, он не стал бы понятнее.
Сначала нужно постараться с организацией данных, потом с общей концепцией. И только потом аргументы за "резать" или "не резать" начинают что-то значить.
Лес разный. В ленточном сосновом бору некоторых регионов Сибири, например, деревья стоят относительно плотно и тянутся вверх, а почва это непрочный суглинок. Когда ветер сильный, то одно из деревьев рано или поздно не выдерживает нагрузки, получается пробел и нагрузка на другое дерево возрастает, оно тоже падает.
В итоге, можно найти участок, где полосой повален ценный пиловочный материал, приезжай и бери. А контроль за лесом жесткий, его воруют и в черную, и в белую, поэтому споров о том, что кому когда можно, немало. А еще там сухо и даже упавший сухостой еще местами пригоден на распиловку, а уж точно на дрова.
В болотистых таежных местах Томской области, например, такого нет. Другие почвы и сыро. Если что-то упало, то значит оно сгнило еще стоя, а если и нет, то сгниет в считанные недели.
Насколько я понял, это такой enterprise интерфейс для self-hosted моделей. Акцент на контроле: кто куда заходил, с чем ему можно там работать и что он при этом у модели спрашивал. Потому, что даже внутри одной компании есть вещи, с которыми работают люди и которые не нужно знать работникам. Даже бизнес-подписка от openai, где обещают не использовать ввод пользователей для обучения моделей, все равно не подходит корпорациям, потому что секреты публикуются в чужом контуре.
Судя по описанию, умеет оно примерно то же, что и projects в gpt: диалоги с доступом к контексту в файлах и кастомным prompt. На картинках все больше о ролях, аудите и о том, что развивайте как хотите, мол это платформа, а не готовый ИИ ассистент.
Такое мнение можно найти про все, что требует усилий. Так уж устроен человек. И вместе с тем, есть люди увлеченные, готовые чем-то заниматься уже только потому, что это интригует. Позвольте под вашим комментарием разместить манифест о том, что учиться очень хорошо и полезно, это развивает мозг и формирует личность.
Возможно ли сконфигурировать прикладное решение, не прочитав ни одной книги и заработать на этом? Да, конечно. С ростом опыта еще и время эффективно потратив.
Так то эти задачки придумали для собеседований, чтобы как-то формализовать отбор, чтобы рекрутеры могли высокомерно рассуждать о квалификации кандидата, не утруждаясь значению слов. И вот конкретно в Яндекс задачи третьей секции выбирают откровенно глупые, наверное потому, что сложные не каждый интервьюер сможет. И эти интервьюеры еще наплевательски относятся к собеседованию: опоздал, ну да и ладно, зато неспеша начнем, как раз поболтать захотелось и есть идея про задачу (неправильная). Кроме молодых ребят, которые на первых двух этапах, те волнуются и серьезны, причем у них и задачи интереснее бывают, чем на "алгоритмической" секции.
Так вот, задачи глупые, а собеседования пафосный бардак. Но алгоритмы это круто и алгоритмы это не пара трюков из однострочных задачек. Можно не учить и не знать, но не нужно таких специалистов смешивать в одном ряду, они из разных сфер. Кто-то уже все сделал, что можно использовать готовое? Так оно не само готовым сделалось.
К слову, для сотрудников того же Яндекс одно время читал лекции Максим Бабенко.
С GPT есть другая серьезная проблема в нашей работе, о ней пока мало говорят. Это коллеги, которые раньше ничего не делали и потому не мешали.
Например, входящий запрос от руководителя: "Я ввел описание твоей задачи в gpt и мне кажется, что она написала что-то дельное, но я не читал. Прочитай, напиши мне аргументированный ответ и объясни свою позицию, обязательно понятную мне, чтобы я мог цепляться к словам не утруждаясь".
Или соседняя команда, которые сгенерировали JSON и опубликовали его в качестве контракта не читая. И передали его тебе на ревью, чтобы ты сделал эту работу целиком. Отчитаться, что на их стороне все готово, они не забыли, теперь ждут одного только тебя.
У гоферов проблема с `go run`, там компилятор такой быстрый, что можно запускать из исходников. В rust есть `cargo run`, хотя оно и медленнее. Например, это автоматическое тестирование: собрали в нужной конфигурации, запустили и так много раз. Можно еще представить что-то сервисное, когда код генерируется из шаблонов под задачу и сразу же выполняется.
Спасибо за ссылку, интересно было почитать, как люди живут. Там в POSIX пытались сделать так, чтобы дочерный процесс получал закрытые дескрипторы после fork. И не сошлись во мнении, что будет с сокетами.
>> The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.
То есть мешал не столько запрет на запись в выполняемый файл, сколько запрет запускать не закрытый после записи файл. Насколько я понял, проблема была с fork'нутыми процессами, которые успевали форкнуться до того, как файл был закрыт. И страдали из-за этого, в первую очередь, go разработчики с их goрутинами, которые форкаются сами по себе.
Раз статья для того, чтобы вставить свою фамилию в первом абзаце, то писать ее нужно все же самому. Ведь есть же интересные истории про проекты, где не выполнялось то или иное, или все сразу. Редактор молодец, а вот материала ей большой директор выделил мало.
Мне тоже это кажется наглостью. Требования жесткие, а бюджет скромный. И даже если никто не предложит это "вау" из коробки, то можно забесплатно собрать обзор по использованным подходам. Одна только сопроводительная документация позволит упростить разработку собственного решения.
Бывает и веселее, одна компания рассылала приглашения на свой хакатон. И в приглашении конкретное ТЗ, по которому им нужен прототип, приходите мол с уже готовым, показывайте. Призовой фонд 150тыс (нашими, бесполезными). И я тогда подумал, что за такие деньги тоже хочу прототип нового продукта, а еще с возможностью нанять разработчиков.
На форуме wasm.ru он писал развернутые сообщения о своей жизни в США после переезда. Работал в McAfee и делали они анализ зловредов в сети на лету. Рассказывал про анализ pdf (там есть js внутри), доказывал что у него там всякие крутые ребята вокруг и что он не выделяется.
А меня удивляет, что если человек не против работать в условном озоне, то его собеседуют по принципу брать/не_брать. При этом компания отчаянно нуждается в людях, задачи разноплановые, у команд разные стили и требования.
Как по мне, обязательно нужно проверить на адекватность и умение связно мыслить, дисциплину и умение работать. А техническое интервью нужно для оценки и проф. ориентирования, но не как барьер.
Завалил задачку на кодинг в граничных случаях, но правильно рассуждал про нее и архитектуру? Ну покрутись вот в этой команде на мидловской роли во время испытательного срока, джунов поменторишь и сам подучишься. Будет 0.75 от ожидаемой зп, через три месяца пересмотр. Или вот в этой команде, они там документацию никак не успевают наладить, а у тебя по всем тех. навыкам провал, кроме аналитических. Вектор развития обсудим через два месяца.
В rpg часто есть кнопка для случайной генерации характеристик персонажа. И вот игрок не выбрал первый или второй набор, с которым тоже интересно играть, но в определенном стиле. Тогда его выбор будет через десятки нажатий на эту кнопку: сила 20, даже больше чем хотелось, но ой что-то интеллект маловат, а там разговоры же, понажимаю еще. Сила 18, это что-то мало, бывало и больше. И так до изнеможения, пока глаз не замылится.
Спасибо за статью.
Расскажите, пожалуйста, как вы управляете общим кодом между сервисами? Что у вас получается выделить отдельно, а что приходится копировать?
Это ElectricTrains. time-usage показывает, что на него приходится половина времени. Не зависит от статуса поезда, мод на каждый тик обновляет статус топлива для всех поездов и делает это прямолинейно:
function OnTick()
if anzLoc > 0 and anzControl > 0 then
for i,loc in pairs(global.LocList) do
if loc and loc.entity and loc.entity.valid then
if not (loc.provider and loc.provider.valid) then
CreateProvider(loc)
else
needPower = loc.entity.burner.currently_burning.fuel_value - loc.entity.burner.remaining_burning_fuel
restPower = loc.provider.energy - needPower
if restPower > 0 then
loc.entity.burner.remaining_burning_fuel = loc.entity.burner.currently_burning.fuel_value
loc.provider.energy = loc.provider.energy - needPower
else
loc.entity.burner.remaining_burning_fuel = loc.entity.burner.remaining_burning_fuel + loc.provider.energy
loc.provider.energy = 0
end
end
else
RemoveLoc(i)
end
end
end
end
Есть ups оптимизированная версия от другого автора, Advanced electric train. Она не обновлялась, но там много изменений и он делает так:
function onTick()
for i, train in pairs(global.TrainList) do
if train and train.entity and train.entity.valid then
train.entity.burner.currently_burning = global.Fuel
train.entity.burner.remaining_burning_fuel = global.Fuel.fuel_value
else
table.remove(global.TrainList, i)
end
end
end
Если остановить поезда, то играбельность повышается от остановки производства. Нет мода, чтобы включить все поезда разом и я включил чуть больше ста, ups просел на 6, так что в оценке, кто второй по потреблению ups, не уверен. Time-usage для ElectricTrains не вырос, поднялось все остальное, а поиск путей для поездов все еще около нуля.
Могу еще заметить, что 1000 поездов для такой базы, это слишком много: без неоптимизированного мода они бы и не тормозили, но их все же тяжело менять или обновлять. С LTN хватило бы и 50, заправка топливом в депо.
У вас также слишком длинные транспортеры, причем без особой нужды. И длинные надземные трубы — жидкость в каждой секции расчитывается отдельно, поэтому AdvancedFluidHandling замечательный мод. Ну и перекрестки, пропускающие по одному поезду за раз (идей с дизайном путей можно набраться на factorioprints).
Вы пробовали «Advanced Fluid Handling»? Он добавляет много всяких хитрых труб, что позволяет уменьшить их количество в 3-4 раза. Если нужен хаб на четыре стороны, то вместо пяти ставится одна. Расчет жидкостей может отнимать и четверть от всего времени.
Из bob's мне понравился мод про inserters, держу только его из пакета и это позволяет использовать меньше транспортеров.
Ну и все в духе минимализма: LTN позволяет использовать десяток поездов вместо 100, Krastorio добавляет производительные smelters, которые отлично сбалансированы и ничего не ломают. Это отдельный фан, когда модуль базы должен содержать только необходимый минимум деталей.
С копипастом легко расширяться, но появляется много лишнего. По сети доступны гигафабрики в самом разном стиле, многие отчаянно тормозят и при этом явно избыточны, но трейновые все же самые производительные.
Было бы интересно посмотреть на проблему с сигналами поездов, потому что это неожиданно, такую базу можно отправить разработчикам, они специально просят для профилировки. Вижу комментарий ниже, у вас точно с остановкой поездов не останавливается производство? В общем, если хотите, давайте вместе посмотрим.
Вы пробовали Logistic Train Network? Это мод про автоматическое расписание для поездов по запросу и с ним поездов становится на порядок меньше. Загружаторы и warehouse тоже сильно снижают количество деталей. Еще, для меня было сюрпризом, что и в ванильной версии можно делать одинаковые имена остановок, добавляя в расписание только одну из них, а пустые выключая по условию, но с LTN все равно элегантнее выходит.
Самые часто упоминаемые моды, но имхо, у bob's серьезные проблемы с балансом. Зато мне очень понравилось Krastorio + Space-exploration. Их реже упоминают, так что рекомендую всем, кто про них еще не слышал.
Например, Адриан Чайковски "Дети Времени". В научной фантастике нестандартные образы мышления часто исследуются с разных сторон. Оно есть, оно требует кропотливой работы и недюжинного ума. Даже просто написать историю о людях, которые мыслят действительно по-разному, не каждый автор может. А люди у нас в мире очень разные, не нужно даже инопланетян придумывать, чтобы удивляться.
Имхо, углубляться во что угодно нестандартное было бы странно при создании развлекательного продукта. Одно дело сделать сюжет про инопланетянина, который спасает дочку и производит понятные условному большинству действия в небудничном антураже. И совсем другое, экспериментировать с устройством общества этих инопланетян. Вы же первый скажете, что "прикольная попытка, но должно быть не так".
У Mass Effect идея о том, что объединились расы, у которых похожие проблемы. А у которых не похожие, не объединились. Что жизнь, это неизбежность и не эти, так другие, но снова пойдут этим путем когда-то однажды. Ну и на культуру рас сильно влияет федерация, тысячи лет членства это ощутимо.
С крайностями понятно, потому что они очевидные. Когда линейная рутина и просто устанавливаем нужное состояние, то резать ее на куски излишне. А когда из алгоритма легко можно выделить библиотечный примитив, то не выделять его, это сбивать фокус у читателя.
Но давайте поговорим о чем-то среднем. Сегодня разбирал класс, у него в основе несколько списков (to_update, to_create) и пара хэш таблиц, в которые по ключам расставляются данные.
Сам класс пытается сравнить две последовательности: то, что пользователь пытался заказать и то, что поставщик в итоге в посылку положил. Если чего-то нет, то отметить, если что-то разделили на товары из разных партий, разделить это и в заказе. И т.п., логики много, есть позиции с дочерними позициями, есть виртуальные позиции.
Так этот класс аккуратно порезан на функции, функции какими-то флагами обмениваются между собой, но все обращаются к общим переменным, постоянно туда что-то добавляя. Оформлено тщательно и хорошо, а читать тяжело, 600 строк туго переплетенного месива на python: хоровод с циклами, списками и словарями. Было бы дерево в основе, было бы куда его растить.
И вот имхо, даже если бы этот код написали плохо, но в том же стиле, сильно хуже он читаться не стал бы. А если бы двое разработчиков сели и потратили день-два, чтобы перетасовать методы класса, не переписывая начисто, он не стал бы понятнее.
Сначала нужно постараться с организацией данных, потом с общей концепцией. И только потом аргументы за "резать" или "не резать" начинают что-то значить.
Лес разный. В ленточном сосновом бору некоторых регионов Сибири, например, деревья стоят относительно плотно и тянутся вверх, а почва это непрочный суглинок. Когда ветер сильный, то одно из деревьев рано или поздно не выдерживает нагрузки, получается пробел и нагрузка на другое дерево возрастает, оно тоже падает.
В итоге, можно найти участок, где полосой повален ценный пиловочный материал, приезжай и бери. А контроль за лесом жесткий, его воруют и в черную, и в белую, поэтому споров о том, что кому когда можно, немало.
А еще там сухо и даже упавший сухостой еще местами пригоден на распиловку, а уж точно на дрова.
В болотистых таежных местах Томской области, например, такого нет. Другие почвы и сыро. Если что-то упало, то значит оно сгнило еще стоя, а если и нет, то сгниет в считанные недели.
Насколько я понял, это такой enterprise интерфейс для self-hosted моделей. Акцент на контроле: кто куда заходил, с чем ему можно там работать и что он при этом у модели спрашивал. Потому, что даже внутри одной компании есть вещи, с которыми работают люди и которые не нужно знать работникам. Даже бизнес-подписка от openai, где обещают не использовать ввод пользователей для обучения моделей, все равно не подходит корпорациям, потому что секреты публикуются в чужом контуре.
Судя по описанию, умеет оно примерно то же, что и projects в gpt: диалоги с доступом к контексту в файлах и кастомным prompt. На картинках все больше о ролях, аудите и о том, что развивайте как хотите, мол это платформа, а не готовый ИИ ассистент.
Такое мнение можно найти про все, что требует усилий. Так уж устроен человек.
И вместе с тем, есть люди увлеченные, готовые чем-то заниматься уже только потому, что это интригует.
Позвольте под вашим комментарием разместить манифест о том, что учиться очень хорошо и полезно, это развивает мозг и формирует личность.
Возможно ли сконфигурировать прикладное решение, не прочитав ни одной книги и заработать на этом? Да, конечно. С ростом опыта еще и время эффективно потратив.
Так то эти задачки придумали для собеседований, чтобы как-то формализовать отбор, чтобы рекрутеры могли высокомерно рассуждать о квалификации кандидата, не утруждаясь значению слов. И вот конкретно в Яндекс задачи третьей секции выбирают откровенно глупые, наверное потому, что сложные не каждый интервьюер сможет. И эти интервьюеры еще наплевательски относятся к собеседованию: опоздал, ну да и ладно, зато неспеша начнем, как раз поболтать захотелось и есть идея про задачу (неправильная). Кроме молодых ребят, которые на первых двух этапах, те волнуются и серьезны, причем у них и задачи интереснее бывают, чем на "алгоритмической" секции.
Так вот, задачи глупые, а собеседования пафосный бардак.
Но алгоритмы это круто и алгоритмы это не пара трюков из однострочных задачек. Можно не учить и не знать, но не нужно таких специалистов смешивать в одном ряду, они из разных сфер. Кто-то уже все сделал, что можно использовать готовое? Так оно не само готовым сделалось.
К слову, для сотрудников того же Яндекс одно время читал лекции Максим Бабенко.
С GPT есть другая серьезная проблема в нашей работе, о ней пока мало говорят. Это коллеги, которые раньше ничего не делали и потому не мешали.
Например, входящий запрос от руководителя: "Я ввел описание твоей задачи в gpt и мне кажется, что она написала что-то дельное, но я не читал. Прочитай, напиши мне аргументированный ответ и объясни свою позицию, обязательно понятную мне, чтобы я мог цепляться к словам не утруждаясь".
Или соседняя команда, которые сгенерировали JSON и опубликовали его в качестве контракта не читая. И передали его тебе на ревью, чтобы ты сделал эту работу целиком. Отчитаться, что на их стороне все готово, они не забыли, теперь ждут одного только тебя.
У гоферов проблема с `go run`, там компилятор такой быстрый, что можно запускать из исходников. В rust есть `cargo run`, хотя оно и медленнее.
Например, это автоматическое тестирование: собрали в нужной конфигурации, запустили и так много раз. Можно еще представить что-то сервисное, когда код генерируется из шаблонов под задачу и сразу же выполняется.
Спасибо за ссылку, интересно было почитать, как люди живут. Там в POSIX пытались сделать так, чтобы дочерный процесс получал закрытые дескрипторы после fork. И не сошлись во мнении, что будет с сокетами.
>> The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.
То есть мешал не столько запрет на запись в выполняемый файл, сколько запрет запускать не закрытый после записи файл. Насколько я понял, проблема была с fork'нутыми процессами, которые успевали форкнуться до того, как файл был закрыт. И страдали из-за этого, в первую очередь, go разработчики с их goрутинами, которые форкаются сами по себе.
https://github.com/golang/go/issues/22315
Выручает плагин "I don't care about cookies". А на смартфоне хромовские плагины можно ставить в браузер kiwi, в том числе и фильтры рекламы.
Но за что оно так с пользователями, я тоже не понимаю.
Раз статья для того, чтобы вставить свою фамилию в первом абзаце, то писать ее нужно все же самому. Ведь есть же интересные истории про проекты, где не выполнялось то или иное, или все сразу.
Редактор молодец, а вот материала ей большой директор выделил мало.
Мне тоже это кажется наглостью. Требования жесткие, а бюджет скромный.
И даже если никто не предложит это "вау" из коробки, то можно забесплатно собрать обзор по использованным подходам. Одна только сопроводительная документация позволит упростить разработку собственного решения.
Бывает и веселее, одна компания рассылала приглашения на свой хакатон. И в приглашении конкретное ТЗ, по которому им нужен прототип, приходите мол с уже готовым, показывайте. Призовой фонд 150тыс (нашими, бесполезными). И я тогда подумал, что за такие деньги тоже хочу прототип нового продукта, а еще с возможностью нанять разработчиков.
На форуме wasm.ru он писал развернутые сообщения о своей жизни в США после переезда. Работал в McAfee и делали они анализ зловредов в сети на лету. Рассказывал про анализ pdf (там есть js внутри), доказывал что у него там всякие крутые ребята вокруг и что он не выделяется.
Вот тут подняли архив, можно почитать его сообщения:
https://wasm.in/search/40827668/
https://wasm.in/search/40827736/ (с фильтром по нетехническому разделу)
https://wasm.in/members/kaspersky.305/
А меня удивляет, что если человек не против работать в условном озоне, то его собеседуют по принципу брать/не_брать. При этом компания отчаянно нуждается в людях, задачи разноплановые, у команд разные стили и требования.
Как по мне, обязательно нужно проверить на адекватность и умение связно мыслить, дисциплину и умение работать. А техническое интервью нужно для оценки и проф. ориентирования, но не как барьер.
Завалил задачку на кодинг в граничных случаях, но правильно рассуждал про нее и архитектуру? Ну покрутись вот в этой команде на мидловской роли во время испытательного срока, джунов поменторишь и сам подучишься. Будет 0.75 от ожидаемой зп, через три месяца пересмотр. Или вот в этой команде, они там документацию никак не успевают наладить, а у тебя по всем тех. навыкам провал, кроме аналитических. Вектор развития обсудим через два месяца.
В rpg часто есть кнопка для случайной генерации характеристик персонажа. И вот игрок не выбрал первый или второй набор, с которым тоже интересно играть, но в определенном стиле. Тогда его выбор будет через десятки нажатий на эту кнопку: сила 20, даже больше чем хотелось, но ой что-то интеллект маловат, а там разговоры же, понажимаю еще. Сила 18, это что-то мало, бывало и больше. И так до изнеможения, пока глаз не замылится.
Как по мне, полезно уже тем, что фронты могут какие-то вещи делать сами. Особенно в проектах, где SPA с кучей логики, а на бэке просто REST.
Меньше суеты, меньше звеньев, быстрее и дешевле разработка. Бывает, что один час в забытом бэком проекте, это два дня ожидания и день правок.
Расскажите, пожалуйста, как вы управляете общим кодом между сервисами? Что у вас получается выделить отдельно, а что приходится копировать?
Есть ups оптимизированная версия от другого автора, Advanced electric train. Она не обновлялась, но там много изменений и он делает так:
Если остановить поезда, то играбельность повышается от остановки производства. Нет мода, чтобы включить все поезда разом и я включил чуть больше ста, ups просел на 6, так что в оценке, кто второй по потреблению ups, не уверен. Time-usage для ElectricTrains не вырос, поднялось все остальное, а поиск путей для поездов все еще около нуля.
Могу еще заметить, что 1000 поездов для такой базы, это слишком много: без неоптимизированного мода они бы и не тормозили, но их все же тяжело менять или обновлять. С LTN хватило бы и 50, заправка топливом в депо.
У вас также слишком длинные транспортеры, причем без особой нужды. И длинные надземные трубы — жидкость в каждой секции расчитывается отдельно, поэтому AdvancedFluidHandling замечательный мод. Ну и перекрестки, пропускающие по одному поезду за раз (идей с дизайном путей можно набраться на factorioprints).
Из bob's мне понравился мод про inserters, держу только его из пакета и это позволяет использовать меньше транспортеров.
Ну и все в духе минимализма: LTN позволяет использовать десяток поездов вместо 100, Krastorio добавляет производительные smelters, которые отлично сбалансированы и ничего не ломают. Это отдельный фан, когда модуль базы должен содержать только необходимый минимум деталей.
С копипастом легко расширяться, но появляется много лишнего. По сети доступны гигафабрики в самом разном стиле, многие отчаянно тормозят и при этом явно избыточны, но трейновые все же самые производительные.
Было бы интересно посмотреть на проблему с сигналами поездов, потому что это неожиданно, такую базу можно отправить разработчикам, они специально просят для профилировки. Вижу комментарий ниже, у вас точно с остановкой поездов не останавливается производство? В общем, если хотите, давайте вместе посмотрим.