Zander_driver

Да, да. У себя уже по-базарили на эту тему... ИМХО - OGSR имеет смысл приготовиться.

Ну сгущать краски-то не надо. Апдейт актора и большинства объектов в X-Ray, по частоте не превышает фпс игры. Т.е. иными словами, апдейт работает с частотой фреймов рендера. И тогда это условие обрабатывается раз в ~16мс (при 60 фпс, например). Процессоры работают на частотах в несколько гигагерц, т.е. 1 такт длится сотни пикосекунд. Так что тактов процессора за один апдейт пройдет порядка сотен миллионов. И один раз в каждые несколько сотен миллонов тактов, процессор будет заниматься перепроверкой этого условия. Это не хорошо, но все же это не каждый такт Очень далеко не каждый. В остальном согласен

Почему? Сохранение как раз и в вашем коде выше работает. Там чтение из сейва не работает. А где именно начудил, я же и показал уже в посте выше. Про то что лучше использовать get_stored_vars(), а не пстор, тоже уже сказали (Я не знал что вы OGSR используете). На OGSR, пстор вообще ни для чего не нужен. Так а что еще нужно то? Это всегда хуже. Но, может автор так хочет не допустить того что юзер сам ручками в консоли свои значения впишет. Апдейт тут же скинет как было...

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

@boneset-hq Опять смотрим в движок... void CUIMMShniaga::CreateList(xr_vector<CUIStatic*>& lst, CUIXml& xml_doc, LPCSTR path){ * * * for (int i = 0; i < nodes_num; ++i) { st = xr_new<CUIStatic>(); st->Init(0,0,m_view->GetDesiredChildWidth(), height); // Вот кнопка создается st->SetTextComplexMode (false); st->SetTextST(xml_doc.ReadAttrib ("btn", i, "caption")); // Вот ей читается текст, из конфига if (pF) st->SetFont(pF); st->SetTextColor(color); st->SetTextAlignment(CGameFont::alCenter); // А вот ей ставят выравнивание, принудительно хардкодом. Игнорируя конфиг. // st->SetTextAlignment(CGameFont::alLeft); st->SetVTextAlignment(valCenter); st->SetWindowName(xml_doc.ReadAttrib("btn", i, "name")); st->SetMessageTarget(this); lst.push_back(st); } xml_doc.SetLocalRoot(xml_doc.GetRoot()); } "Скажем спасибо ПЫС" - эти кнопки, в части выравнивания, игнорируют что написано в конфиге, и выравниваются принудительно по центру кодом в движке. Чтобы это переделать, надо поменять одну строчку в движке (прочитать выравнивание из конфига), и собрать движок. Перед кем? И за что? Не вижу в твоем посте иных глупостей, кроме просьбы прощения за непонятно что.

Раньше и трава была зеленее, и девки красивее. Оно и понятно - они моложе были.

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

С бубном - будут. Обязательно.

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

Ну, это другими словами то же самое. Ну, Да. Только нафига?) У меня был такой опыт - я взял микроконтроллер с 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 рад что появились на амк. Теперь хоть информативнее будет. Ну и, тему жду с нетерпением, т.к. вопросы остались.

Нет.