Поиск сообщества

Добрый вечер господа. Как изменить текст этой строчки, сорцы проковырял, не нашел. Нашел информацию про msg, но тоже что то глухо.

[src] Запоминаем значение @autoloot Хотелось бы дать пояснение для всех, кто начнёт разводить холивар, что мод не мой. Своё авторство доказывать даже не думаю, т.к. не смогу, мод писался несколько лет назад (3 года назад, если быть точным), но из-за смерти eA все мои моды на форуме были потёрты, но мод после оживления форума начал появляться в английской ветке форума без указания авторства (да и нужно ли оно? Пользуйтесь!). Описание Элементарное и изящное решение для запоминания значения указанного при использовании команды autoloot. Установка Править нужно два файла. Первым правим src/map/atcommand.с, находим функцию команды: ACMD_FUNC(autoloot) В конце функции после: clif_displaymessage(fd, msg_txt(1188)); // Autoloot is now off. Добавляем: pc_setglobalreg(sd, add_str("char_autoloot"), sd->state.autoloot); Теперь правим второй файл src/map/pc.с, находим: void pc_reg_received(struct map_session_data *sd) { uint8 i; sd->vars_ok = true; Добавляем после: sd->state.autoloot = pc_readglobalreg(sd, add_str("char_autoloot")); Всё, пользуемся на здоровье. Принцип работы Принцип работы очень прост, при использовании команды autoloot значение заносится в глобальные переменные персонажа (текстовый файл или база SQL — как у вас настроен сервер). Для этого используется переменная char_autoloot, впринципе, вы можете получить к ней доступ из ваших скриптов: mes "Значение команды @autoloot персонажа: ^3355FF"+char_autoloot+"^000000"; Практической пользы в скриптах в этом нет, но если интересно, то можно запрещать использование команды игрокам и создавать NPC с обработкой установки значения команды (но зачем?).

