MechCommander 1 / Gold - further Modding notes tutorial

Hello dear MechCommander Modding Community,
this article shows just some information about modding MechCommander. This should be seen as a thread for useful side information and maybe can support your personal modwork with MechCommander. Have fun while digging for information:

---

Mech Colors / Color setups

Tigress on NGNG 2013:

Thanks Tigress.

Although i found a website that has every single file extracted and available for download. Now i'm just messing with the compbas.csv file using excel. I'm just trying find the file to change the main blue /yellow mech color. i'm still trying to figure out the weapon slots on a mech. Sometime some mechs shoot 2 ppc from 1 arm, while machine gun fires from missile launchers. Any tips on which are the simple things i can edit?

Thanks.

Mech colors are controlled by the pilot data, believe it or not, so you'd have to go through and change every single one of the player-usable pilots to reflect a different color scheme..including the ones pre-assigned in the start0.pkk/xstart0.pkk files. I'm looking at a way to automate that, to a point.

Bestia_Infernali, 2013:

//////////////////////////////////////////////////////////
//////////////////////PAINT SCHEMES///////////////////////
//////////////////////////////////////////////////////////

15 = Black/Tan
17 = Gold/Navy
18 = Copper/Gold
25 = Tan/Gold
26 = Yellow/Red
27 = Red/Gray
28 = Green/White
29 = White/Red
30 = Black/Red
31 = Navy/Gold
32 = Black/Light Blue
33 = NONE
34 = NONE
35 = NONE
36 = NONE
37 = Navy/White
38 = Gray/White
39 = Gray/Black
40 = Gray/Copper
41 = Gray/Navy
42 = Gray/Tan
43 = Gray/Red
44 = Gray/Gold
45 = Gray/Light Blue
46 = Black/White
47 = Black/Light Black
48 = Black/Copper
49 = Black/Navy
50 = Black/Tan
51 = Black/Red
52 = Black/Gold
53 = Black/Gray
54 = Copper/White
55 = Copper/Black
56 = Copper/Light Copper
57 = Copper/Navy
58 = Copper/Tan
59 = Copper/Red
60 = Copper/Gold
61 = Copper/Gray
62 = Navy/White
63 = Navy/Black
64 = Navy/Copper
65 = Navy/Light Navy
66 = Navy/Tan
67 = Navy/Red
68 = Navy/Gold
69 = Navy/Gray
70 = Tan/White
71 = Tan/Black
72 = Tan/Copper
73 = Tan/Navy
74 = Tan/Dark Tan
75 = Tan/Red
76 = Tan/Gold
77 = Tan/Gray
78 = Red/White
79 = Red/Black
80 = Red/Copper
81 = Red/Navy
82 = Red/Tan
83 = Red/Light Red
84 = Red/Gold
85 = Red/Gray
86 = Yellow/White
87 = Yellow/Black
88 = Yellow/Copper
89 = Yellow/Navy
90 = Yellow/Tan
91 = Yellow/Red
92 = Yellow/Gold
93 = Yellow/Gray
94 = Light Blue/White
95 = Light Blue/Black
96 = Light Blue/Copper
97 = Light Blue/Navy
98 = Light Blue/Tan
99 = Light Blue/Red
100 = Light Blue/Gold
101 = Light Blue/Gray
102 = White/White
103 = White/Black
104 = White/Copper
105 = White/Navy
106 = White/Tan
107 = White/Red
108 = White/Gold
109 = White/Gray

Those paintschemes can be used (the code ID) into MechWarrior profiles. There is a line for Mech paint scheme that should be used with the warrior.

---

1stBeast:

is it possible to do a new Hardpoint system?
or weapons? for example LRM´s in subcategories (LRM5, LRM10....)

or at least change the system how ammo is added to a mech?
right now if you want 30 shots in a gauss u have to bring 2 and both are fired at the same time so u still have effectivly still only 15 "shots" but 2 fired

Tigress:

Hardpoints have been discussed and do not appear to be possible with the level of control we currently have over the game. New weapons are definitely doable, and we'll be putting in plenty of stuff, perhaps not immediately, but at some point. I know Sean Lang and myself spent the majority of an evening just reading through Sarna to see what weapons were available during the time frame of Op. Bulldog/Op. Serpent, so if that's any indicator, expect to see some new technology added in.

The Ammo problem is also being discussed, and I have it set up to test, I just haven't had the time to do so thanks to my new job. There is no logical reason why it's not possible to have separate ammo items in the mechlab to let players bring along extra ammunition, however it will eat into the limited number of new weapons we can add (approx. 150 if memory serves) so we have to balance this feature versus addition of totally new equipment.

Bestia_Infernali:

Hello,

bbc_standard_quote wrote:

• Battlemech loadouts *weapon & component placement as well*
• When placing weapons onto a battlemech, we know where the game will place said items on the battlemech

I've tried with:

1) weapons' placement in Mech's Profile (both original, and modified files).

Result: overwritten. Each time mission is loaded, new Mech Profile is created in \DATA\SAVEGAME\temp\ (ALT + TAB the game to see it). All data about weapons' placement is replaced by some default, broken, make-no-sense system:

- missiles fired from arms,
- 5/6 of loadout placed on one arm,

2) values Yes/No for hardpoints (head,CT,LT,RT,LA,RA,LL,RL) from compbas.csv.

Result: seems to be ignored as well.

3) I did some testing, and looks like components' placement (based on its ID) is defined somewhere else. Like pair of Pulse Lasers placed one per arm, while pair of PPCs are both placed on the same arm.

Result: Executable? Binary *.HSP files?

Code:

// referenced in OBJECT2.PAK
[HotSpots]
st HotSpotFileName = "lk"
// SHAPES.FST dir
data\sprites\LK.HSP

Guessing. Can't reverse the exe to figure out what's going on behind the scenes. I don't know how.

Am I missing something? Components' Tonnage? I'm out of ideas.

@ adding new weapons

Isn't the number of components hardcoded, or something along these lines? If you add a new weapon, and this weapon isn't mounted to mech (saved in mech's profile), it will be gone when mission is over.

One of weapons I added isn't even attached to anything in Mech's Profile*, while another is, but both are working. Weird.

* see point 1: overwriting Mech'a Profile.

@ OBJECT2.PAK

you can speed up projectiles over there, but only for missiles, and ballistic - energy weapons are missing statement below:

Code:

[BulletData]
f Velocity = 200.0 // m/s

but do it in hex editor (don't be fooled with fact that this file can be read in any text editor). Repacking/unpacking this huge no-file-names archive makes no sense...

Speaking of effects... my old notes about available(?) types (IIRC from compbas.csv)

Code:

//////////////////////////////////////////////////////////
//////////////////////WEAPON EFFECT///////////////////////
//////////////////////////////////////////////////////////
0 - Small Laser
3 - Heavy Flamer, C/Heavy Flamer
4 - PPC
5 - ER PPC, C/ER PPC
6 - AMS, C/AMS
7 - AC/5, Ultra AC/5, C/Ultra AC/5
8 - SRM/2, C/SRM/2, Streak SRM/2, C/Streak SRM/2
9 - LRM/5, C/LRM/5
10 - Gauss Rifle, C/Gauss Rifle
11 - Machine Gun, C/Machine Gun
12 - Laser
13 - Pulse Laser, C/Pulse Laser
14 - C/ER Laser
15 - Large Laser
16 - Large PS Laser, C/Large PS Laser
17 - Large ER Laser, C/Large ER Laser
18 - AC/10, C/Ultra AC/10
19 - AC/20, C/Ultra AC/20
20 - LB 20-X AC
21 - LB 10-X AC
22 - LB 5-X AC
23 - C/LB 20-X AC
24 - C/LB 10-X AC
25 - C/LB 5-X AC
26 - Large X-PS Laser
27 - Thunderbolt
28 - Light Gauss Rifle
29 - Rail Cannon
30 - LT Cannon
31 - Heavy LT Cannon

I think I know where the problem is: something wrong happens during Mech's Profiles creation in \DATA\SAVEGAME\temp. This is where temporary profiles for player's mechs/warriors are created during logistic <-> mission phase. Seems like weapons' placement in case of Mechs controlled by AI is working fine. Only player is affected by this. For example:

Mech Profile file:

[LeftTorso]
uc[2] Component:0 = 15,0 //Ultra AC/10
uc[2] Component:1 = 16,0 //Streak SRM/2
uc[2] Component:2 = 19,0 //Streak SRM/2 Ammo

[RightTorso]
uc[2] Component:0 = 17,0 //Streak SRM/2
uc[2] Component:1 = 18,0 //Streak SRM/2 Ammo
uc[2] Component:2 = 20,0 //Ultra AC/10 Ammo

[LeftArm]
uc[2] Component:4 = 13,0 //ER PPC

[RightArm]
uc[2] Component:4 = 14,0 //ER PPC

"New" Mech Profile file created by the game:

[LeftTorso]
uc[2] Component:0 = 18, 0, //Streak SRM/2 Ammo

[RightTorso]
uc[2] Component:0 = 19, 0, //Streak SRM/2 Ammo

[LeftArm]
uc[2] Component:2 = 13, 0, //ER PPC
uc[2] Component:3 = 14, 0, //ER PPC
uc[2] Component:4 = 15, 0, //Ultra AC/10
uc[2] Component:5 = 17, 0, //Streak SRM/2
uc[2] Component:6 = 20, 0, //Ultra AC/10 Ammo

[RightArm]
uc[2] Component:2 = 16, 0, //Streak SRM/2

---

Bestia_Infernali:

Yes, game is very linear. "You-can't-lose-the-mission" is lame too.

Anyway, it's possible to improve a lil' how the enemy units act. I've been playing with two things:

a)
An example of code for unit that makes random decisions. You'll never know what decision is made, because it's random*! Ha! Chance of picking particular decision may be something other than fifty-fifty, of course. For example, during one playthrough unit(s) may move to place X. During another playthrough units may move to place Y.

b)
Enemy units are very "static", and very predictable. So... example of code for unit that will move to, and assist other unit during combat. It works like this:

Mission ABL code example in clear words:

if particular group is targeted* then
cancel your current order (like guard, or patrol), and move to unit
if unit you're moving to is dead then
move to unit that is alive from group you're moving to

if you moved to unit from group, and nothing happens then
withdraw, and back to your default order

if group you're moving to is dead, and you're not fighting then
withdraw, and back to your default order

* if killed with one shot this won't work (let's say that had no time to send a radio message).

It works pretty cool: Mech(s) may pop up from nowhere, without waiting for sensor's contact, taking initiative. Depending from terrain (patch finding) it may even occur from your back, or flanks.

What is possible with code above:

- unit can assist multiple groups on the map,
- unit can only assist one group at time (no moving back, and forth between groups) unless withdraw is triggered,
- unit may perform only specified number of "move to, and assist" tasks,
- unit may stick to group it moved to,
- withdraw can be based on various circumstances,
- distance at which unit will run/move to group is random*,
- whole thingy may be random, or based on various circumstances, or mix of both.

I want to make one more thing:

- random timer for how long unit will stick with group, or unit.

Been thinking about not-in-fight, flanking maneuvers, but maps scale is lil' a bit small, and there's a lot tress which would make hard to get "tracking" properly.

* random in MC is kinda ugly: I can specify only range from 0 (start) to end of the range. Such command would be great: random(100, 200), where I could specify my own start of the range, as well as the end.

//////////////////////////////////////////////////////////////////////

I've made a use of very nice macro that is already defined in library* - all-units-on-map pointers for a mission:

ABL scripting library Code:

ObjectList[6] = GetVehicleID(CLAN_FORCE,0,0);
ObjectList[7] = GetVehicleID(CLAN_FORCE,1,0);
ObjectList[8] = GetVehicleID(CLAN_FORCE,1,1);
ObjectList[9] = GetVehicleID(CLAN_FORCE,2,0);
ObjectList[10] = GetVehicleID(CLAN_FORCE,2,1);
ObjectList[11] = GetVehicleID(CLAN_FORCE,2,2);
ObjectList[12] = GetVehicleID(CLAN_FORCE,3,0);
ObjectList[13] = GetVehicleID(CLAN_FORCE,4,0);
ObjectList[14] = GetVehicleID(CLAN_FORCE,4,1);
ObjectList[15] = GetVehicleID(CLAN_FORCE,5,0);
ObjectList[16] = GetVehicleID(CLAN_FORCE,5,1);
ObjectList[17] = GetVehicleID(CLAN_FORCE,5,2);
ObjectList[18] = GetVehicleID(CLAN_FORCE,6,0);
ObjectList[19] = GetVehicleID(CLAN_FORCE,7,0);
ObjectList[20] = GetVehicleID(CLAN_FORCE,7,1);

All is defined in include file for a mission, and I can use each pointer both in unit's, and mission's brain without wasting a time for additional const, variables, inits, and sh*t.

I think, it's possible to make mission failed when player force is dead, and continue the game (no more stupid "reply" button). Some mission's script editing should do the trick. Mission briefing screen will show "Mission Successful", but you don't get any RP for uncompleted mission objectives. It's possible to make successful objectives failed that has been successful before the mission "failure". And that means RP = 0 all the way.

The sh*t thing is:

- you'll get all salvaged mechs,
- you'll get stuff from resource bunkers/etc. (perhaps it would be possible to change side back to Clan in case of "failure"),
- all your destroyed Mechs, and ejected MechWarriors will be available for the next mission.

---

Does it work for you?

uc AlwaysRevealed = 1 // This determines whether or not the terrain stays revealed once it is revealed.

With "AlwaysRevealed = 0" my Mechs are visible, but terrain/enemies not, I can't even select unit when clicking outside of UI. When my Mechs are moving terrain starts to flicker (from time to time), and I see that terrain that once was revealed isn't revealed anymore (is black). This is how it looks like. Is this another not implemented/broken feature or something?

