Времени до службы у меня не так много, но в принципе сообщить идею я успею, а она в следующем:

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

Зачем переименовывать msk? Они же всё равно генерируются deftool'ом.
А насчёт изменения клеток - есть ощущение, что это может сдвинуть охрану на рандомках, надо проверить этот момент.

Логично, но ведь генерироваться будет "объект на карте", а не конкретный объект. Я не силён и в этом.

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

Ты был прав, действительно охрана сбивается, но почему-то мне кажется, что это решаемая проблема.

В общем, выяснил. Идеально подходит msk костра, но, естественно обрезается def.

Sav, нужен патчик ^^


По-идее, тогда не будет сдвинутых охран. Все проблемы как раз таки из-за лишних клеток вокруг монстра. Насколько это возможно?

msk - это файл, в котором прописан размер и положение отображаемой части объекта.
Проблема в том, что генератор для всех монстров считает, что правая нижняя клетка и есть активная и при постановке не анализирует, где она находится на самом деле.
Проблема решаемая, но не простым патчем. Если всё это дойдёт до Хоты, я займусь этим, отдельно же - не знаю. В любом случае, кроме как включить в проект под Сод или оформить в виде плагина для Эры это сделать не удастся.

Хм.

А вот интересно: если я нечто меняю у себя, то должно ли это отражаться у игрока напротив?


Вот, например, я меняю msk, у меня архангел обрезается, это логично. Но обрежется ли он на той стороне? Если нет, то по идее Profit, ибо для него-то карта будет вполне в порядке, разве не так?

Всё прописаное в objects будет по хосту (оно хранится в файле генерируемой карты). msk и def'ы на геймплей не влияют и должны быть у каждого свои. Дефы точно, а msk - не уверен, но вроде как в карте не хранятся и загружаются из лода.

ну вот и я так думаю

таким образом надо придумать, как сделать msk ресурса, но при этом отображать def полностью, а не заточённым в одну клетку и обрезанным по бокам. Если это удастся, то можно ко всем широким объектам приделать эту схему и тогда карта явно должна облагородиться за счёт более плотной группировки объектов. В любом случае, технически это возможно сделать путём простого редактирования msk в h3sprite, но с отображаемой частью нужно что-то придумать.

так можно же раскопать формать этого msk и сделать прогу, которая в файле будет центрировать изображение (а данные уже все есть)

Формат msk в общих чертах:

00 db Размер в клетках по-горизонтали
01 db Размер в клетках по-вертикали
02 db *6 Отрисовывать ли объект и на каких клетках каждого ряда
08 db *6 Отрисовывать ли тени и на каких клетках каждого ряда


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

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

Я, кажется, всё понял.
Жёлтая клетка монстра - его правая нижняя, правее и ниже неё ничего не отображается. Можно сдвинуть её в objects.txt влево, тогда она станет второй справа-нижней, но такие существа, как горгона, будут вылезать из своей клетки и влево, и вправо. В этом случае изображение будет обрезаться (насколько я помню, размер монстра - 2 на 2 клетки). Чтобы расширить изображение, нужно изменить msk. Но настоящая проблема в том, что монстры будут генерироватья в генераторе и, вероятно, случайном монстре сдвинутыми.

по-моему достаточно избавиться от этого

Клетки правее и ниже правой нижней клетки объекта не хранят никакой информации о том, что там что-то есть. А игра рисует всё поклеточно.

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

Берётся клетка, у неё есть список объектов, которые на ней стоят, из дефа каждого из них выбирается нужный квадрат и отрисовывается на клетку.

как сложно все. тогда уж легче исправить генератор и убрать ограничение на 2х2 клетки

Такого ограничения нет (хотя, вполне может оказаться, что msk монстров обязаны быть одинаковыми, но вряд ли более того, во всяком случае, по части генератора). Просто генератор всегда ставит монстра правой нижней клеткой туда, куда считает нужным поставить жёлтую клетку охраны. Ну, я в общем, уже сказал на этот счёт.

Весь движ в том, что сдвинутые охраны появляются из-за того, что рядом с существом должно быть n свободных клеток, минимум одна, либо одна активна, такое бывает в случае бага генерации. Избавиться нужно от привязки дефа к клеткам, то бишь чтобы деф накладывался на любой msk и не обрезался. Отсюда мы получим довольно широкий список объектов, где можно поменять msk во благо нормальной генерации. Я протестировал: у оппонента всё в порядке. Таким нехитрым образом можно генерировать карты с благородной начинкой, а после и играть в них, когда будет всё в порядке с дефами. Гипотетически можно изобразить себе схематично любой деф монстра, банально заменив его msk на необходимый минимум - одну клетку - а сам деф отрисовать в пределах одной клетки. Тогда генерации будут хорошими, но у игрока-хоста будут маленькие существа на карте. Вот мне почему-то кажется, что можно этот алгоритм обойти. Ибо какого фига у оппонента всё нормально отрисовывается и он играет на нормальной карте?)

msk вообще не должны играть никакой роли в генераторе, они управляют только тем, на каких клетках объект будет отрисовываться, а на каких нет. Это нужно, чтобы не отрисовывать те части объекта, которые не содержат никакого изображения. Генерации могут быть хорошими или плохими из-за текстовиков: objects, rand_trn, rmg. В данном случае - первого из них. Записи о монстрах лучше вообще не трогать, это ведёт к багам. А если трогать - то только зная код генератора и видя, что делаешь.
У всех обычных объектов можно спокойно оперировать проходимостями, они будут ставиться нормально. И msk тут не при чём, если не считать того, что при слишком маленьком размере объекта, не влезающие клетки не будут учитываться как непроходимые или триггерные.

и вообще странно что вместо 4-дерева сделали эти msk. еще и генератор не научили монстров расставлять.

Что за 4-дерево и как оно поможет? В принципе, я могу объяснить смысл существующего подхода.

Генератор всё нормально расставляет, просто не надо трогать записи о монстрах в objects.txt.

http://en.wikipedia.org/wiki/Quadtree поможет в том же, в чем и клеточная система: не обрабатывать отрисовку того, чего не нужно.

если бы он нормально расстявлял, то расставлял бы по желтым клеткам, как и все остальные объекты

Если бы msk не учитывался, то у меня не было бы сдвинутой на 3 клетки охраны (3!). Охрана сгенерировалась вообще где-то в горах, а кучка ресурсов и объект были вполне себе свободны для посещения.

так ты же правил строчку в текстовом файле

кстати, зачем тогда msg?

Стоп, а может только изображение сместилось, или триггер всё же тоже?



Ну так может в самой отрисовке куска дефа она используется, я не знаю. Но раз отрисовка всё равно поклеточная, почему бы не сделать и msk, благо это элементарно?
А сама клеточная система, полагаю, сделана не только для этого. Хотя бы для того, чтобы при отрисовке маленького куска карты не проходить по всем существующим объектам карты. Я бы не сказал, что это решение убого или т. п.


По такой логике игру не научили нормально работать с графикой - какое-то жалкое отсутствие лода вырубает её. Надо, чтобы она сама в этом случае всё генерировала!

Можно считать это требованием к формату ресурсов: у монстров правая нижняя клетка должна быть единственной триггерной. В оригинале это так и всё нормально.

msg нет в оригинале. Это воговцы что-то намудрили. Они требуются в Вог-редакторе и идентичны msk.

нет же! вместо клеточной отрисовки

а я что говорил? говорил же что могли бы это и через деревья реализовать

ну ты и сравнил. клетка в другом месте = игровые ресурсы в дате. клетка отсутствует = игровые ресурсы отсутствуют. вот это верное сравнение.

Да какая разница? Есть масса вариантов нарушить формат текстовика и игра откажется работать. Хотя бы в objects прописать неверное число записей. Генератор тут не при чём, он имеет право полагаться на правильность внутреннего формата игры.


Объекты могут быть разного размера, могут только частично помещаться на экран. Слабо представляю, как это реализуется деревом без деления на клетки.

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

Да какую ситуацию? С отрисовкой всё нормально.

все объекты распределяются по листьям дерева. при отрисовке берутся все листья, лежащие в пределах экрана, и отрисовываются объекты из них.

с генератором. или ты не помнишь моего и своего мнения по этому поводу?

Ну скажем так, исправлять это на данный момент нет никакой причины. Были бы перерисованные монстры - другое дело. А считать это багом - неправильно.


Подробнее. По какому критерию они распределяются (они ведь не одиночную координату имеют и могут иметь равные координаты) по листьям? Как хранится их порядок отображения? Почему это будет эффективнее существующего решения?

как называется этот деф с монстрами, кстати?

У каждого свой.

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

Sav, как по мне картинка с вики это неплохо объясняет: http://en.wikipedia.org/wiki/File:Quad_tree_bitmap.svg

Не ну это смешно... Сейчас размер msk 2 + 6 + 6 = 14 байт. В него влазит объект размером до 6х8 клеток.

1) Как уместить это дерево в еще меньший размер?
2) Зачем? Ну добъешся, скажем, 4 байта. Но толку? Объектов в игре не настолько много чтоб о размере msk заботиться.

(Поправка - 14 байт и в него влазит две карты - одна на полную непрозрачность и вторая на полупрозрачность)

а еще в дополнение к msk должны быть или циклы, или списки объектов на клетках по которым генератор и смотрит что там есть.

но все это философия, переделывать все равно никто не будет, да и так работает.

msk всё равно нужно, чтобы хранить, грубо говоря, геометрию объекта. В памяти же msk хранится только для шаблона - т. е., грубо говоря, типа объекта. И оно в любом случае должно храниться для любых удаляемых объектов (в Воге - для всех).


Сейчас это определяется их порядком в списке объектов клетки.


Да, но объекты - не пиксели. У них есть размер, порядок наложения.
Мне кажется, алгоритм должен быть слишком навороченным и мне неочевидны его плюсы по сравнению с нынешним.

Размер - в msk он всегда 8х6.
Порядка наложения в msk и так нет.

Если использовать этот quad tree, то размер нужно задавать отдельно - в дереве он никак не хранится.

Мне тоже.
Если уж исправлять/заменять msk то формату должно хватить:
1) размер объекта - как и сейчас, но убрать ограничение 8х6. Ширину можно увеличить до 32 не особо меняя формат, высоту можно и не ограничивать особо.

2) смещение графики - например, если объект со смещением 1х1 расположен в клетке 10х20, то рисоваться он будет начиная с клетки 11х21 - это позволит избавиться от таких приколов как в первом посте не поломав ГСК или сетевую игру.

3) битовая карта как и сейчас - объекты в героях маленькие, маятся с крутыми алгоритмами нужды не вижу.

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

Короче, Склифосовский :-) Я таки хочу сказать нижеследующее







Сим я намекаю, что при изменении определённого количества клеток возле активной (жёлтой) в msk как раз таки и начинают генерироваться сдвинутые охраны. Логично предположить, что если бы у них была всего одна-единственная клетка, она же активная (как, например у костра [а у ресурса тень вылезает за пределы]), то это снизило бы не только количество сдвинутых охран (а, быть может, вообще исключила бы), но и помогло бы, при изменении msk у остальных объектов, облагородить наполнение карты, которое в данный момент хромает.

И два Sav-а в топике это дааа

Я сделал тест: заменил все дефы монстров на костры и msk им поставил тот же. Среди 5-ти генераций джебуса я не нашёл ни одной охраны, где была бы та была сдвинутая (исключением будут только те, в коих виноваты не msk монстров, а msk самих объектов, к примеру охранялся улей, но не охранялся арт, который лежал рядом с ульем, при этом виноват улей, наиболее вероятно).

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