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

[abramcumner 1 234]

OGSE.

В ОГСЕ не использовали храи, спавн собирали асдс. Для простановки правильных гв/лв был специальный скрипт.

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

Настолько, чтобы не писать скрипты квестовики в сталкере не отделяются даже с использованием СДК. Но да, с использованием СДК многое меняется.

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

Тяжелее - надо будет поменять ЛЕ и скрипты вывода координат в сталкере, чтобы выводили глобальные координаты. Изменено 20 Августа 2015 пользователем abramcumner

[abramcumner 1 234]

Карлан, UnLoaded, так как я полностью запутался. Как-то все обобщу.

При работе в СДК вообще нет такого понятия как геймвертексы/левелвертексы(гв/лв). Их там даже ни увидеть нельзя, ни задать.

Их видишь или разобрав спавн асдс или выводя скриптом в игре. В СДК как раз пользуешься тем, про что я и говорю: координаты и имя локации.

 

До гв/лв дело доходит когда что-то пытаешься заспавнить в игре. Это ли из-за неиспользования СДК или из-за того, что средств СДК недостаточно.

И здесь уже почему-то координат и уровня недостаточно. На мой взгляд неправильный дизайн луа апи движка.

 

Про ОГСЕ и вейпоинты:

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

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

[abramcumner 1 234]

@abramcumner, я уже сам запутался, как раз из функций alife():create, я не об асдс речь веду.

Проблему со скриптовым спавном в ОГСЕ я видел такую: куча скриптового спавна. Когда менялись локации, то съезжали гв/лв вертексы.

Координаты особо не менялись.

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

Если спавн собираешь ЛЕ/храи, то вейпоинты хорошее решение.

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

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

[abramcumner 1 234]

Нет это не так. Просто он еще не все потроха выложил А мы то стрим готовили. А все вот-вот расскажут на пальцах и без нас.

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

 

Zander_driver, у вас тоже спавн по вейпоинтам? И ставите их не в сдк?

[abramcumner 1 234]

Тут вроде железное табу.

В смысле табу?

КД собирал хрлц под х64, Трон собирает сам движок под х64.

[abramcumner 1 234]

@Карлан, я тоже про сам движок. Трон его собрал под х64.

[abramcumner 1 234]

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

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

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

[abramcumner 1 234]

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

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

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

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

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

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

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

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

 

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

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

[abramcumner 1 234]

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

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

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

 

 

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

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

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

 

 

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

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

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

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

 

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

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

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

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

[abramcumner 1 234]

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

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

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

 

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

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

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

[abramcumner 1 234]

Что лучше использовать - MessageBox или ::MessageBox?

Смотря что тебе нужно. Загугли global namespace и области видимости в с++.

 

Также и с _tWinMain, wWinMain и просто WinMain. Я пишу код под ASCII, но при этом использую _tWinMain, но при сейчас хочу переехать на Юникод.

С _tWinMain все правильно делаешь. Хочешь, поставь курсор на него и выбери go to declaration. Посмотришь, куда ведет и как все эти винмейны связаны между собой.

 

но с этим пока решено бороться костылем (0, L"", 0, 0);

Чой-то это костыль? Нормальная конструкция с++, загугли с++ string literal. Возможно тебе будет полезен макрос _T(x).

[abramcumner 1 234]

@HESH, читал статью: http://habrahabr.ru/post/164193 ?

[abramcumner 1 234]

Что такое "FG"? Очередной секретный мега-проект?

[abramcumner 1 234]

файлами вида gamedata.db~resources0,

Ужасно

[abramcumner 1 234]

if (!a || !b || c)

[abramcumner 1 234]

В общем, мне не нравится программировать на С++ из-за больших проблем с компиляцией, и сложностей распространения, людям проблематично скачивать огромные студии и компилировать проекты по 40 минут только одна xrGame.dll,

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

 

да ещё для ТЧ, ЧН, ЗП надо разные студии (2008, 2010, 2013, 2015 для разных проектов), а это около 17-19 ГБ живого веса.

С++ не виноват в бардаке среди разных проектов. Все можно собирать в одной студии.

 

