Регуляция цен на шмот и торговые караваны

Vestel, 02.04.05 10:44:52:

Оптимальный вариант на мой взгляд: чтобы магазины продавали то, что им было сдано. То есть, случайно нашел воин 5 уровня штаны для мага - сдал в магазин за 2к, они тут же в продаже за 4 и появились.

snap: 9429

 

У меня такая идея давно в планах

>Но не так что магазин одними шмотками завален, а другие днем с огнем не сыщещь.

А тут вижу два пути.
1. Делать как в старой доброй Элите регулировку цен, в зависимости от количества сданного товара. Чтобы пришлось поискать где подороже штаны продать (там, где их меньше). Это, кстати, может при соблюдении некоторого баланса породить профессию "транспортников", кто будет покупать вещи в одних магазинах, где ими затоваривание, и продавать потом по цене выше закупочной в далёком магазине, где их нет

2. В дополнение к 1 сделать ещё медленное перераспределение товара. Т.е. шмотки определёнными партиями из магазина с затовариванием будут пропадать, а в магазине с дефицитом - появляться...

... Всё, остапа понесло. Можно сделать:

а. Товар, который выбивается из мобов или крафтится, вообще убрать из магазинов. Пусть экономика работает

б. Ещё веселее. Перераспределение товаров можно также поручить NPC. Пусть NPC приходит в один магазин, берёт там товар, и тащит в другой, где его сдаёт. Заодно, это может породить профессию настоящих разбойников. Если при убийстве этого NPC товар будет дропаться Для переноски особых ценностей можно NPC давать охрану из определённого числа гардов...

Перехват торгового NPC-каравана - мне эта идея нравится

А, ведь, реализовать можно уже на том, что есть сейчас. Только приделать дроп, а "караванный AI" легко напишется на JBForth

Блин, мне бы б сейчас недельку свободного времени...

и еще идея, где то поставить магазинчик или просто НПС, где будет все и шмот весь что в игре и рецепты и материалчик. и защиту вокруг. чтоб 10-20 крутых играков левела, скажем так, 40 и выше с боем туда пробивались.

Нет, это не интересно Я (видимо, как творческий чёрный интуит - кто с соционикой знаком, поймёт) больше ратую за неожиданность, непредсказуемость и ожидание

Когда ты всегда можешь купить крутую шмотку, пусть даже и со сложностями, это, считаю, менее интересно, чем когда заранее неизвестно, где и как достанется она

Идея так и осталась идеей?

А хотя бы реализовать сдачу вещей NPC (как в УО) или на аукцион? Такое сложно реализовать?


Торговых ботов очень не хочется разрешать

Пока по-прежнему на уровне идеи. На новой работе всё не выходит период спокойного времени, прихожу домой в таком состоянии, что обычно уже не до сервера

А в приоритетах пока более простые вещи - законченный эвентовый движок, введение параметра Славы игрока и т.п.

закрытие vulnerability с jbforth

zabbix:

закрытие vulnerability с jbforth

 

Если ты про возможность вызова bypass из клиентских html - то это не ко мне. Это в самом сервере что-то править нужно. Не верю, что на официале также, иначе это огромная дыра в сервере вообще, а не только в JBF В принципе, конечно, можно этой дыры избежать, но потеряется много гибкости. В частности, все слова придётся определять заранее и прописывать только их вызов...

на оффе так же
только там скрипты более проработаны, и при попытке залезть куда не надо - кикает

кстати, дыра не в сервере а в клиенте

Если уже точнее, то дыра - в идеологии. Трудно, что ли, разные команды ссылок было для клиентских и серверных HTML сделать? А теперь придётся извращаться... :-/

Постараюсь на днях переписать блок, запретив работу с произвольным Форт-кодом из HTML.

да ты это корейским девелоперам скажи, вот накуя было скилы по трем файлам в офе раскидывать, когда 1 таблицы в безе хватит? А накуя было ipc между сервисом НПЦ и игровым серевером через сокеты делать, когда они геодату через sharedmemory херачат?

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

Balancer:

zabbix:

закрытие vulnerability с jbforth

 

Если ты про возможность вызова bypass из клиентских html - то это не ко мне. Это в самом сервере что-то править нужно. Не верю, что на официале также, иначе это огромная дыра в сервере вообще, а не только в JBF В принципе, конечно, можно этой дыры избежать, но потеряется много гибкости. В частности, все слова придётся определять заранее и прописывать только их вызов...

 

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

дык закрыли уже сей баг
теперь только ГМ читерить может

zabbix:

дык закрыли уже сей баг
теперь только ГМ читерить может

 

