I decided to open new tread instad of ols "let the modding begins".

Here is short update of my search:

dobjects.obj
-------------------------------------------------
bmp 51 false alarm
tga 1129 false alarm
16 bit fnt 1 false alarm
8 bit fnt 83594 false alarm
Autodesk FLI Animation 1 false alarm
Autodesk FLC Animation 15 false alarm
Playstation TIM Type 2 65 FOUND !
Playstation TIM Type 8 28 FOUND !
Playstation TIM Type 9 73 FOUND !
Standard EXE found 31 false alarm
total files extracted 166

fobjects.obj
-------------------------------------------------
bmp 51 false alarm
tga 256 1129 false alarm
16 bit fnt 1 false alarm
8 bit fnt 83594 false alarm
Autodesk FLI Animation 1 false alarm
Autodesk FLC Animation 15 false alarm
Playstation TIM Type 2 65 FOUND !
Playstation TIM Type 8 28 FOUND !
Playstation TIM Type 9 73 FOUND !
Standard EXE found 31 false alarm
total files extracted 166

dobjects.tex
-------------------------------------------------
bmp 66 false alarm
tga true 24 2 FOUND!
16 bit fnt 486 false alarm
8 bit fnt 1745 false alarm
DSMi Module 11 false alarm
Standard EXE found 16 false alarm
total files extracted 2

fobjects.tex
-------------------------------------------------
bmp 75 false alarm
tga 256 2 FOUND!
tga true 24 2 false alarm
16 bit fnt 507 false alarm
8 bit fnt 2067 false alarm
Amiga OctaMed Module 1 false alarm
DSMi Module 18 false alarm
Standard EXE found 217 false alarm
total files extracted 2


dobjects.LOD
-------------------------------------------------
bmp 12 false alarm
tga true 24 2 false alarm
8 bit fnt 363 false alarm
total files extracted 0

dobitmaps.bit
-------------------------------------------------
bmp 4 false alarm
tga true 256 1 FOUND!
8 bit fnt 8 false alarm
Autodesk FLI Animation 2 false alarm
Autodesk FLC Animation 2 false alarm
total files extracted 1

dobjects.TBL
-------------------------------------------------
Standard EXE found 8 false alarm
total files extracted 0

So in bottom line we have 166 files extracted named 3T ("3" in the filename is rather like power of 3, than regular3) and classified as a TIM files used for PSX. I have tried and trying to search and use TIM2TGA converters but the one I found do not see that 3T file format.

What do you think about those false alarms? Program I am using to comb is looking for characteristic HEX patterns so when it sees them attempts to extract the file. When unsuccessful marks them as false alarm. They still may be there though.

I would believe the program - the false alarms are just coincidence.
Also the Playstation files - I would be amazed if the Longbow developers used PS files.

What program are you looking at the OBJ files with?
It sounds interesting.
Presumably they arent IFF files by another name?

Have you tried running my dechunk program on them?
Just drag a file onto the EXE or run it from a command shell with the filename as a parameter.
The latest version is at my website
- this one actually extracts the file components.
I would try it but dont have access to the OBJ files on this PC.

Cheers,
Keith

Thank you Keith for the program and advice. I 'll try to play with dechunk today.

The program I have extracted some of the files is MultiRipper 3.0. Here is the short description of the program :
web page
and here is the program file:
web page

Originally this tool was suggested to me by fng2k in the older days of Gunship!. I must admit that it works erratically and Playstation files are just pure coincidence. It works by identifying Hex patterns, but it did extract some *.3T files I cannot open now and before it has extracted that tga (clean as a whistle) texture I have posted earlier.

I'll move to dechunk now.

Hey guys, if there's anything I can do to help, let me know. If you'd like to post files, or need some web space, etc..

It gives me runtime error 6 or 52.

Polak apologies - looks like I need to do more testing. It works on my laptop but I'm getting error 53 'File not found' on my games PC.
It creates a CSV file with just a header line, and an a folder named after the IFF file, then terminates.
Is that similar to what you get?

--
But the OBJ and TEX files arent IFF format anyway.
The TEX file looks to be a DLL containing lots of TGA files.

The OBJ file has
a 4-byte header
many 104 byte entries, titled eg LBOW_CPIT_U,
a LOT of data (probably the 104-byte entries define which chunk of data to use to define the 3D-shape of the described object?)
I would guess this to be a proprietary format.

The LOD file is similar, but with 44-byte titled entries

The MIF files are text and may be of use

Cheers,
Keith

That is exactly what I get.


Do you guys know any other "extracting" tool then?

Hey guys,