[sRC] Демонические монстры Все играли в Diablo 2 надеюсь... История изменений 2015.09.4: - Обновлено для версии сервера 2015.08.10: исправления, улучшения - Переработан баланс награды, опыта и усилений монстров - Исправлены критические ошибки, которые могли вызывать вылет клиента 2013.02.21: - Значительно усилены и доработаны параметры демонического монстра - Улучшены и доработаны вознаграждения по опыту и предметам Описание Демонические монстры — это обычные монстры, но усиленные и озлобленные на игрока. На карте они генерятся из уже существующих с выбранным вами шансом (настраивается скриптами). За их убийство вы получаете больше опыта и шанс выпадения предметов из них значительно выше. Скриншот Установка В src править придётся несколько файлов. Начнём с src/map/mob.h, находим: unsigned int size : 2; Добавляем перед: unsigned int demonic; /* NeoTemple Extra Demonic Mob */ Это дополнительный статус отвечающий то, что монстр Демонический (на самом деле в этой переменной мы будем хранить разницу между оригинальным уровнем моба и демоническим). Теперь правим src/map/mob.c #include "map.h" Добавляем перед: #include "mapreg.h" Находим: if (data->state.ai) md->special_state.ai = data->state.ai; Добавляем перед (на самом деле это необязательно, но всегда обнуляйте переменные!): md->special_state.demonic = 0; Дальше находим: if(md->db->option) // Added for carts, falcons and pecos for cloned monsters. [Valaris] md->sc.option = md->db->option; Добавляем после: /* NeoTemple Extra Demonic Mob */ md->special_state.demonic = 0; // It's not Demonic now if( !(md->status.mode&MD_BOSS || md->status.mode&MD_PLANT || md->status.mode&MD_NODEMONIC || md->mob_id == MOBID_EMPERIUM || mob_is_battleground(md)) ) { int min_mob_level = mapreg_readreg( add_str("$demonicminlevel") ); if( md->level >= min_mob_level ) { int chance_rate = mapreg_readreg( add_str("$demonicrate") ); if( rnd()%10000 <= chance_rate ) { int list_num, demonic_match = 0, max_tick = -1; // tick = -1 is infinity tick // Проверяем режим карты и запрещённых/разрешённых мобов // 1 - только указанные в списке мобы могут стать демоническими // 0 - указанные в списке мобы не могут быть демоническими // Примечание: // Проверка этого списка явно тяжелее чем прогрузка параметров и вычисление шанса, // поэтому делаем эту проверку уже в самом конце for( list_num = 0; list_num < MAX_MAP_LIST; list_num++ ) { if( !map[md->bl.m].demonic_mobid[list_num] ) { break; // Всегда считаем 0 окончанием списка (накосячили с прописыванием списка мобов - ваши проблемы!) } if( md->mob_id == map[md->bl.m].demonic_mobid[list_num] ) { demonic_match = 1; break; // Достаточно одного совпадения в любом случае } } if( (map[md->bl.m].flag.demonicdisabled && demonic_match) || (!map[md->bl.m].flag.demonicdisabled && !demonic_match) ) { md->special_state.demonic = 10+5*(rnd()%9); // Храним не то, что моб Демонический, а его разницу в уровне с оригиналом // Пригодится при расчёте шанса выпадения md->level += md->special_state.demonic; status_calc_mob(md, SCO_NONE); // Update mob data status_percent_heal(&md->bl, 100, 0); // Heal 100% md->level = md->db->lv + (md->special_state.demonic/5); md->status.flee = (short) (md->db->status.flee+(md->status.flee-md->db->status.flee)/2); sc_start(&md->bl, &md->bl, SC_ASPDPOTION2, 100, 9, max_tick); sc_start(&md->bl, &md->bl, SC_SPEEDUP1, 100, 8, max_tick); sc_start(&md->bl, &md->bl, SC_ENDURE, 100, 8, max_tick); sc_start4(&md->bl, &md->bl, SC_MODECHANGE, 100, 1, 0, MD_AGGRESSIVE|MD_ANGRY, 0, -1); // Anyway create aggressive and angry mob md->status.hit += (short) (md->special_state.demonic/1.5); md->status.rhw.atk = md->status.rhw.atk*(125+md->special_state.demonic)/100; md->status.rhw.atk2 = md->status.rhw.atk*(125+md->special_state.demonic)/100; } } // rnd()%10000 } // md->level } // if( !(md->status.mode&MD_BOSS /* --------------- */ Это основной процесс создания Демонического монстра. Тут всё немного сложно, но если вкратце, то для начала мы проверяем некоторые состояния моба. Если это растение или Босс, то он никогда не станет Демоническим (хотя агрессивная трава это было бы весело), так же не может быть Империум (это моб, кстати, тут ещё было бы неплохо сделать проверку на сокровищницу и стражников), ещё на BG так же не может быть Демонических мобов. Остальные проверки касаются дополнительных настроек — о них чуть позже. Сам Демонический монстр — это более прокаченная версия обычного, достигается это засчёт повышения его уровня, у меня сделано повышение кратное 5, минимально уровень выше на 10, максимально на 50. Затем пропорционально уровню повышаются статы (Agi, Dex, Str, Vit, Luk). Отображаемый уровень монстра мы увеличиваем максимум на 10 уровней (каждый 5 уровней разницы всего на 1 уровень отображения). Это необходимо, чтобы монстр был в механике Renewal'а по вычислению опыта. В самом конце моб делается агрессивным и злобным, на него накладывается некоторые статы для усиления - ENDURE, увеличение ASPD и увеличение скорости передвижения. Так же увеличиваем HIT монстра и его базовые ATK и ATK2. Теперь Демонический монстр действительно получился сильным. Продолжаем, находим: if (drop_rate <= 0) { if (battle_config.drop_rate0item) continue; drop_rate = 1; } Добавляем после: /* NeoTemple Extra Demonic Mob */ if( md->special_state.demonic && drop_rate <= 2500 ) { double rate = drop_rate; double adjust_rate = (log(md->special_state.demonic)*100)/2; rate = rate * pow((5.0 - log10(rate)), (log(adjust_rate/100.) / log(5.0))) + 0.5; drop_rate = (unsigned int)cap_value(rate, 0, 7500); } /* ------------------ */ Это процесс вычисления нового шанса выпадения предметов, он использует код логарифмических рейтов. Шанс выпадения не может быть выше 75%. В расчёт берутся только предметы чей шанс выпадения ниже 25%. Повышающие рейты вычисляются относительно разницы уровня оригинального монстра и демонического. Чем ниже шанс выпадения предмета, тем выше его новые рейты на выпадение. Улучшаем по опыту, находим: if(battle_config.mobs_level_up && md->level > md->db->lv) // [Valaris] bonus += (md->level-md->db->lv)*battle_config.mobs_level_up_exp_rate; Заменяем на: // NeoTemple Extra Demonic Mob if( md->special_state.demonic ) { bonus += (int)(25.*log(md->special_state.demonic)); } else { if(battle_config.mobs_level_up && md->level > md->db->lv) // [Valaris] bonus += (md->level-md->db->lv)*battle_config.mobs_level_up_exp_rate; } Теперь за демонических монстров будет действительно приятное вознаграждение. Кол-во опыта так же вычисляется логарифмически. Идём дальше в src/map/status.h, находим: MD_NOCAST_SKILL = 0x800000, Добавляем после: MD_NODEMONIC = 0x40000000, // NeoTemple Extra Demonic Mob Это особый режим монстра, который можно прописывать в db/re/mob_db.txt указывая в поле Mode, к примеру, вот так выглядит запись Poring'а: 1002,PORING,Poring,Poring,1,60,1,27,20,1,8,9,2,5,6,1,1,0,6,5,10,12,1,3,21,0x83,400,1872,672,480,0,0,0,0,0,0,0,909,7000,1202,100,938,400,512,1000,713,1500,512,150,619,20,0,0,0,0,4001,1 Если указать этот режим, то моб никогда не будет Демоническим. Пример Poring'а после модификации: 1002,PORING,Poring,Poring,1,60,1,27,20,1,8,9,2,5,6,1,1,0,6,5,10,12,1,3,21,0x40000083,400,1872,672,480,0,0,0,0,0,0,0,909,7000,1202,100,938,400,512,1000,713,1500,512,150,619,20,0,0,0,0,4001,1 Учтите, что этот участок исходников может отличаться в разных версиях, будьте внимательны или выбирайте флаг Демонических монстров максимально большим. Теперь правим src/map/map.h, находим: struct map_flag { Добавляем перед: int demonic_mobid[MAX_MAP_LIST]; // NeoTemple Extra Demonic Mob Добавляем после: unsigned demonicdisabled : 1; // NeoTemple Extra Demonic Mob Находим тут же: #define MAX_MAP_SIZE 512*512 // Wasn't there something like this already? Can't find it.. [Shinryo] Добавляем после: #define MAX_MAP_LIST 32 Ещё правим src/map/npc.c, находим: else if (!strcmpi(w3,"autotrade")) Добавляем перед: // ----------- NeoTemple Extra Demonic Mob else if (!strcmpi(w3,"demonicdisabled")) { char *demonic_param = NULL; int demonic_mobid_restriction = 0, demonic_count = 0, demonic_type = 1; // demonic_type: 1 - allow only mob id in list, 0 - deny mob id in list // Always default 1, because is type set to "allow only" mode // First read allow/deny, or may be it's short type of mapflag? demonic_param = strtok(w4, " ,.-"); if( demonic_param != NULL ) { if( !strcmpi(demonic_param, "deny") ) { demonic_type = 0; // Deny mode } do { demonic_param = strtok(NULL, " ,.-"); if( demonic_param == NULL ) { break; // Read last param } demonic_mobid_restriction = atoi(demonic_param); // No need to check this mob id, if it numeric(?!) - it's always correct map[m].demonic_mobid[demonic_count] = demonic_mobid_restriction; demonic_count++; } while( 1 ); } // if demonic_param != NULL map[m].flag.demonicdisabled = demonic_type; // at last set mapflag } // if strcmpi demonicdisabled // ----------- End of NeoTemple Extra Demonic Mob Данный кусок создаёт дополнительный mapflag, который указывает на каких картах не могут появляться демонические монстры. Пример: prt_fild08 mapflag demonicdisabled Можно так же указывать списки разрешённых и запрещённых мобов для появления, пример: prt_fild08 mapflag demonicdisabled deny,1002 На карте prt_fild08 моб с id 1002 (Поринг) не может стать Демоническим, или можно вот так: prt_fild08 mapflag demonicdisabled allow,1002 В таком случае только моб с id 1002 (Поринг) может стать Демоническим. В списках через ","(запятую) можно указывать несколько мобов, максимум можно указать 32 id моба (?! мало будет добавите в MAX_MAP_LIST, но знайте - вы упоролись) Необходимо ещё исправить src/map/map.c, находим: memset(map[i].drop_list, 0, sizeof(map[i].drop_list)); // pvp nightmare drop list Добавляем после: memset(map[i].demonic_mobid, 0, sizeof(map[i].demonic_mobid)); // NeoTemple Extra Demonic Mob Теперь очень важное исправление src/map/status.c, находим: if (battle_config.mobs_level_up && md->level > md->db->lv) И заменяем на: if ( (battle_config.mobs_level_up && md->level > md->db->lv) || md->special_state.demonic) /* NeoTemple Extra Demonic Mob */ Это исправление необходимо для создания усиленных версий, то есть Демонических монстров с повышенными значениями статов. Итак, тут мы закончили, следующие исправления несут только декоративный характер, к тому же незначительно нагружают интернет канал. Если вы считаете, что декор вам не нужен или у вас сильно ограничен канал(?!), то пропустите следующие исправления. Работаем с src/map/cliff.c, находим: if(md->special_state.size==SZ_BIG) // tiny/big mobs[Valaris] clif_specialeffect(&md->bl,423,AREA); Добавляем перед: /* NeoTemple Extra Mobs - Demonic */ if( md->special_state.demonic ) { clif_specialeffect(&md->bl, 680, AREA); } /* --------------- */ Данную процедуру выполяем 2 раза (ДВА РАЗА), то есть вносим два испрваления(!!!) — два раза поиск и два раза вставка. Там же находим: if(md->special_state.size==SZ_BIG) // tiny/big mobs[Valaris] clif_specialeffect_single(bl,423,sd->fd); И добавляем перед: if( md->special_state.demonic ) { clif_specialeffect_single(&md->bl, 680, sd->fd); } Данный фикс добавит красивую зелёную ауру у Демонических монстров. Теперь, для того, чтобы исправление начало полноценно работать нам нужно сделать скрипт, который будет устанавливать некоторые параметры работы фикса. Вот самый простой скрипт: - script DemonicMob -1,{ OnInit: set $demonicrate, 5000; set $demonicminlevel, 1; end; } Этот скрипт просто устанавливает параметры по которым будут создаваться Демонические монстры. — $demonicrate - шанс появления монстров (10000 - 100%) — $demonicminlevel - какой минимальный уровень мобов необходим для появления Демонического монстра (если уровень моба ниже указанного, то он никогда не станет Демоническим) В своих скриптах вы можете делать интересные ивенты или в ночное время увеличивать шанс появления подобных монстров. Вы так же можете сами указывать различные параметры Демонических монстров внося исправления в src. У меня сделано, что монстры могут быть выше от 10 до 50 уровней, но это число можно менять, учтите, что монстры достаточно сильными становятся при повышении уровня. todo (Что нужно сделать) — Сделать в mapflag указание рейтов появления Демонического монстра: mapflag demonicdisabled <type>,<rate>,<...> — Сделать кеширование считывания глобальных переменных ($demonicrate и $demonicminlevel) для уменьшения нагрузки — Сделать модфикс в виде .patch файлика Описание для старой версии rA.

