118 replies to this topic

[Miloch]

The next thing would be to remove all of the wallgroups and whatever else blocks the character’s line of sight and movement (increasing the character’s range of sight would be great, too). Anyone have any ideas on how to do this?

After that, one could remove the people and animations so that they wouldn’t have to be edited out later.

I have no clue how to do any of that stuff in the Lionheart engine. I seem to recall last I looked at it that no one knew of an equivalent to the CLUA console that IE has. If those are issues, it sounds like it would almost be easier to go the first route (convert and extract all the images then piece the area map together with the .zax files).

Does anyone happen to know of a good, free program that pastes overlapping pictures into a panoramic view? It would probably be very helpful for the bigger maps….

I've always done it manually, but you could google around a bit, maybe something like this would be useful.

[Balder]

Any interest on this topic yet?

Recently i've finnished a project related to modding homm2 and I thinked of lionheart as a good candidate for some tweaking. I think even being the game so impopular the concept is just fantastic. It would have done a great novel! And I also like the artwork and music... The problem is not resources but bad programming (or lack of more time to develop, i understand)

Anyway knowing the formats of the game is part of writing a new engine (which probably I'll do on my free time) and so if I found some interesting info or I make any tools I'll try to post here.

I know at least one of you from reflexive forums hahah there's not much info about the game so we end in the same places...

I'll start with the hex editor one day of these, and coding after exams.

About the .dat file of game resources I must say that it's raw zlib(zip) format without any compression at all, you can completely extract the resources with winrar or similars. Of course yo can "rebuild" it too, but this is not necessary as just renaming it and pasting the extrated folders in the game's directory works like a charm (as said in previous post)

See you champs!

[Miloch]

Any interest on this topic yet?

I think there's still interest, but we need some programming help to figure out how to extract the full maps. The way they're stored, we need to plot all the individual buildings and house objects on the background, so it's not as simple as BG2 for example, where they're not separate.

I know at least one of you from reflexive forums hahah there's not much info about the game so we end in the same places...

Is there any useful info about the game formats there? I took a look here, but it doesn't look like much activity, and none for Lionheart that I saw (recently anyway).

About the .dat file of game resources I must say that it's raw zlib(zip) format without any compression at all, you can completely extract the resources with winrar or similars.

Yeah, we've done that. It's just a matter of figuring out the sub-objects, like I said (more info on that on the previous pages too). I think the Lionheart content would work great in the BG2 engine if we can figure out how to do it.

[Balder]

Some investigations:

-FRM16 FORMAT-

<Header>
6 bytes -> Signature, it's always -> 32 10 00 00 00 00
2 bytes -> Width (portraits 90*111, menuBackground 800*600... etc)
2 bytes -> Height
2 bytes -> Seems like always 00 00
4 bytes -> Oscillates between 64-68 in the files i've investigated
4 bytes -> filesize - variable (depends of the file, but this field is always very close to the filesize, may be some kind of offset)
8 bytes -> Al blank bytes 00

Then data starts, but it's less than widht*height*3 (3 bytes per pixel is the most common thing) so I wonder if it may be compressed or have certain codes and thats the reason for being so small.

If you have further information It'll come handy, as I don't have much time these days.

Now what I'm going to do is take a screenshot from the game, cut a portrait 90*111, da vinci for example, convert it to raw tga (which is one of the simplest formats) and go comparing it's frm with tga equivalent. I hope this strategy will help determinating how does it work.

'til next time

Edited by Balder, 19 August 2009 - 06:14 PM.

[Miloch]

4 bytes -> filesize - variable (depends of the file, but this field is always very close to the filesize, may be some kind of offset)

Could be the filesize without the header maybe?

Now what I'm going to do is take a screenshot from the game, cut a portrait 90*111, da vinci for example, convert it to raw tga (which is one of the simplest formats) and go comparing it's frm with tga equivalent. I hope this strategy will help determinating how does it work.

I wrote a utility on the first page that will convert the frm16s to .bmp format. Probably wouldn't be hard to jiggle it to do .tga instead. Only works for the frm16 mini-maps though, got weird results when I tried it on the portraits.

[Balder]

I see... There are different formats of frm16, for now I've detected those of maps that you already worked with (signature 64) and portraits, etc (68)

I wonder how does the 68 one work as the data does not match with width*height of the file * 2 but I don't think it's RLE encoded, cause it wouldn't be so small difference. For example:

aka mana.frm16 (type 68)

90*111 (= 9990) and datasize 20108
Data starts at offset 36
9990 * 2 bytes/pixel = 19980 != 20108 So althought smaller is not enough smaller to think of compression...

And it's yet to discover what are thoses indexes at the end of the file, It's very doubtful that it's just garbage.

Anyway I've rewritten you're app in C++ for frm16 format64 so we can see perfectly some files like water1.frm16 etc but I had a problem with masking. I wonder if you know what masking it's used to get the 3 components from the 16 bit/pixel format.

If you don't know I'll just recode with SDL an let it figure out, that will take some more work but I can make a viewer instead of a "tedious" conversor.

I''ll continue investigating these formats in my free time...

At the moment I have no idea what can be the ending index, maybe something related with alpha channel. The same for 68 frm16 format, we still have to work out the algorithm which cyphers/compress those pixels. It may have some codes like 0 for end of line, which will make it a bit smaller...

bye bye

[Balder]

New info found:

CStandAloneFrame
{
Run Length Encode=1
RLE All Copy=0
Crop Color 0=1
Do Dither=1
Loss Less=0
Quality=65
Center Hot Spot=0
Load Black Biased=0
Blit Type=Normal
}

It seems like each frm16, independently from its format, has an associated txt, and frm16 with 68 format have: Run Lenght Encode = 1, so pixel data is surely runlenghtencoded.

Furthermore, we have de same for mdl16:
CGrannyModelFile
{
Short Name=Leonardo
Is Renderable=1
Specular Lighting=0
Num Textures=5
Num Meshes=2
Render Scaling=1
Hue Remap Textures=0
}

which tells us how to render the granny resource.

And even gr files for animations (walk, attack etc) has the correspondent txt:

CXRPGGrannyAnimationFileAttack
{
Short Name=AttackPunch01
Blit Type=Transparent Mask
Playback FPS=15
Playback Speed=0.5
Playback Speed Type=Loops Per Second
Rotate Offset=0
Model Slot To Get Scale From=Character Slot Types/Body
Root Offset X=0
Root Offset Y=0
Root Offset Z=0
Forward Axis=-Y
Accumulate Forwards Offsets=1
Ignore Zero Time Offset=1
Set X At To Origin=0
Set Y At To Origin=0
Set Z At To Origin=0
When To Pull Back To Origin=0
Triggers=Array
{
Item Count=2
Triggers=CGrannyAnimationTrigger
{
Action=CActionExecutePlugInBehaviorMethod
{
Object containing plugin behaviors=$instigator
Method to execute=Strike Current Target
Target Selection=Instigators Current Target
}
Trigger Forward=1
Trigger Reverse=1
Trigger Time Percentage=50
}
Triggers=CGrannyAnimationTrigger
{
Action=CRandomAction
{
Action=Array
{
Item Count=3
Action=CPlaySoundAction
{
Sound=Enemies/People/Named Characters/LEONARDO_attk_1.ogg
Position=$Trigger
Multiplayer=Heard by all players
}
Action=CPlaySoundAction
{
Sound=Enemies/People/Named Characters/LEONARDO_attk_2.ogg
Position=$Trigger
Multiplayer=Heard by all players
}
Action=CPlaySoundAction
{
Sound=Enemies/People/Named Characters/LEONARDO_attk_3.ogg
Position=$Trigger
Multiplayer=Heard by all players
}
}
}
Trigger Forward=1
Trigger Reverse=1
Trigger Time Percentage=25
}
}
Playback Speed Multiplier=
Auto Set Speed Multiplier=0
Quick RePlay Point=0
Can Interrupt After=60
}

First of all, I'll center on doing a good tool to manage frm, and from there we can move on to the next format. See you!

[Miloch]

Interesting info. I think it might be using a palette for some of the frm16s, whereas others might have straight RGBx entries. I say RGBx because of 4 bytes, the 4th might be unused... IIRC BMPs are like this. The minimaps were pretty similar to BMPs so as you see, it didn't take much to convert them. I had to reverse them and insert a couple bytes or so at the end of each line, so it might be as you say with end of line codes or something. And then other frm16s like the portraits looked like they might be indexed using a palette, which might be that "stuff" and the end of some files. Possibly they could be similar to indexed (256-colour) bitmaps, but I don't think I ever got that far. This could be the case for the mdl16 animation files and such too.

[leahnkain]

I just noticed this topic now. Basically I had given up and started taking screenshots. The most I was able to do was extract some of the data.

[Balder]

I'm actually coding a tool to view and convert frm16, I'll post it when it reachs a functional stage. I don't know what resources do you need from the game, but anyway it's coded in C++ with SDL so you'll have the source code for any kind of project.

As I said, I'm interested in enhancing this game, the problem is time as I have exams on september.

I'll give a try to the other formats when finnished with this one. Music and sound is in ogg and most of the game "behaviours" are in simple .txt files (much better for us than hard-coded in the main .exe) so along with .zax, .mdl16, .gr2 and .seq16 we'll have everything decoded. And maybe some of these formats are similar to frm16

So, if you need something just let me know and I see if I can help.

cheers!

[leahnkain]

I was looking to extract the maps from the game. It has been my challenge all along. Any help would be great.

[Balder]

Some progress:

water1.frm16
 water.bmp   48.05K   340 downloads

stars.frm16
 stars.bmp   48.05K   289 downloads

tempDistrict
 templeDist.bmp   754.15K   371 downloads

This has been converted using my "frm16 viewer". As you can see, It seems like pixels show in the right position, althought colour is garbled. I wonder why does this happen, as I've read everything (except footer) from offset 36 ahead as 16 bit colour components, which I directly displayed on a 16-bit surface. Maybe what Miloch told about reading "reversed", but I doubt that's a reason for getting bad colour. I have also checked that the thing which comes at the end of the frm16 is a 4 byte palette, with the 4th byte for alpha, which is almost always 0. This is also confusing me, why should files which use direct colour include this palette?

Anyway further investigation is needed to completely specify the format, so any info comes handy.

Mike:
We'll decipher 'em don't worry hahah And if we do that I can code a level editor to make whatever you want with the maps. But I think the best thing is to have the resources, as modifying maps in the same format is only useful por modding purposes.

see ya!!

EDITED:
I have already solved the problem, so don't bother to answer the post. I will post the frm tool promptly, when I finnish some debugging and testing with more images.

Edited by Balder, 22 August 2009 - 07:14 AM.

[Balder]

The anticipated update is here...

First of all I leave here a tool which is a viewer/converter for the FRM format. Includes a readme with all the needed info to use it. Link:  FRM16_Viewer_01153.zip   216.99K   616 downloads

And some updated screenshots, obtained with the tool:

Stars texture:
 stars.bmp   48.05K   329 downloads

Temple district minimap:
 templeDistrict.bmp   754.15K   383 downloads

Test map minimap:
 testMap.bmp   754.15K   295 downloads

Water texture:
 water.bmp   48.05K   304 downloads

This tool won't open for you frm of type 68, just 64 one. I'm working on the other format and I'll come again to tell any news. Bye!

[leahnkain]

Is it able to convert the full size maps?

[Balder]

It can convert any map snapshot, textures and other images but .way files are not images at all, just some kind of map definition. What do you actually want? Good night!

[Balder]

Okay, actually the complete map is composed from a bunch of files:

Minimap -> mapname.frm16 (frm16 type 64, that's 16 bit color starting at offset 36)
Intermediate data -> mapname.frm16 (in folder intermediatedata, this one is smaller in size, frm16 type 68, so it may be rle encoded and/or use color palette)
Map models -> bunch of mdl16 files (there's one model for the map, you can find sometimes other models used by the map)
mapname.zax -> plain .txt file, specifies every thing about the map
mapname.way -> no idea yet, may be a file containing placeable object positions etc, info about transitions...

My guess is that the actual painted map that it's seen when playing is built from mapname.zax using the minimap, the .way and the map models, mainly.

Actually any minimap or texture in the game can be extracted thanks to the FRM16 Viewer tool, so the next logical step it's to finnish the tool it manages also FRM16 type68, which leads to the conversion of intermediate data.

Next, we'll have to deal with .mdl16 (we would have to deal anyway, as it's an important format for the game).

With that I think we'll have enough to build a map, but it may be needed to write a tool which does that reading from the .zax. That wouldn't be so simple, but can be done if we can figure most commands.

[Miloch]

My guess is that the actual painted map that it's seen when playing is built from mapname.zax using the minimap, the .way and the map models, mainly.

Actually any minimap or texture in the game can be extracted thanks to the FRM16 Viewer tool, so the next logical step it's to finnish the tool it manages also FRM16 type68, which leads to the conversion of intermediate data.

Next, we'll have to deal with .mdl16 (we would have to deal anyway, as it's an important format for the game).

With that I think we'll have enough to build a map, but it may be needed to write a tool which does that reading from the .zax. That wouldn't be so simple, but can be done if we can figure most commands.

Yep, I said all that up on the 2nd page:

ZAX files contain the map definitions (sounds, models, properties). This file specifies where to place various graphic elements on the map, but not any actual graphics. For example, in Temple District.zax, it indicates there is a Cathedral model (mdl16) at X35, Y878 on the map. It does the same for trees, houses, walls and so on. Toward the end of file is a list of background frm16 textures (grass, water, etc.). However, this is not like a BG tileset since it is just the texture without the overlaying models. Also near the end of the file is a height map (elevations) and light map (light overlay). This is somewhat like an ARE file in the Infinity Engine.

Basically, to translate the big maps, we'd have to figure out the mdl16 format. Then we'd have to come up with some sort of automated routine that would be able to place the multitude of mdl16s overlays and frm16 underlays on a larger map as defined by the zax file. And although I could conceivably figure out former the same way I hacked the frm16 minimaps, it's way beyond my skill to handle the latter. That would probably require some sort of automated tool the likes of DLTCEP or Near Infinity... it'd need someone who knows a programming language like Java or C++ (which is what NI and DLTCEP are written in).

See that link too for my descriptions of the other formats. So once you can finish figuring out the other frm16 background, we need to figure out the mdl16s and then figure out how to plot on a map using the .zax data. Simple, no?

[Balder]

Yeah, at least we have reached a good understanding of the game so we have concrete tasks.

Now I'm giving a look to the compression of frm16 68 which I think we can figure. Reading from the zax is not difficult if you have figured ho does it represent things. The worst task will be figuring mdl16 as it's not so simple as frm or other formats: it includes transparent masks and many strings.

I'll continue working on it so I hope you'll see me back soon with news... 'til then you can paint some small maps with the textures


EDIT: Already figured frm16 type 68 Will update application when I have time!!

Edited by Balder, 23 August 2009 - 12:33 PM.

[leahnkain]

What I am looking for would be in type 68, I think. I am looking for the full size maps as a .bmp or .jpeg.

[Sam.]

What I am looking for would be in type 68, I think.

I am fairly certain not.

I am looking for the full size maps as a .bmp or .jpeg.

The problem is that there is no single file that contains the full size maps in any format. Instead the full map is composed by overlaying the background textures (which are bounded using coordinates) with individual buildings, individual trees and shrubs, individual containers like barrels or crates, etc. (which are placed at specified coordinates on the background). These buildings, containers, trees, etc. are EACH contained in a SEPARATE file. The .ZAX file is what is read to get the coordinates to place each item where it needs to be on the background.

To save people the time it takes to convert them, here are all of the .frm16 files of type 64 (sorted by what they are):
 Loading_Screens.rar   2.52MB   291 downloads
 Mini_Maps.rar   7.77MB   318 downloads
 Textures.rar   2.06MB   276 downloads
 Misc.rar   8.49K   267 downloads