M.A.X.    Вы вошли как гость
Российский Клуб игроков M.A.X.
 
[Новости]   [Новичку]   [Энциклопедия]   [Документы]   [Файлы]   [Игроки]   [Архивы]   [Архив форума]  
[Новый сайт]   [M.A.X. Gold]   [Партии]  

 
 
 
Архив форума  МаксГолд
[Основной форум] [Голосования] [МаксГолд] [Off-Topic]
 


Пояснения.  -  Hruks,  05.07.2010  15:54:31

-Почему в msgutyp mgstring заменён на ansistring?
Потому что msgu хранит не отдельное сообщение, как ожидалось, а набор сообщений (склеиваются в msgu_set). И список их может доходить до десятка (куча заводов активно построили что-то на данном ходу).
Сами сообщения не длинные, но когда их несколько - лимит в 255 символов легко перекрывается. Установить стринг выше 255 тоже не даёт с этими настройками - пришлось воткнуть Ansi. Система сообщений требует переделки кардинальной, так что пока это заглушка, чтобы сообщения вообще высвечивались.


-Не понял, зачем меняется функция getdirbydp в mgcalcs. Предложение 5805?
Я по номерам как-то плохо ориентируюсь :)
Вообще менял её так как надоело, что юниты разворачиваются криво :) Ессно, для соседней клетки всё ок, а вот если разворачивается на расстояние, то угол считается очень грубо. Я чуть улучшил поворот.


-В чём смысл изменения функции mg_isadb в sdiauxi.pas ? unitsdb.num обязан быть равным индексу записи.
Не знаю кому там кно чего обязан, но очень простой пример: Берём редактор юнитов, запускаем и смотрим его параметр Номер. Он равен 78. А вот в отсортированном по этому номеру списке (не фильтрованом конечно) он под номером 69.
Теперь смотрим в отладчике, чему равен mg_game.unitsdb_cnt... Эта переменная равна 78. А проверки делаются по этот каунтер. И как раз в списке юнитов в редакторе 78 позиций.
То есть список рваный, но массив этого не учитывает.
Например нет в базе юнита с номером 5. А вот 5й по счёту это Радар. Но его номер 6. К истребителю набирается аж 9 пропущенных позиций. А у штурмовика чужих расхождение 77 против 86.


-maxg.dpr 514, зачем там system.writeln?
Потому что в файле bochs.pas тоже есть такой файл. Его мне просто нужно выкинуть из uses секции. Всё равно этот файл я не меняю и ценности в проекте у него нет.


-И про расписку юнитов в заголовке того-же файла ты мне так и не объяснил.
Ну я тебе уже говорил. У меня с таким вот включением юнитов, как у тебя было не работает поиск в файлах проекта и список файлов по Ctrl+F12 тоже не показывается.
Осенью потом вернёшь назад. Я до этого мёржил этот список в своей локальной копии, но что-то много было изменений в файле maxg.dpr и я упарился туда сюда дельту гонять. Вот и решил на своём бранче закомитить.
Кстати, я вообще не понимаю, как тебе этот список uses модулей может не нравится. Я его обычно даже не замечаю. Я вообще просто так вот подряд исходники не смотрю.
И ещё, у Delphi есть древние ьаги - количество строк кода в файле проекта ограничено. Причём баги при превышени лимита начинают появляться спонтанно и в самых непонятных местах. Так что давно уже приучил себя, что файл проекта это очень маленький файл - костяк проекта. Всё остальное в отдельных модулях. Это я к тому, что по хорошему этот файл вообще в процессе жизненного цикла проекта и меняться-то не должен - только при добавлении новых модулей. Так что чего смотреть этот список - ума не приложу :)


- Для справки - я не люблю короткие и непонятные имена переменных, я нелюбли длинные и бессмысленные. Поэтому не надо извращаться в ключе array[fb_b-1..fb_e-1] и mg_game.reslvl
Ну я бы 90% твоих переменных назвал извращениями :)
Что до моих попыток подражать твоему стилю. Лучше назнать fb_begin и fb_end?
А mg_game.reslvl чем не угодил? Это resources Level. В чём отличие от plrpas, resmap, stgold и humplr, которые там рядышком?


-Зачем //Frame buttons пронумерованы таким странным образом и с завитком под enum? Если вводить константы, то вместо костыля стоит делать сразу по-нормальному, а если это портит сохранёнку - пока не делать
По нормальному это как? В чём разница от pt_landonly, pt_landcoast и так далее?
Или ты про дополнительные fb_b и fb_e, которые границы задают? Дык это стандартный шаблонный приём. Позволяет при расширении диапазона не менять в куче мест кода.
Ну и самое главное. Имена констант можно заменить в пару кликов во всём проекте вообще без ущерба для проекта. Так что переименовать константы это дело вкуса. В отличии от магических чисел, раскиданных по всему коду.
Енумов я у тебя в коде не видел, и мои енумы ты погрохал, поэтому подстроился под тебя - через константы, благо хоть из ты иногда используешь. Они менее безопасны, но если писать аккуратно, то тоже хороши.


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

- А вообще после более внимательного просмотра общее впечатление приятное, спасибо за помощь.
Да ладно. Я правда старался. Добыл, кстати, форматилку кода... Код конечно читается лучше, но тотальный копипаст и зашифрованные идентитфикаторы вкупе с вё ещё повсеместными магическими числами сводят все старания на нет.

P.S. Ну зачем рассчитывать добычу всего комплекса на каждом кадре при отображении статуса юнита? Почему такие простые вещи не кэшировать в самом юните? И пересчитывать один раз на смену конфигурации комплекса или трансфера ресурсов?