Since i'm the rookie on this forum, allow me to briefly introduce myself ;-). My name is Mario Brito. One of my big hobbies is game modding, since i love to take things apart and see what makes them tick. I've been active in some capacity on the Wing Commander and Lancer communities, where i'm known as "HCl". After +G's e-mail, i looked around LB2's TRE files and created the detre program based on TRE samples he provided. To cut the story short, my curiosity about LB2 peaked and this is how i find myself in the SimHQ forums today. I hope i'll be able to make a valid contribution to LB2 modding and this community.

Now to my findings: I was able to spend a few hours yesterday looking around LB2 files, and was able to determine a few things..

- 1.10 / 1.11 format: This is a known RLE-like compression scheme, used by Wing Commander and StarLancer for compression of 8-bit sprites. I used a small program on a couple of LB2's SHP files and it seemed to decompress the files perfectly (although the palette is clearly wrong, since the program is set to use StarLancer's palette). You can find a link to this program below if you want to play around with it, although it'll need to be adapted to LB2:
http://eden.dei.uc.pt/~mbrito/lb2/spr2bmp.zip

- TEX files: This file is not familiar to me, and is not clearly understood yet. It doesn't seem to be DLL-based, although there are some strings that would suggest this. These, however, seem to be garbage, resulting from uninitialized memory buffers.

The first 768 bytes seem to be ignored by the game, as i've tried to change this data in every way with no results. The size would suggest a RGB palette, but no valid palette seems to exist there.

In any case, after these 768 bytes, there seems to exist a 4-byte value describing the number of images on the archive, and a structure describing each image, in terms of name (100 bytes), offset (4-byte) and dimensions(4+4 bytes). There are still some unknowns, regarding how the game determines which palette to use for each image, and how this offset is used to access the raw image data.

In short, i'm still looking around... The OBJ format doesn't seem familiar either, so it'll need to be documented as well.

Anyway, i'll keep you informed of any progress.

Mario

Nice to hear from you Mario. And thank you for your detre utility which in fact sparked and revitalised interest in LB2 modding myself including. I am also freshman, but like you like modding. However and unfortunately I am not into programming, neither I have suitable background. I am more into graphics and 3d modeling, however my main interest is always terrain modeling. I will comment wherever I will be able on your post above little later, at the moment let me say only that I will definetely check the linked program and menwhile if you knew any other "extractor" to those files please kindly share.

One thing only I would like to mention now also, and this is currently only my guess, that the terrain looks to me as something "related" to Jane's USAF, which in fact if true could be very interesting to play with. I am in process to gather more informations about it which I will share soon.

I have quickly run shp files found in OBJPICS.TRE with spr2bmp utylity and I confirm that it extracts nicely 2 bmp files from each *.shp file. Each of bmp is 640x480 color bitmap in indexed mode(EDIT)depicting 3-view drawing of 3D object and some kind of rendering of the same object. Sometimes only rendering is avaialable and not 3-view line drawing. Good resource for modeling. As Mario says, the palette is false.

The find is exciting, however I would like to mention that 1.10/1.11 format I feel should be 3D object and not just 2d sprites. But then again name "objpics.tre" title is pretty selfexplanatory after all . So perhaps 3D stuff and textures must be elsewhere.

Slowly peel by peel and we may peel off this sucker ........

I've updated dechunk.exe on my website with version 0.3, should work ok now.
Any problems, Double-click dechunk.exe, enter the full path to an IFF file, select Debug and click [Expand] - this will give me a clue...

Cheers,
Keith

Hey Mario, welcome aboard!

You sound very knowledgeable as to how the EXE is performing, would be neat to see if you could determine what's causing a few of the bugs in this one (like the 366 RAM requirement, missle issues, etc. plenty of time for that though).

I'm sure you guys will peel back this onion as Polak mentioned.

I'm a rookie when it comes to modding, but maybe this will be a good excuse to get my feet wet.

Something I came upon today. It may be of some help to us in our quest. Perhaps Mario even knows this site because spr2bmp is here but later version.
Anyway here is the link:
web page

If someone will brave there here is the question: pay please attention while SHPEditor will work first time. Because in my case I have definetely succeded in loading shp file; and even it displayed nothing it did work.
But now I have "load Shp files" greyed out.
Please check and advise.

Later version Spr2bmp does not extract files from shp, but perhaps I am doing something wrong.

After experimenting a bit with spr2bmpv4, i'm fairly sure this is a different SPR format. Besides the differences in the file header, in this format transparency is apparently acheived through an alpha map, while on Wing Commander / StarLancer / Longbow SPRs transparency is provided by the compression algorithm itself (by specifying transparent "runs").

In any case, to clarify, the spr2bmp i linked before was created by me, based on my observation of Wing Commander and StarLancer files. If anyone is interested in the more technical details, there is a small text describing this format which i wrote back then. You can find it on the Lancer\'s Reactor . The decompression algorithm is also described there. :-)

