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

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

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

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Карлан 1 049]

написал кто-то не подумавши

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

Изменено 21 Августа 2015 пользователем Kirgudu

[abramcumner 1 141]

abramcumner, спасибо, я не знал. ТЧ? Просто если не ТЧ, то не удивительно, другими я не интересуюсь, и в своих постах только о нем и говорю .

Не знаю. У него есть репозитории ТЧ и ЧН, но там х64 нет. На других форумах(ГМ) он говорит, что х64 запустил.

Tron здесь и сам появляется - может расскажет.

[Dennis_Chikin 3 658]

Практика показывает что к единому все равно не придут.

 

Чтобы куда-то прийти - надо это самое что-то сначала иметь.

Зайду издалека, и, заодно, слегка намекну на поле напаханное:

 

Вот многие ли из здесь присутствующих ПОЛНОСТЬЮ прочитали "справочник по функциям и классам", и активно пользуются прочитанным ? Прежде чем бить себя пяткой в грудь, прошу чуть-чуть подумать. То есть, вот именно оттуда ли все, чем пользуетесь, или ?

 

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

Ну вот кто знает, как, например, работает ВСЕ, относящееся к memory object ? Ага, я на disable прежде всего намекаю.

 

Меж тем, есть исходники, в которых кто-то копается. "Из интереса". А справочник - и ныне там.

 

Вот хотя-бы, дописать недописанное, расписать подробности, сделать версию не как сейчас "если вы видите в коде неведомую фигню, то возможно, в теме вы найдете - ЧТО ЭТО", а с группировкой по назначению/функционалу.

 

Как минимум, сразу станет видно, что надо поправить/добавить в движок.

 

То есть, range() например, есть, а остальное  конфиговое ? Что сейчас эмулируем через range() в апдейтах.

Далее, да, сколько лет жуем темы всяких "хранилищ", прости-господи, сотворили целое rvp с какими-то файловыми системами, и при этом - до сих пор не имеем средства сохранить произвольному объекту произвольные данные (custom_data -  это ни разу не произвольные).

Далее, разные наименования методов для game и se-объектов, делающих одно и то же, ни кого не смущают, нет ? Сначала проверяем тип объекта по отсутствующим методам (вместо того, чтобы иметь нормальный флажок), а потом... Кстати, какого, вообще, дергать метод, со всеми его накладными расходами, если он возвращает константу ? Что, сразу по людски нельзя ?

Ну и можно продолжать до бесконечности.

 

В общем, пользуются тем, что, во-первых, ЗНАЮТ, во-вторых - как могут. Вот вам и все "мнения".

 

Аналогично, кстати, со скриптовыми велосипедами. Справочника - нет, совместимости - нет, вот и ага.

Изменено 21 Августа 2015 пользователем Dennis_Chikin

[Полтергейст 37]

Как минимум, сразу станет видно, что надо поправить/добавить в движок.

Для начала, достаточно составить список того, что НЕ РАБОТАЕТ так, как предназначено (зависает, вылетает, или просто ничего не делает). Затем внести правки, которые это исправляют, и выложить собранный по этим исходникам движок. И только ПОСЛЕ этого уже пытаться добавлять какой-то новый функционал, не забывая описывать существующий. Как-то так.

 

Далее, разные наименования методов для game и se-объектов, делающих одно и то же, ни кого не смущают, нет ?

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

function game_object:section_name()
    return self:section()
end

[Murarius 10 531]

 

 

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

Я вот не то чтобы даже поддерживаю, а просто на все сто согласен. В 2015-м актуальность этого ничуть не меньше, чем в 2008-м. И примеров такого отношения к делу, кстати говоря, в 2015-м ничуть не больше, чем в 2008-м. Единичные случаи.

[Zander_driver 10 331]

Вот многие ли из здесь присутствующих ПОЛНОСТЬЮ прочитали "справочник по функциям и классам", и активно пользуются прочитанным ? Прежде чем бить себя пяткой в грудь, прошу чуть-чуть подумать. То есть, вот именно оттуда ли все, чем пользуетесь, или ?

 

Во всяком случае это самый полезный ресурс в сети, какой мне известен)

Что ты предлагаешь, Денис? прочесать этот ресурс с граблями и лупой, выявить все неясности и неточности в описаниях того или иного, все протестировать, проверить, выяснить как оно работает и написать...

Да я сам не весь его прочитал. Но вот как то знаешь, когда у меня возникали вопросы "а как сделать, чтобы..." - я первым делом шел туда. В большинстве случаев - ответ прямой или косвенный, в виде наводки, находил. И в большинстве случаев написанное там работало.

