XeNTaX

Ok, theres another thing i'm noticing, i'm not sure if this is a fault or the way the file is... but the values.txt out of the games.mng (tree: \config\) ends like so:

; Mortar / Bombs info

LobberSpeed = 0.01
LobberRange = 24000.0

ChopperLobberDamage = 50.0
ChopperLobberRange = 1500.0

JetLobberDamage = 60.0
JetLobberRange = 2000.0

SuperChopperLobberDamage = 90.0
SuperChopperLobberRange = 1500.0

BuggyLobberDamage = 10.0
BuggyLobberRange = 500.0

HoverLobberDamage = 20.0
HoverLobberRange = 1500.0

SuperHoverLobberDamage = 22.5
SuperHoverLobber


Its that last part that worries me, see how it says that but fails to define a value? Seems like a cut off... tis strange.

Also, with the sound files, i'm noticing that they begin about 1/3rd into what they're supposed to, and end with their beginnings... and in loops there are long pauses at the ends. I have never seen a game developer make a loop with any lag at the end... so this was a red flag to me.

Let me know if ya figure anything out and i'll be glad to put it through its paces.

1. If you are previewing the files in Game Extractor, it won't show the full text file if it is too long. This could explain the cutting off of the end of the text file. However, extracting the file will give you the full file.
2. There is no way that the files could be starting or stopping half way through unless that is what it programmed in the archive. The files are all compressed, which means that you must start at the beginning of the file when trying to read it, otherwise the file could not be decompressed. In other words, if Game Extractor was not starting at the beginning of the file when trying to do the decompression, it would not decompress the file and it would not be readable.
3.T he inverted pcx images must be the way the game reads them. All BMP iamges are stored upside down, so chances are the game also stores the PCX images upside down for consistent reading. There is not much that can be done about this unless we re-write the wrole image the correct way up. It would be easier to change the image in photoshop then to convert it in Game Extractor.

I hope that answers all your questions. I will also try to get a new plugin for the other MBX files to you when I get home.

WATTO
watto@watto.org
http://www.watto.org

Well, i wasn't previewing the file. That was a clipping from the file as it extracted.

If the file was stopping half way through, and this is impossible as it wouldn't be readable... why was it somewhat readable and mostly not the first times around? I dunno, it just seems suspect, if you can agree, that a file defining the values for things would simply cut out on declaring a variable where it had just defined a whole set of them. If the variable was unused (which is not the case with this one, i can confirm its linked to a unit in the game) i would have thought it would be commented out at some point.

I also find it suspect that the wav files, when ya open em up in anything, they display the wave forms as previously mentioned.

Again, i don't know if thats how they're meant to be or not, but it all seems like its incorrect somewhere.

The sounds that display and play improperly for me in sound forge and winamp, play perfectly and fully in the game.

Timed them, found the difference is the full sounds in the game seem to be longer than those extracted. Pitch is the same, i'm sure of that as a large difference of pitch would be required to alter a sample by (in some cases) 2 seconds.

It just seems to me, that all the anomalies must lead to some problem with extracting the archives... but i, of course, can't be sure about that.

Through toying i don't know what could be wrong, but those are my observations.

Oh, and what i mean by that bit about the archives reading was that wouldn't it be possible, if improbable, that the routine to extract or preview the file was truncating part of it? Might that be something that would constitute a possible bug?

Like Watto explained, he extracted them using a decompression method that would not allow one to start anywhere else than at the beginning of the file.

The programmers may, for some reason, have intended it that way. The fact that they play well in the game, does not mean the programmers don't mess with it first to get the sound allright.

Hi again,

Hmm, well there is a possibility that there is a bug in the basic version with the decompression (ie cutting off the end) but I wasn't aware of the bug. I know the bug is not in the full version, if it is a bug, so I may look into it and try to fix up the basic version alittle?

However, if the file starts at the wrong spot, that is definately not a bug and it is correct in that way.

