ну так принимающая микросхема должна же как-то понимать текущую частоту входящего потока? представьте что в канале тишина, а это постоянно происходит в звуке, при частоте семплов в 44100 в секунду, - огромная часть семплов будет просто пустая. как из стабильного нуля в канале понять с какой он частотой поступает?
определять из первых семплов которые отличаются от нуля? можно, на это нужно примерно несколько десятков семплов по спекам любого DAC. выглядеть это будет как отрезание доли миллисекунды на каждой смене тишина-звук. что в принципе может быть и незаметно, настолько быстро это происходит, но как минимум выглядит как знатный костыль, и конечно же вызовет широкий спектр инфарктов на форумах аудифилов, с вечным проклятием цифрового воспроизведения как неизлечимой ереси.
Нет, это исходит из того что I2S это звук который передаётся с какой-то дискретизацией, 44100, 48000,.. вот эти вот смешные цифры из эпохи mp3, - это частота звукового цифрового потока. и I2S как протокол не подразумевает что эта частота всегда одна и та же, или какого-то соглашения между источником и потребителем о том какой она будет на всё время работы.
Живой пример - вы проигрываете файл mp3 на компьютере mp3 44100, он поступает на DAC как I2S прямо со своей частотой 44100. А потом вы берёте и открываете другой файл, который имеет частоту 48000. Тут возможно было несколько подходов как это могло бы быть сделано:
I2S мог иметь что-то типа SPI входа по которому можно было бы "устанавливать" текущую частоту, которую он как вы выражаетесь "запоминал бы". Но это бы означало внедрение во все чипы I2S какой-то рудиментарной микроконтроллерной логики, довольно дорогое решение для дизайна IC. Причём нужно было бы поддерживать эту логику с двух сторон - источник управляемый проигрывателем ставил бы её, а получатель ожидал. Довольно сложная схема.
I2S мог бы работать на установленной на старте частоте, и тогда бы любой источник должен был бы перекодировать все проигрываемые файлы к этой частоте, что про конверсиях 48000 -> 44100 давало бы "артефакты", ну просто потому что это не 1:2 и даже не какой-нибудь 11:54, - там очень неочевидная дробь, и заодной вызывала бы сердечный приступ и аудиофилов на форумах одним упоминанием "цифровых артефактов перекодировки" (кстати спойлер, - современные устройства практически не дают артефактов. я использую это в хардварном I2S микшере с несколькими входами и мне не удалось услышать ничего что можно и близко назвать искажениями). и это ещё ладно на компьютере, а как бы страшно усложнялись хардварные проигрыватели, где микросхем общающихся по I2S обычно несколько.
I2S мог быть сделан так, что в него всегда поступает опорная частота, и он просто работает на этой частоте разбирая поступающий по другому пину поток с этой скоростью. Меняется частота - меняется скорость, меняются места где ожидаются начала битов. На выходе это всё равно превращается в гладкую аналоговую синусоиду, какая разница с какой частотой там исходная лесенка... По этому пути и пошёл дизайн. Просто, надёжно, дешево.
Да уж, какая-то не впечатляющая интрига вышла... Ведь в даташите любого DAC/ADC на I2S будет написано - либо подавайте опорную частоту на CLKIN, либо конфигурируйте чип на автоматическое выделение опорной частоты из BCK.
Вы так говорите, как будто "оппозиция" это всегда про "свергать правительства". Да и вообще как-то странно это звучит, чтобы вдруг кто-то просто переписывался друг с другом, а их за это надо было бы преследовать нарушая право на частную жизнь. Это ж как в диктаторских режимах чтоли?.. Вот это да!
Срочно пишите всем вокруг эти невероятные новости, надо же всем вокруг доказать что проект с открытым исходным кодом который понятно и доступно, для тех кто в этом разбирается, работает, сделан для того чтобы всех поймать и посадить используя скрытые технологии о которых никому не известно...
signal это же просто мессенджер? как его можно "использовать для смены режимов"? даже если отвлечься от желтушности самой терминологии, это же не платформа для публикаций, не средство для перевода денег, это же просто мессенджер???
суть примерна та же, что и "русский язык используется для смены режимов по всему миру". или "рубли, выпускаемые центрабанком, используются в совершения преступлений по всей России"
Именно вера в эту черту политики "кто там чё говорит не важно, главное как оно на самом деле", или "мистическое мышление" отличает российскую политику от современной западной. В политике в 21-м веке то, что говорит представитель страны очень важно, поэтому они взвешивают каждое слово, поэтому политики уходят со своих должностей когда неосторожно сказанное слово вызывает скандал. Потому что то, что говорит представитель страны (а политик это тот, кто выражает мнение страны и её народа, а не своё) это то, какое намерение действовать по тому или иному вопросу имеет страна.
Аллегория со взрывчаткой была призвана всего лишь показать, что оценка россии как "посредственной экономической силы", но "сильным источником проблем" не противоречива. Возможно кто-то как император считает миллионами, ну там миллион "населения" туда, миллион сюда, не большая разница перед лицом мировых событий, но сейчас не 19 век, и ещё до недавнего времени даже случайный выстрел в сторону города населённого людьми попадал во все новости, не говори уж о том если он в кого попал. Была такая, знаете ли, современная тенденция, считать даже незначительные разрушения проблемами. Сложно было бы считать что Россия не стала гораздо большей/сильной/значительной угрозой миру в этом плане, как в плане риторики, так и на деле.
В аналитических отчётах НАТО всегда была "большая опасность" и "меньшая опасность". И это не константа которую определили наши отцы как число Пи, она может меняться со временем. Россия представляла меньшую опасность десять лет назад, когда не бомбила соседние страны, и представляет большую опасность сейчас, когда открыто каждый день говорит что ради достижения своих целей готова прибегнуть к любым мерам. И это не называется русофобия, русофобией называется предвзятое отношение без оснований. Тут же оценка делается на основе и действий, и особенно заявлений о намерениях. Болтать всё что угодно, а потом сказать "ну вы же понимаете, это же несерьёзно всё было" можно с друганами в шестом классе.
РФ может быть крайне слабой в демографическом и экономическом плане, но крайне сильной в плане разрушений и проблем которые может нанести, так же как килограмм взрывчатки крайне энергоэффективно упакован и содержит огромное количество энергии которую может выделить, но крайне мало эффективен в качестве еды, которая вроде как тоже представляет собой источник энергии.
"Сам протокол" не "не запрещает" GET с Body. До 2014-го года RFC2616 (HTTP 1.1 Spec) декларировал что GET запрос может иметь Body, но этот Body должен быть проигнорирован сервером. Если сервер как-то обрабатывает Body, и его ответ меняется в зависимости от передаваемых в нём данных - он нарушает RFC.
После 2014-го это убрали, и заменили на "body GET запроса не имеет семантики и может вызвать реджект запроса".
Это собственно довольно заметно становится в последнее время. Всё больше библиотек просто зафейлит и исходящий GET реквест с Body (javascript fetch, Unity из тех с чем я работал), и входящий GET c Body (вот на вскидку не помню...).
Так что GET с Body был прикольным костылём, но сейчас уже пора писать прямо что это не просто плохая практика, а что так вообще делать нельзя.
Нет, он имеет ввиду что он делает /castrandom, получает то, что выбросил внутренний рандом игры, сравнивает с той последовательностью что есть у него исходя из формулы, если число совпало, повторяет и сверяет следующее (в своей последовательности), если не совпало - двигается дальше по своей последовательности, пока не найдёт тот участок, на котором в данный момент находится внутренний рандом. собственно узнав место в последовательности на котором находится внутренний рандом все следующие числа которые будут выкинуты - доступны. ничего он не передопределяет, "сдвигаем RNG" в этом контексте - это поиск по последовательности которая у него на руках в поисках последовательности которую выкидывает внутренний рандом.
"прокручивать рандом пока не выпадет нужное число" в вашей концепции прямо скажем сильно странное занятие. ну вот мне нужно число 6, я буду крутить рандом пока не выпадет 6. докручу. ииииии...??? ну как бы, я победитель, безусловно, что дальше-то?..
Ничего он там не предопределял. Я специально внимательно прочитал что он делал конкретно.
Он создавал список из нескольких заклинаний в виде листа, который можно вызывать как "castrandom", чтобы "закрытое окружение", то есть сам код игры, скастовало из этого списка рандомное заклинание. потом, исходя из того какое заклинание было скастовано, выводил какое число выбросил рандом кода игры, и, прогнав этот же процесс несколько раз, исходя из того что код для рандома явно лажовый, получал возможность узнать какие числа будут следующими.
вопрос остаётся всё тем же - и чо?..
castrandom итак довольно малоприменимый вызов, ума не приложу для чего им можно пользоваться, ну так ты получишь возможность узнать что из списка который ты сам же составил будет вызвано следующим. умопомрачительные знания, просто хоть стой хоть падай (сарказм). с тем же успехом можно просто составить лист заклинаний и вызывать их подряд, и они ВОТ ЭТО ПОВОРОТ будут вызываться в нужном тебе порядке...
вполне возможно что рандом-то на клиенте как раз был не самый успешный именно потому что лучше и не нужен...
ну допустим был бы ещё вариант размотав внутреннее состояние генератора случайных чисел узнать какой будет следующий /roll, но как там сверху заметили уже, - если бы /roll обсчитывался на клиенте, его бы уже давно наклонили и без аддонов...
Это вы так поняли если статью прочитали, но в сам вов не играли и аддоны не писали.
Я и играл и писал, и такой проблемы там нет вообще.
Аддоны в вове наверное лучший пример того как надо делать расширяемую игру со скриптовым языком. Это event based система, у которой есть огромный лист эвентов за которые можно цепляться и выполнять свой код, реагируя на это как угодно, либо как-то обрабатывая данные логически, либо рисуя на экране что угодно (с довольно простым фреймворком который позволет быстро накидывать на экран примитивы - цифры там разные, либо небольшие спрайты, либо UI элементы которые можно описать .xml файлами).
Так вот этот event stream просто огромен, вов отправляет абсолютно всю инфу в клиента и она вся доступна для того чтобы к ней цепляться. И твои изменения здоровья, и изменения здоровья всех вокруг и все эвенты в определённом радиусе даже если ты их не видишь на экране. Даже рудиментарное отслеживание движений присутствует. То есть можно узнать насколько от тебя далеко кто-то находится, и даже прицепиться к эвенту типа "что-то стало ближе такого-то расстояния ко мне". Отличная, мощная система, спроектированная так, как нужно делать нерд системы для нердов в играх, а не какой-то куцый обрубок с "ну мы подумали вот этого вам хватит, чё вам там ковыряться в нашей игре, вы же не программисты".
Lua прекрасный выбор языка для всего этого. Это один поток, безумно скоростной язык из-за своей простоты. Нужно постараться чтобы всрать производительность даже если ты очень плохо пишешь. Что кстати доказывают тысячи аддонов для вова. Многие из них написаны геймерами, а не программистами.
Короче всё со скриптовой подсистемой в вове нормально, логично, не противоречиво и совсем практически ничем не ограничено.
Конечно есть ограничения которые не позволят сделать прям полноценного бота - никак нельзя контролировать перемещение персонажа, и при входе в состояние боя лочиться АПИ применения заклинаний. То есть не получиться сделать какого-то бота которого можно будет таскать за собой, а он будет допустим автоматом тебя лечить когда твоё здоровье упало до кого-то минимума. Это практически всё из реальных серъёзных ограничений, всё остальное это какие-то реакции на то как кто-то супер умный смог хардкорно запилить что-то через АПИ что покоробило игровой баланс или вводило какие-то фичи которые близзард намеренно запрещали. Типа нельзя использовать АПИ чата до достижения какого-то уровня, и всемирный АПИ не гарантирует ни чтение ни отправление сообщений (люди делали аддоны которые позволяли синхронизироваться через весь мир друг с другом).
Абсолютно никаких проблем, описаных в статье я вообще не помню, и автор комментария выше задал тот же самый вопрос который возник и у меня после прочтения - "и чо?". Не помню ни одной проблемы в вове которую можно было бы размотать предсказав следующее число в генераторе случайных чисел на клиенте. Да я даже не представляю особо что там на клиенте генератором случайных чисел производится...
Все пользователи одной ОС, например винды, попав на мак (или линукс) отчаянно бросаются "осваивать" его, называя почему-то этим словом бесконечную затяжную попытку сделать всё "как привычно", то есть как на другой ОС. Потом пишут огромную статью на хабр о каждой мелочи которую смогли подпилить, подкрутить, подменить, немножко подогнуть и сделать "правильно". И страшно довольны и результатом, и статьёй, столько добра принесли в мир, такой ценный подробный гайд!..
Печальная правда такова, что всё это вода и наносное и особо никому не понадобится никогда... Либо вы через год вернётесь на свою винду, устав бесконечно бороться с тем что по вам "не так" на маке, либо врубитесь что к чему, просто станете пользоваться тем что предлагает мак на маке, потому что это удобно и логично, а на винде тем что предлагает винда, потому что это удобно и логично, и со стыдом и усмешкой будете вспоминать и посматривать на эту длинную простыню, ну уж не удалять же...
У нас есть новая отличная быстрая архитектура aarch64, и куча тулзов которые уже годы её поддерживают, позволяющие использовать её в любых задачах.
Но нет, давайте заколотим костылей по кругу, и запустим эмуляцию x86_64 потому что всё новое очень страшно...
Не надо так. Просто собирайте контейнеры под две архитектуры, это не сложно. Особенно с учётом того что сервера на aarch64 уже вполне себе распространённая вещь, они дешевле и зачастую быстрее.
Надо один раз настроить билдер, чтобы создавались контейнеры под обе архитектуры и multiarch манифест, и никто даже не догадается что у кого-то arm, а у кого-то intel.
увидел кучу макбуков, подумал «вот это дичь», прочитал про 1 айфон - 1 макбук, подумал что «дичь конечно, но теперь понятно почему». потом сразу подумал - а не пробовали виртуализировать macos и пробрасывать usb порты в виртуалки? macos легально запускать в виртуалке на другой макос (хардваре эппл), не пробовали поставить макмини помощнее, запустить на нем пяток виртуалок и пробросить в каждую 1 usb порт?
а в целом нереальный респект за очевидный «колхоз», но без снобизма объяснённый зачем так сделано и почему. нестандартные задачи требуют нестандартных решений!
И это всё так же не имеет смысла для домашнего стенда описанного в статье.
Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.
У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.
Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.
В статье говорится про тестовый кластер для экспериментов.
И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.
если .ValueString это "[ var='B0' metric='Zombie' labels={} value=10.85 ]" то скорее всего все эти данные доступны либо как .Value.metric/.Value.value либо .Values.B0.metric/.Values.B0.value и так далее.
Как минимум в алертах это работает (там через $, как {{ $values.B0.value }})
Основная проблема новых алертов в графане не запутанность, а то что это абсолютно новая система, к которой если начать читать документацию, то дойти до раздела где будет описано то что тебе нужно почти нереально (а часто это будет вообще один абзац который можно запросто пропустить) и гугл ещё не набрал достаточное количество людей с такой же проблемой как у тебя. Раскопать что-то быстро чтобы узнать как это выписать практически невозможно сейчас.
по излишнему употреблению нелепого слова «сие» в текстах и комментариях можно всегда отличить человека который читает много всякой чуши претендующей на серьезность. да и сам такую пишет.
Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.
ну так принимающая микросхема должна же как-то понимать текущую частоту входящего потока? представьте что в канале тишина, а это постоянно происходит в звуке, при частоте семплов в 44100 в секунду, - огромная часть семплов будет просто пустая. как из стабильного нуля в канале понять с какой он частотой поступает?
определять из первых семплов которые отличаются от нуля? можно, на это нужно примерно несколько десятков семплов по спекам любого DAC. выглядеть это будет как отрезание доли миллисекунды на каждой смене тишина-звук. что в принципе может быть и незаметно, настолько быстро это происходит, но как минимум выглядит как знатный костыль, и конечно же вызовет широкий спектр инфарктов на форумах аудифилов, с вечным проклятием цифрового воспроизведения как неизлечимой ереси.
Нет, это исходит из того что I2S это звук который передаётся с какой-то дискретизацией, 44100, 48000,.. вот эти вот смешные цифры из эпохи mp3, - это частота звукового цифрового потока. и I2S как протокол не подразумевает что эта частота всегда одна и та же, или какого-то соглашения между источником и потребителем о том какой она будет на всё время работы.
Живой пример - вы проигрываете файл mp3 на компьютере mp3 44100, он поступает на DAC как I2S прямо со своей частотой 44100. А потом вы берёте и открываете другой файл, который имеет частоту 48000. Тут возможно было несколько подходов как это могло бы быть сделано:
I2S мог иметь что-то типа SPI входа по которому можно было бы "устанавливать" текущую частоту, которую он как вы выражаетесь "запоминал бы". Но это бы означало внедрение во все чипы I2S какой-то рудиментарной микроконтроллерной логики, довольно дорогое решение для дизайна IC. Причём нужно было бы поддерживать эту логику с двух сторон - источник управляемый проигрывателем ставил бы её, а получатель ожидал. Довольно сложная схема.
I2S мог бы работать на установленной на старте частоте, и тогда бы любой источник должен был бы перекодировать все проигрываемые файлы к этой частоте, что про конверсиях 48000 -> 44100 давало бы "артефакты", ну просто потому что это не 1:2 и даже не какой-нибудь 11:54, - там очень неочевидная дробь, и заодной вызывала бы сердечный приступ и аудиофилов на форумах одним упоминанием "цифровых артефактов перекодировки" (кстати спойлер, - современные устройства практически не дают артефактов. я использую это в хардварном I2S микшере с несколькими входами и мне не удалось услышать ничего что можно и близко назвать искажениями). и это ещё ладно на компьютере, а как бы страшно усложнялись хардварные проигрыватели, где микросхем общающихся по I2S обычно несколько.
I2S мог быть сделан так, что в него всегда поступает опорная частота, и он просто работает на этой частоте разбирая поступающий по другому пину поток с этой скоростью. Меняется частота - меняется скорость, меняются места где ожидаются начала битов. На выходе это всё равно превращается в гладкую аналоговую синусоиду, какая разница с какой частотой там исходная лесенка... По этому пути и пошёл дизайн. Просто, надёжно, дешево.
Да уж, какая-то не впечатляющая интрига вышла... Ведь в даташите любого DAC/ADC на I2S будет написано - либо подавайте опорную частоту на CLKIN, либо конфигурируйте чип на автоматическое выделение опорной частоты из BCK.
Вы так говорите, как будто "оппозиция" это всегда про "свергать правительства". Да и вообще как-то странно это звучит, чтобы вдруг кто-то просто переписывался друг с другом, а их за это надо было бы преследовать нарушая право на частную жизнь. Это ж как в диктаторских режимах чтоли?.. Вот это да!
Срочно пишите всем вокруг эти невероятные новости, надо же всем вокруг доказать что проект с открытым исходным кодом который понятно и доступно, для тех кто в этом разбирается, работает, сделан для того чтобы всех поймать и посадить используя скрытые технологии о которых никому не известно...
signal это же просто мессенджер? как его можно "использовать для смены режимов"? даже если отвлечься от желтушности самой терминологии, это же не платформа для публикаций, не средство для перевода денег, это же просто мессенджер???
суть примерна та же, что и "русский язык используется для смены режимов по всему миру". или "рубли, выпускаемые центрабанком, используются в совершения преступлений по всей России"
Именно вера в эту черту политики "кто там чё говорит не важно, главное как оно на самом деле", или "мистическое мышление" отличает российскую политику от современной западной. В политике в 21-м веке то, что говорит представитель страны очень важно, поэтому они взвешивают каждое слово, поэтому политики уходят со своих должностей когда неосторожно сказанное слово вызывает скандал. Потому что то, что говорит представитель страны (а политик это тот, кто выражает мнение страны и её народа, а не своё) это то, какое намерение действовать по тому или иному вопросу имеет страна.
Аллегория со взрывчаткой была призвана всего лишь показать, что оценка россии как "посредственной экономической силы", но "сильным источником проблем" не противоречива. Возможно кто-то как император считает миллионами, ну там миллион "населения" туда, миллион сюда, не большая разница перед лицом мировых событий, но сейчас не 19 век, и ещё до недавнего времени даже случайный выстрел в сторону города населённого людьми попадал во все новости, не говори уж о том если он в кого попал. Была такая, знаете ли, современная тенденция, считать даже незначительные разрушения проблемами. Сложно было бы считать что Россия не стала гораздо большей/сильной/значительной угрозой миру в этом плане, как в плане риторики, так и на деле.
В аналитических отчётах НАТО всегда была "большая опасность" и "меньшая опасность". И это не константа которую определили наши отцы как число Пи, она может меняться со временем. Россия представляла меньшую опасность десять лет назад, когда не бомбила соседние страны, и представляет большую опасность сейчас, когда открыто каждый день говорит что ради достижения своих целей готова прибегнуть к любым мерам. И это не называется русофобия, русофобией называется предвзятое отношение без оснований. Тут же оценка делается на основе и действий, и особенно заявлений о намерениях. Болтать всё что угодно, а потом сказать "ну вы же понимаете, это же несерьёзно всё было" можно с друганами в шестом классе.
РФ может быть крайне слабой в демографическом и экономическом плане, но крайне сильной в плане разрушений и проблем которые может нанести, так же как килограмм взрывчатки крайне энергоэффективно упакован и содержит огромное количество энергии которую может выделить, но крайне мало эффективен в качестве еды, которая вроде как тоже представляет собой источник энергии.
"Сам протокол" не "не запрещает" GET с Body. До 2014-го года RFC2616 (HTTP 1.1 Spec) декларировал что GET запрос может иметь Body, но этот Body должен быть проигнорирован сервером. Если сервер как-то обрабатывает Body, и его ответ меняется в зависимости от передаваемых в нём данных - он нарушает RFC.
После 2014-го это убрали, и заменили на "body GET запроса не имеет семантики и может вызвать реджект запроса".
Это собственно довольно заметно становится в последнее время. Всё больше библиотек просто зафейлит и исходящий GET реквест с Body (javascript fetch, Unity из тех с чем я работал), и входящий GET c Body (вот на вскидку не помню...).
Так что GET с Body был прикольным костылём, но сейчас уже пора писать прямо что это не просто плохая практика, а что так вообще делать нельзя.
Нет, он имеет ввиду что он делает /castrandom, получает то, что выбросил внутренний рандом игры, сравнивает с той последовательностью что есть у него исходя из формулы, если число совпало, повторяет и сверяет следующее (в своей последовательности), если не совпало - двигается дальше по своей последовательности, пока не найдёт тот участок, на котором в данный момент находится внутренний рандом. собственно узнав место в последовательности на котором находится внутренний рандом все следующие числа которые будут выкинуты - доступны. ничего он не передопределяет, "сдвигаем RNG" в этом контексте - это поиск по последовательности которая у него на руках в поисках последовательности которую выкидывает внутренний рандом.
"прокручивать рандом пока не выпадет нужное число" в вашей концепции прямо скажем сильно странное занятие. ну вот мне нужно число 6, я буду крутить рандом пока не выпадет 6. докручу. ииииии...??? ну как бы, я победитель, безусловно, что дальше-то?..
Ничего он там не предопределял. Я специально внимательно прочитал что он делал конкретно.
Он создавал список из нескольких заклинаний в виде листа, который можно вызывать как "castrandom", чтобы "закрытое окружение", то есть сам код игры, скастовало из этого списка рандомное заклинание. потом, исходя из того какое заклинание было скастовано, выводил какое число выбросил рандом кода игры, и, прогнав этот же процесс несколько раз, исходя из того что код для рандома явно лажовый, получал возможность узнать какие числа будут следующими.
вопрос остаётся всё тем же - и чо?..
castrandom итак довольно малоприменимый вызов, ума не приложу для чего им можно пользоваться, ну так ты получишь возможность узнать что из списка который ты сам же составил будет вызвано следующим. умопомрачительные знания, просто хоть стой хоть падай (сарказм). с тем же успехом можно просто составить лист заклинаний и вызывать их подряд, и они ВОТ ЭТО ПОВОРОТ будут вызываться в нужном тебе порядке...
вполне возможно что рандом-то на клиенте как раз был не самый успешный именно потому что лучше и не нужен...
ну допустим был бы ещё вариант размотав внутреннее состояние генератора случайных чисел узнать какой будет следующий /roll, но как там сверху заметили уже, - если бы /roll обсчитывался на клиенте, его бы уже давно наклонили и без аддонов...
Это вы так поняли если статью прочитали, но в сам вов не играли и аддоны не писали.
Я и играл и писал, и такой проблемы там нет вообще.
Аддоны в вове наверное лучший пример того как надо делать расширяемую игру со скриптовым языком. Это event based система, у которой есть огромный лист эвентов за которые можно цепляться и выполнять свой код, реагируя на это как угодно, либо как-то обрабатывая данные логически, либо рисуя на экране что угодно (с довольно простым фреймворком который позволет быстро накидывать на экран примитивы - цифры там разные, либо небольшие спрайты, либо UI элементы которые можно описать .xml файлами).
Так вот этот event stream просто огромен, вов отправляет абсолютно всю инфу в клиента и она вся доступна для того чтобы к ней цепляться. И твои изменения здоровья, и изменения здоровья всех вокруг и все эвенты в определённом радиусе даже если ты их не видишь на экране. Даже рудиментарное отслеживание движений присутствует. То есть можно узнать насколько от тебя далеко кто-то находится, и даже прицепиться к эвенту типа "что-то стало ближе такого-то расстояния ко мне". Отличная, мощная система, спроектированная так, как нужно делать нерд системы для нердов в играх, а не какой-то куцый обрубок с "ну мы подумали вот этого вам хватит, чё вам там ковыряться в нашей игре, вы же не программисты".
Lua прекрасный выбор языка для всего этого. Это один поток, безумно скоростной язык из-за своей простоты. Нужно постараться чтобы всрать производительность даже если ты очень плохо пишешь. Что кстати доказывают тысячи аддонов для вова. Многие из них написаны геймерами, а не программистами.
Короче всё со скриптовой подсистемой в вове нормально, логично, не противоречиво и совсем практически ничем не ограничено.
Конечно есть ограничения которые не позволят сделать прям полноценного бота - никак нельзя контролировать перемещение персонажа, и при входе в состояние боя лочиться АПИ применения заклинаний. То есть не получиться сделать какого-то бота которого можно будет таскать за собой, а он будет допустим автоматом тебя лечить когда твоё здоровье упало до кого-то минимума. Это практически всё из реальных серъёзных ограничений, всё остальное это какие-то реакции на то как кто-то супер умный смог хардкорно запилить что-то через АПИ что покоробило игровой баланс или вводило какие-то фичи которые близзард намеренно запрещали. Типа нельзя использовать АПИ чата до достижения какого-то уровня, и всемирный АПИ не гарантирует ни чтение ни отправление сообщений (люди делали аддоны которые позволяли синхронизироваться через весь мир друг с другом).
Абсолютно никаких проблем, описаных в статье я вообще не помню, и автор комментария выше задал тот же самый вопрос который возник и у меня после прочтения - "и чо?". Не помню ни одной проблемы в вове которую можно было бы размотать предсказав следующее число в генераторе случайных чисел на клиенте. Да я даже не представляю особо что там на клиенте генератором случайных чисел производится...
Если контент общедоступный, обратились бы к его авторам и получили прямо от них, делов-то...
Все пользователи одной ОС, например винды, попав на мак (или линукс) отчаянно бросаются "осваивать" его, называя почему-то этим словом бесконечную затяжную попытку сделать всё "как привычно", то есть как на другой ОС. Потом пишут огромную статью на хабр о каждой мелочи которую смогли подпилить, подкрутить, подменить, немножко подогнуть и сделать "правильно". И страшно довольны и результатом, и статьёй, столько добра принесли в мир, такой ценный подробный гайд!..
Печальная правда такова, что всё это вода и наносное и особо никому не понадобится никогда... Либо вы через год вернётесь на свою винду, устав бесконечно бороться с тем что по вам "не так" на маке, либо врубитесь что к чему, просто станете пользоваться тем что предлагает мак на маке, потому что это удобно и логично, а на винде тем что предлагает винда, потому что это удобно и логично, и со стыдом и усмешкой будете вспоминать и посматривать на эту длинную простыню, ну уж не удалять же...
У нас есть новая отличная быстрая архитектура aarch64, и куча тулзов которые уже годы её поддерживают, позволяющие использовать её в любых задачах.
Но нет, давайте заколотим костылей по кругу, и запустим эмуляцию x86_64 потому что всё новое очень страшно...
Не надо так. Просто собирайте контейнеры под две архитектуры, это не сложно. Особенно с учётом того что сервера на aarch64 уже вполне себе распространённая вещь, они дешевле и зачастую быстрее.
Надо один раз настроить билдер, чтобы создавались контейнеры под обе архитектуры и multiarch манифест, и никто даже не догадается что у кого-то arm, а у кого-то intel.
увидел кучу макбуков, подумал «вот это дичь», прочитал про 1 айфон - 1 макбук, подумал что «дичь конечно, но теперь понятно почему». потом сразу подумал - а не пробовали виртуализировать macos и пробрасывать usb порты в виртуалки? macos легально запускать в виртуалке на другой макос (хардваре эппл), не пробовали поставить макмини помощнее, запустить на нем пяток виртуалок и пробросить в каждую 1 usb порт?
а в целом нереальный респект за очевидный «колхоз», но без снобизма объяснённый зачем так сделано и почему. нестандартные задачи требуют нестандартных решений!
И это всё так же не имеет смысла для домашнего стенда описанного в статье.
Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.
У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.
Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.
В статье говорится про тестовый кластер для экспериментов.
И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.
если .ValueString это "[ var='B0' metric='Zombie' labels={} value=10.85 ]" то скорее всего все эти данные доступны либо как .Value.metric/.Value.value либо .Values.B0.metric/.Values.B0.value и так далее.
Как минимум в алертах это работает (там через $, как {{ $values.B0.value }})
Основная проблема новых алертов в графане не запутанность, а то что это абсолютно новая система, к которой если начать читать документацию, то дойти до раздела где будет описано то что тебе нужно почти нереально (а часто это будет вообще один абзац который можно запросто пропустить) и гугл ещё не набрал достаточное количество людей с такой же проблемой как у тебя. Раскопать что-то быстро чтобы узнать как это выписать практически невозможно сейчас.
по излишнему употреблению нелепого слова «сие» в текстах и комментариях можно всегда отличить человека который читает много всякой чуши претендующей на серьезность. да и сам такую пишет.
Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.