Зона торговли

[lin]

Всем привет!
Сервер interlude.
Возникли вопросы:

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

2. ^^=По аналогии выше=^^
Как сделать зону покупки, чтобы можно было только покупать?

Пожалуйста если где-то есть описание, дайте просто ссылку.

Или просто объясните в какую сторону смотреть и если можно подробнее объяснить где, то будет вообще замечательно.

ТКНИТЕ ПРЯМ НОСОМ МЕНЯ

[Donatte]

Смотрите входящие пакеты на частный торг и крафт. Сформируйте known список с игроками внутри нужного вам радиуса от игрока и если список пуст, то разрешайте торговлю/крафт.

По поводу зон, то нужно создать новую зону типа TradeZone и присвоить ей несколько (или один, если числовое значение) дополнительных параметров разрешающих свой вариант buy/sell/craft.

[lin]

Скорее я не верно задал вопрос.
Как запретить buy/sell/craft везде?
А создать зону я знаю как.

[Donatte]

Сообщение от lin

Скорее я не верно задал вопрос.
Как запретить buy/sell/craft везде?
А создать зону я знаю как.

PHP код:

        if (!activeChar.isInsideZone(ZoneId.SUPERPUPERZONE))
        {
            activeChar.sendPacket("You can't use sell/buy/craft mode in this zone.");
            return;
        } 


[lin]

Donatte, да тут кароче проще потратить времени и переписать, спасибо конечно!
Вариант рабочий но не очень надежный.

оффтопик:

Свернуть ↑ Когда я взял сервер исходников l2jfrozen, l2j, ... их много, не важно какие.
Я лишь посмотрел структуры реализаций, какая-то лучше, какая-то хуже не важно (заключается - это в обработке персонажа, а о входе так никто и не догадался). Структура от <матное слово>, сильно много объектов и методов, вообще глобально не продумана логика построения концепций.
Структуры классов и свойств, методов и реализаций их тел, выглядят так, что пишут лиж-бы было " Нет у нас времени! ". " Времени надо всего то было " - Спроектировать весь проект. И написать аккуратно всю реализацию на 1 персонажа и аккуратный пакетник (авто-контроллер с переданным " xml, json " - со всеми наименованиями) - для обработки динамически, какой нужно когда он запросится. Все оторвано от реализации...
Игровые предметы - вообще ни к чему не обязываются и не привязаны к игровым действиям, их можно получить методом клиента, а не сервера, хоть и работает на сервере. Когда вы пытаетесь отправлять с клиента полученные пакеты " еще хочу ", выполнены уже ранее, можно изменив пакет получить и другие предметы. ! Х. Ну! А если будет невозможно принять, уже приняло?! Пусть не будет получения предметов просто так.
Даже адену не просто так, а придется убить кого-то или сделать, что - то, но, что - бы нельзя вновь было посылать, уже выполнялось и нужно заново. Моб убит и его больше нет или никто не был убит. Не важно должно быть подтверждения всему " в буквальном и подробном " - смыслах.
Меньше сука Объектов и Классов, методов, свойств, меньше!
Зачем делать вообще копипасты!? На java можно написать крутую динамику реализаций.
<матное слово>, каждый раз компилить ядро? И делать рестарт?
Что-то изменил, а серв включен, " рестарт ", ппц, так всегда, народу не давать играть. ! Обновлять скрипт-код из игры, пусть сервер будет вообще в открытом виде и загружать его и обновлять будет ядро на java.
И привязать " на уникальный юник " каждую область сервера для обновления. А если кто - то играет, ему высветится окошко подождите сервер обновляет " юник " - раздел, а если полный рестарт захотелось, а не по одному, то игроку высветится окошко " Ожидайте восстановление соединения, сервер перезагружается " - действия в игре не будут работать и когда сервер загрузился он восстанавливает " стак сохраненных клиентов которые еще существуют ". Схема большая получится ну ничего зато будет работать автоматически. Главное все грамотно и логично спроектировать, а только потом писать скрипт-код.