Anyway, I have attached a plugin for the *.mbx/*.dat files that works with the basic version. To use it, you tell Game Extractor to open the *.mbx files, NOT the *.dat files! I did this because I expect that people would more naturally try to open the big files rather than the small ones, therefore it is more probable that they open an *.mbx rather than a *.dat file. Anyway, same as before, unzip it into your plugins directory.


WATTO
watto@watto.org
http://www.watto.org

OK, well yes it does appear as though there was a decompression bug in the basic version which prevented it from writing the complete file. It isn't really a decompression bug, its just that at the time I wrote the basic version I had only just made my own file buffers, and it seems as though I hadn't remembered to flush out the buffer before writing the file.

Anyway, the good news though is that the full version does not have this problem, i repaired the bug somewhere between verison 0.94 (basic) and 1.02 (full).

Thanks mate!

WATTO
watto@watto.org
http://www.watto.org

See bud, i thought something was off hehe.

In the meantime, i guess i'll continue seein if i can pull a few favors and get your full version (I don't have a paypal acct anymore)... unless you fix the bug in the basic one before i do this... either way, i'll be donating to both of you in the near future.

All of this has made me really happy



So ya see, my persistence in this matter i see as mutually beneficial; i get to write off a cause of a problem and look elsewhere, or you get to find a bug somewhere to fix. Not tryin to be an ass and go off on a rant about about your programs

Hi mate,

Yes thanks for your help - it really does make a difference even if it is just picking out faults in the program

I don't really want to fix the bug in the basic version, mostly because I am currently trying to build a newer basic version off the full version code - thus the bug will have already been fixed. However, I have attached some code which *may* solve the problem - I just stole the code from the full version that I think was causing the problems.

Unzip the attachment INTO THE MAIN DIRECTORY - not the plugins directory. It should be ok because I designed this code to be backwards compatable, but you just never know. If it doesn't work, you will just have to re-install Game Extractor over the top of it

Good luck - hope it works.

WATTO
watto@watto.org
http://www.watto.org

Yeah, doesn't start anymore :\

But i'll wait for your newer version or get the full one soon as i can, its all good hehe.

Ok, so in testing of the dat/mbx decompression, i've found that it doesn't appear to even get the structure right, its all "fileXXXX" (where x's are numbers) and uniform sizes. Doesn't seem to be able to extract anything i can read either... tis strange.

If ya get some time, please do look into this.

OK, first make sure you are opening the *.mbx files, not the *.dat files . Game Extractor won't use the right plugin if you try to open the *.dat file

Secondly, the files won't have proper names - they are not stored in the archives. Therefore, it is perfectly legitimate for the files to have the names File XXXX.

Thirdly, it may be possible that all the files are similar sized, and unreadable - in fact most files used in games are unreadable. Thats because game makers develop their own files for use in-game, just as they make their own archive formats.


So from what you have mentioned here, i cant say either way whether it works or not, however I did test it on some of the archives from the demo without a problem so my assumption at this point in time is that the plugin is working correctly.

WATTO
watto@watto.org
http://www.watto.org

Hi!

Is there any way to open the model files inside the MNG? If I'm correct I should open the bin_* files.

Thanks?

Valor wrote:Hi!

Is there any way to open the model files inside the MNG? If I'm correct I should open the bin_* files.

Thanks?

I've figured out that the bin_* files are binary files and I don't know the specification. What I know:
1. the files starts with BS09 string: 4 bytes
2. zero: 4 bytes
3. length of the object path, int: 4 bytes
4. object path string, length: see 3. point

But the remaining content is unknown. Strange thing is that there are other model files in plain texts like Way point.s01.

Object : way point crystal
Matrix : 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000
Verts (6)
{
0.000000, -0.000000, 526.959045
198.813004, -0.000004, 364.078979
-0.073382, 187.846893, 364.078949
-198.959763, -0.000017, 364.078949
-0.073362, -187.846893, 364.078979
0.000000, -0.000000, 0.000000
}
Texture Verts (9)
{
0.908626, 0.952917
0.953331, 0.908213
0.908643, 0.908213
0.863922, 0.908213
0.908626, 0.863508
0.908643, 0.908258
0.908625, 0.908213
0.908643, 0.908167
0.908661, 0.908213
}
Quads (0)
{
}
Tris (8)
{
2, 1, 0
Texture : 'scanner unit.tif' 0, 1, 2
Opacity : Filter 0.500000
Normals : 0.526252, 0.557179, 0.642348, 0.633738, 0.000000, 0.773547, 0.633738, 0.000000, 0.773547
3, 2, 0
Texture : 'scanner unit.tif' 3, 0, 2
Opacity : Filter 0.500000
Normals : -0.633459, 0.000000, 0.773777, -0.526092, 0.557009, 0.642626, -0.633459, 0.000000, 0.773777
4, 3, 0
Texture : 'scanner unit.tif' 4, 3, 2
Opacity : Filter 0.500000
Normals : -0.526091, -0.557009, 0.642626, -0.633459, 0.000000, 0.773777, -0.633459, 0.000000, 0.773777
1, 4, 0
Texture : 'scanner unit.tif' 1, 4, 2
Opacity : Filter 0.500000
Normals : 0.633738, 0.000000, 0.773547, 0.526252, -0.557179, 0.642348, 0.633738, 0.000000, 0.773547
2, 5, 1
Texture : 'scanner unit.tif' 0, 5, 1
Opacity : Filter 0.500000
Normals : 0.642933, 0.680717, -0.351087, 0.877668, 0.000000, -0.479269, 0.877668, 0.000000, -0.479269
3, 5, 2
Texture : 'scanner unit.tif' 3, 6, 0
Opacity : Filter 0.500000
Normals : -0.877519, -0.000000, -0.479542, -0.877519, -0.000000, -0.479542, -0.642874, 0.680655, -0.351314
4, 5, 3
Texture : 'scanner unit.tif' 4, 7, 3
Opacity : Filter 0.500000
Normals : -0.642874, -0.680655, -0.351314, -0.877519, -0.000000, -0.479542, -0.877519, -0.000000, -0.479542
1, 5, 4
Texture : 'scanner unit.tif' 1, 8, 4
Opacity : Filter 0.500000
Normals : 0.877668, 0.000000, -0.479269, 0.877668, 0.000000, -0.479269, 0.642933, -0.680717, -0.351087
}

...

I think the bin_* files are the same but binary formatted. End of the files I located the texture files too like in the example above.

Could someone help me decoding the model files?