[SMD] хакинг Dune: The Battle for Arrakis

[Ti_]

Связал флаг иконки ($FF) с цветами садаукаров. (Точнее с тем, что окажется в pal3).
И для флага (1) цвета не меняются, остаются как в PAL2 - (атрейдес или (фремен, если фрем+сард+орд)) - как в R81b.
Немного подправил и цвета для иконки девастатора devastat(veh).smd.

Добавлено позже:

да я тут чот про Метро подумал... он жеж с 6 домом хотел хак. вот я и подумал что наверное он в эти места задает другие цвета... но можно и убрать.

Так пусть через .asm задает, а то других пользователей только запутывать таким количеством настроек цветов.
И ещё пункты icon special case: у тебя там hurricane/devastator.
Но ведь можно: 1) им не задавать (другой флаг). 2) задать не им, а другим юнитам. 3) задать нескольким юнитам.

[SeregaZ]

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

про metatiles.bin бы понять... как ты сказал блоки по 4 тайла. то есть я не правильно делаю, что пытаюсь правильно расположить кубики в самом game.smd. там ведь получается правильного порядка и нету. это как конструктор лего, лежащий в коробке, из которого по номерам выдергивается нужный номер тайла из инструкций в metatiles.bin. нет ли примера побайтовой рассшифровки этого самого metatiles.bin?

предположил бы что если 360 блоков, а размер файла 11520, то 11520 / 360 = 32 байта на блок чтоль? но чот не то... там должна быть система

Добавлено позже:
хотя чото чото промелькнуло в моей пустой голове... пойду доразмыслю и перепроверю

[Ti_]

про metatiles.bin бы понять... как ты сказал блоки по 4 тайла. то есть я не правильно делаю, что пытаюсь правильно расположить кубики в самом game.smd.

Я сказал 4x4, то есть = 16 тайлов.   

Добавлено позже:

нет ли примера побайтовой рассшифровки этого самого metatiles.bin?

