Исходники Lindvior

[Dеmon]

За исключением сказаного про лыжу
Там как был дримучий лес, так и остался и я уверен, что и останется)

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

[KID]

Gaikotsu
1. мелкий размер частосоздаваемых классов. помогает "от фризов" из-за gc
2. легкое управление пакетной структурой в 1 месте
3. множество заранее указанных переменных, которые будут жить вместе с игроков, а не неимоверное количество, указанное в частосоздаваемых классах, необходимых в течении 1 мгновения. к томуже при повторном обращении к определенному параметру, серверу не нужно будет "вычислять" их заново.

а насчет трат памяти - покажите мне идиота, который будет к примеру для одномоментной рассылки какой-то одинаковой инфы множеству игроков делать для каждого получателя new Packet(...)

рукалицо.
частенько видел использование в цикле игроков, с приминеним на него метода, а в методе отправляется им одинаковый пакет

[hex1r0]

Лучше бы не просыпался:redlol:

класс UserInfoDetails, в нем содержится вся информация необходимая для клиента, все переменные. этот класс создается в конструкторе игрока.
при получении героя или начала рыбалки, обновляются данные в UserInfoDetails, и после чего я делаю sendPacket(new UserInfo(player.uiDetails), а внутри UserInfo
[src=java]protected void writeImpl()
{
PacketWriter.onUserInfo(this, this.uiDetails);
}[/src]

последовательность байтов находится в одном месте, в случае изменения к примеру предметов - изменяется в 1 месте, применяется во всех.

уменьшение размера пакета и хранение последовательности байтов в 1 месте. плюс ко всему используя эти переменные мы избавляем сервер от постоянного расчета тех же самых данных для каждого пакета (которые не поменялись)

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

все бы хорошо но есть одно "но" кстати в текущих сборках оно тоже есть. Называется оно Memory Visibility. Суть проста игрок и диспетчер в отдельных потоках. Пока this.uiDetails меняется, диспетчер может этих изменений не увидеть, а с long и double полями вообще полная жесть...

[Ashe]

Этим и занимаюсь, просто расставляю приоритеты так, что бы клиенты получали полезный профит от моей роботы)))

И это самый правильный подход к разработке продаваемого ПО. Клиенты получают продукт, который удовлетворяет их требованиям, пусть даже в коде одни костыли и велосипеды, они все исправятся в будущих ревизиях, а Вы получите опыт, клиентов и материальные блага для своего существования.

Я например, к этому довольно долго шёл. Мой врождённый перфекционизм постоянно отдалял меня от начала написания кода, я всё думал, думал и совершенствовал ещё не написанный код. Благо, что вовремя осознал свои ошибки и познал дзен. :redlol:

[KID]

все бы хорошо но есть одно "но" кстати в текущих сборках оно тоже есть. Называется оно Memory Visibility. Суть проста игрок и диспетчер в отдельных потоках. Пока this.uiDetails меняется, диспетчер может этих изменений не увидеть, а с long и double полями вообще полная жесть...

в моем случае я использую подобную систему для пакетов без использования интересов для селектора, напрямую пишу в сокет, вероятностью появления мала. по сути даже несущественна, только коллекции будут требовать более внимательного отношения.
ровно с таким же успехом эта Memory Visibility может возникнуть и в конструкторе пакета

[hex1r0]

в моем случае я использую подобную систему для пакетов без использования интересов для селектора, напрямую пишу в сокет, вероятностью появления мала. по сути даже несущественна, только коллекции будут требовать более внимательного отношения.

только если пакет пишется синхронно с потока игрока – такой проблемы не будет.

ровно с таким же успехом эта Memory Visibility может возникнуть и в конструкторе пакета

нет, для этого есть final поля (чтобы руки не чесались :redlol

[Gaikotsu]

в моем случае я использую подобную систему для пакетов без использования интересов для селектора, напрямую пишу в сокет, вероятностью появления мала. по сути даже несущественна, только коллекции будут требовать более внимательного отношения.
ровно с таким же успехом эта Memory Visibility может возникнуть и в конструкторе пакета

только вот имхо вероятность того что к моменту отправки пакета переданный в него объект, из которого будут читаться данные для отправки, уже уничтожен все же будет выше чем в ситуации когда все нужные данные заносятся в промежуточные переменные еще на стадии создания объекта пакета?

ну а об остальном hex1r0 выше написал.

З.Ы. ладно, все равно все эти споры ни к чему не приведут - в любом случае все будут продолжать писать так как им удобней и логичней.

[KID]

нет, для этого есть final поля (чтобы руки не чесались :redlol

final int a;
final int N..;
final int z;


и пока конструктор назначит f, какой-нибудь там z может быть другим

только вот имхо вероятность того что к моменту отправки пакета переданный в него объект, из которого будут читаться данные для отправки, уже уничтожен все же будет выше чем в ситуации когда все нужные данные заносятся в промежуточные переменные еще на стадии создания объекта пакета?

ну а об остальном hex1r0 выше написал.

З.Ы. ладно, все равно все эти споры ни к чему не приведут - в любом случае все будут продолжать писать так как им удобней и логичней.

это вероятность гавнокода, я предлагал идею классов для пакетов, которые не могут быть null.
кстати, зачем цепляться за такое, когда вы не видите очевидные преимущества в том, что я предложил. это абсурд.

вы не посол сообщества, говорите за себя, "все будут продолжать" - слишком сильное заявление

[Gaikotsu]

ну, не сильнее вашего, что ваша идея единственно правильная и все должны придерживаться её, чтобы не писать "говнокод"

[hex1r0]

final int a;
final int N..;
final int z;


и пока конструктор назначит f, какой-нибудь там z может быть другим

Тоже верно если много потоков модифицируют 1 обьект, ну как сейчас в л2 или аионе. Это уже совсем другая тема и твой подход ее тоже не решает.