Zander_driver

Никак нет. От алгоритма зависит. Что та "конвертация" с материалом делает. Стесняюсь спросить, а зачем...

Ну, это другими словами то же самое. Ну, Да. Только нафига?) У меня был такой опыт - я взял микроконтроллер с 512 байт ОЗУ (Не мегабайт, не килобайт. Просто байт). И попробовал для него написать сетевой протокол, чтобы несколько таких могли между собой по своей сети обмениваться инфой. Такая ачивка чисто для себя. И знаешь что? У меня получилось. Написал, общаются. Где и зачем это пригодилось? Нигде. Бесполезная ачивка. В проектировании если где-то уперлись в ресурсы одного МК, легко и непринужденно заменяют его на более мощный, который на 5 копеек дороже, или добавляют еще парочку (десятков) контроллеров (чипов). Железа завались. Куда? Ну, Закон Мура потихоньку сходит на нет. Темпы роста вычислительных мощностей - да, падать будут. А сами мощности так и будут расти, хоть и не столь быстро. Т.е. вычислительный флопс будет еще немного дешевле, оперативно-памятный байт будет еще немного дешевле. Ну и с какой бы стати меняться то раскладам цен между работой кодера и производством чипов? Когда и если, ИИ научится писать софт (не просто код! А готовый софт) и вытеснит всех программистов, тогда может быть да. Но, код писать он как бы уже умеет, а программисты без дела не остались.

Подход к программированию другой. Та-ак, думает программист, чтобы это сделать удобно (для возможных последующих доработок/улучшений), надо такие-то классы и такие-то. Им надо такие-то переменные, под которые мы возьмем байтов с запасом, чтоб не иметь потом головной боли, для дебага на всякий случай добавим вон то и вот это, и чтобы не компостировать себе мозги, заюзаем вон те и вот эти библиотеки, вместе со всем что в них включено. В итоге разработка относительно быстрая, код относительно хорошо поддерживается и поддается апгрейду в будущем, а потребление памяти и вычислительных мощностей, кхм, такие от которых в годах 80-х ахнули бы, и "вроде бы" для тех же задач. Но только в современных реалиях флопсы CPU и байты ОЗУ обычно не проблема. И приобретаемое преимущество в удобстве поддержки и обновления софта, стоит того. А тогда времена были другие. Сейчас вычислительная мощность и оперативная память в адекватных объемах достаются относительно дешево. Это доступный ресурс. А работа программиста, получается дороже. Что дороже, на том и экономят. А "выжимать все возможное", как из Спектрума, только из современного железа, потребовало бы очень много очень дорогих человеко-часов.

Поздравляю всех присутствующих с Новым Годом. Прошедший год был небогатым на новости по нашей Судьбе Зоны, так уж вышло. И патча готового к НГ не получилось. Но тем не менее, прошедший год мне видится позитивно. Хорошего было гораздо больше, чем плохого. И мои искренние соболезнования тем у кого сложилось в этом году наоборот. Но вот так. Не угадаешь, где найдешь, где потеряешь... В следующем году, я рассчитываю радовать вас новостями больше и чаще. А еще я уверен, это будут не только новости. С наступающим!

У вас счеты не той системы.

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

Не так же. Мобы (Все бегающие по Зоне мутанты) они живые. От CEntityAlive унаследованы. А Вороны нет. Забавно, но с точки зрения X-Ray, самый близкий родственник вороны - это вертолет. Он тоже не живой.

Очень громкое заявление... Ворона: class CAI_Crow : public CEntity НПС: class CAI_Stalker : public CCustomMonster, public CObjectHandler, public CAI_PhraseDialogManager, public CStepManager // * * * class CCustomMonster : public CEntityAlive, public CScriptEntity, public Feel::Vision, public Feel::Sound, public Feel::Touch // * * * class CEntityAlive : public CEntity Так что, Вороны с т.з. иксрея, даже "живыми" не считаются. Впрочем, я в чужие дела не лезу, хочешь сделать - значит зачем-то надо. Открываешь исходники движка, движковую обвязку вкладки контактов (класс CUIPdaContactsWnd), и вперед. На C++, разумеется.

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

Но и в него, говорят, не все верят.

