if (getItemCount(9999) == 9){
giveItem(9999, 1);
changeQuestState(2);
}
giveItem(9999, 1);
if(getItemCount(9999) >= 9){
changeQuestState(2);
}
СталоgiveItem(9999, 1); if(getItemCount(9999) >= 9){ changeQuestState(2); }
giveItem(9999, 1); if(getItemCount(9999) >= 10){ changeQuestState(2); }
Это плохая идея, т.к ИИ примерно 13000 и переписывать код каждого, со второго метода на первый немного затратно по времени.Не, ну тут консилиум нужно задействовать...
Почему же просто не добавлять ко всем квестовым значениям 1?
Было
СталоКод:giveItem(9999, 1); if(getItemCount(9999) >= 10){ changeQuestState(2); }
long count = getQuestCount(9999);
giveItem(9999, 1);
if (count >= 9)
{
do something;
}
public long getPtsScriptCount(Player player, int itemId)
{
return player.getInventory().getItemById(itemId, -1) - 1;
}
Спасибо, но к сожалению, ваше решение не подойдет, т.к в этот же метод используется в обеих версиях кода и он должен отдавать предсказуемое значение. Проблема в том, что количество итемов на момент проверки корректно, с точки зрения скрипта, т.к выдача итема и проверка его количества не идут строго друг за другом во времени.перед каждой проверкой брать колличество итемов у персонажа, потом добавлять 1 и проверять по прошлому колличеству.
Или же сделать универсальный метод в квестах, который будет возвращать значерие сразу с -1Java:long count = getQuestCount(9999); giveItem(9999, 1); if (count >= 9) { do something; }
Java:public long getPtsScriptCount(Player player, int itemId) { return player.getInventory().getItemById(itemId, -1) - 1; }
Именно в этом моя проблема.АИ птса выполняется асинхронно.
оба примера это шило на мыло с одной сутью и исходом, где если у тебя все методы отрабатываются вовремя и возвращают корректные значения - всё работает.
Кстати, мне тут пришла в голову мысль, что возможно оба эти метода обрабатываются по определенным серверным тикам, и GiveItem1 возможно шедулит не прямую выдачу, а добавляет итемы в очередь выдачи, а они потом обрабатываются одним тиком и собственно исполнение OwnItemCount может так же ждать ответа, который придет на следующий тик. Возможно, это причина, по которой на ПТС квестовые итемы выдаются и обрабатываются с некоторой задержкой даже на селфхостед.одно из решений - не выдавать квестовые предметы чаще чем какой-то определенный период.
т.е. при успешной выдаче ставить метку времени, а так же запоминать ид последнего выданного предмета.
ну и проверять это при попытке выдачи - если прошло слишком мало времени и предмет такой же, то не выдавать еще один предмет.
минус способа конечно в том что к примеру на париках мобов в итоге игроки не смогут быстро набивать предметы, т.е. условно с кучи одномоментно убитых мобов получат предметов столько же сколько с одного.
толи в хфе, но 100 % в годе они выдаются моментально.Кстати, мне тут пришла в голову мысль, что возможно оба эти метода обрабатываются по определенным серверным тикам, и GiveItem1 возможно шедулит не прямую выдачу, а добавляет итемы в очередь выдачи, а они потом обрабатываются одним тиком и собственно исполнение OwnItemCount может так же ждать ответа, который придет на следующий тик. Возможно, это причина, по которой на ПТС квестовые итемы выдаются и обрабатываются с некоторой задержкой даже на селфхостед.
Но это все равно не объясняет, почему не выдаются лишние итемы на ПТС)))
AtomicJobCompositor это класс Server.exe или из Npc?P.S. Судите по "JobCompositor", может быть, он задерживается?
Да. Я пришел к примерно таким же выводам. Спасибо за информацию, она очень полезна.это L2NPC.
похоже, что это Queue атомарных исполняемых операций, которая связана с CScriptEngine, которая затем вызывает функцию Process, которая выполняет операции в Queue.
Из-за того, что GiveItem должен запускаться таском RunNpcScript -> Process, он будет (почти?) всегда запускаться после OwnItemCount.
Ну на яве я скорее всего не смогу выделить поток на НПЦ(если конечно виртуальные поток не релизнут на 21 LTS из превью, в чем я сомневаюсь), поэтому ИИ у меня обрабатываются отдельной фабрикой на несколько потоков. При АОЕ смерть наступает не одновременно, но в пределах обработки одного цикла по таргетам в таске скилла. Т, е фактически, одновременно с точки зрения очередности объявления события MY_DYINGТак же отмечу, что у каждого ИИ нпс есть отдельный поток(или есть несколько тредов и там распределены нпсы, я пока не смог разобраться), при убийстве нпс с помощью AOE они не умирают одновременно.
Это и не нужно. Приложение не должно создавать потоков больше, чем ядер процессора (x2 если у процессора есть гипертрединг или аналог). Все что больше – уменьшает производительность на переключении контекста и бессмысленных локах. Если коротко – тяжелый поток на любую шляпу = один из худших видов говнокода, потому что сочетает в себе как косорылого "программиста", так и такую сложную для дебага тему как многопоточность.Ну на яве я скорее всего не смогу выделить поток на НПЦ
В 16 яве, в превью появились виртуальные потоки, которые отвязаны от потоков ОС и являются по сути надстройкой над ними. Затраты на создание VP ничтожны и их можно создавать сотнями тысяч, практически не теряя(а иногда значительно экономя) ресурсы. Проблема в том, что они в превью даже в 20 яве, и скорее всего не выйдут из него на следующем ЛТС релизе. Поэтому использовать их в каком-то мало-мальски серьезном коде я не сильно горю желанием, а уж тем более в ThreadPoolManager’е.Это и не нужно. Приложение не должно создавать потоков больше, чем ядер процессора (x2 если у процессора есть гипертрединг или аналог). Все что больше – уменьшает производительность на переключении контекста и бессмысленных локах. Если коротко – тяжелый поток на любую шляпу = один из худжих видов говнокода.
Для максимальной многопоточной производительности используют пулы потоков, отдельные очереди на каждый поток, work stealing и т.д. Советую всем интересующимся многопоточными приложениями презентацию:
Да, она о C++, но общую суть передает очень хорошо, и в итоге показана одна из лучших реализаций пула потоков (не только на С++).
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?