Date: Thu, 16 May 1996 03:46:54 -0500
From: Christopher Joseph <heaven@interoz.com>
Subject: Mechwarrior 2/Ghost Bear's Legacy Hacking Update (heh)
Hello everyone. First of all, my apologies for not responding to some of you the last week or so. Apologies as well for not updating you guys in a while. *grin* I might actually get a lot more done if I didn't keep playing games. Kali NetMech is AWESOME! Had a couple 4 players games, some 3 players, and some 2 players - all were relatively fast and all were definitely a blast. Anyway...
- WEAPON EDITOR UPDATE Got most of the hard stuff done. Had the whole screen setup done and then it dawned on me that black and white and 14 shades of gray didn't make for a pleasant editor. *laugh* Redoing the interface to be like the one in GBL's Mech Lab, minus cool graphics. *grin* Hey, I'm not an artist I'm a programmer. I'm not EVEN going to predict when it'll be done. *chuckle* Soon, tho'...with source code (C) even - so you can see how NOT to code. Heh.
- MW2.PRJ UPDATE No further info here really, since I've been working on the weapon editor.
- NETMECH UPDATE Soon as DOS NetMech comes out I'm gonna' start fooling around with the files to see if I can't get it to use GBL's engine. Why? So we can blast each other with inferno SRMs, flamers, Arrow IVs, etc., and so we can use the new Mech chassis'. Kodiaks look totally arctic.
![Smile :)](./images/smilies/icon_e_smile.gif)
Have no clue why the ninnies at Activision didn't use it in the first place (the GBL engine). *shrug*
- HOW I PROGRAM UPDATE Like I do everything else...while listening to the Mechwarrior 2/Ghost Bear's Legacy CD. If I could, I'd pump the music into my brain 24-7.
![Smile :)](./images/smilies/icon_e_smile.gif)
MW2 CD:2, 3, 6, 7, 8, 9, 11, 12, and 16.
GBL CD:2, 3, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 14, and 14 (14 is cool).
- MISCELLANEOUS UPDATE Me and my bud from Valdosta Univ. (cpatters@grits.valdosta.peachnet.edu - Lurch - 6'8" *grin*) were thinking while playing some multi-Warcraft 2 how literally awesome it would be to have a Mechwarrior version. I've seen someone post basically the same idea on alt.games.mechwarrio2, and I agree 100%. I also agree with the follow-up poster who said that he didn't think Act' would be doing anything of the kind. *sigh* Which leaves it up to us...
*grin* Seriously. Any more programmers out there? I've thought and thought on this for like, 2 years now. As you can tell by how long it's taken me to graphicalize my weapon editor you can easily understand how come I've accomplished nothing along the lines of a War2 like game in that time. *chuckle* My major stumbling block has been the graphics. It really pains me to have to draw the dang tiles and such. For instance, as far as I've gotten on a War2 game is a 32x32 pixel dude walking (top-down). 12 frames. Blows War2's walking animations away - they've got like 4 frames. Now all I need are 12 frames for attacking, 12 frames for defending, at least 12 frames for dying (falling down) but more like 48 so I can have some different deaths, etc., etc., and then the various weapon frames, misc. objects, terrain tiles, blah, blah, blah. But boy does that walking dude look cool! Heh heh.
Get me some responses along these lines. It pains me how easy something like this *SEEMS* to be to make. Seriously. Not bragging on my awesome programming skills...no way. Heh. That would be a joke. It just seems that it would only take roughly 6 months to get a playable game that would kick butt. Rough as sandpaper, but it would be playable...and fun! I ramble....
- FINAL Including the Mech2/GBL info text file for those of you who didn't get it.
It's updated, so for those of you who already have it replace your old one with it. Not much updated, but still.
![Smile :)](./images/smilies/icon_e_smile.gif)
Later,
Chris
heaven@interoz.com
Jesus is LORD!
Blessed be the Lord my strength, which teaches my hands to war and my
fingers to fight.
- [ Part 2: "Attached Text" ]
MW2/GBL Info (written using Edit)
UPDATED 5/16/1996
First, let me say that all of what is written here is based on the Ghost Bear's Legacy files. Second, I have to give thanks and praise to God and Jesus for blessing me with the understanding I've come to have of the MW2 files. Not being mystical or any crap like that, just giving credit where credit is due. Thirdly (and finally) all of what is here was found out on my own time, with my own brain, and with no one else's help (not bragging, just making it clear I didn't get any unauthorized info from anybody). With that said...
- WEAPONS Located in the MW2.EXE file are thirty five 104 byte entries which seem to specify the characeristics of each weapon. Well, most of the characeristics. I present the following data as you'd see it in a C program (and please be warned - I'm rather wordy with my variables *grin*):
[code]/*--------------------------------------------------------------------------*/
#define d_word unsigned long /* I'm assuming they're unsigned - may not be */
#define NUMBER_OF_WEAPONS 35
struct WEAPON_CLASS
{
d_word unknownA,
unknownB,
unknownC,
unknownD,
shot_type,
hit_type,
unknownE,
unknownF,
unknownG,
unknownH,
lock_on,
shots_per_burst,
shots_per_ton,
sound,
unknownI,
range_factor,
damage_per_shot,
heat_per_shot,
heat_inflicted_per_shot,
degree_of_lock,
range,
burst_reload_time,
shot_reload_time,
range_unknown;
char weapon_name[8];
} weapon_entry[NUMBER_OF_WEAPONS];
/*----------------------------------------------------------------------*/[/code]
- Code Explanation Dang! Just noticed how many unknowns there were again. Heh. Still working on that. Ok, some explanations are in order...
shot_type
This appears to determine what the actual shot looks like. A blue laser bolt for the Large Lasers, a green bolt for Medium Lasers, a red bolt for Small Lasers, a big blue ball for PPCs (JJ told me around Activision they called it 'the pillow' - *grin*), small rockets for LRMs and SRMs, etc., etc.
hit_type
Not only does this determine what the hit graphic looks like, it determines what effect the hit has as well. By hit graphic I mean what the game displays when a shot hits its target, or the ground, or whatever it takes to trigger the graphic. The PPC has a gaseous blue explosion, LRMs and SRMs have small fiery explosions, lasers have those small little colored rings, etc. Also, the type of hit is important. *grin* I found this out when making the Napalm Rocket. I wanted the biggest looking explosion I could get to make it impressive, so I went up from the ARROW IV's pretty impressive explosion to the Nuke's even more impressive one. I thought it would just increase the size of the explosion graphic. Well, it did that, but it also turned the effect of the rocket's hit into a nuclear one, complete with massive spherically expanding damage. Heh.
lock_on
Either a 1 or a 0 as far as I can tell, and just determines if the weapon is capable of locking on (yes, and tracking) it's target. Also see 'degree_of_lock', below. Interesting to see things other than missiles track their targets (PPC shots, even lasers...*grin*).
shots_per_burst
I'm using burst as a general term meaning a single pull of the trigger, no matter how many actual shots are fired. For instance, the ER energy weapons all have a 1 shot 'burst', while the Pulse Lasers all have a 2 shot 'burst'. LRMs have either 5, 10, 15, or 20 shot bursts, SRMs 2, 4, or 6, etc., etc.
shots_per_ton
Self-explanatory.
sound
What sound file the game uses when the weapon is fired. When playing with this variable, the first number I used was 63 for the Large Pulse Laser. Heh. Imagine my puzzlement when I first pulled the trigger and heard not the normal laser shot sound, but the female entity entoning, "Atmosphere hostile - Ejection aborted". Heh heh. Funny. Anyway, the # is just the sound index # in the .PRJ file (see below).
range_factor
It was sort of funny how I got this, and goes to show you how weird I can be at times. I got the ranges as displayed in the Mech Lab for the first few weapons or so and wrote them down. Then by analyzing the element I called 'range_unknown' of the entries I determined it had to have *something* to do with the range, as the numbers were the same for each group of weapons (LRMs, SRMs, ACs, etc.) *grin* I divided the Mech Lab range by the number 'range_unknown' and got a decimal value which I also wrote down. It was only later that I noticed that all the 'factors' I got, when multiplied by 100, equaled this value...'range_factor'. It gets worse...see below under 'range'. *snicker* Oh, some examples: LRMs all have a 1.00 factor (100). That is, if you multiply the range_unknown by 1.00, you get the correct range of 1001m. So this entry would be 100. Umm...SRMs have a 0.7, or 70 in this entry. MGuns have a 300, Gauss 280, etc.
damage_per_shot
Self-explanatory. Interesting to note that the #'s are different than reported in the Mech Lab. For instance, the UAC/20 does 50 points of damage. That is unless I'm interpreting this wrong. LRMs do 2 not 1. SRMs do 3 not 2. PPCs do 17. Etc., etc. Weird stuff.
heat_per_shot
Not per trigger-pull, but per actual shot. This number is not a simple 1, 2, 3, etc. Seems to be multiples of 32768. When you start looking at weapons that do multiple shots (LRMs, SRMs, etc.) it looks like you're generating a lot more heat than 'by the book'. For example, SRM-2s generate a total of 2 heat when fired. The numbers in the entries [seem to] indicate that you generate 131072 heat per shot, or 4 heat per shot for a total of 8 heat! LRM-20s generate a little over 1 heat per shot for a total of 24 heat altogether. Go figure...also, the PPC generates (or so the numbers indicate) 25 heat, not 15. Just for the info, a Flamer generates 7 heat, or the same as an Ultra AC/20 and not the 1 or so as reported in the Mech Lab. *grin* I just thought of this as I was proofreading: the heat for multiple shots probably yield higher total heat per burst than 'by the book' because of the time elapsed between each shot. I mean, it takes .11 seconds between each LRM shot (see below for where I got this number) and the game does heat reduction in real time...so I imagine it takes into account the heat reduced over the time it takes the LRM to discharge. Maybe. *grin* That means we'd have to lose 8 heat units per second (.11*20=2.2 seconds for the LRM to discharge) to give us the 6 it's supposed to. *shrug*
heat_inflicted_per_shot
As above, under heat_per_shot, except this is the amount of heat given to the target when each shot hits. Flamers cause slightly more heat than a Large Laser generates, and PPCs cause the same heat as a UAC/20 generates. Oh, and Nukes cause 100 units of heat. Heh. Like firing 14 Ultra Autocannon/20s at once (using the heat data in the entries that is). *laugh*
degree_of_lock
This is only given for the LRMs and SRMs, so a value of 0 (if the weapon is capable of lock) probably indicates that it doesn't have good 'homing' ability. Also, SRMs (except infernos) have only a 25 compared to the LRMs 7500.
range
*laugh* Ok, so this is the funny part. Here it was the whole time and I didn't even see it until later! This is the actual weapon range as reported in the Mech Lab (or very close to it) except it's in cm (centimeters) and not m (meters). No doubt why I didn't catch on *grin*. For instance, LRMs have a 100100 in this entry. SRMs have a 49686. Etc., etc.
burst_reload_time
Simply put, this is the time (relative to God knows what) that has to elapse after you pull the trigger before you can pull it again. Weapon reload time is maybe a better term. I haven't actually got out the watch yet and timed this, but it *looks* like it might be in centi-seconds. SRM-2s take around 10 seconds (1092 value) this way, PPCs 4 (455 value), Gauss takes about 7 (728 value), etc. Hmm....
shot_reload_time
This is the amount of time it takes between each shot of a burst. For instance, in light of the above interpretation (centiseconds), .11 seconds elapse between each missile shot from an LRM-20 rack meaning the whole thing emtpties in about 2 seconds. ??? Again, I haven't checked....
range_unknown
See above for more info under range_factor and range. This value, when multipled times (range_factor/100) yields the correct range in meters for the weapon. For example, all the SRMs have a 709 here and a 70 for their range_factor. 709*(70/100)=709*0.7=496.3, or just 496.
weapon_name
Exactly 8 bytes long, every time. *grin* Also note that this field is LAST in the entry, not first. Took me a few minutes to figure that out.
![Smile :)](./images/smilies/icon_e_smile.gif)
- THE .PRJ FILE Whew! What a file this baby is. At a little over 30 million bytes this sucker weighs in at a hefty 29.38 MB. Which means making editors for it is extremely aggravating in my opinion because every change you make, if it involves changing the length of some in-file data (like mission briefings), means you have to save a 30 meg file back to disk. Heh. Without smartdrive (like I ain't got - have to keep it disabled so I can run GBL with my measly 8 MB RAM) it takes my system slightly over 42 seconds to save the file.
![Smile :)](./images/smilies/icon_e_smile.gif)
Anyway, about what I know. Geesh. Where to start in 30 meg? Heh. Actually, I don't know a heck of a lot. *grin* Maybe 1%, if that. The major thing I think I've basically figured out is the Indexing system used throughout the file. Stuff is scattered all over. At one spot you'll have 5-10 POLY entries which look likely to contain vertices and stuff defining a particular mech's physical makeup. Right after that you'll have an entry containing the sound for the 5th mission of GBL. And then you might find 2 more entries containing the mission briefings for the 1st mission. *laugh* Indexing...
At the very head of the file are the top level index headers after some file header info: the 4 byte string PROJ, a file length in bytes (from the 8th byte into the file), 4 more bytes, a 4 byte string DDIT, and 10 more bytes. All of those bytes except the file length are unknown to me at this time. *shrug*
Next we have the 20 index entries each of which is 24 bytes long. The index headers are:
FREE, ARCH, POLY, TABL, ANIM, CPIT, HUD, MGEO, MEK, AIT, PAL, CEL, XYC, DISP,
SNDS, MUS, LUMA, TEXT, BWD, and NTXT, and are the first 4 bytes in each entry.
The next 4 bytes in each entry is an unsigned (? - may be signed, I dunno') long pointing to the actual Index table for that header. Next, 4 more bytes and then another pointer which points to the SYMBol table for that Index. Finally, 8 more bytes (?). Oh, when I say 'point' I mean an offset in the file (in bytes). A file pointer, I guess...although I just used an unsigned long.
[code]/****************************************************************************/
#define ROOT_HEADERS
struct ROOT_INDEX_CLASS
{
char header[4];
d_word index_offset;
d_word unknownA;
d_word symbol_offset;
d_word unknownB;
word unknownC; /* these two look like 2 byte values */
word unknownD;
} root_index;
struct SYMBOL_CLASS
{
char symbol_header={"SYMB"};
d_word table_length; /* in bytes, and from the 8th byte into the table */
d_word unknownA;
char header[4]; /* contains the index header */
word max_entries,
current_entries;
word unknownB;
struct SYMBOL_ENTRY_CLASS
{
char entry_name[16]; /* name of the entry - FM1LFTOE for example - this
is an entry under the POLY header and is probably
some polygon info for the FireMoth's left toe */
word index_entry; /* # of the entry in the actual index table */
} entry[max_entries];
} symbol_table;
struct INDEX_CLASS
{
char index_header={"INDX"};
d_word table_length;
d_word unknownA;
char header[4];
word max_entries,
current_entries,
unknown_entries;
word unknownC,
unknownD,
unknownE;
struct INDEX_ENTRY_CLASS
{
d_word offset; /* points to the location in the file of the actual
DATA entry */
d_word length; /* length of the DATA entry in bytes */
} entry[max_entries];
}
/****************************************************************************/[/code]
- Near Finally Wow. I learned a lot just by writing this stuff up! Anyway, I'll go into the DATA entries later if anyone wants me to (what little I know). This is it for now. Geesh. And to think this is only the tiny-tiny tip of the iceberg. The DATA entries account for probably 99.9% of the file!
![Smile :)](./images/smilies/icon_e_smile.gif)
Hope this helps someone. PLEASE don't forget to write me with any questions, comments, and/or criticisms, etc. Oh, almost forgot.
Until I get the patches done (which means I'll have to understand more about how the DATA entries are organized in the .PRJ file) you can play the MW2 missions in GBL by hex editing the following info (and be prepared for some garbled looking briefing screens in GBL!):
- GBL Mission Command Line WOLF FALCON GBL more GBL
yell pink bass bran shar *
oran gree jess gui1 siou *
teal red_ clai gui2 tabb *
taup fuch newc gui3 terr *
jenn cind jeeh gui4
sabl rust tim_ guin
grey umbe andy apac
brow tan_ fost azte *
amy_ heid hoff cali *
silv plum zack coll *
aqua whit sean husk *
kim_ jill fran dobe *
cyan puce asah iroq *
maro blon pete nava *
gold bron cath osag *
iren mary sach pers *
Use a hex editor on MW2SHELL.EXE. Find the third (I believe) mention of the text string 'bass' in the file, or just find the first one and scroll down until you see 'bassSCN1'.Trial on Alshain. For each of the GBL missions just replace the 4 letter scenario header with the corresponding header from the Wolf or Falcon missions (yell and pink would be the 1st Wolf and Falcon mission respectively). You'll notice there's more GBL missions than Wolf or Falcon singly. *shrug* Then go into GBL and play away!
I've noticed that primary objectives, if to destroy a building or structure, are fulfilled by just shooting the darn thing ONCE. Don't know if this is for ANY building or what...but one shot and the structure just blows up. Hmm.
UPDATE 5/16/1996
Instead of hex editing you can just use a command line trick. In your GBL directory just type:
mw2 ????scn1
???? is a 4 letter scenario name (see above list).
The ones with *'s by them are, I finally figured out, the multiplayer NetMech scenarios. Pretty cool, too. For those of you who have KALI and haven't tried NetMech yet...do it! Interface (206.97.227.11) seems to be the hang-out for a bunch of Mech players.
Oh, and for the most part the multiplayer scenarios won't work as single player. Try copying your en01star.bwd to en00star.bwd, en06star.bwd, and en07star.bwd (I think that's all of them - if not just go up to 8, 9, etc.) Some of the scenarios look for star#0 and #'s >5. If you still get a crash back to DOS, keep trying to catch what it says before it crashes - more than likely it's looking for a DOS file and can't find it. Copy something there that seems applicable. *grin* Thus the above trick of copying an existing star .bwd to the en00star.bwd mw2 looks for.
heaven@interoz.com
Blessed be the Lord my strength, which teaches my hands to war and my fingers
to fight.