На данный момент у нас используется оригинальная логика ИИ от X-Ray из-за у нас также остались типичные ограничения на размер AiMap. Но мы планируем добавить поддержку NavMesh в будущем. Т.е. ИИ - это единственное ограничение на использование World Composition. (программа максимум) Не совсем корректно понял вопрос. Но попробую ответь так, как я понял. У нас есть поддержка простых функций для левев скриптов (типа работа с инфопоршнями). У нас Blueprint сейчас не поддерживается, но мы вообще планируем вовсе отказаться от Lua-скриптов. Часть Lua логики перейдет на Blueprint, а часть на C++. (программа максимум) Главным образом вот тут. Решили проблему? Правда? 1) AI от X-Ray, а когда-то потом NavMesh будет (И как тогда будут двигаться NPC? по AI от X-Ray? по NavMesh? Или как это будет работать?) 2) Blueprint не поддерживается, Lua-скриптов не будет, а скриптинг тогда куда? Вы его хотите весь на C++ переносить? И кто это будет делать, и сколько это займет...? Т.е. с ваших же слов. Вы эту проблему (игровой логики) не решили. Даже не написали, как вы это собираетесь решать. Просто подписали (программа максимум). Просто если бы вы эту проблему собирались решать, то с нее бы начали. С вопросами в этой теме закругляюсь, надеюсь ответы в завтрашней теме увидеть. Пока все же вопросов намного более, чем ответов)

@PSI рад что появились на амк. Теперь хоть информативнее будет. Ну и, тему жду с нетерпением, т.к. вопросы остались.

Нет.

Побочные эффекты: Потеря личного свободного времени.

И между делом выяснилось, кто тут больше всех курит

Через движок. А это исходники, Visual Studio, C++, в общем выгоднее опять же взять уже готовый OGSR, чтобы не переделывать с нуля то что там уже давно сделали.

Это верный признак того, что железо пора бы все-таки обновить...

@mole venomous стримов куча, смотри на здоровье)

Методом научного тыка. Тут на форуме есть темка с X-Ray Extensions, как раз для любителей таким заниматься. Там и методы для доступа к определенным байтам клиентских и серверных объектов вроде есть. Скачай, поставь, играйся... Прочитал из объекта тыщу разных чисел и сидишь разбираешься что есть что, для чего, и куда... я в 2014-16 году с этим наигрался. Ну и, строго говоря этими методами пишешь уже не в нетпакет, а непосредственно в объект. Что в каком-то смысле удобнее - избавляет от телодвижений с входом-выходом в онлайн.

А на самом деле да. Смотрел... Ну тут прикольно. Но уже было. Ну вот это красиво, но уже было. Ну вот это да, прям круто сделано, снимаю шляпу, но уже было. ВСЁ уже было. Вот в чем беда сталкера-то.

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

@div обрати внимание: и Эти два действия НЕЛЬЗЯ делать сразу. Тогда ты их просто обнуляешь. Сначала увести в оффлайн. Потом подождать один апдейт. Потом вводить в онлайн. А не сразу-подряд в одном блоке кода.

Вообще если в предельно упрощенном виде. Модуль Артоса читает нетпакет объекта методом STATE_Read, Позволяет изменить там некоторые параметры (Предоставляя более-менее удобный доступ к полям, а не по hex-смещению) Записывает эти параметры в нетпакет методом STATE_Write После чего надо увести объект в оффлайн И затем ввести его в онлайн, чтобы сделанные изменения применились. В принципе, всю эту последовательность действий спокойно делали до всяких Артосо-модулей, правда тогда это выливалось в огромные простыни кода, но тем не менее. Оно работало и в голом виде, и без скриптовых биндеров на серверный объект. А 1.0004 не всем классам позволяет вообще дать такой биндер. И ранние версии Артосо-модулей еще работали на хард-уровне, позволяя просто "читать нетпакет какого-то объекта", и затем "писать нетпакет какого-то объекта", на свой страх и риск, полагаясь на то что юзер знает что делает. Правда, накосячив можно было получить последствия любой степени неожиданности, но это работало с любым объектом. Вообще любым. Да никто ж не спорит. Удобно, и с "защитой от дурака", сделано. Но в 1.0004 нельзя биндер сделать на некоторые вещи. Что тогда?)