Суть проста: данная модификация позволит гильдиям иметь свои собственные локации (Guild locations или гильдлоки). Это наипростейшая версия мода. Возможно, у него будет развитие. Пока что это просто перемещение на локацию, доступную для гильдии. Состав: некоторые @команды + скриптовые команды + SQL запрос. Описание скриптовых команд: @команды:

и так я пробежался по форуму нашёл кое какие данные, но тут смотрелся вопрос только в бинарниках, я столкнулся с проблемой у меня визуал 2010 скачал сорс код неона и вот позлезли какашки.... мне ещё понравилась тема мистера функтора по поводу неонкубе бундле... но что то кажись ссылка давно битая... мож у кого на форуме осталась такая версия... перезалейте буду благодарен собственно о какашках-) тут кажисть как и с еА и рА что-то надо ковырять конфигах... не поделитесь инфой на русском сам патчер отличный в отличии от тора сорс качал с джита https://codeload.git...cube/zip/master многие начнут ругать или возмущаться зачем мне мол это надо? скачай просто готовую версию экзешника... отвечу так...я занялся этим только по одному поводу, сменить иконку...конечно мог воспользоваться прогой рес едит или рес хакер, но по мимо иконки мне надо изменить саму папку neoncube где лежат его все настройки включая папки со скином, на моё имя придуманное мною...