А прочесывать тонну методов на которые раз в пару лет кто-то обращает внимание - какой имеет практический интерес?

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

[Dennis_Chikin 3 658]

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

 

1. Прошерстить, и ответить, наконец, на все проклятые вопросы.

2. По результатам п1 будет сразу видно, чего в него добавить. Или не добавить.

[Zander_driver 10 331]

 

 

Во-вторых, да, я вот не вижу абсолютно ни какого понимания того, что можно и нужно делать скриптами, а что - переносить в движок. То есть, оно у каждого какое-то есть, но свое, и весьма интуитивное.

А у тебя самого это понимание есть? хоть приблизительно. И менее интуитивно.

 

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

В сотый раз кстати замечу - Для адекватной работы, просто для удобства мододелов. А вовсе не для реализации того что лично мне хочется.

И больше всего веселит тот факт что методов этих как не было так в основном и нет, и никто их похоже делать не собирается.

 

Какой можно из этого сделать вывод... те кто ковыряется в движке, занимаются этим либо из спортивного интереса лично для себя, либо просто понятия не имеют / знать не желают о том что может быть реально полезно для мододелов, а что просто фича для того чтоб сказать "вау, смотрите что я сделал".

 

Я кстати пытался Судьбу Зоны на новый движок пересадить) после всяческих танцев с бубном по обрывочным или просто отсутствующим инструкциям, игра рушится с нигде не описанными, неинформативными вылетами.

 

 

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

Имхо, вообще не очень эти пункты связаны. Отчасти п2 можно делать до 1-го, потому что многого тупо не было и нет, как уже было сказано выше. А кроме того, ответ на "проклятые вопросы" вовсе не обязательно прояснит функционал движка. Любопытство утолит - да. Что-то большее - далеко не факт.

[abramcumner 1 141]

И больше всего веселит тот факт что методов этих как не было так в основном и нет, и никто их похоже делать не собирается.

Какой можно из этого сделать вывод... те кто ковыряется в движке, занимаются этим либо из спортивного интереса лично для себя, либо просто понятия не имеют / знать не желают о том что может быть реально полезно для мододелов, а что просто фича для того чтоб сказать "вау, смотрите что я сделал".

Это же жесть какая-то. Вы вообще о чем?! Может так:

И больше всего веселит тот факт что скриптовых функций этих как не было так в основном и нет, и никто их похоже делать не собирается.

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

Денис ужасается, что никто ему что-то не разъяснил о memory_object`ах. Zander_driver`у каких-то методов не хватает.

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

В движке делают то, что реально полезно для делающего. Ровно так же, как пишут скрипты, которые реально полезны для пишущего и вносят правки в конфиги, которые реальны полезны для вносящего.

 

Я кстати пытался Судьбу Зоны на новый движок пересадить) после всяческих танцев с бубном по обрывочным или просто отсутствующим инструкциям, игра рушится с нигде не описанными, неинформативными вылетами.

Что делал? Что за вылеты? Никто не знает. Или опять же должны были протелепать и написать в справочник именно про твои вылеты?

[Zander_driver 10 331]

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

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

И больше всего веселит тот факт что скриптовых функций этих как не было так в основном и нет, и никто их похоже делать не собирается.

 

Вы это серьезно? скрипты я себе пишу какие мне самому нужны, и проблем с этим не испытываю.
 

В движке делают то, что реально полезно для делающего. Ровно так же, как пишут скрипты, которые реально полезны для пишущего и вносят правки в конфиги, которые реальны полезны для вносящего.

 

Ну пожалуй можно сказать что да, все так и происходит. Только почему-то на то, чтоб стало удобнее всем троим, никто внимания не обращает.

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

Изменено 21 Августа 2015 пользователем Zander_driver

[RayTwitty 492]

 

 

по использованию предмета в инвентаре вызывалась моя функция?

Колбек на юз в бинд сталкере.

[abramcumner 1 141]

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

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

Жуть Начиная с того, что материал достался от ГСЦ и почему-то без описаний вылетов и условий. И заканчивая тем, что я даже не представляю, как теоретически я могу описать вылеты, которые будут происходить у тебя.

 

 

Конечно с вылетами моими, никто кроме меня разбираться не обязан, я и не собирался просить о таком

Здесь то же самое, что и у Дениса. Копите, копите в себе мемори_обжекты и вылеты. А потом: "Почему их никто не описал". Да потому, что никто кроме вас о них не знал.

Ну и как бы, если какие-то вылеты победил, где твое описание вылета и причин?

 

 

Вы это серьезно? скрипты я себе пишу какие мне самому нужны, и проблем с этим не испытываю.

