Не большой баг с заточкой

[#r00t]

Заметил интересную особенность заточки на сервере (l2server.com.ua).

Суть заключается в: Ловим 2 пакета когда точимся (например точим пуху)
Пример: (точка ик лука)
19 A2 D3 17 10 00 00 00 00 (UseItem)
5F 72 7E 1A 10 00 00 00 00 (RequestEnchantItem)


Подходим к банку, открываем окно передачи вещей в банк и точим пуху пакетами) шанс значительно повышается, до 7-8 точится сразу без проблем.

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

З.Ы. кстать на этом сервере есть ещё особенность, при старте на персонажа даётся 150кк адены, но не на первого созданного персонажа, а каждому на акке)
З.Ы.Ы. долго думал куда кинуть толи в паблик толи сюда)

[6a4a]

Баги с заточкой были двух типов: либо заточки не пропадают после их использования, либо пушка не ломается после неудачной заточки. Это две глобальные разновидности БАГОВ на заточку. Повышение шанса на заточку, как сейчас принято говорить, это - танцы с бубном. Ну не повысишь ты шанс энчанта никак! Процедура энчанта никак не зависит, что сейчас твой персонаж делает, одето-ли оружие, где твой персонаж находится и т.п. Скажем, после отправки пакета на RequestEnchantItem и после проверок l2serv'ом и Cachedом ( есть ли заточка, есть ли пушка и т.п.) вызывается процедура Enchant (это образно). На примере паскаля, она выглядит так:

Цитата: function Enchant:boolean; begin randomize; i:=random (99); if i<=59 then // здесь 59- шанс заточки 60% enchant:=true else enchant:=false; end;

Это простейший вариант проверки, заточится или нет. Как видим, тут все зависит ТОЛЬКО от выражения I:=random(99), где переменной I присваевается произвольное значение от 0 до 99. То есть может быть 100 разных значений, и шанс, что значение будет от 0 до 59 - как раз и равен 60%

[#r00t]

Ну я заметил такую особенность точки на этом сервере. Я понимаю что это танцы с бубном, но шанс точки у меня повысился...

[Razzor]

Так-же думаю что рендом Бача описал всё правильно, процент нельзя поменять - если конечно не залезть в конфиг. По другому обойти/обмануть значения нельзя.

Более хард-уязвимостей в данном сервере никто не замечал ? ) Сервер на сборкей l2jserver от укр. разработчиков (так сказать украинское подразделение). Фиксы дюпов, не точностей, уязвимостей которые правят в данной сборке, потом расходятся на 10-ки проектов и серверов. Так что найдя уязвимость в данном сервере, можно не плохо "оторваться"
Инфа конечно не точная, но по логике - это так.

[6a4a]

Цитата: Сообщение от Razzor [COLOR="Cyan"]Так-же думаю что рендом Бача описал всё правильно, процент нельзя поменять - если конечно не залезть в конфиг. По другому обойти/обмануть значения нельзя. COLOR]

Можно я немного пофлужу? Теоретически, функция рендома предсказуема. Даже нет, не предсказуема, а математически-вычисляема. На примере делфи под винду, функция рендом выглядит так

i:=random(99)

В этом выражении переменной I присваевается псевдо-случайное число в диапозоне от 0 до 99, то есть 100 различных значений. Почему псевдо-случайных? Да потому что вычислительная машина не может сгенерировать "по-настоящему" случайное число, как это может, к примеру, человек (а че? взял, и ляпнул от балды число 8, или 54, да?). Вычислительная машина строго следует инструкциям, и что бы сделать генерацию случайных чисел, пришлось воспользоваться системным временем (Windows). Определяя системное время Windows, процедура random генерирует псевдо-случайное число, производя математические операции с системным временем. На примере делфи функция рендома выглядит так:

procedure       _RandInt;
asm
{     ->EAX     Range   }
{     <-EAX     Result  }
        PUSH    EBX
{$IFDEF PIC}
        PUSH    EAX
        CALL    GetGOT
        MOV     EBX,EAX
        POP     EAX
        MOV     ECX,[EBX].OFFSET RandSeed
        IMUL    EDX,[ECX],08088405H
        INC     EDX
        MOV     [ECX],EDX
{$ELSE}
        XOR     EBX, EBX
        IMUL    EDX,[EBX].RandSeed,08088405H
        INC     EDX
        MOV     [EBX].RandSeed,EDX
{$ENDIF}
        MUL     EDX
        MOV     EAX,EDX
        POP     EBX
end;

Здесь мы видим, что генериуемое число будет НАПРЯМУЮ зависить, от переменной RandSeed и от предела генерируемых чисел. Более того, следующий вызов функции random будет зависить от ПРЕДЫДУЩЕГО значения, возвращенного функцией рэндом. Если дальше лезть в исходники, мы найдем процедуру randomize. Именно она отвечает за подготовку к функции random. а что она делает? А вот что:

procedure       Randomize;
{$IFDEF LINUX}
begin
  RandSeed := _time(nil);
end;
{$ENDIF}
{$IFDEF MSWINDOWS}
var
  Counter: Int64;
begin
  if QueryPerformanceCounter(Counter) then
    RandSeed := Counter
  else
    RandSeed := GetTickCount;
end;
{$ENDIF}

Видим, что для Винды переменной RandSeed присваевается системное время (GetTickCount). Это время начинает свой отчет с момента запуска винды, и непрерывно растет. Фактически, GetTickCount возвращает время, которое винда запущена. Тем самым, вызывая процедуру randomize перед каждым запуском функции random, мы обеспечиваем одновременно и случайную генерацию чисел, и ПСЕВДО-случайную, напрямую зависящую от текущего времени.
К примеру, если самому задать значение переменной RandSeed, то мы ВСЕГДА будем получать одну и ту же последовательность псевдо-случайных чисел. Вот так:

procedure TForm1.Button1Click(Sender: TObject);
var
  a: integer;
begin
  RandSeed:=1;
  a:=random(500);
  Label1.Caption:=InttoStr(a);
  a:=random(500);
  Label2.Caption:=InttoStr(a);
end;

Сколько не запускай эту программу, она всегда будет генерировать одни и те-же числа - 15 и 430.
а если изменить диапозон генерируемых чисел с 500 на 50 (a:=random(50)), то мы всегда будем получать два значения - 1 и 43. Похожи числа? Хорошо, изменим RandSeed:=1 на RandSeed:=2 (то есть основой для генерации случайных чисел будет число 2). При диапозоне генерации случайных чисел 500 (a:=random(500)) мы будем получать два значения 31 и 345. Изменим диапозон с 500 на 50 (a:=random(50)). И будем получать числа 3 и 34. Есть закономерность?
В функции энчанта на сервере линейки немного проще, там диапозон генерируемых чисел равен 100 (ну, или 1000, для более уверенного шанса заточки; лично я бы так и сделал). Так что если в функцие энчанта перед каждой заточкой будет использоваться процедура Randomize, то успех заточки будет НАПРЯМУЮ зависить от системного времени (то есть, сколько времени система работает).
Блин, че за бред я несу? А, так вот, я хотел показать, что влияет на шанс заточки

[HellFire]

Цитата: Сообщение от 6a4a Можно я немного пофлужу?

ничего себе пофлудил^^, ты корейский рендом на 80% разгадал ^^