Pavel
Тем более что сам матант непосредственно не используют. Чаще всего пачки либ для меогоыакториальной оптимизации.
Snusmumriken
Ну так они про метопты, не?
Топология, но я не очень в курсе о чем ты конкретно, сам особо не вдавался : )
Snusmumriken
Это не совсем относится к разработке. Обычно этим занимается не программист :)
Технически да, но в зависимости от состава команды, может и программист. Прочитай ещё вакансии программистов wot, там очень много всяких аналитических геометрий.
fgntfg
Самое главное чтоб жена умная была
Pavel
Я конечно не знаю как именно гацдзины делают. Но я видел как считали баланс пушек в шутане. И там все равно использовали накоплкнные знания в виде статы, а дальше методами оптмищиуии подбирали оптимальный баланс.. Но самого сатана там не было
Pavel
Там использование функций из библиотеки екселя
fgntfg
Серьезный gamedev это и есть игры с табличками
Pavel
А с картами так это ваше не ясно. Что считать? Как оптимизировать? Вот поставил ты камень. Дальше надо карту раз 100 проиграть чтобы увидеть новую хит-мапу передвижения, смертей, выстрелов
Highly Likely
А с картами так это ваше не ясно. Что считать? Как оптимизировать? Вот поставил ты камень. Дальше надо карту раз 100 проиграть чтобы увидеть новую хит-мапу передвижения, смертей, выстрелов
Учитывая лютую багованность карт тундры и частенько лютый дизбаланс при релизе (да и после тоже несколько карт отвратные) – девочка Снуса особо на работе не парится :)
Pavel
Croteam ботов гоняли для talos
Говно. Боты либо уровня openai должны быть... Иначе их поведение слабо совпадает с пользовтальским
Pavel
Ну то есть это лучше чем ничего. Но это такой себе способ понять что оптимизировать
Pavel
Мы пробовали иначе. Делать мелкие изменения и в виде аб-теста катить. А дальше снимать телкметрию и смотреть что стало.
Snusmumriken
А с картами так это ваше не ясно. Что считать? Как оптимизировать? Вот поставил ты камень. Дальше надо карту раз 100 проиграть чтобы увидеть новую хит-мапу передвижения, смертей, выстрелов
Ну да, сначала собирается стата с игроков, на основе неё выделяются основные ключевые моменты (в данном случае, топологии в данном районе карты), потом оно считается какой-то хитрой фигнёй. Потом на основе фигни двигаются кусты и деревья, слегка меняется ландшафт, снова запускается плейтест, правильно ли посчитали, и насколько обоснованы выводы. Повторить N раз. А то игроки одной команды имеют явное преимущество по всем фронтам, например.
Pavel
Боты дешевле чем play test
Ну окей. И? Возможно мы не умели их готовить, но если ты смотришь на ботов то и оптимищируешь карту под ботов. А их поведение очень даже не похоже на поведение людей
Pavel
Как этап - работало так. Боты. Внутренний плей тест. Аб-тест.
Pavel
Но полезность ботов была низкая. Они показывали достаточно очевидные вещи,которве тупо проглядели. Типо того что на уступ не забраться. Или наклон слишком крутой. Или расстояние малое.
Pavel
Но это не самое интересное. В этом месте аналитика - это то как интерпретировать результат. Стало ли лучше|хуже
Pavel
@Snusmumriken https://hi-tech.mail.ru/news/kvantoviy_telefon/
Snusmumriken
Но это не самое интересное. В этом месте аналитика - это то как интерпретировать результат. Стало ли лучше|хуже
Не, таки ещё вычисление "куда двигать и на сколько" в этом тоже есть, с этим тоже что-то делают.
Snusmumriken
И куда? На основе какой метрики вычислять что стало лучше?
Ещё раз повторю, я описываю со слов, сам глубоко не вдаюсь. Мб я сам бобик и неправильно понял
Pavel
Понимаю. Но нужно мерило того что стало лучше. А объективным мермлом является только юзеры.
Pavel
Можно придумать разные метрики. Но они такие... Типо количество точек для прострела. Или наличие кустов у возвышенности.
Pavel
Но это аналитические метрики. Они слабо помогают понять что объект надо двигать
Snusmumriken
Но это аналитические метрики. Они слабо помогают понять что объект надо двигать
Я это приводил в пример школьнику, который хочет делать игры но очень не хочет математику. Расслабься.
Snusmumriken
Есть шанс, что при адекватной модели, построенной на основе статистики, можно вычислить много всякой фигни.
Pavel
Есть шанс, что при адекватной модели, построенной на основе статистики, можно вычислить много всякой фигни.
Нууууууууу... Слабый. Вернее как - работающая модель это серьёзная заявка на успех кмк
Maxim
Коллеги, всем привет! Разрешите попросить, у кого есть время и желание, пройтись свежим взглядом по коду небольшого сервиса и указать на ляпы и "говнокод" если таковые будут замечены, поделиться профессиональным мнением, здоровая критика приветствуется. Входной скрипт, или другими словами main.lua, в main.lua приходят данные GET запроса из nginx и начинается магия lua Ссылочка на файлик https://github.com/maxim-avramenko/static/blob/master/images/app/main.lua Буду рад узнать ваше мнение
Serezha
да вроде нечего критиковать - маленький скрипт, работает и ладно :) ну если ты в команде - обязательно кто то скажет выкинуть простыни комментариев из рабочего кода
Serezha
если ты не в команде и делаешь для себя - окей, пофиг
Serezha
ну разве что вот этот код
Serezha
if ngx.var.width ~= nil and ngx.var.width ~="" then args.w = ngx.var.width end
Serezha
пусть знатоки посоветуют как переписать в однострок типа
Serezha
args.w = ngx.var.width or 0
Snusmumriken
Очень маленький кусочек кода, в целом всё типа ок. Конструкции проверок на nil и '' можно было вынести в мини-функцию isEmpty(v), типа function isEmpty(v) return v ~= nil and v ~= '' and v end а потом типа комбить args.path = isEmpty(ngx.var.path) or ngx.var.content_pwd .. "/" .. ngx.var.path Но это не признаки говнокода. Ещё лично я бы форматировал таблично (пробелами!) всякие объявления рядом, типа local weserv = require "weserv" local weserv_client = require "weserv.client" local weserv_api = require "weserv.api" local weserv_server = require "weserv.server" Просто потому что оно так аккуратнее смотрится и лучше видно что там реквайрится. Но это тоже не признаки говнокода. Кстати, вот эти кеширования не нужны, у тебя и так luajit. Если трасса разогреется, все поиски функций сократятся до ~0, а если не разогреется то как бы и пофигу. local ngx = ngx local type = type local pairs = pairs А вот ngx.var можно было бы и закешировать во что-то типа nvar, тернарники будут чуть короче и чуть читаемее. Так-то, ещё раз повторяю, кусочек слишком маленький и слишком линейный чтобы тут можно было сильно наговнокодить.
Snusmumriken
args.w = ngx.var.width or 0
'' == true Если нужна проверка на пустоту, простой or не пройдёт, но можно выделить в функцию.
Maxim
@Snusmumriken благодарю за комментарии! про вынести в отдельную функцию отдельные благодарности, внесу исправления, по local ngx = ngx необходимы, суть заключается в том что этот код mail.lua выполняется внутри worker процесса nginx, и если эти переменные будут в гломальной зоне видимости виртуальной машины lua тогда значения будут перетираться сделующим worker процессом, в итоге будем иметь во всех worker процессах значения которые были присвоены в последнем запущеном worker процессе
Maxim
если ты не в команде и делаешь для себя - окей, пофиг
этот репозиторий для себя делаю, он открытый на гитхабе
Snusmumriken
Я про строки, ну лан
Snusmumriken
Для чисел - отдельная функция.
Maxim
но я согласен с тобой, этот участок кода требует изменения, не очень красиво получилось
Snusmumriken
На самом деле, это все есть погоня за красотой. В общем-то, мало осмысленная в проде, но чисто чтобы показать "как можно сделать все мило и аккуратно" тем кто не в курсе что и так можно, и к чему можно было бы стремиться.
Maxim
Очень маленький кусочек кода, в целом всё типа ок. Конструкции проверок на nil и '' можно было вынести в мини-функцию isEmpty(v), типа function isEmpty(v) return v ~= nil and v ~= '' and v end а потом типа комбить args.path = isEmpty(ngx.var.path) or ngx.var.content_pwd .. "/" .. ngx.var.path Но это не признаки говнокода. Ещё лично я бы форматировал таблично (пробелами!) всякие объявления рядом, типа local weserv = require "weserv" local weserv_client = require "weserv.client" local weserv_api = require "weserv.api" local weserv_server = require "weserv.server" Просто потому что оно так аккуратнее смотрится и лучше видно что там реквайрится. Но это тоже не признаки говнокода. Кстати, вот эти кеширования не нужны, у тебя и так luajit. Если трасса разогреется, все поиски функций сократятся до ~0, а если не разогреется то как бы и пофигу. local ngx = ngx local type = type local pairs = pairs А вот ngx.var можно было бы и закешировать во что-то типа nvar, тернарники будут чуть короче и чуть читаемее. Так-то, ещё раз повторяю, кусочек слишком маленький и слишком линейный чтобы тут можно было сильно наговнокодить.
и этот main.lua это только входной скрипт, так то в этом lua приложении побольше чем один файлик
Max
https://github.com/soumith/sunfish.lua
интересный пример кода, который luajit/raptorjit исполняет в разы дольше, чем должен. и даже дольше, чем ванильный lua 5.1
Serezha
дело в том что там может прилететь что угодно, а необходим пропускать только integer и больше ноля
У нас в проекте есть небольшая либа для приведения аргументов к заданному типу + инициализация неким значением по умолчанию которое является оптимальным для переменной - вот пример использования - очень удобно чтобы не кодировать лишние if
Serezha
этап валидации-трансформации в любом АПИ нужен потому что ты не знаешь что может прилететь на вход
halt
Парни, такой вопрос. Скрипт слушает события и при наступлении оных хочется сделать уведомлялку (не важно куда, куда то), но проблема в том, что не хочется по каждой ошибке бить тревогу. Направте в нужную сторону или пример какой-нить подскажите, как лучше сделать, чтоб, например, тригер срабатывал на 5-ой ошибке. И ещё загвоздка, т.к. параметров основых 2 - "статус" и "кто" и их несколько нужно учитывать и то и другое. Сейчас это выглядит так: local gateway = event:getHeader("Gateway") local status = event:getHeader("State") if status == "NOREG" and gateway == "mixnet" then Отправка на мыло, в телегу и ещё куда то..... end
Snusmumriken
Запили функцию отправки на мыло. local gateway = event:getHeader("Gateway") local status = event:getHeader("State") if status == "NOREG" and gateway == "mixnet" then sendMail('y@and.ex', 'Плохой статус: ' .. status) end
halt
Нужно чтоб не на каждый NOREG отправлялась уведомлялка, а например, на 5-й
Snusmumriken
В целом, можно извратиться и сделать таблицу определения комбинаций, с которыми надо что-то уведомлять. enum = { NOREG = { mixnet = true, }, BLABLA = { intranet = true, extranet = true } } local status = event:getHeader("State") or '' local gateway = event:getHeader("Gateway") or '' if enum[status] and enum[status][gateway] then sendMail('y@and.ex', status .. ':' .. gateway) end
halt
Смотри. Событие прилетает примерно раз в минуту. Gateway может отвалится и при следуещем прилете снова подняться. Вот и не хочется на каждый чих обращать внимание. Твой пример я примерно понял. Но он все равно будет слать при каждой ошибке
Snusmumriken
Ох, а при каком условии тогда должно уведомляться?
Snusmumriken
Условно, на первый запрос раз в пол часа?
halt
при тех же, но если ошибка NOREG прилетела 5 раз с того же шлюза —> бьем тревогу
Snusmumriken
Опа, тебе уже нужна бд ))
halt
И если после 4-й прилетел REG, то обнулить счетчик
Snusmumriken
Я писал себе такую же штуку. У меня в базу заносится статус отработанных запросов (в каждом множество источников, и некоторые падают/их надо чинить). Обнуляется раз в сутки условно.
Snusmumriken
Ща вспомню как оно работает.
Snusmumriken
А, во, точно. 1. Записываешь в базу плохой статус текущего запроса. 2. Смотришь сколько в базе за сегодня плохих статусов подряд, сортируя по времени и сравнивая с конца в начало. Если ровно пять — отправляешь сообщение. Если больше — уже уведомляли.
Snusmumriken
Можно не "за сегодня" а "за последние пять часов", например, мне хватает раз в сутки.
Snusmumriken
Дык там надо уведомляху на ивент, причём когда всё уже точно плохо.
halt
Идею понял) Спасибо. Немного по другому.... это примерно как при пропадании интернета переключиться на резервный канал, и обратно, когда основной поднимится. Смысл в том, что в этом случае пинговать нужно ресурс и считать сколько вернулось ответов на пинг. Не будешь же переключаться если хотябы один пакет не вернется
fgntfg
Дык там надо уведомляху на ивент, причём когда всё уже точно плохо.
Ну тогда несколько одинаковых событий повышают статус.
Snusmumriken
Надо отлавливать несколько плохих событий подряд, которые могут быть не очень связаны между собой по времени, и даже приходить на разные машины. В целом, с таким отлично работает редиска, кстати.
fgntfg
Статусов, по опыту, нужно штук пять
fgntfg
Все зависит от контекста
Snusmumriken
Есть такое дело, но контекст уже сказан "пять подряд — надо уведомить".
fgntfg
/me пилит мониторинг
halt
FreeSWITCH. Мониторинг транков. Если отвалился - уведомляем
halt
Машина одна