такие же как для спрайтов. (приоритет, #палитры, зеркала, номер тайла).

Добавлено позже:

11520 / 360 = 32 байта на блок чтоль? но чот не то.

вроде всё так. 32 байта , потому что тайл описывается 2 байтами, а не 1.

[SeregaZ]

тут получается смещений на несколько пикселей никаких нет? все четко в знакоместо чтоль? ну тогда вроде в голове мозаика складывается. посмотрим теперь на практике что получится

[Ti_]

тут получается смещений на несколько пикселей никаких нет? все четко в знакоместо чтоль? ну тогда вроде в голове мозаика складывается. посмотрим теперь на практике что получится

В бекграунде нельзя смещать отдельные тайлы. Только весь слой целиком (не считая эффектов засчёт построчного изменения hscroll (точнее там 2 режима per-row и per-scanline), и вертикального смещения целых рядов тайлов) Vscroll:

Код: [Выделить]

Both planes can be scrolled completely, or the VDP can scroll a 2 tile wide column of the name tables at onceВ этом и есть принципиальное отличие фона от спрайтов, которые можно располагать как угодно.

Добавлено позже:

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

ну тогда, прикручивай ещё сразу misc\block_type.asm   

[SeregaZ]

ну теперь карту рисует из ресурсов игры. радости полные штаны.

теперь значит юниты. беру sprites_cfgs.asm. читаю. например тот-же MCV. там он упоминается в трех местах

mcv_spr1:
 incbin   gfx\sprites_gfx\mcv_spr1.smd

понятно вроде. за mcv_spr1 закрепляется файл такой-то.

mcv_tile1   equ   (mcv_spr1-units_spr)/32+base

units_spr? и почему делить на 32? base?

; (число_записей-1), размерX, размерY, смещение_Y, размер_спрайта, номер_тайла+маски, смещение_X
mcv_spr_cfg1:   dc.w 0,   $18, $18, $FFF4, $600, mcv_tile1, $FFF4+4

тут тоже вроде понятно.

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

[SeregaZ]

хотя не... походил тут кругами... подумал - это походу размер файла. и 32 - это 32 байта - размер тайла 8х8, где в 1 байте по 2 пикселя.

после видимо код делает примерно то-же самое, что находится в game.smd - собирает все тайлы всех юнитов в один большой файл. и запоминает все метки.

однако я все-таки недогоняю... как система понимает что конфиги спрайтов для 17 юнита должны начинатся с mcv_spr_cfg1.

[Ti_]

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

В файлах юнита есть номер sprite. Он указывает на номер первого конфига в таблице поинтеров:

Код: [Выделить]

; main sprites ptrs
sprites_offs:В sprites_ptrs.asm

Код: [Выделить]

dc.l NO_LOAD_GFX
dc.l mcv_spr_cfg1|STD_UNIT_SPR

[SeregaZ]

вот например 253 написано, а если считать с sprites_offs то dc.l mcv_spr_cfg1|STD_UNIT_SPR на 508 строчке. может мне надо считать только те строки, где есть STD_UNIT_SPR?

Добавлено позже:
хотя видимо они по 2 штуки идут и номера считать с 0.

Добавлено позже:
но теперь тогда откуда знать, что у харикейна и лазертанка надо игнорировать номер спрайта из файла юнита и искать где-то в другом месте? ведь там номер 121 у обоих. он же у хеви танка. разве не должна система на лазертанке по идее рисовать осадной?

[Ti_]

но теперь тогда откуда знать, что у харикейна и лазертанка надо игнорировать номер спрайта из файла юнита и искать где-то в другом месте? ведь там номер 121 у обоих.

DuneHack r82test версия (апдейт для 81б) :
+ у всех юнитов спрайт берется по номеру из файла юнита (по общей таблице sprites_offs).

[SeregaZ]

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

[SeregaZ]

все. я сдаюсь sprites_ptrs.asm еще ладно. читаю, загоняю в массив и по номеру 253 скажем - мкв - получаю mcv_spr_cfg1. однако в sprites_cfgs.asm все задом наперед. упоминание mcv_spr_cfg1 находится в конце файла. из этой строчки с mcv_spr_cfg1 я получу mcv_tile1, который надо искать выше - напомню файлы читаются сверху вниз. снизу вверх не умеют. эээ... читать 3 раза файл чтоль? или прогонять 3 раза массив? чот как-то ну ваще не улыбается... хорошо нашел mcv_tile1 - mcv_tile1   equ   (mcv_spr1-units_spr)/32+base получил mcv_spr1 - который опять таки выше, а не ниже.

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

отчасти помогло бы деление файла sprites_cfgs.asm на 4 файла в одном только метки и имена файлов:

repair_spr:
 incbin gfx\sprites_gfx\repair.smd

в другом математика:

rep_tile equ (repair_spr-misc_spr1)/32+base2

в третьем конфиги:

rep_spr_cfg1:   dc.w 0,   $18, $18, 4, $A00, rep_tile|PAL2, 4

в четвертом проверки:

   IF (misc_spr1_end-misc_spr1)>1312
   bad_size1
   ENDIF

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

base2   equ   $D800/32
base3   equ   $F980/32
base4   equ   $BD20/32

; ---------------------------------------------------------------------------
; sprites cfg equates
spr1x1      equ   $000
spr1x2      equ   $100
spr1x3      equ   $200
spr1x4      equ   $300
spr2x1      equ   $400
spr2x2      equ   $500
spr2x3      equ   $600
spr2x4      equ   $700
spr3x1      equ   $800
spr3x2      equ   $900
spr3x3      equ   $A00
spr3x4      equ   $B00
spr4x1      equ   $C00
spr4x2      equ   $D00
spr4x3      equ   $E00
spr4x4      equ   $F00
HMirr      equ   $0800
VMirr      equ   $1000
HVMirr      equ   $1800
Prior      equ   $8000
pal2      equ   $2000
pal3      equ   $4000
pal4      equ   $6000

[Ti_]

снизу вверх не умеют. эээ... читать 3 раза файл чтоль? или прогонять 3 раза массив?

ну так и ассемблер не в 1 проход всё собирает. 

Добавлено позже:

отчасти помогло бы деление файла sprites_cfgs.asm на 4 файла в одном только метки и имена файлов:

ну, можешь сам разрезать как тебе удобно.

Добавлено позже:

вот нашел я к примеру units_spr - понятно оттуда начинаются юниты и надо их записывать

Units_spr это общий большой блок, где большинство юнитов.  Ещё в пару мест засунуты спрайты  (misc_spr1,misc_spr2,misc_spr3), которые, по идее, редактировать не особо нужно. Потому что видеопамять для юнитов не 1 большим куском идёт.
И Hfactory_ex_tiles сделано так, чтобы в постоянном месте были.

[SeregaZ]

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

заодно посмотрел внимательнее - бывают случаи что метка есть, а ссылки на файл нет - закоменченно. типа как с бойцом-пвошником и утяжеленного танка. тут видимо надо будет ориентироваться на двоеточие. типа двоеточие в строке есть - значит метка, а если в фразе incbin есть - значит видимо на файл указывает. (это если читается sprites_cfgs1.asm файл) ну или закоментить и эти метки тоже. и тогда это будет как закон - что если есть метка, то следующая строка обязательно будет инфа. а не так что метка есть, а инфы нет - что несколько запутает мой редактор при попытке чтения файла.

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

Добавлено позже:
но самая ржака случилась с последним файлом

   IF (misc_spr1_end-misc_spr1)>1312
   bad_size1
   ENDIF
   
   IF (misc_spr2_end-misc_spr2)>1152
   bad_size2
   ENDIF
   
   IF (units_spr_end-units_spr)>18912
   bad_size3
   ENDIF

если строки без табов вначале - пишет ошибку ставишь таб перед IF и другими строками - работает )))

