03.09.2020, 00:38
03.09.2020, 01:33
(02.09.2020 21:37)Berserker Wrote: [ -> ]А может стоит вообще ввести проверку на сетевую игру и в ней все использования T автоматически считать за R? Мы получим прекрасный рандом в скриптах в сингле и стабильность в мульте.если это реально уберёт часть сетевых вылетов - то СТОИТ

тут просто надо здраво оценивать пользу для игроков, думаю все минусы такого решения куда меньше плюсов
03.09.2020, 01:53
Night, может, sn:r?
03.09.2020, 02:59
Bes, это не исправит вылеты в имеющихся скриптах без VR:T, но позволит спокойно использовать VR:T без страха испортить мультиплеер.
По поводу замены штатного генератора вопрос остаётся открытым. Генерация препятствий и ландшафта боя привязана к старому генератору. Разве что найти место, где он используется и временно переключать на оригинальный, как предлагал RoseKavalier.
По поводу замены штатного генератора вопрос остаётся открытым. Генерация препятствий и ландшафта боя привязана к старому генератору. Разве что найти место, где он используется и временно переключать на оригинальный, как предлагал RoseKavalier.
12.02.2021, 20:25
Иногда, нужно задать шанс срабатывания чего-либо с определённой вероятностью. Допустим с вероятностью 33%. Простое в итоге может давать и 10% и 90%. 
Используя следующий код, мы получим шанс очень близкий к желаемому, а при многократном использовании - практически идеальный. Мы будем получать числа 0; 1; 2; в произвольном порядке, но пока не выпадет весь ряд - числа не повторятся. Выбираем любое из этих чисел на срабатывание шанса (я выбрал 0). Понятно, что если мы хотим иметь шанс в 25%, то нужно создать массив из 4-х ячеек, а если шанс в 10% - то из 10 ячеек.
Можно ли оптимизировать этот скрип на ERM? (не ERM2
)
Или, может, есть более "крутые" варианты?

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

Или, может, есть более "крутые" варианты?
13.02.2021, 03:37
SergOz, не нужно подобных усложнений.
13.02.2021, 04:09
Berserker, согласитесь, что в таком случае из, скажем, 10 вариантов, может ни разу не сгенерироваться число меньше 33. А единица из ряда 1;2;3; в 10 вариантах выпадет наверняка и не раз.
А ведь и там и там предполагаемые 33% вероятности.
Впрочем, это кто как посчитает нужным...
А ведь и там и там предполагаемые 33% вероятности.
Впрочем, это кто как посчитает нужным...
13.02.2021, 17:03
SergOz, отправлю тебя к азам теории вероятности. 33% — это и 6666 подряд мимо, 3333 подряд в цель.
То, что ты подсознательно хочешь, это не настоящие 33%, а ограниченный набор результатов с фиксированным соотношением успех/неудача. Скажем, ты хочешь что из 10 бросков гарантированно 3 выпали с ДА, 7 — с НЕТ. При этом если для первого броска вероятность ДА будет 3/10 = 30%, то для второго уже либо 2/9 = 22.2%, либо 3/9 = 33%. С каждым броском вероятности будут другие. Такой подход позволяет гарантировать сбалансированность на небольшом числе генераций, но он также достаточно детерминирован и с ним некорректно писать про фиксированные проценты. Корректно писать: в 3 из 10 раз. При это если все три раза выпали сразу, то следующие 7 бросков будут гарантированно провальными. У меня такой генератор есть в плагине, даже используется в Фениксе. Но для начала определись с тем, что тебе нужно.
То, что ты подсознательно хочешь, это не настоящие 33%, а ограниченный набор результатов с фиксированным соотношением успех/неудача. Скажем, ты хочешь что из 10 бросков гарантированно 3 выпали с ДА, 7 — с НЕТ. При этом если для первого броска вероятность ДА будет 3/10 = 30%, то для второго уже либо 2/9 = 22.2%, либо 3/9 = 33%. С каждым броском вероятности будут другие. Такой подход позволяет гарантировать сбалансированность на небольшом числе генераций, но он также достаточно детерминирован и с ним некорректно писать про фиксированные проценты. Корректно писать: в 3 из 10 раз. При это если все три раза выпали сразу, то следующие 7 бросков будут гарантированно провальными. У меня такой генератор есть в плагине, даже используется в Фениксе. Но для начала определись с тем, что тебе нужно.
13.02.2021, 18:20
Berserker, я понял это. Значит я хочу чтобы из 10 вариантов 3 были успешными.
Вопрос в другом. Когда в описании артефакта указано, что он предохраняет от повреждений в 50% случаях, а игрок получает по факту 1 положительный случай из 10, то ему пофиг теория вероятности: он хочет чтобы в половине случаев этот арт оберегал его героя от повреждений. Именно так большинство игроков воспринимает текст
"защита в 50% случаев".
Но, ещё раз повторю: каждый картодел/мододел должен для себя сам решить какой подход использовать.
Вопрос в другом. Когда в описании артефакта указано, что он предохраняет от повреждений в 50% случаях, а игрок получает по факту 1 положительный случай из 10, то ему пофиг теория вероятности: он хочет чтобы в половине случаев этот арт оберегал его героя от повреждений. Именно так большинство игроков воспринимает текст
"защита в 50% случаев".
Но, ещё раз повторю: каждый картодел/мододел должен для себя сам решить какой подход использовать.
13.02.2021, 18:25
SergOz, так добавь счётчик, каждый раз повышающий вероятность.
13.02.2021, 18:29
daemon_n, меня мой код устраивает по функциональности.
Я лишь хотел узнать какие ещё могут быть подходы для решения гарантированного выпадания 3 из 10.
Я лишь хотел узнать какие ещё могут быть подходы для решения гарантированного выпадания 3 из 10.
13.02.2021, 18:35
SergOz, имхо, счётчик - единственный вариант.
13.02.2021, 18:42
daemon_n, ты видел мой код? Это тоже своего рода счётчик. Но, если ты имел ввиду что-то другое, то опиши, пожалуйста, хотя бы алгоритм.
P.S. Хотя, для вариантов, когда нужен некий процент везения/невезения, можно просто уменьшать цифровой ряд.
Для 50% шанса писать не а
P.S. Хотя, для вариантов, когда нужен некий процент везения/невезения, можно просто уменьшать цифровой ряд.
Для 50% шанса писать не а
13.02.2021, 20:20
SergOz, код только что посмотрел.
Массив он и в Африке массив.
Просто нужен код на автозаполнение массива через 2 цикла. Вот и всё.
Массив он и в Африке массив.
Просто нужен код на автозаполнение массива через 2 цикла. Вот и всё.
13.02.2021, 21:25
SergOz, ты ошибаешься, грубо смысл «вероятности» насилуя. 50% — это именно 50%. И даже если предыдущих 5 раз результат был отрицательный, у 6-го вероятность остаётся 50%. Иначе это не полноценно случайные результаты и не значение вероятностей. ГСЧ в игре теперь качественный.
В остальном верно, у тебя ручной генератор для одного объекта. Для него верно писать «срабатывает Х раз из 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.
Побочный эффект. Если пара раз повезло — дальше гарантированное «невезение», что человек точно так же болезненно воспринимает.
Quote: !!VR(random:y):R0/1/10;Наоборот, лучше 1..1000000 и отсев по 500000.
!!FU&y>5:E; продолжить с вероятностью 50%
В остальном верно, у тебя ручной генератор для одного объекта. Для него верно писать «срабатывает Х раз из 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.
Побочный эффект. Если пара раз повезло — дальше гарантированное «невезение», что человек точно так же болезненно воспринимает.