Zander_driver

@abramcumner А они тебе хорошо платят за то, что ты бегаешь по форумам и выпрыгивая из штанов, их защищаешь? кмк, за такое самоунижение полагается премия.

Я даже запустил проверил. И таки действительно да, есть такой баг. Это не то что планировалось, но сейчас действительно так. На момент создания этой галочки в меню, все работало корректно. Но это было в каком-то ЗБТ-патче еще до выхода 0.8.1. А после видимо сломалось и никто не заметил. Ну что ж, поправим.

Сложность понизить ниже мастера, и включится. Та строчка в движке находится. Потому что они на старте Новой Игры записываются в сейв, и с этого момента читаются из сейва прохождения игры, а не из юзера. В юзере/главном меню, именно стартовые настройки. Они только на старте и читаются.

Это было ожидаемо, вопрос был лишь - когда. Не парься, моддинг живет не только на гитхабе. И вообще некоторые проекты без него обходятся

Да, да. У себя уже по-базарили на эту тему... ИМХО - 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++, разумеется.

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