Я разрабатываю эмулятор сервера для Lineage 2 Chronicle 1: Harbingers of war на Node.js.
Столкнулся с проблемой синхронизации скорости персонажа на сервере с клиентом. Когда в игре вы нажимаете мышкой в то место, куда хотите перейти то происходит плавный переход с анимацией движения. На сервере в этот момент тоже происходит движение по таймеру, но не такое плавное.
GIF
GIF
C(client) – двигается плавно из одной точки в другую. S(server) – делает прирост координат по таймеру.
Для примера я взял сборку написанную на java l2j-lisvus Сборок много. Но все они являются fork’ами проекта l2jserver https://l2jserver.com/ и многое наследуется. В том числе и передвижение персонажа.
В l2j-lisvus, как и во всех сборках l2jserver перемещение персонажа на сервере идет при помощи таймера с приростом одинаковых значений.
Проблема проявляется, когда нам надо сделать какое-то действие после того, как персонаж добежал до пункта назначения. Например, нанести удар по NPC.
GIF
На коротких расстояниях проблема незаметна. Нога наступает точно в монету.
GIF
На длинных расстояниях действие атака начинается раньше, чем персонаж добегает до цели.
GIF
А если выкрутить скорость на максимум (900) то проблема расхождения очевидна. Это связанно с тем, что помимо скорости бега есть скорость ходьбы.
Как работает передвижение персонажа на сервере.
За основу взяты базовые характеристики персонажа. Скорость бега 126.
126 — это количество внутренних unit’ов за секунду.
На данной схеме идет прирост координат персонажа каждые 1000мс на 126 unit’ов. Исходя из схемы выше пример кода для действий персонажем после достижения пункта назначения:
// Прироста координат нет. Просто считаем когда персонаж дойдет до конечных координат.
const distance = 1500;
const playerSpeed = 126;
const ticks = distance / playerSpeed; // 11.90
const time = ticks * 1000; // 11900mc
setTimeout(() => {
// действие персонажа после бега
}, time);
GIF
На коротких расстояниях.
GIF
На длинных расстояниях.
Расхождения на коротких расстояниях.
Расхождения на длинных расстояниях.
Зеленой зоной показана точка куда должна ступить нога персонажа если бы не было расхождений.
Рост скорости при развитии персонажа.
126 — это базовая скорость. И по мере развития персонажа будет расти и скорость передвижения. А значит расхождение будет больше. Но перед тем, как создать формулу надо подтвердить теорию, что скорость ходьбы влияет на расхождение.
Данные о характеристиках персонажа передаются от сервера к клиенту.
Выставляю значения walkSpeed: 126. Если скорость ходьбы будет равна скорости бега, то расхождения должны пропасть.
GIF
Нога персонажа достигает правильной конечной точки.
Персонаж синхронизирован и начинает атаку вовремя. Теперь надо понять, как скорость ходьбы влияет на расхождения между клиентом и сервером.
Сколько же персонаж успевает пройти перед тем, как начинает бежать?
Надо поймать момент когда ходьба переходит в бег. Для этого передадим в клиент данные, где скорость ходьбы будет больше скорости бега. Из-за этой разницы будет виден переход и можно будет рассчитать пройденное расстояние при ходьбе.
runSpeed: 10
walkSpeed: 600
GIF
Ходьба быстрее бега.
При скорости шага в 600 персонаж успевает пройти 250, прежде чем начинает бежать.
600 / 250 = 2.4
700 / 291 = 2.4
800 / 333 = 2.4
Из этого вывод, что персонаж перед тем, как начать бежать успевает пройти расстояние в 2.4 раза меньше, чем его скорость ходьбы.
Значит при скорости ходьбы 88 персонаж пройдет 36 unit’ов.
88 / 2.4 = 36
Первое деление — это начало движения (ходьба) а следующие деления — это бег.
Помните как мы бегали по горам и не придавали значение тому как быстро спускались или поднимались на них?
Как мы знаем в реальной жизни перемещаясь на плоскости горизонтальная скорость у нас постоянная.
Как только мы начинаем преодолевать горы и другие неровности то горизонтальная скорость у нас будет меньше.
Но не в мире Lineage 2 где горизонтальная скорость всегда постоянная и нее зависит от неровностей.
Связанно это с тем чтобы было проще синхронизировать персонажа на сервере и клиенте.
Ведь на сервере нет точной модели мира, а лишь примерное очертание называемое geodata.
А из-за того, что geodata приблизительно повторяет ландшафт клиента то было бы невозможно синхронизировать персонажа по Z оси.
Поэтому синхронизация идет только по X и Y оси.
Видео:
1) Горизонтальная скорость на плоскости постоянная.
2) Как было бы в жизни. Взбираясь на гору горизонтальная скорость падает.
3) Как сделано в игре. Горизонтальная скорость постоянная.
4) Демонстрация из игры. Бежит словно нет никаких гор.
Я разрабатываю эмулятор сервера для Lineage 2 Chronicle 1: Harbingers of war на Node.js.
Столкнулся с проблемой синхронизации скорости персонажа на сервере с клиентом. Когда в игре вы нажимаете мышкой в то место, куда хотите перейти то происходит плавный переход с анимацией движения. На сервере в этот момент тоже происходит движение по таймеру, но не такое плавное.
GIF
GIF
C(client) – двигается плавно из одной точки в другую. S(server) – делает прирост координат по таймеру.
Для примера я взял сборку написанную на java l2j-lisvus Сборок много. Но все они являются fork’ами проекта l2jserver https://l2jserver.com/И многое наследуется. В том числе и передвижение персонажа.
В l2j-lisvus, как и во всех сборках l2jserver перемещение персонажа на сервере идет при помощи таймера с приростом одинаковых значений.
Проблема проявляется, когда нам надо сделать какое-то действие после того, как персонаж добежал до пункта назначения. Например, нанести удар по NPC.
GIF
На коротких расстояниях проблема незаметна. Нога наступает точно в монету.
GIF
На длинных расстояниях действие атака начинается раньше, чем персонаж добегает до цели.
GIF
А если выкрутить скорость на максимум (900) то проблема расхождения очевидна. Это связанно с тем, что помимо скорости бега есть скорость ходьбы.
Как работает передвижение персонажа на сервере.
За основу взяты базовые характеристики персонажа. Скорость бега 126.
126 — это количество внутренних unit’ов за секунду.
На данной схеме идет прирост координат персонажа каждые 1000мс на 126 unit’ов. Исходя из схемы выше пример кода для действий персонажем после достижения пункта назначения:
// Прироста координат нет. Просто считаем когда персонаж дойдет до конечных координат. const distance = 1500; const playerSpeed = 126; const ticks = distance / playerSpeed; // 11.90 const time = ticks * 1000; // 11900mc
setTimeout(() => { // действие персонажа после бега }, time);
GIF
На коротких расстояниях.
GIF
На длинных расстояниях.
Расхождения на коротких расстояниях.
Расхождения на длинных расстояниях.
Зеленой зоной показана точка куда должна ступить нога персонажа если бы не было расхождений.
Рост скорости при развитии персонажа.
126 — это базовая скорость. И по мере развития персонажа будет расти и скорость передвижения. А значит расхождение будет больше. Но перед тем, как создать формулу надо подтвердить теорию, что скорость ходьбы влияет на расхождение.
Данные о характеристиках персонажа передаются от сервера к клиенту.
Выставляю значения walkSpeed: 126. Если скорость ходьбы будет равна скорости бега, то расхождения должны пропасть.
GIF
Нога персонажа достигает правильной конечной точки.
Персонаж синхронизирован и начинает атаку вовремя. Теперь надо понять, как скорость ходьбы влияет на расхождения между клиентом и сервером.
Сколько же персонаж успевает пройти перед тем, как начинает бежать?
Надо поймать момент когда ходьба переходит в бег. Для этого передадим в клиент данные, где скорость ходьбы будет больше скорости бега. Из-за этой разницы будет виден переход и можно будет рассчитать пройденное расстояние при ходьбе.
runSpeed: 10
walkSpeed: 600
GIF
Ходьба быстрее бега.
При скорости шага в 600 персонаж успевает пройти 250, прежде чем начинает бежать.
600 / 250 = 2.4
700 / 291 = 2.4
800 / 333 = 2.4
Из этого вывод, что персонаж перед тем, как начать бежать успевает пройти расстояние в 2.4 раза меньше, чем его скорость ходьбы.
Значит при скорости ходьбы 88 персонаж пройдет 36 unit’ов.
88 / 2.4 = 36
Первое деление — это начало движения (ходьба) а следующие деления — это бег.
У проекта появилась чёткая архитектура управления сущностями. Теперь NPC, игроки, питомцы и другие объекты взаимодействуют в мире через систему менеджеров — рассказываю, как это работает.
В игровом мире есть разные типы сущностей: NPC, игроки (Player), питомцы (Pet) и другие. Каждая из них имеет свои состояния (движение, атака, бездействие) и требует управления.
Основные сущности и их поведение
• NPC – управляет собой (перемещение, атака, idle).
• Player – управляется игроком (те же состояния: ходьба, атака и т. д.).
• Pet – похож на NPC, но принадлежит игроку.
Менеджеры и их задачи
1. NpcManager – создаёт NPC, реагирует в случае смерти NPC.
2. PlayersManager – отвечает за вход игроков в мир.
3. PetsManager – управляет питомцами (аналогично NPC, но с привязкой к игроку).
4. EntitiesManager – главный координатор:
o Управляет NpcManager и PlayersManager.
o Обрабатывает взаимодействия (например, если игрок подошёл к NPC, оба получают информацию друг о друге).
5. VisibilityManager– отвечает за видимость объектов:
o Определяет, кто кого видит.
o Периодически обновляет списки видимости для оптимизации.
6. MovingManager – обновляет позиции всех подвижных объектов в мире.
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
При добавлении SoulShot функционала не добавил проверку не только на наличие оружия, но и кто атакует — игрок или NPC.
Как итог теперь все атакуют с помощью SoulShot.
Тестирую синхронизацию объектов на перемещение и атаку между NPC и игроком и немного намусорил. Дроп, который падает, показывает текущее местоположение объекта на стороне сервера. Каждый n-ный тик происходит синхронизация. Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
В первой главе мы с вами узнали, как и где создавались первые "шахматные автоматы", которые были всего лишь имитаторами программируемых шахматных роботов. Сегодня знакомство с первыми настоящими шахматными алгоритмами и программами.
*** Глава 2. Как роботы научились играть в шахматы ***
Чтение советской и американской прессы 70-х годов прошлого XX-го века оставляет приятное послевкусие.
Конечно, нельзя было говорить о дружбе между СССР и США, но отношения явно улучшились по сравнению с послевоенными годами.
В американской прессе мелькают сообщения о смягчении давления американской бюрократии на Коммунистическую партию США. В частности, в 1973 году федеральный окружной суд в Аризоне постановил, что большая часть закона против американских коммунистов неконституционна, и Аризона должна допустить КП США к участию в голосовании на всеобщих выборах ("Блавис против Болина").
В советской прессе насмешки над убогим мещанским западным (в основном американским) образом жизни продолжались (в духе Михаила Задорнова "ну, тупые"). Но при этом явно начала изменяться эмоциональная окраска этих насмешек. Злая язвительная сатира потихоньку менялась на добродушный юмор с весёлыми приколами.
Вот мы читаем сообщение о нищем, который обитает на богатой парижской помойке. Ничего особо интересного в этом факте нет. Не было никакого секрета в том, что на этом Западе нищих огромное количество, как блох на бродячей собаке. Но именно в этом нищем была интересная изюминка. На своём плакате, ниже стандартного объявления "подайте плиз, кто сколько может жертве холокоста, бюрократии и бездушия", нищий сделал странную и наглую приписку "доллары США не принимаю".
Не знаю, придумал журналист эту хохму, или реально зафиксировал нечто подобное, но эта короткая заметка порождает у читателей множество мыслей, начиная от надежд, что долларовая долговая пирамида скоро рухнет до желания дать нищему полезный совет: "бери, дурачок, что дают, потом ненужное выбросишь".
Учёные экономисты по обе стороны океана начинают осторожно высказывать идеи о возможности "конвергенции" капитализма и социализма. При этом, в США должны усилиться социальные гарантии для трудящихся, а в СССР для "деловых людей" должны быть предоставлены возможности для полезных экономических частных инициатив (типа строительства личных дач и не только).
Самое главное, что в такой атмосфере о прямом военном конфликте не могло быть и речи. Решались вопросы о возможностях сотрудничества в разных областях.
В 1972 году в Москве председатель Совета министров СССР Алексей Косыгин и президент США Ричард Никсон подписывают "Соглашение о сотрудничестве в исследовании и использовании космического пространства в мирных целях". В 1975 году в рамках этого соглашения был реализован совместный полёт советского и американского пилотируемых космических кораблей со стыковкой на орбите (знаменитый проект "Союз - Аполлон").
Вот в таких условиях мирной конкуренции и делового сотрудничества СССР и США с явным желанием обеих сторон уйти от прямых военных столкновений в 1974 году состоялось грандиозное событие для всех любителей шахмат и прикладного программирования: первый в мире чемпионат мира среди шахматных программ.
Состоялось это мероприятие в Стокгольме во время конгресса ИФИП (IFIP, International Federation for Information Processing).
Лидерами в области шахматного программирования были американцы. В США было 50 действующих шахматных программ, во всем остальном мире (Европа + СССР) около 20. Также в США уже был богатый опыт проведения внутренних чемпионатов. Последний чемпионат США стал отборочным к первому чемпионату мира. Лучшими оказались программы: "Чесс-4.0", "Теч-2", "Хаос" и "Острич". Они и представляли США на этом турнире.
Что же касается нашей страны, то у нас в боевом режиме была единственная программа "Каисса" и ещё несколько программ в стадиях подготовки и перспективной разработки. Именно "Каисса" и представляла СССР на этом турнире. По итогам турнира "Каисса" заняла первое место и завоевала золотую медаль весом 110 грамм.
После окончания турнира "Каисса" в виде бонусного трека сыграла дополнительную товарищескую партию с лучшей американской программой "Чесс-4.0". После долгой и упорной борьбы партия завершилась вничью.
Насколько сильно играли лучшие компьютерные программы в 1974 году? Мне представляется, если бы они играли в сегодняшних (2025 год) турнирах для людей, например, на популярном шахматном сайте "ЛиЧесс", то изначально показывали бы рейтинг в диапазоне 1800-2000 в блице с контролем 5+0. Для сравнения сегодняшние лучшие гроссмейстеры показывают здесь рейтинги 3000+ или, как минимум, около того. А если бы обсчитывали рейтинги современных лучших компьютерных программ типа "Стокфиш" и "АльфаЗирро" при их играх с людьми, то мы увидели бы рейтинги 4000+ или даже 5000+. Короче, эти современные роботы били бы всех людей без малейших шансов для последних. Примечание. При условии взаимной честной игры, но это уже совсем другая тема.
После первого чемпионата разработчики упорно работали над усовершенствованием своих программ.
В 1977 году состоялся второй чемпионат мира среди компьютерных программ в канадском городе Торонто.
Наша "Каисса" приняла участие и в этом чемпионате. Уже в первом туре чемпионка преподнесла неожиданный сюрприз для всех, включая зрителей, своих разработчиков и присутствовавших на турнире гроссмейстеров и мастеров.
Позиция из партии: "Duchess" - "Каисса", Торонто, 1977. Тур: 1.
"Каисса" до этого игравшая неплохо в этой чуть лучшей позиции вдруг делает ряд странных ходов, начиная отсюда: 29. … а5?
30. g4 Фe6
31. Лc6 a4?
32. Ф:а4 Лd6
33. Л:d6 Ф:d6
34. Фа8+
Здесь все ожидали естественного хода 34. … Крg7
Но "Каисса" вдруг ставит под бой ладью 34. … Лe8 и затем постепенно проигрывает без каких-либо шансов.
После партии, когда Каиссу спросили, в чем дело, она объяснила, что ход 34. ... Крg7 гораздо хуже, чем сделанный ею ход 34. ... Лe8.
В доказательство "Каисса" показала такой вариант:
34. ... Крg7 35.Фf8+! Крxf8 36. Сh6+ Сg7 37. Лc8+
"Каисса" демонстрирует вариант, которые не увидели даже гроссмейстеры
37. … Фd8 38. Л:d8+ Лe8 39. Л:e8X.
Специалисты, среди них были гроссмейстеры Ботвинник, Эдуард Ласкер, Ганс Берлинер, канадский международный мастер Леон Пиасетский эту комбинацию не обнаружили и объясняли народу этот заскок Каиссы "несовершенством шахматных программ".
В конечном результате турнира Каисса разделила 2—3 места с программой Duchess. Победила в чемпионате программа "Чесс-4.0".
До сих пор идут диспуты, а увидела бы программа Duchess во время партии этот выигрывающий ход 35.Фf8+
Далеко не факт, учитывая, ограниченность времени на обдумывание в турнирной партии.
В любом случае, если ход 34. ... Лe8 объективно сильнее (т.к. затягивал поражение на много ходов), то никто не будет спорить, что практических шансов больше у скромного хода 34. ... Крg7
Мне стало любопытно, а как бы в критической позиции пошла бы современная программа: 34. ... Лe8 или 34. ... Крg7 - ?
Я задал этот вопрос "Стокфишу" и получил ответ: 34. ... Лe8
Вот так!
Такие тонкие психологические моменты не понимали шахматные программы в 1977-м году, не понимают их они и сейчас, в 2025-м.
Возьмем этот факт на заметку, он нам пригодится для дальнейших рассуждений.
А как вообще роботы научились играть в шахматы? Точнее говоря, кто был их первым учителем?
Вообще говоря, много умнейших людей брались за эту интереснейшую проблему и решали её с разной степенью успеха.
Традиционно считается, что самым первым шахматным программистом в мире был Алан Тьюринг. В 1951 году он написал алгоритм Turochamp, с помощью которого машина могла бы играть в шахматы. Самое забавное, что это был чисто теоретический труд. У Алана не было компьютера, чтобы проверить свою программу на практике.
Тем не менее, его идеи были использованы другими учёными, а идеи тех, в свою очередь, новыми учёными, и вот, что мы имеем в сухом остатке.
Попробуем набросать примерный алгоритм игры в шахматы.
Что нам нужно сделать? Написать программу, которая умеет находить сильнейший ход в любой позиции.
Немного подумав, почитав разных полезных статей, становится ясно, что тут есть 2 принципиальных краеугольных камня.
Функция, которая оценивает позицию (оценочная функция).
Функция, которая как-то умеет определять максимальную глубину просмотра.
Давайте, попробуем набросать функцию, которая оценивает позицию.
Для простоты пока сделаем глубину просмотра равную одному полуходу и анализировать будем начальную позицию.
Примечание. Пусть будет 0.1 балл за одно свободное поле под атакой.
Премия за очередь хода. Пусть пока будет 0. Не уверен, что это вообще хорошая идея.
Проверку на мат проводим. Вообще, вряд ли кому-то будет мат в начальной позиции или после первого полухода. Но проверять надо.
Оценка позиции = Белые - Черные = (38.2+18)-(38.2+18) = 56.2-56.2 = 0
Теперь нам надо подобным образом оценить все позиции после всех возможных ходов.
Оценка позиции после 1-го хода белых
Ход Баллы
a3 0.0
a4 0.2
b3 0.2
b4 0.2
c3 0.2
c4 0.3
d3 0.6
d4 0.7
e3 0.9
e4 0.9
f3 0.0
f4 0.1
g3 0.2
g4 0.2
h3 0.0
h4 0.2
Кa3 0.1
Кc3 0.3
Кf3 0.3
Кh3 0.1
Получается следующий результат. Если применять данную оценочную функцию и использовать глубину расчета на 1 полуход, то в данной позиции получаются лучшие ходы: e3 или е4.
Теперь мы можем уточнить оценку начальной позиции. Если изначально она была равна 0, то после первого полухода стала равной 0.9.
Разумеется, если мы посмотрим чуть глубже (т.е. оценим все позиции после всех возможных 2-х полуходов), то оценка начальной позиции опять изменится. Наверное, она опять станет равной 0, например, после 1. e4 e6.
А если посмотреть немного глубже, хотя бы на 20 полуходов? Все это, конечно, можно сделать, посвятив этому процессу месяц или два, но это уже всё сделано до нас.
Всем привет. Меня зовут Максим. Являюсь веб-разработчиком и сейчас поставил цель разработать два своих небольших проекта и довести дело до продаж.
Вообще имею большое кладбище стартапов. Их конечно нельзя назвать полностью неудачными, т.к получал с них опыт, что очень важно и полезно.
Но сейчас решил изменить подход к разработке, развитию проектов. Одно из изменений - вести заметки и делиться удачным, неудачным опытом. Возможно это поможет довести проекты до конечной цели и вполне возможно опыт, которым поделюсь будет кому-то полезен.
Для разработки выбрал два проекта: система лояльности для небольшого бизнеса и seo-мониторинг сайтов. Пока без подробностей.
Точка отсчёта - 22 мая 2025 года. Релиз seo-мониторинга - 1 июля 2025 года, система лояльности - 1 августа 2025 года.
Первый раз при разработке своих проектов сделал оценку трудозатрат и будет интересно сравнить ожидание и реальность.
Также посоветовали больше писать о проектах, делиться мыслями. Будет конечно трудно, но попробуем)
Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.
Мой стек
Frontend: - React (без сюрпризов) - WXT (лучший фреймворк для браузерных расширений) - MUI (библиотека UI-компонентов под Material Design) - Netlify (бесплатный и надёжный хостинг)
Backend: - Supabase (как Firebase, только лучше) - Yandex Cloud (serverless-контейнеры + S3-хранилища)
Процесс
На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.
С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:
Перенёс на WXT (фреймворк для Chrome Extensions)
Заменил самописные компоненты на MUI
Добавил TypeScript для типобезопасности
Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API
Что получилось
Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.
Дополнительно добавил:
Аудиоплеер для предпросмотра файла перед отправкой
Анонимную расшифровку по прямой ссылке на аудио
Бонус
Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.
Выводы
Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.
Хотите больше деталей? Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.
Вот есть нормальные же игроки. Они, там, с террористами воюют на компьютере, выживают на скорость, ну или зомбей шинкуют. А я в несезон запускаю Euro Truck Simulator 2, беру в руки руль и везу на 40тонной фуре груз в Алмазный. Ой, извините, в Марсель. Ну или в Штутгард. Монотонная, скучная компьютерная игра, почему она? Не, конечно, я не только в ETS играю, но вот поговорить хотел бы именно об этой игре. Точнее, на её примере.
Те мотоциклисты, которые раньше были только автомобилистами, поездив за рулем мотоцикла, начинают больше замечать другие мотоциклы. И дело тут не только в интересе. Дело ещё и в том, что техника, она по разному едет на дороге. Мотоцикл может быть слева, посредине, справа в колее - машина нет. Мотоцикл ускоряется сам по себе быстрее потока при обычной скорости открывания газа. Мотоцикл изменяет ширину в наклоне. В свою очередь у машин есть некое своё среднеарифметическое ускорение. Даже переключение с первой на вторую у авто и мото не совпадает, а ведь переключение это пауза в ускорении. Мотоцикл был в левом зеркале и теперь не виден? Возможно он сзади, но теперь в правой колее. Мотоцикл пытается первее вас успеть на поворот эстакады или почему-то пропускает? Ему там надо будет наклониться а под это нет места. И таких примеров можно придумать массу.
А с фурами - ещё сложнее. На место водителя легкового автомобиля себя поставить не так уж и сложно. Старый ВАЗ или каршеринг, категория Б, что была открыта "хвостом" с А, или даже раньше. Готово, можно ехать. Но не на фуре. Особенно, если фура гружённая ближе к тем самым 40 тоннам. И вот Euro Truck Simulator это игра, где ты ведёшь гружёную фуру, а остальному потоку плевать на то, что ты существуешь. НПС влезают перед тобой в последний момент, внезапно оттормаживаются, залезают в мёртвые зоны, подлезают так, что ты можешь легко снести их бортом при повороте. На трассе нужно держаться справа, тебя опережает буквально весь поток а при опережении тихохода можно не смочь вернуться назад, потому что легковушки попёрли опережать справа не дожидаясь, пока ты вернёшься. Поворачивать направо вдоль бордюра сложно, лучше бы на вторую полосу а оттуда снова в первую. Не забудь проверить, что хвост борта не сносит ретивую легковушку ведь конец борта уходит левее при повороте направо. А ещё полосы, оказывается, весьма узковаты, когда ты сидишь от первого лица играешь и у тебя половина обзора это кабина, а правые зеркала даже не в поле зрения.
Я это всё к чему? Умение ставить себя на место другого участника движения - ключ к пониманию того, что он может делать, а что нет. Что хочет - а что нет. Что он видит, как ускоряется и тормозит. Обвинять - легко, это вам любой комментарий из инета в помощь. А вот понять, почему водитель действовал так а не иначе - сложнее. И пусть ETS это всего лишь игра, но водителей фур она помогает понять и помогает безопасно. Такие вот мысли.
Послесловие
У меня есть ТГ-канал с анонсами, новостями и краткими очерками, которые слишком малы для полноценных постов, а теперь его дублирует и ВК. Спасибо всем, кто поддерживает творчество.
No-code выглядит соблазнительно. Не надо учиться кодить. Разработчики не нужны. Накликал интерфейс - и запускай единорога. Звучит красиво.
А на деле - быстро превращается в болото. Недавно видел пример: ребята сделали приложение для изучения испанского языка на no-code. Через месяц им пришлось переписать всё на код. Причина простая - костыли.
И это не открытие. Я ещё лет десять назад видел такие штуки. Delphi, Microsoft Access, Lotus Notes, позже Oracle APEX — там тоже можно было натыкать кнопочек, набросать интерфейс, и оно даже работало. Но стоило захотеть что-то серьёзнее - и упираешься в потолок платформы. В итоге такие проекты либо переписывают, либо бросают.
No-code повторяет ту же историю. Хочешь добавить функцию - нельзя. Делаешь костыль. Хочешь ещё - снова костыль. Через месяц костылей так много, что проект перестаёт развиваться.
Да, есть исключения. Специализированные инструменты работают классно. Тильда для лендингов. Airtable для таблиц. Retool для дашбордов. Но это не «замена программистов», а «ускоритель для специалистов».
А универсальные конструкторы «сделай любое приложение без кода» - это мираж. Ты вроде строишь продукт, а на деле собираешь небоскрёб на болоте.
Я сам часто запускаю проекты и пишу про эти попытки, удачные и не очень. Так что тема no-code для меня не теория, а наблюдения из практики.
Изначально я собиралась на втором уроке рассказать о венозном кровотечении, но хорошо поразмыслив, решила напомнить о том, как устроена наша система кровообращения. Вот скажите честно, многие из вас помнят, что вам рассказывали в школе об этом? Ну вот. Понимая как и что устроено в человеке, проще оказывать помощь. Поверьте. Итак. Начнём.
Кровообращение - это слово говорит само за себя. Значение его не надо объяснять. Сегодня я не буду рассказывать о функциях крови (а их очень много), скажу только, что без крови человек не может существовать. Потеряв одномоментно большой объём, человек погибает. Как, например, здесь. Но как всё происходит? По большому счёту весь наш организм как бы омывается кровью. Кровь течёт по замкнутой сердечно-сосудистой системе. В неё входят сосуды и сердце.
Сердце - "насос", а не пламенный мотор. Это мышечный орган, который перекачивает кровь по кровеносным сосудам. Я не буду углубляться в описание строения сердца. Однако, если кому-то очень хочется - можно посмотреть вот это видео
Расскажу я о сердце в общих чертах. К этой статье мы будем возвращаться потом - она нам пригодится в дальнейшем процессе обучения.
Сердце состоит из четырёх отдельных полостей, называемых камерами: левое предсердие, правое предсердие, левый желудочек, правый желудочек. Функционирует оно за счёт электрических импульсов, возникающих в самом сердце. Кровь попадает в сердце по венам. Изначально она попадает в предсердия, затем, за счёт сокращения предсердий, проталкивается в желудочки. Желудочки сокращаются с большей силой и направляют кровь в организм по артериям. В этом ролике хорошо всё рассказано
Продолжим.
Сосуды
Посмотрите на эту схему.
Голова может с непривычки закружиться. Сколько в нас имеется сосудов! И это только те, что художник нарисовал. Здесь мы видим изображение артерий, вен и капилляров, и круги кровообращения.
Виды кровеносных сосудов:
артерии — сосуды, несущие кровь от сердца (на рисунке обозначены красным цветом);
вены — сосуды, несущие кровь к сердцу (обозначены синим цветом);
капилляры — тончайшие кровеносные сосуды, образующие сеть в тканях и органах.
Самые мелкие артерии и вены, переходящие в капилляры, называются артериолами и венулами.
Круги кровообращения
Их три. Большой, малый и внутрисердечный. Последний мы сегодня разбирать не будем. Остановимся на первых двух. И начнём с большого круга кровообращения. Большой круг называют еще телесным.
Большой круг кровообращения начинается в левом желудочке, из которого артериальная кровь поступает в аорту (самую большую артерию организма). Аорта расходится на артерии. Они идут ко всем тканям тела, переходят в артериолы и затем в капилляры. Капилляры соединяются в венулы и затем в вены. Именно через капиллярные стенки происходит обмен газов и веществ. Венозная кровь с отработанными продуктами обмена веществ по венам собирается в два крупных сосуда - верхнюю и нижнюю полые вены, которые вливают ее в правое предсердие. На этом большой круг кровообращения заканчивается. И мы переходим к малому кругу. Малый круг еще называют легочным.
Малый круг кровообращения начинается в правом желудочке. Из лёгочная артерия несёт кровь к лёгким. Эта кровь насыщена углекислым газом и содержит продукты обмена веществ. И она венозная. Лёгочная артерия делится на две ветви, которые и несут венозную кровь в лёгкие. В лёгких артерии ветвятся на мелкие артериолы, переходящие в сеть капилляров, густо оплетающих стенки альвеол, где и происходит обмен газами. Насыщенная кислородом артериальная кровь по легочным венам поступает в левое предсердие. Таким образом, в артериях малого круга кровообращения течет венозная кровь, в венах — артериальная.
Вроде всё понятно? Дайте подытожим. Кровь из сердца опускается вниз к телу или верх к голове, отдаёт кислород и нужные вещества органам и тканям, насыщается отработанными веществами. Затем поднимается вверх (в случае с головой - вниз), попадает в сердце, а оттуда идёт в лёгкие. В лёгких - отдаёт углекислый газ, насыщается кислородом, отправляется обратно к сердцу.
Сейчас мы вспомнили то, что должны были проходить в школе. Про другие системы очистки организма как-нибудь потом напомню. Дополнительно к полученной информации хочу дать ещё одну. Думаю вы сталкивались с тем, что с похмелья изо рта пахнет дурно. Почему-то многие уверенны, что это из желудка несёт. На самом деле это лёгкие привет от вчерашнего застолья предают.
На этом урок закончен. В следующий раз расскажу про вены.
Спасибо за внимание.
До свидания!
P.S. Попрошу ещё раз. Уважаемый @editors, добавьте пожалуйста тег "ЛикБезМед". Он означает "Ликвидация Безграмотности в Медицине" и будет в дальнейшем помогать искать мои посты (возможно, не только мои) на эту тему. Заранее спасибо.
Если по какой-либо причине меня забанят, то ищите меня на моём ТГ-канале https://t.me/Mama_Ladushka или в Вк. Последнее время ну очень неспокойно на сайте.
В 1870 году в британском Лондоне открылся Тауэрский тоннель — первая подземная линия железной дороги, проходившая от северного до южного берега реки Темзы. Длина тоннеля составляла примерно 400 метров. Отличительной особенностью было то, что железная дорога пролегала в железной трубе, а не в кирпичном тоннеле. В трубе находился вагон, вмещавший до 12 человек. В каждом конце тоннеля были установлены паровые двигатели, благодаря которым вагон на стальном тросе преодолевал указанное расстояние всего за 70 секунд.
Как-то так это выглядело
Сам тоннель под Темзой на глубине 5 с лишним метров выкопали меньше чем за год благодаря инженеру Джеймсу Генри Грэйтхеду («великая голова»!), который придумал проходческий щит цилиндрической формы — предтечу современных тоннелепроходческих машин. Линия была закрыта в 1898 году, однако вход на станцию и сегодня сохранился рядом с лондонским Тауэром.
В 1992 году американская легкоатлетка Джеки Джойнер-Керси победила в семиборье на Олимпийских Играх в Барселоне, став первым в истории двукратным победителем в этой дисциплине Игр.
I believe I can fly
На тех же Играх белорусский гимнаст Виталий Венедиктович Щербо, представлявший Содружество Независимых Государств, стал первым в истории обладателем шести золотых медалей, полученных в ходе одних Игр. Вот как это выглядело:
Бонус-трек: 1 августа 1967 года ВМС США вернули на активную службу капитана Грейс Мюррей Хоппер для того, чтобы она возглавила разработку языка программирования COBOL (COmmon Business Oriented Language). В 1940-х Хоппер работала в Гарварде над компьютерами Mark I и Mark II, а теперь возглавила команду сотрудников из нескольких фирм-производителей компьютеров и Пентагона.
Целью разработки COBOL было прежде всего создание легко читаемых компьютерных программ с максимально возможной независимостью от аппаратного обеспечения: предполагалось, что программа на COBOL сможет запускаться на любом компьютере, где есть компилятор, с минимальными модификациями.
Грейс Мюррей Хоппер (слева)
Вообще, за свою долгую карьеру Хоппер внесла значительный вклад в развитие компьютерных систем, в том числе благодаря тому, что написала, как считается, первый компилятор "А-0". А ещё, судя по всему, она первой ввела в оборот слово "баг" (bug) в контексте компьютерных технологий — так она в журнале однажды отметила мотылька, который попал в реле компьютера Harvard Mark II.
Эта рубрика выходит не только в виде рассылки на Substack, но и в собственном телеграм-канале в формате "одно сообщение — одна памятная дата" (и из опубликованных там постов часть сюда не входит). Подписывайтесь, читайте раньше остальных и поражайте знакомых и незнакомых ненужной им информацией в самое сердечко!
Комментарии