Arisu

Одноразовый - можно. Ничего страшного не произойдет.

Специально для любителей ловить всё таймерами, я привожу цепочку вызовов до onClientRender, глядя в исходники клиента. С комментариями и ссылками на строки. http://code.google.com/p/mtasa-blue/sou ... ce9.cpp#20: CProxyDirect3DDevice9::CProxyDirect3DDevice9 ( IDirect3DDevice9 * pDevice ) Здесь начало. В конструкторе класса CProxyDirect3DDevice9 захватывается объект Direct3D, выше мне копать тупо лень, поэтому глядим конструктор и по смыслу понимаем, что это так и есть. Метод этого же класса Present - не что иное, как сигнал того, что экранный буфер готов к отрисовке. Это проверяется гуглом и MSDN-ом. В теле метода - вызов http://code.google.com/p/mtasa-blue/sou ... e9.cpp#358: CDirect3DEvents9::OnPresent ( m_pDevice ); Здесь вызов статического метода класса CDirect3DEvents9::OnPresent. CDirect3DEvents9 это еще одна прослойка между движком MTA и Direct3D. В его теле нас интересует вызов http://code.google.com/p/mtasa-blue/sou ... s9.cpp#134: CCore::GetSingleton ().DoPostFramePulse (); Здесь: получение синглтона (это нагуглите в целях развития) класса CCore, и вызов его метода DoPostFramePulse(). В его теле: http://code.google.com/p/mtasa-blue/sou ... e.cpp#1284: m_pModManager->DoPulsePostFrame (); Вызов DoPulsePostFrame() в объекте-менеджере модов (один из модов - deathmatch). Метод в CModManager::DoPulsePostFrame вызывает http://code.google.com/p/mtasa-blue/sou ... er.cpp#289: m_pClientBase->PostFrameExecutionHandler (); В теле CClient::PostFrameExecutionHandler: http://code.google.com/p/mtasa-blue/sou ... nt.cpp#251: g_pClientGame->DoPulsePostFrame (); В CClientGame::DoPulsePostFrame: http://code.google.com/p/mtasa-blue/sou ... me.cpp#736: Тут останавливаемся, и начинаем смотреть в тело этого метода. http://code.google.com/p/mtasa-blue/sou ... me.cpp#925: DoPulses (); Спускаемся ниже в теле уже этого метода. http://code.google.com/p/mtasa-blue/sou ... e.cpp#1121: // Call onClientRender LUA event CLuaArguments Arguments; m_pRootEntity->CallEvent ( "onClientRender", Arguments, false ); И теперь самое занимательное. Это и есть точка вызова события onClientRender в скриптах. А теперь покрутим над этим вызовом и посмотрим внимательно, и над ним находится целая куча вызовов вида m_pUnoccupiedVehicleSync->DoPulse (); m_pPedSync->DoPulse (); #ifdef WITH_OBJECT_SYNC m_pObjectSync->DoPulse (); #endif И тому подобное. А это, если посмотреть внутрь методов соответствующих классов - код обновления положений, состояний и прочего для разнообразных игровых элементов: машин, объектов, и т.п.. Так вот, к чему я это пишу? Из этого кода видно, что вызов onClientRender производится сразу же после обновления мира. И поэтому, если нужно отследить какие-то изменения в игровом мире, нет ничего удобнее, чем поглядеть в вызове onClientRender. И внести свои изменения в него. И не нужно городить убербыстрых таймеров на 50ms, когда можно сделать всё и без них, сразу на месте. Это не будет слишком накладно, если использовать функции (getElementsByType(type = "vehicle", streamedIn = true)) правильно. Плюс, таймеры ненадежны, и могут иметь задержку до выполнения, тогда как какие-то изменения в мир нужно произвести немедленно. И лучше их делать сразу же в этом кадре. Вот так.

Лучше всего сделать это в рендере, а не по таймеру. Потому что до выполнения таймера может гонка состояний произойти, и еще куча всего. И рендер это не только отрисовка, а событие обновления состояний объектов всего игрового мира. Поэтому и ловить новое состояние (попадание в воду) тут удобней всего. addEventHandler("onClientRender", root, function () -- берем списочек машин в зоне видимости и проходимся по нему for k, v in ipairs( getElementsByType( "vehicle", root, true ) ) do -- я отвечаю за состояние машинки в игре? if isElementSyncer( v ) then -- она в воде и еще живая? if isElementInWater( v ) and not isVehicleBlown( v ) then -- ну и умирает пусть тогда blowVehicle( v, false ) end end end end ) syncer тоже очень полезная вещь иногда. Имитировал таким способом умирание машин в воде, как в SA:MPе, когда писал свой мод.