Добавлено позже:
ага... закомментить то и не выйдет. поплывет нумерация в sprites_ptrs.asm 

Добавлено позже:
ну вот очередной писец подкрался и украл всех кур...

начал разбирать типы спрайтов и делать табличку:

; sonicblast type  0, num 160. конфигов 16 (видимо по сторонам света)

; mcv        type  1, num 253, config  3 (0, 45, 90 градусов)

; trike      type  2, num 243, config  5 (0, 22, 45, 67, 90)

; soldire    type  3, num 311, config  9 (0, 90, 180, 0+anim2, 0+anim3, 90+anim2, 90+anim3, 180+anim2, 180+anim3)
; кадры могут быть напутаны. уточнится в процессе.

; infantry   type  4, num 329, config 12 (эээ... понятно что 9 как у солдата. что еще за 3? подумал может аним где солдаты не в ногу идут, но нет. тайл везде один и тот-же)

; ornitopt   type  5, num 289, config  8 (8 направлений по кругу. но крылья видимо в другом месте)

; worm       type  6, num 213, config  1 (супер. все бы так.)

; cariall    type  7, num 283, config  6 (3 стандарт 0, 45, 90 и 3 с дополнением - харвестером)

; harvester  type  8, num 248, config  3 (0, 45, 90 - но должно быть 6 или даже больше так как хвост при фарме спайса. видимо в другом месте)

; frigate    type  9, num 298, config 

и на фригате все сломалось к чертовой бабушке... когда читаю sprites_ptrs.asm, то предполагается что там по 2 строки для каждого конфига так сказать. и мне типа интересна была вторая строчка, так как в ней указатель на конфиги в другом файле. тут-же с фригатом - а видимо 4 конфига для него - все 4 раза повторяется frig_spr_cfg1, который ведет к frig_spr_cfg1: dc.w 0, $20, $20, $FFF0, $F00, $7F0, $FFF0 - оказывается надо смотреть не frig_spr_cfg1, а строчкой выше, которую я вобще-то игнорирую, а там frigate1_spr|LOAD_GFX, которую в свою очередь надо искать ваще в другом месте - в include.asm. а во вторых в frig_spr_cfg1: dc.w 0, $20, $20, $FFF0, $F00, $7F0, $FFF0 не метка для тайла, а четкий адрес. что опять таки заводит не туда... теперь я точно концов не найду.

[Ti_]

а во вторых в frig_spr_cfg1: dc.w 0, $20, $20, $FFF0, $F00, $7F0, $FFF0 не метка для тайла, а четкий адрес. что опять таки заводит не туда... теперь я точно концов не найду.

Хочешь сделай метку. А конфиг спрайта на все 4 положения одинаковый, потому что там 1 спрайт в памяти только единовременно. Нужный спрайт подгружается в память в зависимости от положения фрегата.
Может не редактировать фрегат будет проще. Сделай отображение в редакторе первого спрайта и всё.

[SeregaZ]

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

frigate1_spr:
 incbin   gfx\sprites_gfx\frigate1.smd
frigate2_spr:
 incbin   gfx\sprites_gfx\frigate2.smd
frigate3_spr:
 incbin   gfx\sprites_gfx\frigate3.smd
frigate4_spr:
 incbin   gfx\sprites_gfx\frigate4.smd

из include.asm в sprites_cfgs1.asm - там где все... эээ... большинство указателей на файлы и даже добавлять математику, как у всех и конфиг создавать для всех 4 вариантов - то вся нумерация тайлов поплывет. да и одним фригатом там не отделаться. я смотрю там топтерные крылья рядышком саботёр и так далее, а это все нужно. для редактора палитры то конечно подойдет и спрайт, где мордой вверх - но ведь планировалось то и полный редактор графики юнита пилить. чтоб там все было: и все градусы, и все зеркала, и все анимации и даже кадр за кадром анимация в отдельном окошке как в GIF для демонстрации. хочу много и всё, а по факту хер там чо получится как обычно

[Ti_]

да только я подозреваю если переносить из include.asm в sprites_cfgs1.asm

Если надо, то я могу перенести всё от thopters_tiles до unit_types.  Но, вероятно и малые иконки тоже надо icons_superlauncher и далее. Вышли мне свои sprites_cfgs.asm которые порезал на 4 части, и в какую перенести.

[SeregaZ]

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

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

а sprites_ptrs.asm будет поправлен? тот-же фригат чтоб вместо:

      dc.l frigate1_spr|LOAD_GFX
      dc.l frig_spr_cfg1|FRG_UNIT_SPR

стало что-то типа:

      dc.l LOAD_GFX
      dc.l frigate1_spr|FRG_UNIT_SPR

я то читаю из 2 строчки по каждому случаю, а не по первой. то есть чтоб ссылался на конкретный конфиг. и чтоб все 4 были разные со своими указателями на тайлы. сейчас конфиг 1 и все 4 случая в sprites_ptrs.asm ссылаются на него. получается редактор дойдет до этого момента и затупит.


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


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

[Ti_]

а sprites_ptrs.asm будет поправлен? тот-же фригат чтоб вместо:

Тут нет ошибки. На каждый спрайт по 2 поинтера - первый - на графику, второй на конфиг. Но, поскольку, это не ПК , и все юниты заранее лежат в vram, то поинтер на графику везде пустой. Кроме фрегата, deathhand, саботера и некоторых других, перезагружаемых на лету спрайтов. А сделать frig_spr_cfg2 - 4 , и продублировать конфиг можно , да.

Добавлено позже:

а по поводу иконок - а зачем их тоже переносить? иконки без проблем читаю из include.asm.

Поинтеры на иконки в sprites_ptrs тоже.

[SeregaZ]

эм... а я в обход этого файла иконки читал, поскольку нашел четкий список иконок, соответствующий порядку юнитов и зданий - bmenubuild_ico: и bmenuunits_ico: в файле include.asm. в случае же с графикой юнитов и зданий такое не проканало, так как нет четкого списка в include.asm - поэтому я и не мог понять эту последовательность, пока ты не сказал что все дело в sprites_ptrs. правда в том списке еще фримены и сардукары есть. по хорошему им бы предусмотреть 33, 34 и далее места для юнитов в списке - ведь малая иконка есть, большая есть, даже какие-то отличительные статы есть в екстрас. файла правда своего отдельного нет. но в целом практически полноценные отдельные юниты

Добавлено позже:
вопросы:
infantry_spr_cfg1: почему 12 конфигов? морда вверх+2 анимации, морда вправо+2 анимации, морда вниз+2 анимации = итого 9. но тут 12. так-же труперс 12.


blank_i_spr_cfg1:
blank_t_spr_cfg1:
почему по этому непонятному указателю указаны тайлы солдата? это типа фримены или сардукары?


blank5f_spr_cfg1:
а тут такой-же непонятный рокетквад, хотя вроде рокетквад в другом месте указан.


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


хвост харвестера htail_spr_cfg1:
надо перенести к самому харвестеру чтоб рядом, то есть чтоб система при типе спрайта - 8 - ожидала 3 конфига 0, 45, 90 и сразу-же плюс еще 8 конфигов для хвоста при фарме спайса. там причем момент сначала метки идут как htail_spr_cfg1 а потом word_640C8


так-же спрайты еды червя подложить рядом с самим червем worm_spr_cfg: - чтобы когда тип спрайта - 6 - система ожидала найти еще метки помимо самого червя - еще 4 или сколько там когда черв ест.


харрикейн sprites_ptrs.asm:
      dc.l NO_LOAD_GFX   ; $7E
      dc.l hurricane_spr_cfgs|STD_UNIT_SPR
      dc.l NO_LOAD_GFX   ; $7F
      dc.l hurricane_spr_cfgs|STD_UNIT_SPR
      dc.l NO_LOAD_GFX   ; $80
      dc.l hurricane_spr_cfgs|STD_UNIT_SPR
все три одинаковые. похоже что имелся ввиду стандарт 0, 45, 90 - но почему указатель один и тот-же? должны быть разные. или если одинаковый - то единожды разве будет недостаточно?



по переносу:
thopter_spr_cfg1:
указатели на файлы-крылья перенести в смысле анимации. так-же добавить конфиги этой самой анимации, чтоб читалось из 1 места. чтоб редактор мог найти как базовый спрайт с расправленными крыльями, так и знал как заменять эти расправленные на 2 других вида.

saboteur_spr_cfg:
подправить ptrs и конфиги дописать

dhand_spr_cfg
подправить ptrs и конфиги дописать

frig_spr_cfg1
тоже самое.



так вроде бы ром собирается без ошибок с порезанными спрайтами и подправленными конфигами.

[SeregaZ]

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

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

[Ti_]

некоторые спрайты я порезал и конфиги подправил.

надо было выложить, только то, что ты правил.


Добавлено позже:

еще там програмку специальную сделал. при запуске создатель чистой копии.exe -

удаляет все нужные и вспомогательные файлы. особенно из gems. кому это нужно?

[SeregaZ]

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

а насчет только тех, что изменял - так там их много было.

и рокетквад так и не заработал. лазер танк у ордосов появился, а рокетквад нифига.

[Ti_]

а насчет только тех, что изменял - так там их много было.

полагаю, только папка sprites_gfx.

Добавлено позже:

не удаляет - а просто недокопирывает.

да какая разница? зачем?

Добавлено позже:

blank_i_spr_cfg1:
blank_t_spr_cfg1:
почему по этому непонятному указателю указаны тайлы солдата? это типа фримены или сардукары?

blank5f_spr_cfg1:
а тут такой-же непонятный рокетквад, хотя вроде рокетквад в другом месте указан.

blank это шаблоны.

Добавлено позже:

saboteur_spr_cfg:
подправить ptrs и конфиги дописать

в ptrs нет ошибки. конфиги 2/3/4 можешь сам дописать.


Добавлено позже:

должны быть разные. или если одинаковый - то единожды разве будет недостаточно?

Тут только первый используется, да. $7F и $80 если мешают можешь затереть.

Добавлено позже:

вопросы:
infantry_spr_cfg1: почему 12 конфигов?

не знаю, не смотрел.

Добавлено позже:

так-же спрайты еды червя подложить рядом с самим червем worm_spr_cfg: - чтобы когда тип спрайта - 6 - система ожидала найти еще метки помимо самого червя - еще 4 или сколько там когда черв ест.

также можешь сам сделать.

Добавлено позже:

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

я ничего не понял. графику я перенесу из include.asm в sprites_cfgs00.asm, далее двигай как хочешь.

[Ti_]

Перенес:

[SeregaZ]

да какая разница? зачем?

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

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

[Ti_]

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

Файлов у меня много, но система простая. У меня 2 папки, вторая для релизов.

Добавлено позже:

и все-таки - почему ракетный квад не хочет строится на легком заводе?

требует upg.level = 2 . либо уменьши на 0-1 в файле юнита, либо upgrades.asm редактировать, разрешив для lf 2 апа.

[SeregaZ]

спасибо. буду ковырятся.

[Ti_]

вопросы:
infantry_spr_cfg1: почему 12 конфигов? морда вверх+2 анимации, морда вправо+2 анимации, морда вниз+2 анимации = итого 9. но тут 12. так-же труперс 12.

Посмотрел. Последние 3 можно удалить. Видимо, в ПК-версии зачем-то нужны были. И у саботера последний тоже неясно зачем.

[M3tro ™]

Ну вы тут развели, конечно!.. Аж более 2ух страниц понастрочили… Я уже неделю вас читаю . Imho: как по мне, так делать эти искусственные разрезания спрайтов, переписывания миллиёна конфигов и прочее эта какая-то пустая трата времени, никому они не сдались , раньше ведь редачили как-то и никто на эти спрайты не жаловался вроде .

в ПK-версии зачем-то нужны были. И у саботера последний тоже неясно зачем.

Это он типа с двух рук стреляет .

+Kонфиги танков в .asm , а не .bin.

Если инклуд в r81b подправить для него, этот *.asm подойдёт ведь вместо *.bin?