Например, автоматическое / эвристическое планирование и нейросети. Они где-то на уровне 80х зависли.

SCADA-системы, например.

посмотрите в сторону SAP ABAP.

Все технологии постоянно меняются, таков виртуальный мир.

>>16592
ПЛК туда же.

микрокнтроллеры какие-то. там всю жизнь одно и тоже на си байтики кидать со стороны в сторону
только не интересно все это, надоедает

>>17324
Решил пойти в embedded. Через сколько мне это надоест?

>>17350
Или надоест сразу, или не надоест вообще.

https://github.com/sipsorcery/sipsorcery

Не подойдет?

Ладно. Подумаю над сюжетом и задумкой. Сформтрую их, и создам новый пост

Бамп. Реквест все еще актуален.

>>21723
Но ты так и не сформировал новый пост с сюжетом задумкой...

>>21723
Прототип игры на квадратиках можно сделать за неделю. Прототип чуть получше можно сделать за две недели. Прототип без опыта можно сделать не больше, чем за два месяца. Треду два года. Где?

Вверх.

Шел 2019 год. Создатель с сюжетом и задумкой так и не определился.

Время у нас есть. Подождем до 2025.

>>21796
>Время у нас есть
... у нас мозгов не хватает.

Я раб

>>21723
бамп вопросу. тоже интересно.

Расскажи о том, что пишешь на расте и для каких платформ. Очень интересен опыт из первых рук.

>>16152
с какого языка переходил?

Вопрос один: нафига так много разных типов контейнеров? Пока учил, окончательно запутался и дропнул. Всего-то нужна безопасная замена указателей и ссылок, а тут вон чего нагородили.
Вопрос два: что на нем на данный момент можно написать на практике? Язык это одно, а среда другое. Есть свой нормальный гуи или биндинг в QT? Целесообразно ли писать серверное приложение, может ли он в PostgreSQL/MongoDB, вебсокеты, шаблоны, криптографию. Может ли соперничать на этом уровне с NodeJS или Django/Flask? Микроконтроллеры еще не завезли? Киллер-фича вроде как. Как смотрят производители, им же все тулчейны под раст перепиливать. Как скриптовый язык можно использовать? Может ли он в хоть простенькй гемдев? Есть готовые 2д/3д фреймворки? Как с деплоем под разные платформы?
Вопрос три: что там с IDE? Idea уже поддержтвает? Или пиши в блокноте @ компилируй в консоли.

>>16165
Основное это сетевая программа под линукс для обработки UDP пакетов для серверного Линукса. (по сути обёртка над epoll с помощью mio с кастомной логикой и парсером на nom) Плюс пишу no_std библиотеки, немного баловался с embedded на STM32, всё шло достаточно хорошо, но не попалось подходящего проекта, так что тут далеко не продвинулся.

>>16167
Основной рабочий язык был Питон, но имел опыт на разных языках: Паскаль, Дельфи, Го, немного С. Немного баловался Фортом, Лиспом и Эрлангом.

>>16173
>Вопрос один: нафига так много разных типов контейнеров? Пока учил, окончательно запутался и дропнул.
Подозреваю что ты про вещи типа Rc<RefCell<T>>. Конкретно и подробно по всем контейнерам ответить не смогу, но лично моё мнение что всё это нужно и играет свою роль позволяя производить композицию из того что тебе нужно в текущем контексте, а не пытаться натягивать комбайн. Проблема в том, что пока тебе конкретно данный контейнер не понадобиться будет ощущение что он не нужен. Но когда такая ситуация возникнет ты поймёшь почему сделано именно так. Так что если чего-то непонятно сейчас, то можешь смело пропускать, необязательно штудировать книгу от корки до корки.

Сообщение слишком длинное. Полный текст.

Ах да, если интересует сеть, то обязательно стоит посмотреть на tokio:
https://tokio.rs/
Это решение Раста на тему асинхронщины, которое работает без корутин и с zero-cost abstraction™. На выходе всё компилируется в машину состояний работающую на event-loop.

Единственная проблема, это опять же неизбежный высокий порог входа. Большинству пользователей имеет смысл использовать библиотеки на основе tokio, а не опускаться на этот уровень самостоятельно.

легко ли перейти с питона на раст?

>>16192
Сильно зависит от человека приходящего из Питона. Ну и плюс о полном переходе наверно думать не стоит, Раст и Питон отлично друг друга дополняют, чему отлично помогает возможность вызова кода в обоих направлениях.

