Отличия версий l2phx

[cmdprompt]

В версии phx 3.4 конструкция вида if pck[1]=#3 работала нормально, но в 3.35.33.172 переменная pck как будто не массив, и обращаться к байтам по индеску не получается. Работает только ReadC(1), поэтому конструкция вида case pck[1] of превратилась в case ReadC(1) of и от этого изменилось вот что, если пакет состоит только из 1 байта, то ReadC(1) возвращает 0 или каке-то неверное значение, поэтому этой с помощю этой функции нельзя работать с такими пакетами. Приходится добавлять в оператор выбора действие по умолчанию, например else if pck=#9 then. Странно, что такое сравнение работает, в отличии от if pck[1]=#9 например.

Простое case pck[1] of превратилось в сложное
case ReadC(1) of // для многобайтных пакетов
1:...
2:...
else case pck of // для однобайтных пакетов
#3:..
#4:..
end;
end;


Но это не основное неудобство, самые костыли получаются тогда, когда надо изменить входящий пакет перед отправкой, если раньше можно было например изменить байт пакета так pck[2]:=#0;, то теперь это превращается в такой велосипед: buf:=pck; pck:=''; WriteC(0,2); SendToServer; ужас. :confused:

Подскажите, кто сталкивался с такой проблемой, это особенность только моей версии 3.5.33.172 или всех 3.5?

[J-Fobos]

Переменная pck имеет тип string. Конструкция pck[n] должна работать.
Но не работает, это баг программы. Который устранили. Неужели опять всплыл? На последней версии проверяли?

[cmdprompt]

Не пробовал последнюю, так как пропатчил 3.35.33.172 через лаунчер (ехе править нельзя, защита :)), дабы разгрузить процессор. Уменьшил макс. длину пакета до 16кб (длиннее пакетов никогда не втречал), удалил в нескольких местах вызов процедуры FillMemory - она вызывается раз 10 при приходе каждого(!) пакета. В итоге при большой нагрузке проц стал в 2 раза меньше напрягаться.

А вообще разработчикам напишу то, что я увидел в IDA disassembler. Вы передаёте пакет не по ссылке, а по значению, даже тогда, когда функция изменяет пакет :confused:. При приходе пакета вызываются около 4х вложенных функций, и каждый раз пакет копируется из одного буфера в другой, предварительно выделив под него место в стеке, и копируется не столько байт, сколько занимает пакет, а всегда весь буфер 64кб(!) что ОЧЕНЬ напрягает процессор, особенно старые одноядерные. Пропатчил прогу потому, что в тот момент, когда у меня был слабый комп, не были доступны исходники.

[kpa9pt]

Не пробовал последнюю, так как пропатчил 3.35.33.172 через лаунчер (ехе править нельзя, защита :)), дабы разгрузить процессор. Уменьшил макс. длину пакета до 16кб (длиннее пакетов никогда не втречал), удалил в нескольких местах вызов процедуры FillMemory - она вызывается раз 10 при приходе каждого(!) пакета. В итоге при большой нагрузке проц стал в 2 раза меньше напрягаться.

А вообще разработчикам напишу то, что я увидел в IDA disassembler. Вы передаёте пакет не по ссылке, а по значению, даже тогда, когда функция изменяет пакет :confused:. При приходе пакета вызываются около 4х вложенных функций, и каждый раз пакет копируется из одного буфера в другой, предварительно выделив под него место в стеке, и копируется не столько байт, сколько занимает пакет, а всегда весь буфер 64кб(!) что ОЧЕНЬ напрягает процессор, особенно старые одноядерные. Пропатчил прогу потому, что в тот момент, когда у меня был слабый комп, не были доступны исходники.

Не совсем по теме скажу но вот у меня целерон старый одноядерный(не вкурсе есть ли 2х ядерные). Ужасно тормозит при сильной нагрузке в игре. А на i5 у друга всё отлично( 0 лагов.