cHAm ну молодца. Вообще говоря тот кому надо было, тот понял меня =)

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

Еще вопрос - checksum какие-нить проверял?

И еще - замена по словарю - очень слабая защита, добавил бы хотя бы какое-нить матричное преобразование

NETRAT добавил:
Еще - вломы лезть внутрь, т.ч. расскажи пожалуйста сколькими символами кодируешь вещи/левел ну и т.п. - то есть то о чем мы с тобой говорили

NETRAT добавил:
То есть длинна выходного кода

NETRAT, конечно, шифровки взломать можно, но их же все равно делают и, думаю, будут делать.
checksum я здесь одну проверял, а замена по словарю очень неплохо действует. Кому надо, тот как хошь взломает, а кому не надо, тому и так хватит.
Ваще-то из CCS можно и покруче код составить, все дело в твоей фантазии.

Угу, помницца я предлагал кодировать левел, все скиллы, все аттрибуты, весь инвентарь + бонус жизней + ресурсы. И все это 25-30 символов =)

NETRAT добавил:
cHAm так какая длинна кода?

NETRAT добавил:
Вломы в код вникать. Допустим, число 100 и число 1 будут кодироваться строкой одинаковой длинны? Если да - значит добавляешь пустые?! Если нет, то как ты при обратном преобразовании определяешь длинну строки?!

В примере 15 символов. Но можно КОНКРЕТНО ужать, если хошь.

Если юзаешь GetCharCodeWithLength(1,3), то при словаре "0123456789" получаешь "001". Это для удобства.

Я так же предлагал обьединять некоторые группы Int переменных в одну для оптимизации длинны. Так же при кодировании жизней и ресурсов использовать множители - типа жизни с точностью до 25, деньги и дерево с точностью до 10

Темы связаны, поэтому мне хотелось бы оставить здесь линк на ту тему http://xgm.guru/forum/showthread.php?t=1824

NETRAT добавил:
cHAm нет, для примера 15 нормально. Просто если заносить в код больше данных, то придется ужимать. В-общем импрувмент пока не нужен, так что можно оставить и так. Молодец, описуху нормальную сделал - хоть в статьи помещай. Кстати можно что-нить по этой теме из двух тем собрать и одну статейку замутить про загрузочные коды, привести твой пример и перспективные методы оптимизации из моего первого поста. Как тебе идея?

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

В-общем вечерком чего напишу конкретней

Я хочу написать вторую часть статьи. Помещу в нее три главы:
«Шифруем предметы» или «Шестерых одним ударом»
«Безопастность кода» или «Как бородануть читеров»
«Оптимизация по методу NETRAT’a» или «Подать сюда микроскоп!»
Последнюю главу я отдам тебе, NETRAT. В ней напишешь про оптимизацию. Лады?

NETRAT, я тебе лс послал, в нем вторая часть статьи в *.doc. В ней напиши про оптимизацию и перешли обратно мне. Как пришлешь, я поставлю вторую часть.
Насчет начала... Я думаю, что начало и так имеется (называется "Предисловие. Зачем это надо"), но перед 2 статьей я его перепишу, навеное.

Markiz, согласно статистике 80% геймеров вара и знать не знают, что такое WE. А тех, кто сможет взломать такую защиту, очень и очень мало...

cHAm добавил:
Особенно, если карта защищена от редактирования.

Markiz, cHAm какая уж тут защита, если карта запротектена?!

NETRAT добавил:
Аттачи у мя отключены (как у злостного флудера), так что выкладываю здесь
Обязательно включи в своем ворде проверку орфографии - у тебя там такие забавные очепятки встречаются. И еще посоветовал бы так сильно не снижать качество картинок. Получилось даже больше - я добавил еще одну главу.

Глава четвертая «Оптимизация по методу NETRAT’a» или «Подать микроскоп!»
Слово предоставляется NETRAT’у.

