Курилка программистов

[Allender 11]

Здравствуйте!

Уважаемые, @Malandrinus, @xStream,

прочел ваши обсуждения – сложилась впечатление, что все же, несмотря на 2015г, что-то еще делается для сталкера? Не очередная "солянка", а новое-новое по возможностям движка/скриптов?

Видел проект XRayEx до моменты открытия исходников. Сейчас ведутся какие-то работы по расширению возможностей движка (используя исходники, с полной/частичной компиляцией)? Где можно посмотреть/почитать?
Если запрещено правилами, просьба к модераторам вырезать абзац.

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

[Allender 11]

@Dennis_Chikin, ура, теперь стала понятна мысль, которую обсуждаете.

А что мешает сесть и написать прослойку между существующими вызовами и движковыми функциями, в которой будет стек вызов на удаление, перемещение, потерю предметов и тд?

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

Например, поймали  on_drop, это же колбек на потерю предмета, ловится через bind.stalker? Если да, то как в примере выше, предмет пытаются удалить две функции. Обе добавили вызов на удаление в стек "прослойки". Далее, все просто... система взяла вызов из стека обработала (удалила) предмет, и выкинули из стека все вызовы на удаленный объект. 

[Allender 11]

Здесь - смысла в таком нет. Хоть и через ивенты, но ваши исполняемые действия выглядят именно так как в приведенном примере. Хотя каждому "подписчику", нужен вполне определенный предмет, и не нужны все остальные.   Ну неужели так сложно сделать хотя бы так _g.script item_reactions = {     matras = function(obj)          end,     medkit = function(obj)          end,     bandage = function(obj)          end     ... } колбек на дроп или где там у вас производят это дело ивенты

 

Не есть хорошо. Например тебе нужны бинты и аптечки, а мне моя секция [beer], все равно придется править _g ручками.

 

 

self.am:call("on_drop_"..obj:section(), obj, sobj)

--Тогда для в модуле для подписки на событие дропа аптечки сделаем так:
function attach(sm)
    sm:subscribe({signal = "on_drop_medkit", fun = this.on_medkit_drop})
end
function on_medkit_drop(obj, sobj)
end

self.am:call("on_drop_"..obj:section(), obj, sobj) -- дроп предмета с секцией
self.am:call("on_drop_"..obj:clsid(), obj, sobj) -- дроп предмета какого-то класса
self.am:call("on_drop_"..(obj:mass() > 10 and "heavy" or "lightweight"), obj, sobj) -- дроп предмета массой больше/меньше 10-и кг 

 

А вот так можно?

function handler(obj)
	if obj.clsid = "WP_LR300" and ... then
		script.onDropSpecial();
	end
end

function onDropSpecial()
end

-- где-то...
self.am:call(loadstring("script.handler("..obj..")")); -- дроп предмета (неважно какого), обработчик разберется

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

 

-- upd:

Пардон, глупость написал с ..obj... Нужен же сам объект. Поправляюсь:

 

-- где-то...
self.am:call(loadstring("script.handler("..obj:id()..")")); -- дроп предмета (неважно какого), обработчик разберется

-- и в script
function handler(sId)
    obj = alife:object(sId);
    ...
end

Изменено 6 Февраля 2015 пользователем Allender

[Allender 11]

@Viнt@rь, 

Можно написать класс, который хранит поле с координатами конечного местоположения, поле в котором хранится либо массив всех промежуточных местоположений, либо просто текущее.
И уже его хранить в mSetting. Доступ к нему будет из всех диалогов. Выглядеть примерно так:

 

 

class Position() {
    private double[] finalLocation;
    private double[] currentLocation;
    private boolean arrived = false;

    public Position(double lat, double lon) {
        finalLocation = new double[] {lat, lon};
    }

    public void setPosition(doulbe lat, double lon) {
        currentLocation = new double[] {lat, lon};
        if (currentLocation[0] == finalLocation[0] &&
            currentLocation[1] == finalLocation[1]) {
            arrived = true;
        }
    }

    public boolean isArrived() {
       return arrived;
    }
}

// в диалоге
Position position = new Position(10.0, 10.0);
// если местоположение изменилось 
position.setPosition(location.getLatitude(), location.getLongitude());
// прибыли на место?
if(position.isArrived()) {
   ...
}

 

 

 

 

 

В итоге в будущем приложение может использовать одновременно и координаты текущего и конечного местоположения, да и при том в границах одного метода, например для сортировки по дистанции(радиусу) от пользователя до конечного адреса.

Метод можно написать в том же классе. Или нужно что-то другое?

Изменено 7 Февраля 2015 пользователем Allender

[Allender 11]

@Viнt@rь, 

"Так вот как его готовить нужно!"

Базовый класс с логикой диалога. Два наследника, один из которых реализует показ кнопки с методом получения координат, а во втором показываем финальный результат.

Если на примере JComponent, там просто переопределяется метод paintComponent(), чтобы задать свою отрисовку. По-аналогии сделать содержимое диалога. Так не подойдет?

Изменено 7 Февраля 2015 пользователем Allender

[Allender 11]

 

 

Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию.

 

это все же венгерка, вернее ее очень малая часть

Точнее, основная идея венгерки.   Выглядит, эм, несколько странно в java, верблюд мастхэв. Да и Сode Conventions дает однозначную рекомендацию:

 

Naming
If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.

 

 

@Viнt@rь,

Ааа, любимая IDEA с dracula. 

 

@xStream, 

А можно по наглеть, попросить небольшую заметку по разработке проектов написать? Как нужно, как не можно делать, как принято.)

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

Или в книжку тыкнуть носом. 

[Allender 11]

@Desertir, 

Пардон, я слишком абстрактно выразился. Немного не то. Инструменты под задачи это отдельная, интересная тема.

Я вот про что, если перечитать тему, можно набрать с десяток "советов" как не нужно делать. Вот это было бы интересно.)