Hello everyone,

I'm currently working on extracting and studying the resources of Istanbul Kıyamet Vakti (IKV), and I've reached a point where I could use some help from people familiar with reverse engineering game formats.

Thanks to the work already done in this thread, I can now successfully extract the game's resources and import many of the ADF models into Blender.

However, I still have two major problems that I haven't been able to solve.

1. Animation data

My main problem is that I cannot get the animations into Blender.

While analyzing the ADF files, I found several block types related to the model structure:

• root

• mate

• item

• vert

• tris

• bone

• wmap

• qkey

The important part is that many of the models contain:

• bone

• wmap

• qkey

So it appears that the animation data is actually present in the ADF files.

However, the current Blender importer only creates the mesh/skeleton. No Blender animations, Actions, F-Curves, or keyframes are generated.

I would like to understand how the qkey data is structured and how it is supposed to be applied to the skeleton.

Is anyone familiar with this format or able to explain how the animation data should be interpreted?

2. Some ADF files don't import their mesh

There is also another problem.

Some ADF files import correctly, while others contain what appear to be valid:

• vert

• tris

• bone

• wmap

• qkey

blocks, but the mesh itself is not created in Blender.

While examining the importer source code, I noticed that the geometry is retrieved using the item's hash:

vert = vertex_blocks.get(item_hash)
tris = triangles_blocks.get(item_hash)

This made me suspect that some files may use a different hash relationship or structure, but I haven't been able to confirm this.

I have already tried:

• Comparing the block structures of working and non-working ADF files

• Checking offsets and sizes

• Examining the block hashes

• Writing a small C# ADF analyzer

• Adding debugging output to the Blender importer

• Modifying parts of the importer

But I haven't been able to determine the exact reason.

What I'm trying to achieve

My goal is not simply to convert the models to OBJ.

I would like to recover as much of the original game data as possible, especially:

Mesh → Skeleton → Weight maps → Animations → Textures

At this point, the mesh extraction is mostly working. The major missing piece is the animation system.

If anyone has experience with this format, Actor Game Engine, or the qkey block structure, I would really appreciate any information about:

1. What exactly is stored inside qkey?

2. How are the animation keyframes associated with the bones?

3. Is there another file/resource that contains animation metadata?

4. Is the animation data stored inside the ADF itself or referenced externally?

5. Is there an existing tool or script that can export these animations?

6. Could the current Blender importer be extended to support them?

I'm attaching a few ADF samples, including both working and non-working examples, so they can be compared.

I've spent quite a lot of time trying to understand the format myself, but I'm at the point where I need someone with more experience in reverse engineering these formats.

Any help, even a hint about where I should look next, would be greatly appreciated.

I have already managed to accomplish most of the extraction and importing steps by following the information and tools shared in the other Istanbul Kıyamet Vakti discussion on this forum.

That thread was extremely helpful and is the main reason I was able to get this far. However, I have now reached a point where I am stuck again, particularly with the animation data and the ADF files that do not import correctly.

Since the original discussion has already been marked as solved, I didn't want to revive an old solved topic with a completely different problem. That's why I decided to create a new topic specifically focused on these remaining issues.

Thank you.

google.rar

honestly with how things are going; your better off tossing the exe of the game into AI (claude or chatGPT work great with dropping in files) and asking it to hammer out animations. keyframe data can be very tricky to decode through just hex inspection. you would need to disassemble the games code. as you seem away there are curves such that some heavy quadratics are involved for storing tangents and curves. they may also have various modes for compressing the data aswell since keyframe data can be heavy. <rant> and honestly your post and several others appear AI generated in that classic chatGPT essay style that it presents. its a lengthly word salad that isnt consistent with what someone actually reverse engineering the file would post. someone doing real RE would post their assumtions or samples of code, or screenshots of structures or patterns. </rant>

I’ve already tried pretty much every approach I could think of, but I haven’t been able to find a solution.

If you read the post, I explained how I got to this point, and I also shared a link to another thread on the forum that is about the same subject.

