Night, в этом случае используй VR:T смело.

(02.09.2020 21:37)Berserker Wrote:  А может стоит вообще ввести проверку на сетевую игру и в ней все использования T автоматически считать за R? Мы получим прекрасный рандом в скриптах в сингле и стабильность в мульте.

если это реально уберёт часть сетевых вылетов - то СТОИТ
тут просто надо здраво оценивать пользу для игроков, думаю все минусы такого решения куда меньше плюсов

Night, может, sn:r?

Bes, это не исправит вылеты в имеющихся скриптах без VR:T, но позволит спокойно использовать VR:T без страха испортить мультиплеер.
По поводу замены штатного генератора вопрос остаётся открытым. Генерация препятствий и ландшафта боя привязана к старому генератору. Разве что найти место, где он используется и временно переключать на оригинальный, как предлагал RoseKavalier.

Иногда, нужно задать шанс срабатывания чего-либо с определённой вероятностью. Допустим с вероятностью 33%. Простое в итоге может давать и 10% и 90%.
Используя следующий код, мы получим шанс очень близкий к желаемому, а при многократном использовании - практически идеальный. Мы будем получать числа 0; 1; 2; в произвольном порядке, но пока не выпадет весь ряд - числа не повторятся. Выбираем любое из этих чисел на срабатывание шанса (я выбрал 0). Понятно, что если мы хотим иметь шанс в 25%, то нужно создать массив из 4-х ячеек, а если шанс в 10% - то из 10 ячеек.
Можно ли оптимизировать этот скрип на ERM? (не ERM2 )
Или, может, есть более "крутые" варианты?

SergOz, не нужно подобных усложнений.

Berserker, согласитесь, что в таком случае из, скажем, 10 вариантов, может ни разу не сгенерироваться число меньше 33. А единица из ряда 1;2;3; в 10 вариантах выпадет наверняка и не раз.
А ведь и там и там предполагаемые 33% вероятности.

Впрочем, это кто как посчитает нужным...

SergOz, отправлю тебя к азам теории вероятности. 33% — это и 6666 подряд мимо, 3333 подряд в цель.

То, что ты подсознательно хочешь, это не настоящие 33%, а ограниченный набор результатов с фиксированным соотношением успех/неудача. Скажем, ты хочешь что из 10 бросков гарантированно 3 выпали с ДА, 7 — с НЕТ. При этом если для первого броска вероятность ДА будет 3/10 = 30%, то для второго уже либо 2/9 = 22.2%, либо 3/9 = 33%. С каждым броском вероятности будут другие. Такой подход позволяет гарантировать сбалансированность на небольшом числе генераций, но он также достаточно детерминирован и с ним некорректно писать про фиксированные проценты. Корректно писать: в 3 из 10 раз. При это если все три раза выпали сразу, то следующие 7 бросков будут гарантированно провальными. У меня такой генератор есть в плагине, даже используется в Фениксе. Но для начала определись с тем, что тебе нужно.

Berserker, я понял это. Значит я хочу чтобы из 10 вариантов 3 были успешными.

Вопрос в другом. Когда в описании артефакта указано, что он предохраняет от повреждений в 50% случаях, а игрок получает по факту 1 положительный случай из 10, то ему пофиг теория вероятности: он хочет чтобы в половине случаев этот арт оберегал его героя от повреждений. Именно так большинство игроков воспринимает текст
"защита в 50% случаев".
Но, ещё раз повторю: каждый картодел/мододел должен для себя сам решить какой подход использовать.

SergOz, так добавь счётчик, каждый раз повышающий вероятность.

daemon_n, меня мой код устраивает по функциональности.
Я лишь хотел узнать какие ещё могут быть подходы для решения гарантированного выпадания 3 из 10.

SergOz, имхо, счётчик - единственный вариант.

daemon_n, ты видел мой код? Это тоже своего рода счётчик. Но, если ты имел ввиду что-то другое, то опиши, пожалуйста, хотя бы алгоритм.

P.S. Хотя, для вариантов, когда нужен некий процент везения/невезения, можно просто уменьшать цифровой ряд.
Для 50% шанса писать не а

SergOz, код только что посмотрел.
Массив он и в Африке массив.
Просто нужен код на автозаполнение массива через 2 цикла. Вот и всё.

SergOz, ты ошибаешься, грубо смысл «вероятности» насилуя. 50% — это именно 50%. И даже если предыдущих 5 раз результат был отрицательный, у 6-го вероятность остаётся 50%. Иначе это не полноценно случайные результаты и не значение вероятностей. ГСЧ в игре теперь качественный.

Quote: !!VR(random:y):R0/1/10;
    !!FU&y>5:E; продолжить с вероятностью 50%

Наоборот, лучше 1..1000000 и отсев по 500000.

В остальном верно, у тебя ручной генератор для одного объекта. Для него верно писать «срабатывает Х раз из Y посещений», поскольку вероятность зависит от предыдущих посещений напрямую.
Я делал весьма схожий функционал, но без массива. Храним три значения: число успешных результатов, число заданных успешных результатов и общее число оставшихся результатов до перегенерации.

Скажем, 0 успешных было, 3 успешных гарантированно, 10 заходов осталось.
При посещении генерируем случайное из диапазона 1..заходов осталось и
успехом считаем значение <= (гарантированно - успешных).

Пример:
-) Случайное из 1..10 Выпало 7. 7 <= (3 - 0)? Нет, неудача.
-) Случайное из 1..9. Выпало 5. 5 <= (3 - 0)? Нет, неудача.
-) Случайное из 1..8. Выпало 2. 2 <= (3 - 0)? Да, успех.
-) Случайное из 1..7. Выпало 4. 4 <= (3 - 1)? Нет, неудача.

Если имеем 10/10 заходов, то сбрасываем счётчики на начальное состояние. Массив не нужен даже для сложных решений вроде 17 из 45.
Побочный эффект. Если пара раз повезло — дальше гарантированное «невезение», что человек точно так же болезненно воспринимает.