Рассмотрим теперь более полную модель - пускай нам нужно сохранить героя в такой карте, в которой могут быть использованы книжки ловкости, силы, жизни - то есть такого героя, которому необходимо сохранять дополнительно атрибуты и очки жизни. Разумеется, ни один нормальный герой не может обойтись без инвентаря - ему будет очень обидно, если супер-пупер меч, который он заработал в бесчисленных схватках ценой своих постоянно ноющих и незаживающих ран и ссадин, не перенесется в другую карту, а попросту будет потерян. То есть добавим так же к этой модели и 6-слотовый инвентарь. Возьмем именно шесть слотов, так как это стандартный размер, следовательно такой инвентарь можно считать самым популярным. Если у вас инвентарь более 6 слотов, то вы можете оформить спецзаказ, обращаясь к авторам данной статьи, либо сделать все по аналогии самому. Разумеется, помимо уровня героя, неплохо бы еще запоминать уровни его скиллов, добавим и этот пункт в модель.

Итак, входные данные:
1. Уровень героя
2. Уровни скиллов
3. Атрибуты
4. Дополнительные очки жизни
5. Инвентарь
6. Ресурсы

Теперь опишем входные данные более подробно. Пределы будем брать для среднестатистической RPG карты - то есть такие, которых хватает хорошей карте.
1. Уровень героя - целое число, находится между 0 и 100.
2. Уровни скиллов - пускай у нашего героя 5 скиллов, но сумма уровней скиллов не может превосходить уровень героя - это при нормальной прокачке - то есть когда за уровень дается одно очко скилла. Разумеется, скиллы могут быть неравнозначными - то есть могут быть ультимейты, которые мы получаем не так уж и часто. Тогда предположим, что уровень каждого из скиллов не может превосходить 30. Тогда рассчитать максимальное число, которое может понадобиться для хранения данных о скиллах нам поможет комбинаторика. Это число равно 30*30*30*30*30 = 3^5 * 10^5 = 243 * 10^5. Это достаточно большое число, поэтому, пока, оставим его в таком виде.
3. Аттрибуты - три аттрибута, каждый из которых не превосходит 500. Использовать значения больше не рекоммендуется, потому что это уже попахивает извращением, в всяком случае карта из рпг может перейти в разряд аркадных. Таким образом все та же комбинаторика дает нам верхний предел числа, которое может однозначно определять все 3 аттрибута как 500*500*500 = 125 * 10^6. Аналогично и это число оставим в таком виде.
4. Дополнительные очки жизни - это очки жизни, которые могут быть получены при помощи томов жизни. Колеблются в пределах от 0 до 20000. Однако эти очки будут
кратны 50 так как том жизни поднимает очки на 50. Значит, мы можем заменить это поле на очки жизни, поделенные на модификатор жизни. В данном случае, модификатор очков жизни равен 50, значит верхний предел для этого поля будет равен 20000/50 = 400. Если вы будете использовать значения больше 20000, то можете увеличить модификатор жизни. Таким образом, мы можем сказать, что значение этого поля колеблется в промежутке между 0 и 400 с модификатором 50.
5. Инвентарь - не думаю, что в своей карте вы будете использовать более, чем 400 вещей. Использовать строковые коды(или соответствующие им численные дескрипторы) для идентификации вещей - это верх расточительства. Обьясняю почему - строковые коды используют для идентификации объекта 4 символа(эквивалентные им числовые дескрипторы являются числами порядка 10) - то есть один слот инвентаря будет кодироваться числами десятого порядка - то есть число будет колебаться от 0 до 10000000000, и это только один слот. Нетрудно посчитать что 6 слотов таким образом будут кодироваться 10^60 числом, и в итоге выйдет, что один только инвентарь кодируется 30 символами. Почему так получается - да потому что игра Warcraft использует универсальную кодировку всех своих объектов - то есть каждый игровой объект - будь то дерево, камень, казармы, грант, олень или маска Соби, имеет свой идентификатор типа, причем этот идентификатор уникален. А поскольку в игре используется огромное количество различных объектов, а еще существует возможность добавления пользовательских объектов, то для идентификации используются числа типа longint с огромным верхним пределом. Нам же нужна не универсальная идентификация, а идентификация только вещей. Для этого необходимо создать базу данных вещей - нечто вроде двух массивов - один массив типа int, а второй - item-type. Первый будет содержать
идентификатор вещи по нашей системе, а второй - по системе игры Warcraft. Это может показаться непосильной задачей, однако база такого типа уже создавалась в наработке DimonT'а "Полноэкранный инвентарь", ее нетрудно адаптировать для наших нужд (разумеется при некоторых навыках жасс-скриптера). Таким образом, весь инвентарь можно закодировать числом, находящимся между 0 и 400^6 = 4096 * 10^12.
6. Ресурсы - тут все достаточно просто. Пусть золото находится в пределах от 0 до 100000, тогда возьмем это поле с модификатором 10, получим предел равным 10000 с модификатором 10. Если у вас предел больше, то модификатор тоже можно взять больше. Дерево аналогично - от 0 до 10000 с модификатором 10. Таким образом золото и дерево мы можем закодировать числом, предел которого равен 10^8.