Ну пожалуй можно сказать что да, все так и происходит. Только почему-то на то, чтоб стало удобнее всем троим, никто внимания не обращает.

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

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

 

Только почему-то на то, чтоб стало удобнее всем троим, никто внимания не обращает.

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

Взять тот же инвентарь: в xp-dev репозитории к нему добавили кучу коллбеков. И если тебе не подходит стандартный и там нет того, который подходит тебе. То думаю, добавили бы и твой.

Изменено 22 Августа 2015 пользователем abramcumner

[Dennis_Chikin 3 658]

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

 

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

(Ага, спрашиваю: что делает enable_memory_object() ? У меня оно либо не делает ничего, либо виснет; also, спрашиваю: что у них внутри всех ихних *info ?)

 

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

 

 

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

 

---

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

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

Изменено 22 Августа 2015 пользователем Dennis_Chikin

[abramcumner 1 141]

Ага, спрашиваю: что делает enable_memory_object() ? У меня оно либо не делает ничего, либо виснет; also, спрашиваю: что у них внутри всех ихних *info ?)

Вообще он делает то, что написано: активизирует/деактивизирует объект в памяти(сразу в трех: visual, sound, hit). Причем что-то делает, только если находит этот объект в памяти. Передавать строго game_object.

Виснуть там особо не чему, только если передал кривой game_object.

 

Правда увидеть результаты активизации/деактивизации ты скорей всего не сможешь В списках memory_ххх_objects деактивированный объект по-прежнему выдается, признак активации в скрипты не вынесен, специально активированный объект в списках не появляется.

В движке этот признак проверяется только при добавлении во враги и денжер. То есть "что-то делание" можно заметить, если успеть деактивировать объект до того, как он занесется в список врагов - тогда он не занесется.

Изменено 22 Августа 2015 пользователем abramcumner

[Полтергейст 37]

Ага, спрашиваю: что делает enable_memory_object() ? У меня оно либо не делает ничего, либо виснет

if self.object:memory_time(db.actor) > 0 then
     self.object:enable_memory_object(db.actor, false)
     printf(tostring(self.object:memory_time(db.actor))) -- выведет 0
end

Можно использовать для удаления (отключения?) объектов из памяти. Результат можно проверять по memory_time. Для добавления в память нового объекта использовать не пробовал, возможно, что метод и не предназначено для этого.

upd: точно не предназначено, CVisualMemoryManager::enable ничего не делает, если не находит передаваемый объект в списке видимых.

Изменено 22 Августа 2015 пользователем Полтергейст

[Dennis_Chikin 3 658]

успеть деактивировать объект до того, как он занесется в список врагов

Во-во. Именно это я и пытался делать. Результаты- вышеуказанные.

[Malandrinus 615]

 

is_ammo()

А это в движок надо зашивать?

Можно спросить зачем?

 

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

 

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

[Dennis_Chikin 3 658]

И что у нас таким образом попадет в категорию ammo ?

 

Вот у нас сейчас есть: собственно патроны. С этими понятно все, и я не понимаю, почему до сих пор ни кто (да, помню, отучаемся говорить за всех, но тем не менее таскаемая из мода в мод таблица в _g.script как бы намекает) не вытащил из в class_registrator ?

Заряды для rpg, заряды для подствольников, гранаты (в 4-х ипостасях).

Ага, а еще - заряды для огнемета и какие-то странные заряды для бинокля.

 

Что будет возвращать сия функция для каждого из них ?

 

Вопрос второй: сколько можно плодить китайский код ( function return_true() if true == true then return true else return false end ) ? Почему не obj.cls_id == clsid.ammo, или, точнее, obj.category == IsAmmo ?

[Zander_driver 10 331]

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

Хотя да, магазинное питание внести в движок, пусть опционально - это было бы неплохо.

 

А то там еще какие то странные заряды для темной материи присутствуют в ранних правда, версиях.

Изменено 23 Августа 2015 пользователем Zander_driver

[RayTwitty 492]

Вот у нас сейчас есть: собственно патроны. С этими понятно все, и я не понимаю, почему до сих пор ни кто (да, помню, отучаемся говорить за всех, но тем не менее таскаемая из мода в мод таблица в _g.script как бы намекает) не вытащил из в class_registrator ?

Почему не obj.cls_id == clsid.ammo

Потому что ты проверяешь на соответствие одному классу, а наследуемые на учитываешь.

 

is_ammo() учитывает и наследуемые, хотя конкретно для этого случая таких вроде нет, но например для оружия - is_weapon() просканирует все дочерние классы, а не только CWeapon (предметов на чистом CWeapon в игре вообще нет).