Balancer: Все сообщения за 17 Августа 2005 года

zabbix:

ок, а если сделать пул свободных идентификаторов?

 

Так было в самом первом варианте ID Factory. Как только сервер становился более-менее популярным, сбор стартовых данных о пуле занимал до получаса Плюс такая система жрёт очень много памяти - каждую дырку в адресах помнить нужно.

>Ну если внутриигровые генерить по порядку, а в базе использовать нормальные свои, тогда можно

Да, я так и предлагаю

>что то вроде геодаты планируется ?

Геодата на основе сбора перемещений игроков, которую я задумывал ещё в начале года, мне очень не нравится. Ну да её и без меня уже почти доделали Геодату нужно делать на основе клиентских данных. Но это нужен упёртый товарищ, который разберёт формат

>Дайте мне готовую пхп страницу для отображения колличества игроков он-лине и топа

Я же писал - поищи на форуме. Я пару раз давал код.

>А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что это не вариант...

Чем не вариант? Даже обычного INT'а хватит на несколько лет, а в случае чего, переиндексация займёт считанные секунды и без сбоев в общей БД. Считать просто в новую таблицу и всё

>Ты считаешь, что текстовые поля будут лучше???

С точки зрения скорости выборки в mysql - пофиг. И все принадлежности, типа id игроков или кланов безусловно лучше делать текстовыми, именными. Очень упростится ручная работа с БД

>вопрос какой способ генерации IDшников выбрать для базы

Тут велосипед изобретать не нужно. Автоинкремент и всё

>Как используются идентификаторы пользователей. Это что что-бы получить пользователя, идет обращение к ID в базе. А затем по этому ID ищится ник и работа по никам производится?

Работа по никам не ведётся вообще. Ники используются только для отображения и, редко, для всяких админских фич, типа //target {имя}. Каждый игрок в памяти сервера хранится своим игровым идентификатором. Все операции с ним делаются по идентификатору.

>Как не крути, а по ID доступ в разы быстрее если по этому полю построен индекс.

По ID доступ быстрее в разЫ если НЕ построен индекс Индекс создаёт хеш как для числовых, так и для строковых данных. Так что время выборки практически не различается (на строках есть мелкие штрафы, типа конфликтов хешей и т.п., но это капля в море).

>Заблуждаешся. Медленее. На маленьких базах этого не будет заметно. Но когда записей много тогда это очень заметно.

Объём базы в 600 тыс. записей - достаточен для тестов? Это у меня на основном форуме. Разница, повторюсь, не наблюдается. А на l2j-сервере, дай Бог, 1/10 этого количества записей. Впрочем, даже если бы выборка строковых данных была бы на пару порядков тормознее, роли бы это не сыграло, т.к. лишние полсекунды ожидания при логине погоды не сделали бы. Так же разница будет измеряться тысячными долями

>А как тогда обращаться к мобам или каким-то вещам в квестах?

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

>Бардак с ID потому что надо делать ID Auto Increment. Тогда будет все ок.

Проблема в том, что при таком подходе ID кончатся очень быстро (32 бита со знАком), а переиндексация их занимает дофига времени. Особенно, если долго её не делаешь. Кроме того, при переиндексации, например, теряется возможность отслеживать судьбу той или иной вещи (в нынешнем варианте это невозможно, в варианте с фиксированными ID можно будет вести такие логи, для решения множественных игровых споров такого рода).

>В этом я сомневаюсь. Все равно придется. Например после удаления пользователя.

Это не сжатие идентификаторов

>Пользователи и админы вообще не должны лазать в базу что-бы произвести какие-то манипуляции. Все эти манипуляции должны делаться через интерфейсы в игре либо WEB интерфейсы.

Прекрасно, но ты такой интерфейс сделаешь? Тогда вопрос отпадёт. Пока же все задачи приходится решать через phpMyAdmin или из консоли

>Те ID что у нас в базе и те что используются в самой игре разные?

В текущей реализации - нет. И из-за этого и возник этот топик

>А насчет хеша - честно говоря насколько я знаю, это зависит от реализации. на MS SQL насколько я знаю делается по все строке

В MySQL можно явно указывать по скольки символам строки строить хеш. По умолчанию - строится на всю строку.

•  инфо
•  инструменты
• Ответить на сообщение

Anya:

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

 

Таких ГМов назначить могу. Но и требования я уже опубликовывал
1. Общая культура общения
2. Несостояние в любых кланах (т.к. ГМ может обеспечить преимущества для своих)

Буде таковые кандидатуры найдутся - я не против их ГМства.

•  инфо
•  инструменты
• Ответить на сообщение

Если будет интерес, а сам не разберёшься, могу сделать платного гейткипера в любые координаты, заданные координатами по карте. И за сумму, например, прямо зависящую от дистанции переброски

•  инфо
•  инструменты
• Ответить на сообщение

ГМ может давать клану много преимуществ и кроме гейткипера Просто не буду тут всё указывать

Kamilla "вступила в клан" для проверки падучести варехауза

Вещи гарантированно перестанут пропадать после отказа от "сжатия" идентификаторов в БД. Постараюсь сделать этот механизм побыстрее. Впрочем, шансы на их пропажу и сейчас невелики. Если за ~8 месяцев игры пропало только 455 вещей (всего сейчас в БД около 60 тыс. вещей).

•  инфо
•  инструменты
• Ответить на сообщение