Куплю Гайд запуска два сервера на одном VPS! Можно в txt формате полный гайд что и где менять от А до Я! Либо через Демонстрацию! Сам пытался что то не как не пполучилось) Пишите свои контакты где я могу вас найти) Спасибо за внимание

Мод добавляет небольшую проверку для агрессивных монстров, они не будут атаковать тебя если на персонаже стоит определенная переменная. Но они будут атаковать если вы начнете первым. Патч для rA и Herc и демо скрипт: GitHub Как использовать: Если вы хотите сделать монстра лояльным к игроку нужно утановить переменную на 1. Например: set loya1785,1; // Где 1785 ID монстра -> Atroce В этом случае Атрос не будет агриться на ерсонажа. Чтобы сделать все как было надо поставить переменную на 0 set loya1785,0; // Где 1785 ID монстра -> Atroce В этом случае Атрос будет атаковать персонажа как обычно

[script][src][custom] Квас — один глоток сделает вас монстром Встречал на ЛюмиРо, очень понравилась идея. Описание Отличный мод для внесения кое-какого разнообразия в игру — из мобов выпадает особый предмет, который позволяет игроку принимать облик этого моба. Работает до перезахода в игру. Можно создавать интересные ивенты и квесты. Необходимо скачать PHP-скрипт для конвертации: conv_mobtosql.php (2.00) (после сохранения удалите расширение файла .txt) eA-скрипт для выпадения предметов: drop_kvass.txt Установка Правим только один файл src/map/pc.c, находим: sd->itemindex = n; Добавляем после: /* NeoTemple Extra - Kvass */ if( sd->status.inventory[n].card[0] == 254 || sd->status.inventory[n].card[0] == 255 ) { pc_setglobalreg(sd, "useditemsign", ((sd->status.inventory[n].card[3]<<16)+sd->status.inventory[n].card[2]) ); } /* end of NeoTemple Extra */ Готово, теперь нам нужно немного изменить базу предметов, открываем db/re/item_db.txt находим строку: 12233,Kvass,Kvass,0,20,,200,,,,,0xFFFFFFFF,7,2,,,,,,{ percentheal 100,100; },{},{} И заменяем её на: 12233,Kvass,Kvass,0,200,,50,,,,,0xFFFFFFFF,7,2,,,,,,{ disguise useditemsign-140000; },{},{} (настройки веса и стоимости продажи можете сами поменять на нужные вам) Шаманим с базой монстров Теперь нам понадобится скаченный ранее файлик .php, запускать его нужно на сервере, но для начала необходимо сделать настройки. В самом файле есть такие строчки: // Измените эти данные в соответствие с вашими настройками сервера MySQL $mysql_host = "localhost"; $mysql_name = "ragnarok"; $mysql_pass = "ragnarok"; $mysql_db = "ragnarok"; $chardb_start_id = 140000; // С какого ID будет стартовать список мобов $mob_account_id = 1999999; // ID аккаунта, которое выставляется для мобов Основные настройки — это данные для подключения к базе MySQL, внестите необходимые изменения в переменные: $mysql_host — сервер для подлючения к MySQL $mysql_name — имя пользователя MySQL $mysql_pass — пароль $mysql_db — название базы данных Следующие две переменных можно не изменять, но всё равно расскажу о них: $chardb_start_id — каждый персонаж имеет уникальный ID, чтобы подпись к предмету работала, нам нужно создать псевдо-персонажей с именами монстров, с данного ID они будут начинаться (если не знаете, что это, то настоятельно рекомендую ничего не менять) $mob_account_id — у персонажей должен быть уникальный аккаунт, это идентификатор (тоже самое предупреждение, что и в предыдущем пункте) Так же необходимо поместить вместе с файлом и файл базы монстров — mob_db.txt. Если создание пройдёт успешно, то мы увидим на экране заветное: All Done Остаётся только подгрузить скрипт выпадения предметов: - script kvassDrop -1,{ OnNPCKillEvent: if (rand(10000) <= 40) { set .@itemdrop, killedrid+140000; getitem2 12233,1,1,4,0,254,0,.@itemdrop&0xffff,(.@itemdrop>>16)&0xffff; } end; } И всё будет готово, в скрипте выставлен шанс выпадения предмета 0.40 (<= 40), вы можете поменять его на любое удобное для вас. Как это работает Небольшой сорц-мод создаёт глобальную переменную персонажа: useditemsign — это сделано потому, что разработчики eA не сильно заботились мыслью о том, что кому-то могут понадобиться данные об используемом предмете внутри скрипта предмета. Более того, если предмет последний в инвентаре, то до вызова скрипта будут удалены его данные и даже зная его порядковый номер в инвентаре уже ничего нельзя получить. Поэтому, данная переменная сразу делает то, что нам нужно — вычисляет ID подписанного персонажа (в нашем случае — это псевдо-персонаж с ID монстра). Но данный фикс был бы неполный, если бы не скрипт выпадения предмета, который создаёт данную подпись персонажа. Впринципе, можно немного дописать скрипт и сделать, чтобы изменение сохранялось (допустим) на продолжительный срок даже после перезахода. Перспективы тут достаточно интересные.