Теперь посмотрим, какое число у нас получается в итоге:
100 * 243 * 10^5 * 125 * 10^6 * 400 * 4096 * 10^12 * 10^8 = 243 * 125 * 4 * 4096 * 10^34 = 497664000 * 10^34 = 497664 * 10^37
Немаленькое число получается, неправда ли?!
Теперь, возьмем максимально возможный словарь - 90 символов. И возведем это число в 22-юю степень, получим число, равное 90^22 = 984770902183611232881 * 10^22 ] 984770 * 10^37 а, значит большее числа, которое нам нужно чтобы закодировать всю модель. Таким образом получаем, что для кодирования описанной выше модели, нам необходимо всего 22 символа - то есть код может состоять из 22х символов. Однако это нереализуемо. Для того, чтобы получить оптимальный код, нам придется работать с очень большими числами - более чем 40го порядка. Игра Warcraft неспособна на такие манипуляции. Поэтому нам придется уменьшить эти числа и увеличить длину кода.

Словарь 90 символов позволяет нам наиболее оптимально кодировать числа, ограниченные числами, степени 90, то есть:
90 - один символ
8100 - два символа
729000 - три символа
Числа больше брать не рекомендуется, так как они могут оказаться слишком большими для расчетов.

Обьясню теперь, как наиболее оптимально использовать словарь в 90 символов в описанной системе:
1. Для начала, мы можем обьединить два поля - поле уровня и поле дополнительных очков жизни - то есть число, представляющее обьединение этих полей будет колебаться от 0 до 100*400 = 400000, а такое число может быть закодировано по словарю тремя символами.
2. Далее закодируем обьединение поля скилла и поля золота. Оно может колебаться от 0 до 30*10000 = 300000, и, значит, может быть закодировано тремя символами. Такую операцию можно проделать со вторым полем скилла и с количеством ресурсов дерева. То есть еще два обьединения по три символа.
3. Затем обьединим поле скилла с полем вещи из инвентаря. Такое обьединение кодируется числом от 0 до 30*400 = 12000. Обьединим таким образом оставшееся три
поля скиллов и первые три поля вещей инвентаря. Три обьединения, по три символа каждое.
4. Нам остается только обьединить каждую из трех оставшихся вещей, с каждым из трех аттрибутов. Максимальное число, представляющее обьединение будет равно 400*500 = 200000. Три обьединения, каждое по три символа.

Таким образом получаем длинну кода, равную 1*3 + 2*3 + 3*3 + 3*3 = 27 символов. Разумеется, длинна этого кода больше чем длинна оптимального кода, но оптимальный код намного труднее реализовать и генерация такого кода может занять достаточно много процессорного времени, и, значит, вызывать значительные лаги.

Это не самый оптимальный вариант обьединения полей, зато достаточно понятный.