Не чета простому проекту XRay-Extesions_portable с жалкими мегабайтами и моментально компиляцией (17 сек для ТЧ для xrGame.dll). Это я про конкуренцию ассемблера и С++ в рамках проекта модинга движка.

C++ можно использовать и в xray-extesions. Экспортируешь нужные символы в с++, используешь метки и naked-функции. А линкеру неважно какие объектные файлы собирать, полученные из асма или с++.

 

А еще можно баллистику вынести в отдельную статическую библиотеку и компиляция будет те же 17 секунд

Изменено 3 Декабря 2015 пользователем abramcumner

[abramcumner 1 234]

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

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

 

Раз решает сложно, а получается неправильно, значит замахнулся выше своих навыков, опыта и понимания. Бывает...

И у Алпета и в ОГСЕ как бы все работает. Не работает совсем у другого программиста. Возможно он не до конца разобрался. Изменено 23 Апреля 2016 пользователем abramcumner

[abramcumner 1 234]

Сложный путь, это именно изучения С++, и студии в частности, среда разработки очень простая у меня, изучать даже ни чего не надо, я все силы бросаю на сам код, хотя программировать на ассемблере сложней чем на С++, но это только для программиста который освоил С++ и саму студию. Для меня как раз сложный путь это программирования на С++, в качестве примера когда надо было изучить базу данных наследования, я смотрел код smart_cast.cpp и... ни хрена не понял как он работает, я во обще не понял как он работает, абсолютна, так что ассемблер рулит, он круче С++, просто потому что ПОНЯТНЕЙ!!!!!!!!!

Именно так и думают те мифические программисты, идущие сложным путем.

И именно так говорил в свое время Алпет, ну можешь ассемблер заменить на паскаль

 

smart_cast.cpp для изучения наследования вообще не нужен. Для этого смотрят на объявления классов.

[abramcumner 1 234]

@Malandrinus, нет-пакет - это просто буфер с удобными методами для записи в него. Какая разница как он называется.

Можно написать над ним обертки для паковки/распаковки конкретных сообщений.

Обмен сообщениями между объектами - это хорошо. Надо и дальше его развивать. Выкинуть g_actor.

 

Оффлайн/онлайн и два вида объектов нужны по-любому. Это очень здравая идея.

 

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

 

> сетевая архитектура движка

-

Все эти сообщения, объекты и все такое - это зародыш многоагентной системы. Это один из тех элементов, из-за которых мне нравится сталкер.

 

> разные среды разработки (и в сущности разные языки) самого движка и SDK

+

Вообще это не очень плохо. Луа, с++, шейдеры, конфиги, хмл как-то переживаются. Проблемы в билдере.

Сам пробую перенести СДК в студию, пока все печально.

 

> архитектура, основанная на dll, а не на статических библиотеках

+

Тут плохи не сами длл, а то, что движок по факту монолитен, но раскидан по разным длл.

Достаточно легко можно собрать один экзешник, но зачем?

 

> разные версии рендера

+

Но они по-любому будут. Уберешь р1, добавятся как минимум р5(дх12) и вулкан.

На гитхабе к примеру пилят опенгл рендер. Главное меню заводилось полгода назад.

 

> абсолютная недокументированность кода

+

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

[abramcumner 1 234]

Как там кстати дела у Сурвариума? Они уже запилили монстров в свою игру?

По-моему нет. Но я за ним не слежу. Пока там не будет условно говоря ПВЕ, он мне не интересен.

 

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

Моё сугубо личное мнение, что это достаточно бесперспективное занятие.

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

Глобально если смотреть, переносу на другие платформы мешает только ДХ. Если осилить рендер, то остальное по сравнению с ним ерунда.

Кооп - мне кажется, все хотели бы пройти сталкер в коопе

 

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

Skyloader делает что-то похожее(на скрине видна сетка и вейпоинты???) на базе встроенного ЗПшного редактора погоды.

 

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

 

В OpenXray сделали отдельные xrAICore, xrScriptEngine. Читал кстати обсуждения там?

 

Статические либы и единый экзешник вообще технический вопрос. Должно собраться без сильных правок.

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