Если состояние задается, как для этого случая, например, тремя битами для выключателей плюс скажем 16-ть битов (short) значение задержки, итого получается два в 19-й степени возможных состояний. Это все еще конечное число состояний? То есть имеет ли смысл рассматривать такое большое число состояний как конечное?
Вы либо никогда в реальной жизни не использовали FSM, либо просто прикалываетесь.
Почти во всех реализациях FSM можно передавать payload вместе с переходом, если уж так сильно надо, и это никак не связано с количеством возможных состояний.
Если задержка не влияет на поведение переходов, то и передавать не обязательно, и она будет учитываться где-то в другом месте, там где реализована ф-я мигания. Вы же сами решаете, что именно моделирует ваш автомат
Поведение contenteditable - это шляпа, подтверждаю. Я так и не смог победить, правда у меня чуть сложнее задача была - примитивный редактор кода с подсветкой. Пришлось в итоге пойти путем, которым идут почти все такие редакторы - адовый костыль с невидимой textarea и наложенным на него дивом с форматированным текстом
Забавно что раньше люди писали тексты для машин, а теперь машины пишут тексты для людей. Борьба мочи с гоvном, seo-копирайтеров c ии-генерацией, ведь одни учились у других
Если бы еще блокировали нормально. Не знаю как у других, а с моим провайдером (мелкий местный, под ростелекомом) уже полгода половина интернета тупо не работает. Документация в 99 процентов случаев не открывается, форумы разработчиков не работают, даже на алиэкспресс картинки не грузятся. Не работает даже npm, пришлось переключиться на китайское зеркало. И все это ресусры, которые не были заблокированы официально, они просто попали под раздачу. Фактически без впн работать уже невозможно.
Хороший проект, не забрасывайте, на lit не так много ui либ, я знаю shoelace и spectrum web components от adobe. Концепция у вас крутая, особенно для тех, кто делает не совсем стандартные для веба интерфейсы. Добавил в закладки и достану когда придет время ковырять интерфейсы в своем пет проекте. Сейчас там хаос из разрозненных lit компонентов. Из пожеланий: компонент tree (в идеале с dnd перетаскиванием, пробежался по вашим статьям и видел что вы уже это реализовывали на vue). Кстати вроде на ts пишете, тут решили отказаться в пользу упрощения?
Смотрел доклад этого чувака на ютубе, забавно было увидеть теперь в виде статьи. Но тут в тексте кажется часть контекста упущена.
Чел врач и занимается играми как хобби, подвеска - эта та кроличья нора, до которой он еще не дошел. Сход/развал, стабы и т.д. у него только в планах.
Примитивная подвеска в игре реализована - автор этого проговаривает и это видно в роликах. Скорее всего просто пружина+демпфер, без какой-то сложной геометрии и кинематики. (для многих игр этого может быть достаточно)
Шины - действительно самое сложное в симуляторах, упругие деформации по всем осям, изменение пятна контакта, то, что происходит между шиной и асфальтом и т.д. У любой подвески ограниченное число элементов, их кинематику смоделировать легче, также как и углы схода/развала и т.д. Но в конечном итоге все это нужно передать на колесо, на шину. Короче говоря, нет смысла супер точно моделировать подвеску, если у тебя нет адекватной этому модели поведения шины.
Ну и чел пилит тупо в кайф, на вопрос "вы делаете симулятор?" он ответил, что не осилит симулятор, но хочет сделать максимально реалистично, насколько это получится. Когда делают игры, все-таки перидерживаются другого подхода - понять что за опыт нужен от управления и реализовать его максимально простым способом. Не случайно один из вопросов ему был "а как вы управляете таким огромным кол-вом параметров?" Потому что это реально сложно, чем больше у тебя переменных, которые еще и изменяются в динамике, тем сложнее добиться желаемого поведения. Поэтому моделировать нужно только то, без чего уж совсем не обойтись, и желательно чтобы сама модель была максимально простая.
Вы либо никогда в реальной жизни не использовали FSM, либо просто прикалываетесь.
Почти во всех реализациях FSM можно передавать payload вместе с переходом, если уж так сильно надо, и это никак не связано с количеством возможных состояний.
Если задержка не влияет на поведение переходов, то и передавать не обязательно, и она будет учитываться где-то в другом месте, там где реализована ф-я мигания. Вы же сами решаете, что именно моделирует ваш автомат
"Что с чем носить летом: 6 лучших комбо"
"Где дешево поесть в Москве: 13 столовых и кафе с чеком до 700 ₽"
Пожалуй скажу. Но там хотя бы коменты есть забавные и полезные, так что какая-то ценность все же есть, за счет большой аудитории
То, что высосано из пальца
Главная проблема сеошников в том, что ценность их текстов равна нулю, кто бы их не писал, а нейросетки уже умеют делать это дешевле и быстрее.
Главная проблема остальных людей - что SEO-тексты существуют
Как же все плохо в корпоративной разработке
Очевидно что происходит - начинает писать бессмысленные псевдофилософские статьи на хабр.
предлагаю “нейрошиза”
Поведение contenteditable - это шляпа, подтверждаю. Я так и не смог победить, правда у меня чуть сложнее задача была - примитивный редактор кода с подсветкой. Пришлось в итоге пойти путем, которым идут почти все такие редакторы - адовый костыль с невидимой textarea и наложенным на него дивом с форматированным текстом
Забавно что раньше люди писали тексты для машин, а теперь машины пишут тексты для людей. Борьба мочи с гоvном, seo-копирайтеров c ии-генерацией, ведь одни учились у других
Если бы еще блокировали нормально. Не знаю как у других, а с моим провайдером (мелкий местный, под ростелекомом) уже полгода половина интернета тупо не работает. Документация в 99 процентов случаев не открывается, форумы разработчиков не работают, даже на алиэкспресс картинки не грузятся. Не работает даже npm, пришлось переключиться на китайское зеркало. И все это ресусры, которые не были заблокированы официально, они просто попали под раздачу. Фактически без впн работать уже невозможно.
Хороший проект, не забрасывайте, на lit не так много ui либ, я знаю shoelace и spectrum web components от adobe. Концепция у вас крутая, особенно для тех, кто делает не совсем стандартные для веба интерфейсы. Добавил в закладки и достану когда придет время ковырять интерфейсы в своем пет проекте. Сейчас там хаос из разрозненных lit компонентов. Из пожеланий: компонент tree (в идеале с dnd перетаскиванием, пробежался по вашим статьям и видел что вы уже это реализовывали на vue). Кстати вроде на ts пишете, тут решили отказаться в пользу упрощения?
Смотрел доклад этого чувака на ютубе, забавно было увидеть теперь в виде статьи. Но тут в тексте кажется часть контекста упущена.
Чел врач и занимается играми как хобби, подвеска - эта та кроличья нора, до которой он еще не дошел. Сход/развал, стабы и т.д. у него только в планах.
Примитивная подвеска в игре реализована - автор этого проговаривает и это видно в роликах. Скорее всего просто пружина+демпфер, без какой-то сложной геометрии и кинематики. (для многих игр этого может быть достаточно)
Шины - действительно самое сложное в симуляторах, упругие деформации по всем осям, изменение пятна контакта, то, что происходит между шиной и асфальтом и т.д. У любой подвески ограниченное число элементов, их кинематику смоделировать легче, также как и углы схода/развала и т.д. Но в конечном итоге все это нужно передать на колесо, на шину. Короче говоря, нет смысла супер точно моделировать подвеску, если у тебя нет адекватной этому модели поведения шины.
Ну и чел пилит тупо в кайф, на вопрос "вы делаете симулятор?" он ответил, что не осилит симулятор, но хочет сделать максимально реалистично, насколько это получится.
Когда делают игры, все-таки перидерживаются другого подхода - понять что за опыт нужен от управления и реализовать его максимально простым способом. Не случайно один из вопросов ему был "а как вы управляете таким огромным кол-вом параметров?" Потому что это реально сложно, чем больше у тебя переменных, которые еще и изменяются в динамике, тем сложнее добиться желаемого поведения. Поэтому моделировать нужно только то, без чего уж совсем не обойтись, и желательно чтобы сама модель была максимально простая.