Свернуть ↑Развернуть ↓

[linliss]

Сообщение от lin

Donatte, да тут кароче проще потратить времени и переписать, спасибо конечно!
Вариант рабочий но не очень надежный.

оффтопик:

Свернуть ↑ Когда я взял сервер исходников l2jfrozen, l2j, ... их много, не важно какие.
Я лишь посмотрел структуры реализаций, какая-то лучше, какая-то хуже не важно (заключается - это в обработке персонажа, а о входе так никто и не догадался). Структура от <матное слово>, сильно много объектов и методов, вообще глобально не продумана логика построения концепций.
Структуры классов и свойств, методов и реализаций их тел, выглядят так, что пишут лиж-бы было " Нет у нас времени! ". " Времени надо всего то было " - Спроектировать весь проект. И написать аккуратно всю реализацию на 1 персонажа и аккуратный пакетник (авто-контроллер с переданным " xml, json " - со всеми наименованиями) - для обработки динамически, какой нужно когда он запросится. Все оторвано от реализации...
Игровые предметы - вообще ни к чему не обязываются и не привязаны к игровым действиям, их можно получить методом клиента, а не сервера, хоть и работает на сервере. Когда вы пытаетесь отправлять с клиента полученные пакеты " еще хочу ", выполнены уже ранее, можно изменив пакет получить и другие предметы. ! Х. Ну! А если будет невозможно принять, уже приняло?! Пусть не будет получения предметов просто так.
Даже адену не просто так, а придется убить кого-то или сделать, что - то, но, что - бы нельзя вновь было посылать, уже выполнялось и нужно заново. Моб убит и его больше нет или никто не был убит. Не важно должно быть подтверждения всему " в буквальном и подробном " - смыслах.
Меньше сука Объектов и Классов, методов, свойств, меньше!
Зачем делать вообще копипасты!? На java можно написать крутую динамику реализаций.
<матное слово>, каждый раз компилить ядро? И делать рестарт?
Что-то изменил, а серв включен, " рестарт ", ппц, так всегда, народу не давать играть. ! Обновлять скрипт-код из игры, пусть сервер будет вообще в открытом виде и загружать его и обновлять будет ядро на java.
И привязать " на уникальный юник " каждую область сервера для обновления. А если кто - то играет, ему высветится окошко подождите сервер обновляет " юник " - раздел, а если полный рестарт захотелось, а не по одному, то игроку высветится окошко " Ожидайте восстановление соединения, сервер перезагружается " - действия в игре не будут работать и когда сервер загрузился он восстанавливает " стак сохраненных клиентов которые еще существуют ". Схема большая получится ну ничего зато будет работать автоматически. Главное все грамотно и логично спроектировать, а только потом писать скрипт-код.

Свернуть ↑Развернуть ↓

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

[Donatte]

Сообщение от lin

Donatte, да тут кароче проще потратить времени и переписать, спасибо конечно!
Вариант рабочий но не очень надежный.

оффтопик:

Свернуть ↑ Когда я взял сервер исходников l2jfrozen, l2j, ... их много, не важно какие.
Я лишь посмотрел структуры реализаций, какая-то лучше, какая-то хуже не важно (заключается - это в обработке персонажа, а о входе так никто и не догадался). Структура от <матное слово>, сильно много объектов и методов, вообще глобально не продумана логика построения концепций.
Структуры классов и свойств, методов и реализаций их тел, выглядят так, что пишут лиж-бы было " Нет у нас времени! ". " Времени надо всего то было " - Спроектировать весь проект. И написать аккуратно всю реализацию на 1 персонажа и аккуратный пакетник (авто-контроллер с переданным " xml, json " - со всеми наименованиями) - для обработки динамически, какой нужно когда он запросится. Все оторвано от реализации...
Игровые предметы - вообще ни к чему не обязываются и не привязаны к игровым действиям, их можно получить методом клиента, а не сервера, хоть и работает на сервере. Когда вы пытаетесь отправлять с клиента полученные пакеты " еще хочу ", выполнены уже ранее, можно изменив пакет получить и другие предметы. ! Х. Ну! А если будет невозможно принять, уже приняло?! Пусть не будет получения предметов просто так.
Даже адену не просто так, а придется убить кого-то или сделать, что - то, но, что - бы нельзя вновь было посылать, уже выполнялось и нужно заново. Моб убит и его больше нет или никто не был убит. Не важно должно быть подтверждения всему " в буквальном и подробном " - смыслах.
Меньше сука Объектов и Классов, методов, свойств, меньше!
Зачем делать вообще копипасты!? На java можно написать крутую динамику реализаций.
<матное слово>, каждый раз компилить ядро? И делать рестарт?
Что-то изменил, а серв включен, " рестарт ", ппц, так всегда, народу не давать играть. ! Обновлять скрипт-код из игры, пусть сервер будет вообще в открытом виде и загружать его и обновлять будет ядро на java.
И привязать " на уникальный юник " каждую область сервера для обновления. А если кто - то играет, ему высветится окошко подождите сервер обновляет " юник " - раздел, а если полный рестарт захотелось, а не по одному, то игроку высветится окошко " Ожидайте восстановление соединения, сервер перезагружается " - действия в игре не будут работать и когда сервер загрузился он восстанавливает " стак сохраненных клиентов которые еще существуют ". Схема большая получится ну ничего зато будет работать автоматически. Главное все грамотно и логично спроектировать, а только потом писать скрипт-код.

Свернуть ↑Развернуть ↓

А чем вас не устраивает существующая модель кода?

[lin]

Сообщение от linliss

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

Ничего лишнего обновляться не будет и даже не то, чтобы не будет, а будет выводиться в случаях " мошенничества игрового ", которое делать нельзя, кроме того, что имеется.
А работает как оно есть.
Если попытается, что - то получить со стороны клиента, сервер ему это не даст сделать, высветится сообщение " последующие попытки могут привести к бану ".

Сообщение от Donatte

А чем вас не устраивает существующая модель кода?

Нет логики скриптов, написано от <матное слово>.
Да и просто хочется переделать , для себя...
На какие либо продажи я не хочу делать, просто, что то сел и захотелось именно эту игру и именно interlude, в других мне не нравится, ушло куда-то, в жопу. Игровая блуда начинается, нет линии игры, нет смысла все одно типичное. Игра желает лучшего, но не в сторону наворотов и это должно быть главное, всего должно быть в меру. Иначе получится <матное слово>

[Donatte]

Сообщение от lin

Ничего лишнего обновляться не будет и даже не то, чтобы не будет, а будет выводиться в случаях " мошенничества игрового ", которое делать нельзя, кроме того, что имеется.
А работает как оно есть.
Если попытается, что - то получить со стороны клиента, сервер ему это не даст сделать, высветится сообщение " последующие попытки могут привести к бану ".

Нет логики скриптов, написано от <матное слово>.
Да и просто хочется переделать , для себя...
На какие либо продажи я не хочу делать, просто, что то сел и захотелось именно эту игру и именно interlude, в других мне не нравится, ушло куда-то, в жопу. Игровая блуда начинается, нет линии игры, нет смысла все одно типичное. Игра желает лучшего, но не в сторону наворотов и это должно быть главное, всего должно быть в меру. Иначе получится <матное слово>

В одиночку менять архитектуру сервера это тарифный план "прощай молодость". Но если вы горец и у вас есть на лень пару веков, то всегда пожалуйста. Только учтите, писать нужно с нуля, иначе обрастёте костылями.

[lin]

Сообщение от Donatte

В одиночку менять архитектуру сервера это тарифный план "прощай молодость". Но если вы горец и у вас есть на лень пару веков, то всегда пожалуйста. Только учтите, писать нужно с нуля, иначе обрастёте костылями.

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

Ага еще производительней на каждом ходу писать player == null или еще производительнее писать постоянно instanceof. ОХ какая производительность будет прям ммааа...