Всякие функциональные фишки, итераторы, нормальная система модулей, человечный инструментарий (rustup, cargo) в плюс. Необходимость думать о том где, что и как у тебя лежит в памяти, отсутствие привычной гибкости и развязности, отсутствие REPL, продолжительность компиляции (работа по улучшению ведётся), для большинства скорее в минус.

С другой стороны строгая типизация, обработка ошибок через enum'ы, паттерн матчинг, borrow checker, компилятор дающий по рукам в случае чего (иногда конечно бывают перегибы, но в большинстве случаев дураком оказывается программист), что позволяет отлавливать ошибки при компиляции, а не в рантайме, и прочие фишки, лично для меня, оказались глотком свежего воздуха, но что бы прочувствовать всю прелесть этих вещей полезно походить по граблям Питона и набить на них шишки.

Кстати насчёт контейнеров, думаю, эта ссылка будет полезна:
https://www.reddit.com/r/rust/66t56s/

>>16197
>человечный инструментарий (rustup, cargo)
Энджой ёр монополия.

Что мертвее D или Rust?

>>17146 Go

>>16127
Да, рассматривать организованный отряд как единое целое, а неорганизованным толпам позволить "спотыкаться" друг о друга — тоже вариант.

> Расскажи что-нибудь про свою игру, чтобы не обсуждать сферических гусей в вакууме.

Был концепт игры, который в частности требовал быстрый turn-based multiplayer, и хотелось, чтобы игроки принимали решения, не дожидаясь друг друга, с синхронной реализацией и автоматическим разрешением конфликтов.

Но сейчас я этот вариант не рассматриваю, просто обдумываю single-player рогалик для души, а вопрос вырос из того, предыдущего концепта.

В общем, вопрос и задумывался как сферический теоретический.

>>16131
>Был концепт игры, который в частности требовал быстрый turn-based multiplayer, и хотелось, чтобы игроки принимали решения, не дожидаясь друг друга, с синхронной реализацией и автоматическим разрешением конфликтов.

Не знаю, порадует тебя это или нет, но кажется такую игру всё же сделали, называется Frozen Synapse: http://store.steampowered.com/app/98200

А как организовать рогалик с партией?

>>16130

Не знаю, правильно ли ты меня понимаешь, но UFO:After* и вправду довольно интересны комбинацией "клетчатого" игрового поля и непрерывного времени. Штука же, что ты описываешь, называется "активной паузой", но меня больше интересует не то, как игрок видит события и управляет ими, а то, как они симулируются и взаимодействуют друг с другом.

>>16133

> ○　быстрый turn-based multiplayer
> ●　кажется такую игру всё же сделали
> ●　Multiplayer is really versatile too, since you can just leave your turn and play another match (or even another game altogether) while you wait your opponent's; you can even set the game to send you an email when a new turn is awaiting you.
Не совсем то всё-таки, да и концепт был по сути не про "быстрый turn-based multiplayer", просто оно там вытекало с необходимостью из других требований.

Сообщение слишком длинное. Полный текст.

>>16136
Если это не секретные сведения, расскажи про игру, что планируешь.

>>16145
Могу только повторить >>16131:
> Но сейчас я этот вариант не рассматриваю, просто обдумываю single-player рогалик для души, а вопрос вырос из того, предыдущего концепта.

Тут рассказывать бесполезно — нужно делать прототип и показывать или не делать.

Может, можно на время хода проиграть движение "в реальном времени"? И для этих целей может подойти дифференциация логических координат и физических. Прям как в современных ААА-играх графика и физика. Вкратце как сделано там: для графики используется многополигональная карта, с бампингом и тесселяцией, а физика обрабатывается на ооочень упрощенной модели уровня.
Так и тебе, возможно, стоит для игровой логики использовать дискретное пространство, а для модуля, рассчитывающего движение - полноценную систему координат с флоатами или даблами и реальным временем.
Как я это реализовал бы: в течение хода каждый юнит движется к "полноценным" координатам центра соседнего целла дискретного пространства, находящегося по вектору цели хода. Радиус коллизии (при котором юнит не может двигаться, поскольку пространство занято другим юнитом) очевидно должен быть меньше физических координат целла (я б для начала поигрался бы с 0,6 - 0,8 размеров целла). Получаем, что юниты будут ходить от клетки к клетке по направлению хода все вместе.
Очевидно, что будут возникать ситуации, когда на одном целле два юнита. В случае "гуська" это норм и они нормально разрулятся - первый пройдет в следующий целл, второй пройдет в целл первого и они не столкнутся. Во второй половине случаев произойдет коллизия. Это, вероятно, будут те случаи, когда у юнитов различные векторы движения. Хоть я и не могу представить, как такое может получиться в описанной в ОП-посте задаче, но это нужно разрешить. Я б послал инициатора столкновения в обход, хотя можно и остановить юнит/послать на предыдущий целл (например "не дошел", так как вражеский персонаж раньше пришел). Соответственно хозяином целла считать того, кто ближе к его центру. Как только не осталось движущихся персонажей - ход завершен.