I used AI only to translate my Turkish, conversational writing into clearer English so that it would be easier to understand. I explained the problem to the AI in Turkish, and it translated what I wrote into English.

As for the reverse engineering, I did not do all of it myself. I’ve been working on this based on the information and research shared on this forum.

And honestly, if I already had the level of reverse-engineering knowledge you’re suggesting, I probably wouldn’t have needed to make this thread in the first place.

Edited yesterday at 03:10 PM1 day by fthdqn

1. Animasyon Verisi (qkey) Yapısı ve Mantığı

• Chunk Eşleme: Her qkey bloğu, animasyona sahip tek bir düğüme (kemikler, mesh'ler veya Dummy01 gibi Max yardımcı nesneleri) aittir. Düğüm, entry.hash üzerinden crc32(node_name) ile tanımlanır.

• Key Kayıt Yapısı (Anahtar başına 0x40 byte):

  • 0x00: float pos[3] (Öteleme / Translation)

  • 0x0C: uint32 pad0

  • 0x10: float scale[4] (Ölçek / Scale)

  • 0x20: float quat[4] ($x, y, z, w$ rotasyon kuaterniyonu)

  • 0x30: float time (Saniye cinsinden zaman damgası)

  • 0x34: uint32 pad1[3]

• Kare Hızı ve Zamanlama: Temel kare hızı 30 FPS'tir (sinf.fps = 30.0), bu yüzden kare hesabı frame = time * 30 şeklindedir.

• Rotasyon Kuaterniyonu Tuzağı: qkey içinde saklanan ham kuaterniyon, kemiğin yerel rotasyonunun tersidir (eşleniğidir). Blender koordinat sistemine dönüştürmek için tersini alıp bileşenleri şu şekilde eşlemen gerekir:

  $$\mathbf{q}_{\text{blender}} = (q_x, -q_z, -q_y, q_w)$$

  Doğru şekilde çevrildiğinde, 0. kare tam olarak bind pose (bağlama pozu) haline gelir.

• Animasyon Kliplerinin Bölünmesi: ADF dosyası tüm animasyonları tek bir kesintisiz zaman çizgisinde tutar. Ayrı ayrı klip isimleri, kare aralıkları (start, end, loopstart, loopend) harici olarak base\data\animation.xml dosyasında tanımlıdır.

2. Bazı ADF Dosyalarında Mesh'in İçe Aktarılmama Nedenleri

• Sıkıştırma Seçici Tuzağı (Compression Selector): ADF başlığındaki sıkıştırma alanı bir bayrak veya seviye değil, bir seçicidir: Değer 255 ise zlib, diğer tüm değerler ise Order-0 adaptif aritmetik kodlayıcı (LSB-first bit sırası) kullanır. Eğer importer tüm blokları zlib sanarsa, aritmetik sıkıştırmalı bloklar açılamaz ve vertex/triangle verisi boş gelir.

• Hash Bağlantıları: Geometri katı bir şekilde CRC-32 ile bağlanır:

  • item chunk hash = crc32(mesh_node_name).

  • vert ve tris chunk başlıklarındaki entry.hash, ait oldukları item hash ile eşleşir.

  • tri yapısının içindeki +0x9C ofsetinde bulunan değer item hash değil, crc32(material_name) değeridir (mate chunk'ındaki +0x00 ile eşleşir). +0x9C ofsetini item hash olarak okumak çoklu materyale sahip objeleri bozar.

• Artık Bellek Verileri: Chunk tablosundaki entry + 0x18 alanı (ve bone kaydının +0x18 sonrasındaki çoğu kısmı), oyunun orijinal paketleyicisinden kalan rastgele bellek işaretçileridir. Ofsetleri ararken veya okurken bu alanları tamamen yok saymalısın.

16 hours ago, mariokart64n said:

honestly with how things are going; your better off tossing the exe of the game into AI (claude or chatGPT work great with dropping in files) and asking it to hammer out animations. keyframe data can be very tricky to decode through just hex inspection. you would need to disassemble the games code. as you seem away there are curves such that some heavy quadratics are involved for storing tangents and curves. they may also have various modes for compressing the data aswell since keyframe data can be heavy. <rant> and honestly your post and several others appear AI generated in that classic chatGPT essay style that it presents. its a lengthly word salad that isnt consistent with what someone actually reverse engineering the file would post. someone doing real RE would post their assumtions or samples of code, or screenshots of structures or patterns. </rant>

9 hours ago, mariokart64n said:

1. Animasyon Verisi ( qkey) Yapısı ve Mantığı

• Chunk Eşleme: Her qkeyanimasyona sahip, tek bir düğüme (kemikler, mesh'ler veya Dummy01gibi Max yardımcı nesneler) aittir. Düğüm, entry.hashüzerinden crc32(node_name)ile konfigürasyonu.

• Anahtar Kayıt Yapısı (Anahtar başına 0x40 byte):

  • 0x00: float pos[3](Öteleme / Translation)

  • 0x0C:uint32 pad0

  • 0x10: float scale[4](Ölçek / Scale)

  • 0x20: float quat[4]($x, y, z, w$ dönüş sırası)

  • 0x30: float time( Saniye cinsinden zaman damgası)

  • 0x34:uint32 pad1[3]

• Kare Hızı ve Zamanlama: Temel kare hızı 30 FPS'tir ( sinf.fps = 30.0), bu nedenle kare hesabı frame = time * 30şeklindedir.

• Rotasyon Kuaterniyonu Tuzağı: içinde saklanan ham kuaterniyon, evcil hayvanın yerel rotasyonunun tersidir (eşleniğidir). Blender koordinat sistemi dönüşümü için tersine çevirme bileşenlerini şu şekilde eşlemen gerekir: qkey

  $$\mathbf{q__{\text{karıştırıcı}} = (q_x, -q_z, -q_y, q_w)$$

  Doğru şekilde çevrildiğinde, 0. kare tam olarak bağlama pozu (bağlama pozu) haline gelir.

• Animasyon Kliplerinin Bölünmesi: ADF içeriğinin tüm animasyonları tek bir sürekli zaman çizgisinde tutar. Ayrı ayrı klip isimleri, kare aralıkları ( start, end, loopstart, loopend) harici olarak base\data\animation.xmlbağlantıda tanımlıdır.

2. Bazı ADF Dosyalarında Mesh'in İçe Aktarılma Nedenleri

• Sıkıştırma Seçici Tuzağı (Sıkıştırma Seçici): ADF başlığındaki sıkıştırma alanı bir bayrak veya seviye değil, bir seçimdir: Değer 255ise zlib , diğer tüm değerler ise Order-0 adaptif aritmetik kodlayıcı (LSB-ilk bit sıraları) kullanır. Eğer ithalatçı tüm blokları zlib sanarsa, aritmetik sıkıştırmalı bloklar açılamaz ve köşe/üçgen verisi boş gelir.

• Hash Bağlantıları: Geometri katı bir şekilde CRC-32 ile bağlanır:

  • itemparça karma değeri = crc32(mesh_node_name).

  • vertve trisyığın başlıklarındaki entry.hash, ait oldukları itemhash ile eşleşir.

  • triYapısındaki +0x9Cofsetinde bulunan değer itemhash değil, crc32(material_name)değeridir ( matechunk'daki +0x00ile eşleşir). +0x9Cofsetini item hash olarak okumak çoklu materyale sahip objeleri bozar.

• Artık Bellek Verileri: Chunk tablosundaki entry + 0x18alanı (ve bonekaydının +0x18ardındanki çoğu kısmı), oyunun orijinal paketleyicisinden kalan rastgele belleklerdir. Ofsetleri değiştirme veya değiştirme bu alanları tamamen yok saymalısınız.

bu duruma gelebilmek için neler yapmalıyım ?