Только не забудьте отрубить античит, потому что будет кикать. Скорость - нет. Стабильность - нет. (особенно, если вы в поточном программировании не разбираетесь) Потоками можно сделать параллельное выполнение инструкций внутри скрипта. Вот тут почитайте: http://www.lua.ru/doc/2.11.html - документация http://wiki.roblox.com/index.php/Beginn ... Coroutines - гайд с примерами

А логи что показывают?

Вот да. И поэтому каждый начинающий скриптер должен написать свой дырявый и кривой метод авторизации, хотя ему уже предложен встроенный, где за скриптера всё продумали заранее. Давайте не переходить на личности. Но вообще, меня встроенная система аккаунтов вполне устраивает. И, если думать по вашему, давайте, пусть они ей так и пользуются, пишут ini-шные скриптовые системы, е**тся с ними и изобретают, вместо пользования встроенной, которая подходит под эти же задачи, но без всяких накладных расходов. Ну или напишут свою говносистему на говноMySQL, и её взломают через неделю, потому что в этой области опыта было ноль, ну или же она будет тормозить, потому что сервер MySQL не настроен или настроен конфигом искаропки. Большой онлайн - это единицы. И они сами знают, что им нужна собственная система, и она уже есть у них. А для среднестатистического сервера? Это какой онлайн должен быть? Сотни заходов в секунду? Вряд ли где-нибудь вообще такое было. Поэтому не нужно сюда лепить еще и MySQL, да еще и с кешированием. Всяким мелким серверам SQLite-а хватит выше головы.

О каких проблемах речь? Проблемы уровня "что-то где-то недосмотрели, не забекапили и всё похерилось"? Не плодите лишних сущностей без особой надобности, господа. Встроенная система аккаунтов вполне самодостаточна. И по надежности она даже лучше окажется, чем самописная.

Что-то встроенное есть для колшейпов через setDebugMode, вроде бы.

Аккаунты на сервере - это легко и просто, вот зачем. И БД готовая, и связать с админ-правами и ACL легко, и функции готовые есть для управления всем этим, и безопасность продумывать не надо. Поэтому и даем. Писать свою систему авторизации с блекджеком и шлюхами - занятие трудоемкое, если делать это сходу. [offtopic] А я создаю. И изолирую их друг от друга. Ну не для игроков, а для серверов всяких. Потому что это мера безопасности, и лучше перебдеть, чем недобдеть (ну а еще лучше - точно знать, где и как ограничивать). [/offtopic]

Мне это не нравится. Что это еще такое и зачем?

Чем отличается от обычной компиляции? Опять велосипед какой-то?

Хорошая попытка развенчания, ага. Но пост какой-то слишком предвзятый, сейчас я по пунктикам распишусь. Текст завлекательный, но ни одно утверждение не подтверждено фактами. Где реальные измерения: времени, скорости, производительности? Их нету. Сравнение Xen и OpenVZ, при этом ни слова про KVM. Повествуется только о плюсах OpenVZ и минусах Xen, о плюсах Xen'а и о минусах OpenVZ'и ни слова. Ни слова и о достоинствах и недостатках KVM как гипервизора. Теперь по отдельным строчкам, которые бросились в глаза, и по которым у меня мнение отличное от мнения автора статьи: Как здесь и сказано, полноценная виртуальная машина позволяет иметь выделенный набор ресурсов хост-машины, который будет закреплен именно за ней и перераспределен между остальными виртуальными машинами не будет и всегда окажется доступен, в любой требуемый момент. В случае виртуализации нет привязки к ОС хост-машины, и можно настроить сервер на любом/любимом дистрибутиве (как сделал себе я - VPS на Arch Linux), и не зависеть от системы хостера вообще. Обновить ядро? Без проблем, обновляйте хоть каждую ночь. В Debian нет новой версии пакета, под которую вы написали сайт? Извиняйте, надо было думать наперед и не брать хостинг на OpenVZ. Namespaces - еще один способ ограничения пользователя, выражается в установке определенных лимитов на действия внутри виртуальной машины. Например, ограничение в 100 записей iptables. Или количество страниц памяти. Или количество открытых сокетов. Весь список можно погуглить по слову "user_beancounters". И в первую очередь хостер, при обращении в поддержку, напомнит вам, что вы, такой подлец, превышаете лимиты! А не будет заниматься решением вашей беды. Под KVM никаких ограничений вам не устроят. Творите что хотите. Для игрового сервера - особенно критично, чтобы была доступна оперативная память по требованию, чтобы можно было держать большое число открытых соединений долгое время. Поэтому виртуализация, однозначно. Да, это действительно так. Вот тут OpenVZ и позволяет нечестно продать простаивающие ресурсы. А под KVM я уверен, что мои такты и мои мегабайты памяти будут доступны мне в любой момент, независимо от загруженности хоста в целом. Ну кто ж так делает вообще. На сервере swap не нужен в принципе. Не хватает памяти - доплатите за больший объем. Или ограничивайте использование её процессами, если не хотите платить. Да даже если и создавать своп, то хорошие хостеры сейчас делают системы на SSD, так что дисковые издержки минимальными будут. Никакого ущерба производительности. А OpenVZ и своп создать не даст, и VZswap далеко не все включают. А чтоб DDoS отбивать, нужно специально настроить сервер на лимит запросов к нему, если слабый. А не искаропки конфиги использовать. А то так что угодно можно положить. Ну и чтоб лимита на iptables entries не было, потому что это самый эффективный способ отражения атак - отбросить или перенаправить пакеты. Вот и делайте себе выводы, насколько этот пост на хабре непредвзятый и не рекламный. Да или сразу берите KVM, потому что на OpenVZ далеко не уедешь, как бы его не хвалили.