Сообщение слишком длинное. Полный текст.

>>16174

Неплохо, и без нагромождения правил позволит симулировать сложные взаимодействия. Но что будет, если в комнате на n клеток сидит n мобов и туда убегая от игрока пытается набиться (n+1)-ый? Благодаря маленькому радиусу коллизии, "сидящие" смогут подвинуться, и временно места хватит всем, но дальше начнётся игра в музыкальные стулья, и как долго ждать, пока кого-нибудь выкинет? Наверное, систему можно стабилизировать, если посадить юниты на "короткие поводки" в исходных точках, и в любой непонятной ситуации начинать эти поводки натягивать. Главное, чтобы всякие ворота и другие перегородки не закрывались посреди раунда.

>>16202
>Благодаря маленькому радиусу коллизии, "сидящие" смогут подвинуться
Сидящие сами по себе никуда не двигаются же. Двигаются лишь те, у кого задана цель перемещения. А такие вещи, как
>на n клеток
>пытается набиться (n+1)-ый
элементарно решается в тот момент, когда наткнувшись на сидящего, граф движения по клеткам к цели перерассчитывается и репортит о том, что текущая позиция к целевой ближе при нынешнем расположении уже не станет. Тогда и остановиться можно или сменить цель. А если ходы в игре совсем-совсем дискретны донельзя, то, возможно, лучше даже отказать в таком ходе / предложить ближайшую свободную клетку еще на этапе задания цели.

То есть алгоритм вкратце такой:

Пока (у юнита есть цель) {
 ПостроитьГрафОтТекущейКлеткиДоЦелиПоЦентрамКлеток();
 если (нетпути || граф.длина < 2) {
  Остановиться();

Сообщение слишком длинное. Полный текст.

>>16203
Это всё дискретный pathfinding. В >>16174, как я понимаю, предлагается "физическая" симуляция движения на более низком уровне: все уже решили, куда направляются (используя индивидуальный pathfinding и т.п.), приобрели векторы скорости, и дальше мы смотрим просто, кто куда протолкнётся (причём натурально можно реализовать механику толкания с учётом скоростей и масс юнитов). Но в некоторых ситуациях вот это конечное условие может оказаться трудновыполнимым:
> Соответственно хозяином целла считать того, кто ближе к его центру. Как только не осталось движущихся персонажей - ход завершен.
Если пример с комнатой слишком утрирован, представь станцию метро с несколькими входами и выходами, через которые соответственно входят и выходят юниты, но входящих больше. Те же, кто внутри, надеются продвинуться к выходам, поэтому вектор скорости у них ненулевой.

>>16219
>В >>16174, как я понимаю, предлагается "физическая" симуляция движения
Нет, я предлагал именно то, что что описал в >>16203. И это таки физическая симуляция движения по графу, вершины которого - клетки дискретного пространства, но само движение и коллизии считаются в обычных координатах.
>Но в некоторых ситуациях вот это конечное условие может оказаться трудновыполнимым
Элементарно выполнимо. Даже в вычислении того, кто ближе к центру нет необходимости - достаточно овнить клетку при успешном
>ПереместитьсяНа1ВершинуГрафа();
т. е. когда не произошло коллизии. Таким образом, заходить в переполненное метро никто не будет.

Это идей-для-стартапов-тред?

Не выгорит. Даже на ИБ нет таких досок в тематике, ибо аудитория скудна, и сидит в соцсетях.

>>16077
> сидит в соцсетях
За себя говори.

Но ведь по сути Россия будет первой страной где явление киберпанка будет самым ярким, по моим субъективным прогнозам конечно. Не вижу плохого в объединении параноиков и сетевого гетто в единый "Glitch City"

>>16077
Насчет сетей... хз что еще придет в голову правительству. Возможно еще будет наплыв и на двач, а следовательно оттуда и черпать аудит

>>16085
> будет наплыв и на двач
Если только возвращающую в 2009 год машину времени изобретут.

>>26900
А я и не питонист.
Я около бэкендер на жабаскрипте.

>>26900
Кризис - это перманентное состояние, просто он сейчас более глубокий.
А работу как-то искать надо.
Я за год неторопливых поисков так и не нашёл.
Начинаю думать, что мой стэк (RoR) в моей локации умер.

>>26899
Зазубривай алгоритмы, собеседуйся стажером в крупную компанию, готовую в тебе вкладываться.

>>26956
> собеседуйся стажером в крупную компанию, готовую в тебе вкладываться.
Сейчас в СНГ это малореально в общем случае. Не нужны сейчас стажеры.

Интересно, не проще ли с нуля вкатиться в дельфи в РБ и РФ сейчас. Целесообразность спорная конечно, но тем не менее любопытно.

>>16018
Php, node.js (ванильный жс нахуй не нужон), как вариант можно выше озвученный питон, но на нём работу найти сложнее. Не слушай задротов которые советуют плюсы, шарпы или уж тем более Си. Только зря время потратишь.

>>26993
Питон еще куда ни шло (пока однажды не придется разбираться, почему сборщик мусора не собирает мусор), но node.js - это достаточно неочевидная штука. Колбэки, замыкания, динамическая типизация, [object Object]... Может это и востребовано, но очень уж грустно и невесело.

>>26995
Тем не менее денежек там больше чем где либо ещё. А вопрос состоит именно а вкатывании.

А у меня такая проблема. Я в этом году заканчиваю магистратуру по прикладной информатике, но из-за родительского кредита был вынужден ещё с третьего курса работать на относительно оплачиваемой физической работе. Собственно, я простой повар вот уже четвёртый год. Навыки кодинга находятся в зачаточном состоянии, но я уже просто не вывожу стоять на ногах по 12 часов. Проблема ещё и в том, что после работы совершенно невозможно сесть и копать в это вот всё хотя бы часа по три. Ловушка какая-то, а что делать—на знаю. Город—миллионник на юге. Помогите советом мудрым.

>>27031
Не знаю, что можно предложить, кроме сидения на шее у родителей \ партнёра и улучшения навыков после выплаты того кредита.

Репозиторий вроде все еще жив
https://github.com/WagonOfDoubt/iichan-extensions
И в контрибуторах есть Мицгол, который еще с нами, так что шансы на починку есть.

>>25694

Эппловскихъ устройств не имѣю, ѿлаживать негдѣ.

>>25693
Учитывая обстоятельства >>25705 получается, надо создавать issue на гитхабе, чтобы хоть как-то обратить на проблему внимание.

Кстати, ни у кого не осталось кода для поддержки ЎэбП, который когда-то постили в /d/? Или какой-нибудь новый кот для этого.

>>25770

http://ii.yakuji.moe/d/res/250303.html#251062

Упомянутая в сообщении >>20993 проблема https://trac.ffmpeg.org/ticket/7613 исправлена разработчиками FFmpeg, и предположительный срок её исправления оказался даже больше того, насчёт которого я мрачно подозревал в сообщении >>21078: не только до середины 2021 года, но даже и до февраля 2022 года поневоле пришлось дожидаться.

Дополнительные подробности я изложил в сообщениях https://t.me/ReadMithgol/476 и https://t.me/ReadMithgol/478 в Телеграме, растровые копии которых я прилагаю и тут, но только по одной (а не то итог склеивания их по вертикали, весьма вѣроятно, натолкнулся бы на препятствие >>/d/2649 при малѣйшей попытке помѣстить его на 410чан).

Второе приложение к сообщению >>26119.

На «Ычане» севодни была сделана прилипающая навигация (по аналогии с местной). Некоторым она не нравится, так что можно было бы сделать её настраиваемой (как на «4чане»).
Предлагаю сделать как на картинке. Кнопку закрепа следует взять из местного движка. Поведение у кнопки такое же, как тут в быстром ответе.
Делать, очевидно, через ӁС и надо, чтобы оно запоминало положение. По умолчанию навигация должна быть прилипающая. Скрипту достаточно просто изменять "position: sticky;" в ЦСС, я так понимаю.

Это официальный запрос.

>>27428
Почему кукла то не работает на ыче? Раньше работала и было удобно, теперь же даже менюшки в правом нижнем углу нет. Я не погромист этот ваш, не знаю как чинить. Без куклы оно и не надо же, а с куклой -- пусть будет. Верните куклу, пожалуйста.

>>27430
>Почему кукла то не работает на ыче?
Не знаю, спрашивайте у её разработчика. Это не тред поддержки куклоскрипта. «Ычан» тут ни при чём.