Закрыли на уровне анализа откуда приходит bypass или "закрыли" на уровне того, что bypass всё равно приходит какой захочет взломщик, но на сервере стали им пользоваться с большими ограничениями?

к сожалению порезали
bypass на jbforth только от ГМа отрабатывается теперь
квесты на профессию фтопке, эвентовая мишура фтопке :-/

по теме
пункт 2b очень хорош, но:
- аи местный скриптов не умеет
- аи местный вейпоинтов не умеет
- аи местный эвенто-обделенный, т.е. гемороится придется с событиями "пришел в пункт назначения" и т.п.

>bypass на jbforth только от ГМа отрабатывается теперь

Хреново :-/

>квесты на профессию фтопке, эвентовая мишура фтопке :-/

Это дело поправимое, переделаю. Но будет не так красиво :-/ Всё же, какими надо быть идиотами разработчикам Линейки, чтобы не различать данные клиентских и серверных HTML :-/

у них это не работает - просто есть доп. проверки в скриптах, а их скриптовый движок на десять голов выше чем то, что имеется в л2ж, ибо очень хорошо интегрирован в неписей
причем там даже какие-то зачатки объектно-ориентированные есть, то есть, положим, объявляем непися, с базовым классом default_npc:

class mynpc: default_npc
handler 3 // событие "TALKED"
shift_sp 1 // вытащим параметр из стека
call 77 // какая-то функция
handler_end
class_end

теперь можно объявить класс mynpc2, с базовым классом mynpc - и в нем уже будет обработчик события talked, а можно его (обработчик) перегрузить
как делать классы и перегрузку в форте пока не ясно - а без этого непонятно как красиво организовать скриптованный аи, без кучи повторяющегося кода

Сперва про устранение уязвимостей в имеющихся скриптах (попробую сегодня вечером поправить).

1. Убираем нынешнюю прямую обработку Форт-определений. Точнее - оставляем её для админских целей, ещё нужно будет.
2. Вместо неё оставляем вызов одиночных слов
3. При получении нужного bypass-кода, дописываем к вызываемому слову некий префикс, например, bypass_ и выполняем это слово
4. Это слово описано на сервере в .f-файле.

Неудобство - на каждый чих придётся описывать слово. Т.е. как сделано в имеющихся bypass-обработчиках. Плюс только в том, что на форте проще отлаживать - переписывается только нужный .f и перезагружается форт-система без рестарта сервера.

Например, стоит у NPC телепортация за бабки:
forth 111111 22222 -3333 18500 gatekeeper-jump

Теперь описываем в .f-файле команду, типа

1. : bypass_jump1   111111 22222 -3333 18500 gatekeeper-jump ;

А в html пишем что-то типа:
jbfu jump1

Всё. (jbfu - JBF call by User ) Никакой уязвимости.

Теперь по реализации AI на Форте.

Подходов два. Традиционный объектный (объектная система на Форте - это на пару килобайт исходников, но дополнительные тормоза) или, что лучше, использование его словарей. Словари пока не реализованы, хотя для их реализации уже много чего написано, так что доделать их не сложно.

Словари форта - это древовидные области видимости слов. Т.е. сейчас, как и в "полных" Фортах по умолчанию, все слова создаются в одном словаре. Но создавать новые слова можно в определяемых пользователем областях видимости. Например, так.

Базовый словарь: on_kill ( obj_id npc_id — )

Создаём словарь L2Monsters. Там описываем такой же on_kill, если нужно.

При убийстве моба выставляем характерную для него цепочку словарей (можно вообще сделать их одноимёнными с классами Java) и вызываем on_kill. форт будет искать это слово в словарях в заданном порядке и когда найдёт - выполнит.

...

Наконец, можно реализовывать вообще без всяких изысков. Java-обработчик события onKill просто будет искать все подходящие слова, типа on_npc_id_7767_kill, on_L2Monster_kill, on_L2Npc_kill, on_L2Character_kill и т.п. и по мере их нахождения - выполнять (все, или только первое - тут уже продумать нужно).

Последний вариант, не смотря на то, что он не объектный, ИМХО, самый простой и быстрый

в принципе, это все детали
проблема только одна - как выдрать это из пакейджа gameserver - все пришито стальными нитками
классы вроде NpcTable,SpawnTable & Spawn и технология их взаимодествия с L2World/L2worldRegion вообще о суициде мысли вызывают - притерто все друг к другу

btw, если я в хелп.хтмл добавлю jbfu teleport1 - из любого места портануться смогу

Точно также, как при имеющейся записи через npc_<...>_goto NNN

Doch, там таргет валидный при bypass npc_ должен ведь быть?
хотя. что мешает добавить проверку таргета в jbfu...

Пошёл тестировать "затычку" для bypass-форта