www.open-tager.ru

То есть через ini-файл?
Но тогда, чтобы прописать - нужно знать UIDы датчиков?
А как же их узнать пользователю?

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

По сценариям надо думать заранее и не оставлять это на потом... Проделывал опыты с двумя зонами "голова" и "броня" в 90% случаев срабатывают обе зоны и совершенно непонятно что с этим дальше делать. Если пуляли издалека и срабатывают обе зоны отдавать преимущество голове неправильно, всё время будут хедшоты, и чем больше дистанция тем проще попасть в голову - что нелогично. Если тело сидит в укрытии всегда будет срабатывать голова(нет плюса к ношению сбруи), в упор всегда будет отрабатывать тельце. Получается чит броненосцу - нет смысла прятать тельце, пусть лучше все пули приходят в броню, тогда получается и датчики на голове вообще не нужны их сигнал игнорируется. Итого делали разделение зон, а получилось что это формальность и всего только узаконенный чит - датчики на голове это просто декорация

Есть мнение что вопросы мигания второстепенны: cложная "сбруя" с датчиками должна работать в плюс обладателю, а не развлекать противника. Поэтому важнее отмечать что принятый пакет-пуля был именно один и применять мажоритарный способ вычисления конкретной точки попадания. Например сработали датчики колена + живот + рука, значит попали в "живот", а там у нас броня + "пояс из рожков", "в общем мимо и не больно"

Для приятного доната мигание надо отделить от датчика и сделать его полезным для игрока, например функция определение направления откуда пуляют, может быть специальную информационную панель в прицел или мигалки на руке с каждой стороны.

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

ИМХО есть два относительно простых варианта.
Вариант №1
Затупление датчиков головы - физически, диафрагмой например.
Тогда эмулируется уменьшеная геометрическая вероятность попадания в голову , и если он таки сработал , то значит игнорим попадание в тушку и делаем хедшот.
Функционал выйдет донатныйм.

Вариант №2
Посылка последовательности уменьшающейся мощности вслед за пакетом, коственно можно будет измерить прием какой зоны лучше и поставить на основе этого приоритет - хедшот или корпус.
Тут кроме донатности ещё можно и использовать как измеритель мощности коственный , что довольно интересно, но вот уже не совместимо до конца в отличие от предыдущего варианта с обычным майлзом.

_________________
"какой фонтан !! какое артериальное давление !!!" © Фаргус
-Look, buddy,- i'm a complete ZERO in HSL.

Этосвместно с первым вариантом, с загрублением чувствительности головных датчиков? Если нет, тогда не понимаю, с чего бы голове принимать ослабевающую последовательность хуже чем телу?

Заметка вообще не об этом
Есть шикарный задел в виде умных сенсоров, есть возможность описать его использование в скриптах и ini файлах. Мигалки это одна сторона, приём и логика обработки совсем другая часть программы. Есть смысл описать умный датчик как комбинацию абстрактных устройств мигалка + приёмник + излучатель(для трансляции осколков и тд ). Например вариант: сеть датчиков зажигает только один индикатор (как уже писал алексис). Тогда внутри прошивки получим некоторый менеджер обработки сообщений от датчиков к индикаторам и далее к другим частям программы. Желательно иметь возможность менять поведение этого менеджера с помощью внешних конфигурационных файлов не меняя прошивку, что уже частично реализовано. Однако просто мигать или не мигать это никак на геймплей не повлияет - это украшательство. Вот давайте вместе и подумаем над _сценариями_ которые позволят реализовать именно умные датчики, чтобы это была _реально_полезная_ вещь для игры (как пример радар направления обстрела) а не просто "прорыв-прорывов"

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

Прочитать шильдик на корпусе


Именно так и сделано. Мигалки и приемники - это разные абстрактные устройства.

Излучатели в датчиках пока программно не реализованы, тут как руки дойдут.

Я говорю о том случае когда от одного выстрела срабатывают две зоны в 90%. имхо это наибольшая проблема двухзонности. Если используется одна зона то абсолютно пох сколько и куда пришло .

как потом обработать это уже другой вопрос. имхо полегче.

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

_________________
"какой фонтан !! какое артериальное давление !!!" © Фаргус
-Look, buddy,- i'm a complete ZERO in HSL.

Если любопытно то цена 10 евро за штуку каждого разъёма (не пионерские траты на разъём)

Не, это перебор. Я заказал разъемы по 35р. за пару с уже распаянными проводами. Думаю, их будет достаточно

Новости проекта
Наконец-то дошли руки и протокол обмена с датчиками удалось стабилизировать. Исправил неприятный баг с потерей некоторых пакетов на шине от повязки к сенсору. Это критично, когда посылается программа мигания. Если она доходит только частично, датчик может остаться в зажженном состоянии. Да и все датчики станут вести себя в разнобой. Баг был непростой, и связан с data race между прерыванием UART и основным циклом обработчика событий. Дебаггер в такой ситуации бессилен, из средств отладки оставались только осциллограф С1-65 и красный светодиод.

Теперь умный датчик полноценно заменяет глупый. Задумка с полудуплексным UART, дающим 3 провода в произвольной топологии, полностью себя оправдала: решение получилось надежное и максимально простое (с хардварной стороны). При текущих настройках опрос одного датчика с учетом таймаута длится 3 мс. Поэтому если у нас 10 датчиков, и попали только в один, в худшем случае повязка узнает об этом через 0,03 с. Если пошаманить с таймерами, можно получить прирост скорости ещё в 3 раза.

Первые 10 контроллеров для умных сенсоров уже пришли, платы едут из Китая.