wl.illusion

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

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

upd ещё раз обновил, теперь в mapflag'ах можно указывать списки или разрешённых или запрещённых мобов.

Да без времени, сколько помню, раньше 0 указывал на бесконечную работу. Нынче убрали? upd слазил посмотрел — убрали, жаль, поставлю максимальное значение тика.

upd — дополнил, доработал, теперь есть mapflag и режим моба. Добавил список todo

Да, пожалуй мне стоило указать версию ревизии. Не знаю будет ли вообще у вас работать на оригинальной афине, но попробуйте поместить перед: unsigned int size : 2;

Какая ревизия афины?

Всё дело в необходимости — писалось для личных целей, настройки сделать можно, с мапфлагами там ничего сложного нету. Глобальная скриптовая переменная - для более удобных изменений «на лету». upd из идей, мапфлаг на запрет demonic'а, а не на его разрешение. Что-нибудь вроде: prt_fild08 mapflag demonicdisabled Что касается запрета конкретного ID, то я ярый противник создания бесконечных «костылей», предлагаю режим моба - MD_NODEMONIC. Предлагаю именно «запреты», а не «разрешения».

Да, постараюсь исправить эту оплошность со временем.

[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.

Функция status_calc_mob_ Такой кусок кода: if(first) { //Set basic level on respawn. if (md->level > 0 && md->level <= MAX_LEVEL && md->level != md->db->lv) ; else md->level = md->db->lv; } С какой ревизии он появился и какой смысл он несёт? Даю наводку, если ставить мобу возможность после убийства повышать свой уровень, то после убийства моба и его респауна у него остаётся уровень и повыешнные статы (моб так и до максимального уровня дорасти может). Хотелось бы узнать, если кто вкурсе — это просто набросок, который забыли дописать или есть скрытый смысл?

Я бы дал дельный совет — учиться вообще что-то делать в PS. Отговаривать вас от этого занятия (рисовать в PS) не буду, то, что вы показали, как школьный вариант похвастаться перед «пацанами» пойдёт, но в дело даже как черновик не годен. Если хотите учиться, то я не буду отправлять вас читать туториалы и прочее, даю опытный совет — возьмите любой дизайн сайта (хорошего качества) и без копипасты попробуйте его повторить 1 в 1. Проделайте такую работу не меньше 10 раз (повторяя разные дизайны), когда научитесь хотя бы делать «клоны», то получите жизненный опыт и понимание «дизайн», «юзабелити», «интерфейс». Для начала можете хотя бы дизайн этого форума попробовать повторить. Получите хороший опыт и навыки в PS.

Не так, я предлагаю сделать родительский класс, а от него уже наследовать для каждой db. Пусть это старый mysql драйвер или новый или pdo или вообще другая db. Хоть noSQL или вообще работа с текстовиками. У твоей CP в целом плохая структура, но думаю ты не думал заниматься этим серьёзно потому так и получилось, я бы на твоём месте эту версию бросил и сел писать новую с уже хорошо продуманной структурой и иерархией классов. Ну и в целом многого нехватает, если задумаешь писать новое, то с удовольствием помогу, опыт создания фреймворка и CMS к нему есть. Можно вполне сделать употребляемый продукт, правда, у меня условие — freeware. Вкратце, я писал для своих коммерческих целей свой фреймворк+CMS под конкретные задачи, внутри это напоминает Joomla или Drupal, очень удобная конструкция внутри, работа с шаблонами плохо сделана, но это не было задачей, т.к. на каждый продукт натягивается один раз шаблон и непредусматривается наличие их смены. Сейчас у моего провайдера работает на этом биллинговая система и сам биллинг (админка и клиентская часть).

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

Ещё раз меня простите, но 500р за говно школьного уровня (честно, простите, редко употребляю такие термины) — это много, тут даже не уровень: "я научился запускать Dreamweaver", а гораздно ниже, учитывая, что вроде с CS3 фотошоп сам может нарезать вам шаблончик. Но дело даже не в этом, в примерах нет дизайна - шрифты не подобраны, размер невыправлен и платить за это как-то... не знаю. В общем, такое я за 100р сделал бы (совесть только непозволит говно делать). Нормальный дизайн от 1500-2000 по уровню требований, тут не спорю. Про патчер вообще молчу. Пример, 2 минуты работы (Thor Patcher + 5 минут на понимание как это скомпоновать, полоска прогресс-бара тоже нарисована своя): В общем не лезу в ваши дела больше, я видимо просто не привык к песочнице, простите

Переменные нужны для понимания какое значение для чего, в вашем примере непонятно для чего те самые магические числа, в моём примере сразу было видно где X, а где Y, да и в целом в создание временных переменных, в которых происходят какие-то вычисления, ничего плохого нет. Другой вопрос, что это немного затратно по ресурсам, но это недостаток афиновского скриптового языка в целом (с другой стороны, если кусок скрипта не вызывается постоянно, то какая разница в его затратности по ресурсам?).

*warp "<map name>",<x>,<y>;

Вы кем работаете, если не секрет? Я вот программист — C/C++, Python, PHP. Самая частая работа — доработка чужого говна, и вы мне сейчас что-то хотите рассказать про что лучше? Возьмите проект на пару сотен файлов, с минимальным комментированием кода, на пару сотен тысяч строк кода. А оптимизированием занимайтесь, когда это необходимо — истинный дзен программирования, главное читабельность и понимание.

Мне кажется, или мой пример легче? Мне кажется они одинаковые, только стилистика разная. У вас сокращённая, у меня строгая развёрнутая — в самый раз для понимания принципов.

Сделайте рандумизатор, что-нибудь вроде: set .@x, 162+rand(0,20); set .@y, 352+rand(0,20); warp "prt_fild01", .@x, .@y;

Классическая мозаика (это на окнах такое в храмах и соборах) в стиле RO, цветовая гамма тоже из RO (VGA 256). Узор можно что-нибудь из мобов, я лично за поринга.

Каждый в праве дописать свои точки для телепорта, делать под каждый сервер с прописыванием всех woe данжей, а небездумно брать чужой скрипт. Если давать всё готовое — то админов нубов меньше не станет. А вообще, не нравится - попросите модераторов удалить тему, мне лично дела нет, free — не означает, что будет всё и сразу, проявите немного своего внимания и помогите доработать, вам скажут спасибо.

Простите, не удержался - ужасный дизайн, а вы за эти студенческие поделки ещё и серьёзные деньги берёте подучились бы в фотошопе работать.

[NPC] Very Advanced Warper v2 Осторожнее с настройками данного варпера, так же варпер весьма «тяжёлый» — использует много переменных, есть несколько циклов, размер которых зависит от внесённых по указанному направлению целей перемещения. Описание Данный Варпер полностью универсален, позволяет создавать сложные схемы перемещения, взымать различную оплату (купоны, зени, предмет(ы)). Варпер указывает цены (перемещение может быть и бесплатным, о чём игроку будет сообщено), предлагает направления, а так же сообщает чего именно нехватает для перемещения и в каком кол-ве. Скачать Сам NPC: nt_warper.txt NPC не будет работать без вот этого: nt_extra.txt Настройка, добавление направлений Скрипт достаточно сложный, поэтому принцип работы мы обсуждать не будем (кому интересно внутри достаточно много комментариев). Давайте поговорим о создание направлений и целей для перемещения. Для начала определимся с некоторыми терминами, важный термин — Маркер направления. Всего может быть 5 направлений (запомните, это чертовски важно). Маркер направления — это символ-идентификатор (любой принимаемый символ скриптами). Текстовые значения для меню направлений задаются в скрипте: set .menu_name_waycity$[.@def_waycity], "В город"; set .menu_name_waycity$[.@def_waydun], "В подземелье"; set .menu_name_waycity$[.@def_wayvip], "Особые места"; set .menu_name_waycity$[.@def_wayvip2], "Бесплатное перемещение"; set .menu_name_waycity$[.@def_wayvip3], "За предметы"; Можете заменить на свои значения, это делается только в одном месте и безболезненно. В скрипте есть define для ID-направлений — их менять нельзя, это временные переменные, созданные для удобства создания целей для перемещения. Вот их список: set .@def_waycity, 1; // ID перемещения в город set .@def_waydun, 2; // ID перемещения в подземелье set .@def_wayvip, 3; // ID перемещения в vip set .@def_wayvip2, 4; // ID перемещения в vip set .@def_wayvip3, 5; // ID перемещения в vip Каждый NPC имеет 5 разных маркеров, которые и определяют доступные перемещения для игрока. Рассмотрим имя NPC: alberta,113,53,5 duplicate(nt_wrp) Телепортация#00000_02 124 У любого NPC есть понятие «Скрытое имя», в указанном примере оно: «00000_02» — последние «_02» всего лишь порядковый номер NPC (кстати, будет лучше, если для каждого NPC они не будут совпадать, указывать их можно не только цифрами, но и буквами), а вот первые пять символов — это и есть Маркер направления. Данный маркер определяет с каким именно списком целей нужно работать. Каждый маркер — один символ! <.@def_waycity><.@def_waydun><.@def_wayvip><.@def_wayvip2><.@def_wayvip3> Раз заговорили о настройках NPC, то важно будет ещё сказать, что можно указать имя NPC отображаемое в диалогах и минимальный базовый уровень для работы с NPC. // Имя NPC отображаемое в диалогах set .npc_name$, "Сервис Телепортации"; // Минимальный базовый уровень необходимые для телепортации set .wrp_min_baselvl, 18; Вы можете менять эти значения на своё усмотрение. Теперь перейдём к самому важному — создание целей для перемещения. Пример: callsub L_AddWarpPoint, .@def_waycity, "0:(p|1),1:(p|1)", "Alberta", "alberta", 116, 56; За добавления цели отвечает функция L_AddWarpPoint, её параметры для использования: — ID-направления (.@def_waycity/.@def_waydun/.@def_wayvip/.@def_wayvip2/.@def_wayvip3) — Работа со стоимостью Макера направлений — Название цели для пункта меню — Название карты (из map_index.txt) — Координата X — Координата Y Стоимость задётся очень просто: "<Маркер направления для данного ID-направления><тип стоимости>)|<стоимость>|<только для предметов - название предмета>;...<>" Тип стоимости: z — зени p — кафра купоны <id предмета> — предмет, который необходим, так же к данной записи добавляется параметр с названием, если указать '-', то имя будет браться из базы Если ничего не указывать в стоимости, то перемещение будет бесплатно! (Например: "0:()") Несколько примеров, для понимания: "0:(p|1;z|500;909|20|-)" В данном примере стоимость по Маркеру 0 составит: 1 кафра купон, 500 зени и 20 Jellopy (всё вместе, а не что-то по отдельности или что-то из перечисленного) Более сложный пример "0:(p|5;),1:(z|5000),3:(4001|1|Карта Поринга)" В этом примере видно, что можно указывать стоимость сразу для нескольких маркеров разделённых ',', но вы можете и вызывать для каждого маркера отдельно функцию — оба способа обрабатываются корректно, пример всё в одном: callsub L_AddWarpPoint, .@def_waydun, "0:(p|5;),1:(z|5000),3:(4001|1|Карта Поринга)", "Муравьиный ад", "cmd_fild08", 320, 356; Но, можно и вот так: callsub L_AddWarpPoint, .@def_waydun, "0:(p|5;)", "Муравьиный ад", "cmd_fild08", 320, 356; callsub L_AddWarpPoint, .@def_waydun, "1:(z|5000)", "Муравьиный ад", "cmd_fild08", 320, 356; callsub L_AddWarpPoint, .@def_waydun, "3:(4001|1|Карта Поринга)", "Муравьиный ад", "cmd_fild08", 320, 356; Что ж, думаю будет уместен хороший сложный пример, давайте сделаем перемещение в Московию из Пронтеры и телепортацию на территорию Московии из самого города, укажем разные цены и сделаем, невозможным перемещение из Пронтеры на карту с мобами Московии, а вернуться в Пронтеру будет возможно только из Московии: // Цели перемещения // В Московии можно попасть из Пронтеры, но и с mosk_fild02 (сделаем за зени) callsub L_AddWarpPoint, .@def_waycity, "0:(p|6),2:(z|1500)", "Moskovia", "moscovia", 223, 184; callsub L_AddWarpPoint, .@def_waycity, "1:(p|5)", "Prontera", "prontera", 156, 183; // Данж доступен только из московии (Маркер 1) callsub L_AddWarpPoint, .@def_waydun, "1:(p|2)", "Moskovia Field", "mosk_fild02", 197, 247; // Разместим NPC по местам prontera,161,193,5 duplicate(nt_wrp) Телепортация#00000_17 124 moscovia,220,191,5 duplicate(nt_wrp) Телепортация#11000_44 124 mosk_fild02,194,252,4 duplicate(nt_wrp) Телепортация#22000_43 124 Схема, телепортироваться из Пронтеры можно только в Московию за 6 купонов (зачем Варперу в Пронтере портить в Пронтеру?), из Московии в город — Пронтеру за 5 купонов или в данж ("Moskovia Field") за 2 купона, с "Moskovia Field" можно попасть в город Московию за 1500 зеней. Примечание У меня используется cutin, который не стандартный, если у вас клиент будет крешится, то удалите все строки с cutin. Если вы не понимаете зачем это нужно, то используйте стандартного Варпера, если для вас это сложно, то пишите простые скрипты. Это универсальный Варпер, если нужно помочь с созданием схем направления, то можете обращаться, попробуем решить вашу проблему вместе.

С флагом это правильно, но было бы тогда лучше сделать отдельный type для предмета, 11 в какой-то мере решает проблему, но он не слишком универсален. Мой вариант хорош минимальными исправлениями сорца и работой только с одной db А вообще да, нефиг велосипеды изобретать, по мелочам и 11 пойдёт.