Lords of Magic Utility v0.2

[Boaster]

What about what's here?

superuser.com/questions/160702/get-current-folder-name-by-a-dos-command

Because you're still having to set a directory, and that is not a dynamic input and destination path. They're still set, even as variables.

[Boaster]

But I see what you did.

You just created a file that would extract ALL files in a directory, rather than files selected from the explorer window.

Such that, I would use the BAT file as a program when accessing IMP files, where I would double-click the IMP file and it would extract it's contents to the current folder and into subfolder /PCX/.

[pikol]

I'll try to do something like that, but you have to know that I'm not really familiar with batch as I start using this when you asked me.

Then when you use path in batch, the path is always relative to the batch file himself and not relative to the file you oppened with!

You see the difference?

I'll try to make something else later when I'll have more time. Lot of work these days!

Cheers

[orzie]

Can anyone please reupload LOMUT here? I must experiment with it as well.

Nevermind, I downloaded it from the attachments.

[orzie]

I managed to change animation of an existing sprite using LOMUT.

The only problem was the loss of selection transparency of the green area (it's still transparent, but refers to the unit now instead of terrain).

I can conclude that we will need somebody whose specialty is programming, to fix the IMP compilation options.

Even decompiling an original Air Creature Level 1 sprite and recompiling it back results in a drastic increase of file size (16 kb -> 92 kb). As you can guess, the selection area is the same damn 512x512.
I have a feeling that it will be rather easy to fix for an understanding person... but we can't code.

[Boaster]

Nov 28, 2013 10:02:15 GMT -6 orzie said:

I managed to change animation of an existing sprite using LOMUT.

The only problem was the loss of selection transparency of the green area (it's still transparent, but refers to the unit now instead of terrain).

I can conclude that we will need somebody whose specialty is programming, to fix the IMP compilation options.

Even decompiling an original Air Creature Level 1 sprite and recompiling it back results in a drastic increase of file size (16 kb -> 92 kb). As you can guess, the selection area is the same damn 512x512.
I have a feeling that it will be rather easy to fix for an understanding person... but we can't code.

The reason the file size jumps in size is not because the transparency is selectable, but because the sprites are not properly mirrored and have to be manually inserted by mirroring with a paint program.

[orzie]

We will need a C/C++ coder to fix a few *h and *c files I believe. Something may be wrong in the compilation properties.

Will have to check what part of the code is responsible for selectability.

The size is not of a global problem for now I suppose, unless you will be going to change EVERY sprite (e.g. to make a total conversion).

[ozz]

Hello everyone!
I've been looking through the forum and came across this utility. So I decided to look at the code and some .imp files to figure out what is wrong with it.

typedef struct {
u4 Unknown1; // this looks similar to pairs of XY offsets.
// sample values:
// #10f8000, #10f8004, #1088000, #1088004

u4 Unknown2; // never seen it other than #FF (-1?)
u1 Unknown3; // never seen it other than 0
u2 Unknown4; // never seen it other than 0
u1 Size; // length of sequence
u4 Offset; // offset of facing groups (directions)
} __attribute__ ((packed)) Sequence;

What snv missed here is that Unknown1 is actually used for mirroring. When compiling the .imp the utility doesn't alter that variable at all. Should be fixable.

[Boaster]

Aug 12, 2015 13:25:16 GMT -6 ozz said:

Hello everyone!
I've been looking through the forum and came across this utility. So I decided to look at the code and some .imp files to figure out what is wrong with it.

typedef struct {
u4 Unknown1; // this looks similar to pairs of XY offsets.
// sample values:
// #10f8000, #10f8004, #1088000, #1088004

u4 Unknown2; // never seen it other than #FF (-1?)
u1 Unknown3; // never seen it other than 0
u2 Unknown4; // never seen it other than 0
u1 Size; // length of sequence
u4 Offset; // offset of facing groups (directions)
} __attribute__ ((packed)) Sequence;

What snv missed here is that Unknown1 is actually used for mirroring. When compiling the .imp the utility doesn't alter that variable at all. Should be fixable.

Sounds like a major breakthrough.

[ozz]

Looking at those 4 bytes:
The first is most of the time 0, sometimes 4 for units, 78 (120 in dec) or f8 (248) for some buildings. No idea what it does.
Second is definitely used for mirroring. 80 (128..of what?) for mirrored units, sometimes 81 (129) for buildings (are there mirrored buildings?).
3rd.. 0a, 08, 0f.. no clue here.
4th is always 1.

[Boaster]

Aug 13, 2015 0:48:52 GMT -6 ozz said:

Looking at those 4 bytes:
The first is most of the time 0, sometimes 4 for units, 78 (120 in dec) or f8 (248) for some buildings. No idea what it does.
Second is definitely used for mirroring. 80 (128..of what?) for mirrored units, sometimes 81 (129) for buildings (are there mirrored buildings?).
3rd.. 0a, 08, 0f.. no clue here.
4th is always 1.

One of these might control the unit frame border (ignoring transparent green background), quite possibly, which is for selectable area.

If you have the mirroring solved, selectable area would be the final piece of the puzzle.

[ozz]

It seems there is a rectangular box for unit selection, so there should be width, height and a pair of coordinates somewhere to specify the position of the box.

Update:

typedef struct {
 u1 Type;   // 0=normal, 8=duplicate-back-reference
 u1 HSType; // What kind of value HSpot holds:
            //   0: packed 16-bit DispX and DispY (both signed)
            //   2: offset to HotSpot structure
            //   3: offset to HotSpot structure (how is it different from 2?)
            //   4: offset to HotSpot structure (how is it different from 2?)
 u2 Width;  // real width
 u2 Height; // real height
 u2 Size;   // compressed size, or uncompressed, if Type=8 or Header->Type=9
            // should be aligned to 4-bytes. Unsure about Header->Type=25
            // some IMPs, like missile/spl03ap.imp, have it zeroed.
            // we dont use it for anything.

 u4 HSpot;  // Hot Spot: offset or packed Disp XY-pair
 u4 Offset; // offset or number of duplicating frame
 // Note: duplicates used for animation delay. Don't simply strip them.
} __attribute__ ((packed)) Frame;Here, width, height and Disp XY determine what part of the image is shown (and all of that area is used for selection). It is always set to 512, which leads to the selection problem.
Need a way to determine the height and width of the actual unit graphic without the green area and its location.

[Boaster]

So, if we can get the utility to read the actual dimensions of the graphic (like if we crop each frame to their actual sizes), then we could potentially rectify the selection area problem?

[ozz]

Aug 13, 2015 9:56:38 GMT -6 Boaster said:

So, if we can get the utility to read the actual dimensions of the graphic (like if we crop each frame to their actual sizes), then we could potentially rectify the selection area problem?

Yes.