I want to disable default setting because it doesn't make any sense with fog of war. It should be done like this: terrain that once was revealed, but it's now beyond visual range should have kinda fade effect (see border of visual range), but movers shouldn't be visible. It's a fundamental logic/mechanic of FoW.

btw, to make footprints to not disappear do trick like this:

Code:

[CraterSystem]
l NumCraters = 20000
ul CraterShapeSize = 20479
st CraterFile = "feet"

Originally NumCraters = 100. No idea what the max is. It can be done only per mission basis (in mission's FIT).

---

zocom7:

1) The limitation of units in a mission. Although 45 is the limit, was there a way to extend the limit to 100, infinite or so? The modified TedIds.csv that mentioned to increase the number of units of a map in the Mission Editor did not work, but it did change the units and structures organization areas.


2) Some people managed to edit the original mission maps of Mech Commander and its expansion pack. How can this be done? The mission editor cannot load SP maps with mission data unless you make one. I only wanted to increase the number of units on those maps just to give in a challenge while maintaining the same settings. Weren't the mission map files with mission data in Mission.fst or were they in Terrain.fst?

Those question i can answer easily:

(1)
The limitation of units in a mission is obviously technically limited and set to 45 units total in the editor. It is possible to implement more units into a mission, either - by ABL scripting. So it is possible to place 45 units on a map, then load map without mission data and again set 45 units onto the map. After saving the map you just need to copy and paste the additional unit entries in mission files to it's right place and numbering them in clean order. This way you can implement far more than 100 units into ONE map.

(2)
By using extracted game files you can easily mod any existing mission for MechCommander.

---

This thread is for tossing around ideas for a game engine that can be used to create MechCommander style games. However, the "ideal" engine would allow for much more than just MC style gameplay. I have dubbed this engine concept OpenMech.

Since SeanLang asked, I'll kick this off with some of what I've been thinking and others can toss in their thoughts, comments, ideas, etc.

Basically, the core of the engine should be nothing more than something that handles scenes, scripts, user input, networking, saving and loading of games, as well as loading modules.

Modules are the real meat of the game itself. A module is effectively a map or campaign, with all associated files needed for the module within that module. This effectively allows a user to install and play multiple modules and not worry about having one module stomp on another.

This idea of modules isn't really all that much of a stretch from what MCG is doing already. A MCG campaign is already effectively what we want, it is just that the MCG game engine has hard coded filenames and paths to where the campaign resides and do can't easily accomodate new modules.

Another aspect of the OpenMech engine is that it should contain a complete campaign editor. The editor itself would essentially be a special module that the game engine loads.

Okay enough with the high concept, lets delve into more technical details. This will still be at a high level since much needs to be discussed and looked at, but it should be enough to see where we need to go.

Game Engine:
Needs to be responsible for all the hardware interaction. That is, it is the one that sets the graphics mode, actually plays audio, does any networking, handles split screen (if needed/desired), etc.

The game engine needs to be written in something that is cross-platform. C# is a likely candidate here since Unity uses it already and is the graphics engine suggested for this.

For module/AI scripts, I suggest using Lua. Lua was designed for embedding into other applications and has already acquired a large following in the game community (examples being World of Warcraft, Runes of Magic, Lord of the Rings Online). There already exists a few libraries for using Lua with C#, so integration into a C# project shouldn't be too difficult. A note here is that the Lua API presented to game modules should have some restrictions placed on it in order to avoid possible malware embedded inside a game module.

Earlier I mentioned that the game engine is responsible for scenes. A scene is effectively anything that a player sees and interacts with. Be that a menu, start screen, movies, or a game map. All scenes would be defined by configuration and/or Lua files. I envision a bit of a cross between MCG scene definitions and WoW addons. XML support could be a boon for the configuration files here.

For game saves/loads, these should be placed in a saves folder within which subfolders based on the module name are added and a given modules savegame would be placed in. This allows seperation of all saves so that they don't interfere with some other module.

As for the game engine's main menu and editor, these would be special modules that are placed in a special game folder (lets call it system for lack of a better name) that is loaded by the engine automatically. These should be the only had coded paths in the engine.

Finally, the game engine should render everything in 3D, even the menus. It isn't that hard to simulate 2D in a 3D evironment and this will allow us greater flexibility in the long run. As to the discussion of using 2D sprites vs 3D models for the mechs etc. The main argument in favor of 2D sprites is an aestetic one. But this can all be simulated in a 3D environment anyway. Either by actually drawing panels in a 3D world, or by using 3D models and animating them in such a way as to give the appearance of 2D sprites. Either way, it does not detract from using a 3D engine and environment in order to achieve this.

Well that's about all I can think of at the moment. Feel free to question, comment, add ideas or critique.

---

(c) by RizZen 2020