World Editor - маловато будет. Давайте курить формат карт.

[TeMHbIu]

По сути, для гуя атрибутов не так уж много:

 

-Путь к каталогу "откуда"

-Путь к каталогу "куда" (либо атрибут - "туда же")

 

- 4 координаты "откуда" (выделяем прямоугольник двумя точками X1;Y1;X2;Y2)

- 2 координаты "куда" (X;Y)

 

- атрибут "копируем/переносим"

 

Подумаешь, передать в командной строке 8-9 параметров

 

 

По поводу GUIDов.. все-таки они довольно рандомны .

Даже с координатами не коррелируют. Может, привязка к наносекундам, прошедшим с 1 января 1885 г?

[Saruman]

Апдейт (почти через год, но лучше поздно чем никогда) по GUID'ам в .mob-файлах:

 

Наткнулся на опен-сорсный исходный код на C# от World Builder для Temple of Elemental Evil, который был построен на модифицированном движке от Arcanum'а https://github.com/13xforever/toee-world-builder.

 

Вот как там запилена генерация GUID'а (файл /src/ToEE World Builder/Helpers/MobHelper.cs):

 

public static void GenerateGuid(out string s_GUID, out byte[] GUID)
	{
		var r = new Random();
		var generator = new byte[16];
		GUID = new byte[24];

		s_GUID = "G_";
		GUID[0] = 0x02;
		GUID[1] = 0x00;
		GUID[2] = 0x00;
		GUID[3] = 0x00;
		GUID[4] = 0x00;
		GUID[5] = 0x00;
		GUID[6] = 0x00;
		GUID[7] = 0x00;

		r.NextBytes(generator);

		GUID[11] = generator[0];
		GUID[10] = generator[1];
		GUID[9] = generator[2];
		GUID[8] = generator[3];
		GUID[13] = generator[4];
		GUID[12] = generator[5];
		GUID[15] = generator[6];
		GUID[14] = generator[7];

		for (int j = 16; j < 24; j++)
			GUID[j] = generator[j - 8];

		for (int k = 0; k < 16; k++)
		{
			string s_Elem = generator[k].ToString("X");
			if (s_Elem.Length == 1)
				s_Elem = "0" + s_Elem;

			if (k == 3 || k == 5 || k == 7 || k == 9)
				s_GUID += s_Elem + "_";
			else
				s_GUID += s_Elem;
		}

		return;
	}

 

Как можно видеть, генерация полностью рандомна, за исключением некоторого шаманства с байтами с 9го по 16ый. Остальной код проекта я не смотрел, но подозреваю, что если при генерации вдруг возникнет GUID, уже существующий у другого .mob-объекта (вероятность чего, по всей видимости,

) - это легко будет проверить по списку всех .mob-объектов в модуле и при необходимости заново его сгенерировать.

 

Предполагая, что данный софт работал (а судя по двум крупным релизам и неоконченной версии 3.0 это так), можно предположить что просто рандомных GUID'ов и проверки на совпадение будет достаточно для копирования .mob-объектов при выполнении copy-paste.

[Saruman]

Долго вглядывался в получающиеся sec-файлы и в ман Криптона:

 

here comes sector objects, which structure is undefined now, but objects can be looked-up by pattern:
offset  val
0x00	0x77
0x01	0x00
0x02	0x00
0x03	0x00
0x04	0x00
0x05	0x00

0x1c	0x00
0x1d	0x00
0x1e	0x00
0x1f	0x00
0x20	0x00
0x21	0x00
0x22	0x00
0x23	0x00

From each object we can now get following:
offset					  size	  name
0x0C						2 bytes   proto_id
0x34						4 bytes   mob_type
0x3A + type_skip*4 - 1	  4 bytes   x_coord //type_skip see later
0x3E + type_skip*4 - 1	  4 bytes   y_coord

type_skip depends on mob_type:
mob_type	mob_name	type_skip
1		   Portal	  4
2		   Container   4
3		   Scenery	 5
4		   Projectile  5
5		   Weapon	  7
6		   Ammo		7
7		   Armor	   8
8		   Money	   8
9		   Food		8
10		  Scroll	  8
11		  Key		 9
12		  Written	 9
13		  Generic	 9
14		  PC		  11
15		  NPC		 13
16		  Trap		13
17		  Bag		 9

 

Заметил, что 77 00 00 00 хорошо работает как маркер объекта - можно безошибочно найти все, не набрав мусора. Однако Криптон пишет, что нулевых байтов должно быть 5, а у меня во время экспериментов появляется только 3.

 

Глядя на то, что должно быть координатами исходя из предложенных Криптоном оффсетов, создается впечатление что объекты в файле записаны в рандомном порядке - в двух соседних идентичных по наполнению секторах у первого объекта не совпал ни X, ни Y. Правда возможно я не на то смотрю - формулу оффсета я считал в десятичных числах, вначале конвертировав первое число, а возможно имелось в виду, что mob_type тоже - шестнадцатиричный и складывать нужно соответственно. Также не исключена кривая запись координат как в случае с координатами в .mob-файлах. Буду пробовать дальше.

[Saruman]

Начал с простого - взял пустую "водную" карту и начал смотреть на координаты простых статиков типа "дерево". Для них нашлись координаты (по всей видимости 4 байта длиною, как описал Криптон) со смещением в 71 и 75 байтов соответственно от первого байта статика со значением 77.

 

Манипуляции с этими значениями закономерно привели к тому, что статики "поплыли" в нужном направлении, и при изменении значения на n*64, n ∈ N оказывались в соотвествующих n секторах выше/ниже/левее/правее. Теперь предстоит поэкспериментировать с более сложными статиками типа стен, но достаточные для первых скриптовых экспериментов на Питоне или типа того результаты уже близко.

[Saruman]

То же самое получилось совершить и со стенами - смещение для них оказалось 75 байтов для X и 79 байтов для Y соответсвенно. Попробовал вручную перенести сектор с находящимся в нём домом: переименовал .sec файл сектора с учётом его новых координат, пропатчил все координаты статиков в файле с учётом переноса в соседний сектор (на 64 по Х), результаты на скринах ниже. Теперь нужно поэкспериментировать с остальными статиками и распознаванием типа статика (верифицировать соображения Криптона), которое будет необходимо для автоматизации патчинга координат.

[Woratiklis]

Вот это да! Близко подобрался к разгадке

Ждём с нетерпением новых экспериментов!

[Кислый]

Вот это да! Близко подобрался к разгадке

Ждём с нетерпением новых экспериментов!

 

Кто-нибудь, свяжитесь с Раджаном (radzh) он меня жестоко игнорит. Мне нужен от него код для декодирования art id.

Без этого я не смогу перенести карты компании арканума на новый движок.

 

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