[src] Usable-предмет не исчезает после использования Описание Всё просто, очень полезно для создания custom-предметов (в моём случае карманного PDA с выводом полезной инфы), Usable|Healing|Cash-предмет не исчезает после использования. Установка Правим только один файл src/map/pc.c, находим: if( sd->status.inventory[n].expire_time == 0 ) { Заменяем на: if( sd->status.inventory[n].expire_time == 0 && sd->inventory_data[n]->atk != -1 /* NeoTemple Extra */ ) { Теперь если в описание Usable|Healing|Cash-предмета в item_db.txt в ячейке ATK указать значение -1 — предмет после использования не будет убираться из инвентаря. Пример: 17000,Kafra_PDA,Kafra PDA,2,20,,0,-1,,,,0xFFFFFFFF,7,2,,,,,,{ callfunc "nt__kafraqinfo"; },{},{}

[src] Шанс выпадение предметов не зависящий от рейтов Традиционное примечание, незабывайте о такой полезной функции Афины, как работа с db/mob_item_ratio.txt, что он умеет и для чего нужен вы можете почитать прямо внутри. От себя добавлю, что данный мод и работа этого файла отличаются. Описание Данный мод позволяет игнорировать рейты на шанс выпадение предметов, такое иногда бывает нужно, когда хочется сделать, чтобы определённые предметы из мобов падали с шансом без рейтов. Благодаря этому моду, подобное можно будет делать без перекомпиляции сервера, а только перезагрузив базу предметов. Установка Правим только один файл src/map/mob.c, находим: if (battle_config.logarithmic_drops && rate_adjust > 0 && rate_adjust != 100 && baserate > 0) //Logarithmic drops equation by Ishizu-Chan Добавляем перед: if( baserate < 0 ) { return (unsigned int)cap_value(abs(baserate),rate_min,rate_max); } Теперь, если в mob_db.txt указать шанс выпадения отрицательным числом (например -1), то рейты на шанс выпадения будут игнорироваться. Ещё раз говорю (если кто не прочитал), данный мод не одно и то же, что и работа с db/mob_item_ratio.txt.

[src] Динамические рейты Описание Динамические рейты позволяют настроить рейты по своему усмотрению, к примеру, сделать рейты для тех или иных классов больше или меньше (самый распостранённый вариант использования). Установка Нам нужно будет поправить всего два файлика (diff'ы не делаю, кому нужно — создайте сами, тут только ручная правка по привычке). Первым правим src/map/pc.h, находим: int pc_gainexp(struct map_session_data*,struct block_list*,unsigned int,unsigned int, bool); Добавляем после: unsigned int pc_ntexprate (struct map_session_data *sd); Теперь приступаем к правке src/map/pc.c, находим: if(!battle_config.pvp_exp && map[sd->bl.m].flag.pvp) // [MouseJstr] return 0; // no exp on pvp maps Добавляем после: if( !quest ) { unsigned int nt_rateexp = pc_ntexprate(sd); if( base_exp ) { base_exp = (unsigned int) cap_value(base_exp * (nt_rateexp/100.), 0, UINT_MAX); } if( job_exp ) { job_exp = (unsigned int) cap_value(job_exp * (nt_rateexp/100.), 0, UINT_MAX); } } Дальше находим: unsigned int pc_maxbaselv(struct map_session_data *sd) Добавляем перед: /*========================================== * NeoTemple Extra: Returns Base/Job Exp Rate using Dynamic Base/Job Exp Rate System *------------------------------------------*/ unsigned int pc_ntexprate (struct map_session_data *sd) { unsigned int exprate = 100; if (sd->status.base_level > 70) { exprate += 50; } else if (sd->status.base_level > 50) { exprate += 25; } else if (sd->status.base_level > 30) { exprate += 10; } switch ( sd->class_ ) { case MAPID_MERCHANT: case MAPID_MERCHANT_HIGH: case MAPID_ALCHEMIST: case MAPID_CREATOR: case MAPID_BLACKSMITH: case MAPID_WHITESMITH: exprate += 200; break; case MAPID_ACOLYTE: case MAPID_ACOLYTE_HIGH: case MAPID_PRIEST: case MAPID_HIGH_PRIEST: case MAPID_BABY_ACOLYTE: case MAPID_BABY_PRIEST: exprate += 100; break; case MAPID_NOVICE: case MAPID_NOVICE_HIGH: exprate += 50; break; } return exprate; } Готово, мы добавили основную функцию, в данном исходном коде находится готовый пример, вам нужно обладать кое-какими познаниями в программирование, чтобы дописать свой, но общая концепция будет понятна сразу. Описание примера Итак, вы всё это сделали, но ничего не понимаете. Разумно, ведь это исходник. Сейчас я поясню пример. Все изменения под свой сервер вам нужно делать в функции pc_ntexprate, но для начала объясню, что в примере происходит. Каждый раз, когда вы получаете какой-либо опыт, дополнительно вызывается функция pc_ntexprate, это не касается только квестового получения опыта (из скриптов). Первым делом внутри функции устанавливается 1 рейты на получения опыта: unsigned int exprate = 100; затем, проверяется уровень персонажа, который должен получить опыт: if (sd->status.base_level > 70) { Логика такая: если игрок ниже 31ого уровня, то он не получает дополнительных бонусов к рейтам, если выше 30ого, то его бонус составляет ещё 10%, если выше 50ого, то 25%, если 70ого, то 50%. Затем функция делает проверку на класс персонажа и в зависимости от этого решает какой ещё бонус даётся. Учтите, что эти бонусы идут после уже установленных в конфиге, то есть, рейты не складываются с рейтами в конфиге, а вычисляются после. Так, допустим, если у вас рейты на сервер по опыту 2х, то при добавление 50% они составят уже 3х. Это самый простой пример использования таких рейтов, к примеру, можно добавлять/убавлять получение опыта по более сложным принципам (вычислять статы и предполагать билды чара, учитывать какие статусы на персонаже, какие предметы и прочее). Если вы хотите, чтобы опыт начислялся только для Базового или Профессионального уровня, то удалите одну из строчек указанную тут: if( !quest ) { unsigned int nt_rateexp = pc_ntexprate(sd); if( base_exp ) { base_exp = (unsigned int) cap_value(base_exp * (nt_rateexp/100.), 0, UINT_MAX); } if( job_exp ) { job_exp = (unsigned int) cap_value(job_exp * (nt_rateexp/100.), 0, UINT_MAX); } } Соответственно строчка с base_exp — базовый опыт, строчка с job_exp — профессиональным. Если желаете, чтобы квестовый опыт так же учитывался, то удалите проверку, должно получиться так (без if): if( base_exp ) { base_exp = (unsigned int) cap_value(base_exp * (nt_rateexp/100.), 0, UINT_MAX); } if( job_exp ) { job_exp = (unsigned int) cap_value(job_exp * (nt_rateexp/100.), 0, UINT_MAX); }