Теперь напомню, чем можно пользоваться для уменьшения длинны кода:
1. Модификаторы - то есть множители для чисел, значения которых могут быть достаточно велики, и небольшие ошибки в этих числах не имеют значения. То есть
если у меня 50037 золота, то если я во время сохранения/загрузки потеряю из них 37 единиц, то я не буду сильно о них жалеть. Зато это уменьшит длинну кода.
2. Обьединения нескольких полей - такой метод не только уменьшает длинну, но и делает код более устойчивым к взлому.
3. Уменьшение максимально допустимого значения поля - это означает, что можно "подгонять" максимумы всех полей под длинну словаря - например, сделать
максимальное число уровней не 100, а 90 и кодировать ее отдельным символом, или максимальное количество ресурсов сделать не 10000 (с модификатором 50), а 8100 (с модификатором 50) и кодировать это число двумя символами.

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

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

Глава пятая «Защита кода по методу NETRAT’a» или «Open Source в студию!»
Пускай у нас есть готовый код - код, который выдается генератором. Так вот предлагаю его перекодировать невырожденным(то есть восстановить оригинальный код вы сможете) преобразованием. Преобразование такого вида - пробегаем все буквы кода, получаем их номер по словарю, добавляем к нему определенное число, находим это число в словаре и вместо взятой буквы, подставляем букву из словаря, соответствующую полученному числу.

Обьясню это все на примере:
Пускай у нас есть словарь - "0WVUYXZRQSTqPONMLponmlKkJjIiHhGgFfEeDdCcBbAa1r2s3t4u5v6w7x8y9z~`!@#$%^&*()-_=+;:[]{},.[]/?" - это словарь по умолчанию из системы cHAm'а. И есть некоторый 8-символьный код "Netrat?!" . Преобразуем его по описанному правилу, с добавлением ключевого числа 21.
Код символа "N" в словаре равен его позиции - то есть 15, добавим к нему число 21, получаем 36, буква с номер 36 из словаря - это "e", далее символ "e" имеет код 36, с добавлением 21 получаем 57, соответственно символ "7", далее, аналогично из символа "t" получаем символ "&", из символа "r" получаем символ "#", из символа "a" получаем символ "!", из символа "t" мы уже получали "&", далее для символа "?" код по словарю равен 90, при добавлении 21 получаем 111, в этом случае число превосходит размер словаря и предлагаю просто поделить на 90 (длину словаря) по модулю - то есть взять остаток от деления на 90, а он будет равен 21 и полученный символ будет "m", для символа "!" получаем символ ".". Тогда исходный код будет кодироваться строкой "e7&#!&m.". Это все достаточно просто реализуется и достаточно эффективно защищает от взлома. Для обратного преобразования достаточно будет отнять ключевое число от каждого из символов, а если получится отрицательное число, то добавить длину словаря - в данном случае это 90. Для более извращенного кодирования, предлагается добавлять к числу кодирования(то есть к 21) еще и номер позиции символа в коде, тогда код получится еще более безопасным - то есть вот таким "D8)&^=iU". Если вам нужно ввести в код защиту от использования кода другим игроком, предлагаю вместо ключевого числа вводить код буквы ника - либо всегда одной(скажем первой), либо по очередности.

Однако описанные методы могут раскрываться то есть взламываться открытием j файла карты. Для того чтобы еще сильнее обезопасить код от взлома, предлагаю вместо(или вместе) с ключевым числом ввести какой-нибудь атрибут статического объекта на карте, например угол поворота одного из зданий на карте, или одну из его координат, или положение на карте какого-нибудь специфического дерева. Человеку, вскрывшему j файл будет непонятно что это за атрибут и какой единице он соответствует. Даже если он вскроет карту и получит слой дудадов и единиц, то ему придется найти соответствие между объектом на карте и файлом скрипта, а это, если и возможно, то достаточно трудно.

Обращаю ваше внимание, что вышеописанные методы защиты кода от взлома не увеличивают размер самого кода, то есть просто трансформируют код, без увеличения его длинны. Именно поэтому они так удобны.

cHAm како тебе последняя часть?

cHAm я в универе, пеши в приват или флудильню

Вобщем, просмотрел я твою статью, NETRAT. Щас еще напишу, как это применять в карте-примере и завтра выложу готовую статью.