Regarding the bugs on Longbow 2: i'm fairly sure that by examining the EXE it'll be possible to determine the cause of those problems and to come up with a solution. I have to say, however, that i haven't been able to reproduce the 366mb RAM problem so far. My system currently has 384mb RAM and it's running LB2 with no problems to report.

Mario

Mario: Regarding the RAM limit problem, I'm running without a limit (512MB in dual-channel mode), too. Not using any compatibility settings, running Turbo at 35% to achieve a playable rate. The RAM limit problem seems to be system specific on some boards. No idea why that would be a problem. I've hacked the objview.ini file to try and reduce the terrain detail "warping" you see. I think I've improved it a lot, I'll keep testing and modifying it. You might want to try looking at my results at some point and give me an opinion. Thanks for the help.

I will read and try to analyze your notes on WC/SL. But at the moment I would like to bring this link here to your attention:

http://www.simhq.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=30;t=003771

Perhaps for you, being person well versed with file structure and coding, thread linked may be of a help to consider the following hypothetical setup:

* original LB2 graphics are in tga format 32bit allowing for full transparency.
* format then is compressed by using RLE (run length encoding).
* 32 bit is then converted to 16bit (for some reason that is how the graphic card are stored in memory of hardware (LB2 was predominantly 3Dfx game - was there anything specific here?) but this part I do not understand well.

Is in your understanding of how the graphics wok for LB2 any provision for mipmapping?

The above link is from EECH forum. Maybe there and here is similar situation and perhaps we could review them with benefit for both sims. Maybe it is completely wrong direction, but please let us review it.

Some see it, some don't, it's a very odd problem. The nice thing is there are several work arounds that fix it.

I nailed down the exact M$ compatability setting that "fixed it", so that may give us a clue to what's causing it (I posted that value on my web site).

Unfortunately, once you use the M$ compatability fix, you can't get into the Kiowa training missions. The only real fix is the boot.ini adjustments to limit your RAM globally to the system.

+G
I'm not doing anything to limit RAM. Maybe we should consider what chipset(s) allow it to run without limiting RAM and which require it, that might get us another step. I'm running NForce2 in dual-channel mode, on-board audio. I don't have any PCI cards installed, just a 9700Pro AGP card. No AV program or other "goodies" running in the background. Perhaps it's not entirely RAM/OS dependent. It IS a very odd problem.

When I first wrote that install guide I had no problems either. I discovered that the game worked fine on XP, using D3D mode (lots of trial and error, finding that one setting). This was before we had a stable/reliable Glide wrapper.

Now that I'm on a new system/board, I now have the issue. It might be hardware related (or something in the HAL, DLLs) who knows.

The nice thing is that there are solid work-arounds for it. It would be nice to nail it though.

It might be a good idea to test if this problem occurs using D3D and Glide. WC: Prophecy had a problem which only occurred in Glide mode, so the same could be happening here. I'm running the game in D3D mode at the moment, but i'll try to install a Glide wrapper when i get home.

Polak: I'm not up to speed on EECH modding (in fact i'm just starting on Longbow2), but here are some quick thoughts regarding image transparency. Generally speaking, there's several ways of acheiving transparency on a image. The most usual way these days is to include a separate channel which will specify the transparency level for each pixel, which is known as an alpha map. This can be stored along with the image itself, if the format supports it, or dumped to an 8-bit image with a black-and-white palette, where darker pixels are more transparent. After a quick look at the thread you linked, this is probably EECH's "multiple-alpha" mode, so replacing the texture and alpha map should be enough to import new transparent textures, providing you edit the necessary flags (and the engine supports it).

There are other ways of encoding transparencies, however. For example, you can specify a special color which will be regarded as transparent in the game (color key transparency, iirc). This is usually a horrible pink that no one uses, or something similar. This way, you can get all the information on a single image. This is probably what is called "single-alpha" in EECH modding.
Yet another way to store this information, which is used by LB2 SHP files, is on the RLE algorithm itself. RLE basically codes pixel repetition, so the algorithm codes something like "this color occurs 5 times", "afterwards, the next 3 pixels are transparent, draw nothing". Of course, in these two techniques you can only code "full" transparency, not semi-transparency.

This doesn't have anything to do with mipmapping, not directly, although both techniques can be combined. Longbow 2 does use mipmapping, by the way. You can find in the TEX files a lot of textures with decreasing dimensions (256, 128, 64...)

Anyway, i hope i haven't bored you with all this. Some of what i said should hopefully be useful to Longbow 2 and EECH...

How is texture transparency handled in Longbow 2's 3D models? Haven't quite got to that yet, but i suspect there should be a flag somewhere on the OBJ defining this...

Mario