Зависит от того, какие характеристики вы хотите получить. В первую очередь узнайте, разрешает ли хостер размещать игровые серверы такого типа. Некоторые запрещают. Смотрите на ширину канала, на её доступность, на количество хопов к серверу и пинг. Тип виртуализации (KVM, OpenVZ) тоже может играть незначительную роль (KVM - лучше, но дороже). Разрядность ОС - тоже. Тип ОС - тоже (выбирайте то, с чем уже можете управиться). Покупка доп. IP-адресов, если нужна тоже. Из хостингов могу предложить Digital Ocean (в подписи) - низкие цены, магистральный канал, SSD диски, серверы в Европе (Амстердам) и США. Там сейчас хостится gtar, могу проверить, как себя ведет сервер MTA на нем, на отдельном vps. Но настройка системы вся ручная, и пинг немного великоват для России (100-114 мс). Из отечественных - fastvps.ru (который, почему-то, для меня дает больший пинг, чем D.O.; территориально - в Германии, лол); firstvds.ru (позволяют ставить даже ventrilo, так что с сервером мта явно пропустят; территориально - в России). Fornex - не рекомендую даже в крайних случаях, просто запомните это имя. А дальше - хостуйте столько серверов, на сколько хватит канала и айпишников и портов. И фтп создадите столько, сколько нужно (с этим даже помочь могу).

Насколько я помню, ресурс perfrofmancebrowser (https://wiki.multitheftauto.com/wiki/Res ... ncebrowser) позволяет проанализировать и потребление памяти, и загрузку канала, и использование процессора. Но не думаю, что много понадобится. Канала в любом случае должно хватить, везде трафик минимум от терабайта дают.

Таким в данный момент увлекаюсь

Заведите отдельный сервер. VPS сейчас достаточно дешевы, и платить не от слотов, а от потре:Oемой памяти будете.

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

outputChatBox("erre"); What is that? Shouldn't it return in the case of error?

Are they perl-compatible? Support for captures?

Не плачь.

Knife Party по сравнению с Pendulum уже кажется не торт. Дабстеп и дабстеп. Утопили музыкальную темку, а жаль. Подниму, что ли. Как вы относитесь к брейкору со странными названиями?

Возможно что самповский vehicles.txd влияет. Возможно что модель такая. Но у mta по части эффектов всё в порядке, они такие же как в одиночной игре, в отличие от sa-mp.

Хотел было зайти и осмотреться, но сервер по адресу из первого поста встретил паролем. Глянув на вк-страницу ничего не нашел, в блоге тоже. К счастью, обратил внимание на чатбокс в бложике. mtasa://77.220.182.197:22003 - это действительно ваш новый адрес? Скорость загрузки с сервера - ужасная. У меня где-то 50Кб/с набирает, максимум, при канале 4МБит/с. Вам бы отдельный сервер под файлы, как уже говорили выше. Сейчас дождусь, пока загрузит, дальше погляжу. Ну ладно, пол-плюсика за Initial D, только потому что я любитель Японии. (хотя самой франшизой Initial D не увлекался) Вот вам идея для следующего сервера: