How has BTS made life easier for modders and benefactors?

[Canuck]

I'm not sure if BTS realized the modding potential of CM when they first introduced the game but I'm sure they're well aware of it now

How have things changed to make modding easier and to increase the scope of modding.

For instance, all different armies from within the same country (ie Heer & SS) can have their own helmet BMP right?

How else has the modding potential been expanded?

[busboy]

Speaking from a Mac perspecive, the mod potential has increased almost expodentially.

In CMBO, Mac were limited to 15 graphics files of the "ResEdit" type that could be no larger than aprox. 15 megs in size.

To install mods the easy way, a Mod program would take the BMPs and automatically replace pictures for new pictures. This worked well...unless you started getting lots of high resolution Mods.

Then, files would start filling up. Once "Graphics file 1" was full up to its 15 megs, no more could be squeezed on. So, if you wanted to add more Mods of stuff that was in "Graphics file 1," you would have to squeeze in the BMPs into other graphic files. To do this, you would have to copy/paste individual BMPs into the files manually with ResEdit, being careful to delete old pics, ect.

Before you knew it, you had a labyranth of BMPs in your graphics files, and one mistake or missing BMP might cause CM to crash.

Now the Mac BMP archives work just like the PC, and all is good in Mac land!

[Battlefront.com]

We gave Modding careful consideration when making CMBB, but will do even more for the rewrite. The three basic things we were able to do for CMBB:

1. Made the Mac use the same exact BMP and WAV files that the PC uses. As explained above, this makes things A LOT easier for Mac users.

2. Made the texture numbers much more logical. With only a rare exception or two, each vehicle/gun is assigned 20 "slots" used or not. No more scattered BMP numbers scattered all over the place.

3. For the most part, each vehicle/gun has its own unique texture set. This means you can have totally unique textures for each of the PzIVs for example, instead of having to suffer through mix and match instances like often happened in CMBO. CMBO was like that in order to conserve on VRAM (remember, we supported 4MB cards when we started making the game!!).

There were a lot of things we wanted to do but would have required too much recoding. So we are going to incorporate that stuff in the engine rewrite. Things should be much more modularized and easy to mod than CMBB.

Steve

[Guest Panzer Boxb]

Originally posted by Battlefront.com:

We gave Modding careful consideration when making CMBB, but will do even more for the rewrite. The three basic things we were able to do for CMBB:

1. Made the Mac use the same exact BMP and WAV files that the PC uses. As explained above, this makes things A LOT easier for Mac users.

2. Made the texture numbers much more logical. With only a rare exception or two, each vehicle/gun is assigned 20 "slots" used or not. No more scattered BMP numbers scattered all over the place.

3. For the most part, each vehicle/gun has its own unique texture set. This means you can have totally unique textures for each of the PzIVs for example, instead of having to suffer through mix and match instances like often happened in CMBO. CMBO was like that in order to conserve on VRAM (remember, we supported 4MB cards when we started making the game!!).

There were a lot of things we wanted to do but would have required too much recoding. So we are going to incorporate that stuff in the engine rewrite. Things should be much more modularized and easy to mod than CMBB.

Steve

Have we mentioned how much you guys rock lately? No? Well, consider yourselves notified.

[Canuck]

Can you give us a hint about what you would like to include in the engine rewrite?

The ability to give the same set of units a little variation perhaps? So instead of having 5 of the exact same kind of Shermans in a battle they could all have their little quirks to distinguish them. I think that would be great

[Battlefront.com]

Canuck, we have no real plan yet but I can tell you that we do want to figure out a way of there being some distingusishing marks on exactly the same vehicles. The problem is we have to be smart about it because VRAM gets gobbled up real quick if we had unique sets. In CMBB we have pushed things as far as we dare to with unique sets per vehicle type. That means a platoon of mixed tanks might give you 2 unique texture sets, but what you are asking about could result in 5 or so. Big difference to the hardware

Steve

[Pvt. Ryan]

We will have 1 GB videocards by the time CM3 comes out, so go nuts!

[JonS]

Just thinking out loud...

Would it be possible to define part of a surface as a seperate bmp? For example, say the large flat sides of the Panther turret are 1101.bmp

Then there, within that bmp is an overlay that covers the area typically covered by the vehicle number, giving

1102.bmp (left side number area)

1103.bmp (right side number area)

These could be optional transparencies, so if a player didn't care about them, they wouldn't have to use them.

A further wrinkle would be to have several sets of left and right transprancies, eg

1102.bmp (left side number area, set 1)

1103.bmp (right side number area, set 1)

1104.bmp (left side number area, set 2)

1105.bmp (right side number area, set 2)

1106.bmp (left side number area, set 3)

1107.bmp (right side number area, set 3)

1108.bmp (left side number area, set 4)

1109.bmp (right side number area, set 4)

Then the game engine randomly chooses which set to use in conjunction with 1101.bmp (rather like the way I think different buildings are done ... unless I'm way off there?). Alternately, the player could specify which sets to use. Maybe.

That way all vehicles would use the same set of base bmps (ie, have exactly the same basic paint job / camoflage scheme), but with unique bits coming through in terms of tactical markings. It seems to me that this would:

a) allow some uniqueness within otherwise homogenous fleets

minimise the amount of duplication in terms of bmps held in memory.

But then, I'm not a programmer ...

Be cool

JonS

[Foxbat]

To add to what Jon said (which sounds like the ultimate achievable solution*) to save precious VRAM the following things could be implemented:

The overlay BMP's are added on top of the cvehicle and the user can choose between off (no overlays shown at all), default (shows the default overlay BMP for each vehicle type), full overlays picked per vehicle.

And all vehicles that are in the same command structure (same platoon or company) get the same overlay. That would give a lot of variation still while still limiting the number of different bmp's that have to be displayed. Also has interesting tactical "applications" in that your enemy could try to find out which AFV's belong to the same unit

* The only thing better would be IL-2 style vector overlays, that actually calculate the correct and unique vehicle number for each vehicle and display it in the proper style for that vehicle in that period...

But that is of course totally unrealistic at the combat mission scale of things

[mchlstrt]

GEM has something like this going on w/ the new CMMOS, where it can add just the kreuz or # or whatever to the base image & generate a new .BMP. Don't know that this has any direct application to what you guys are discussing, but it's Way Cool, Man, & will definately help w/ file storage & download size issues.

Strt

[Battlefront.com]

Yes, something along the lines of Jon's thinking is what we were looking into. Having a unique turret side texture, for example, doesn't add too much to the VRAM load. Currently CM's engine can't handle overlays as such, but I am sure the new engine will be able to do this because it will be 32 bit. And by the way... going to 32 bit vs. CM's current 16 bit means a HUGE increase in VRAM use without adding a darned thing

Steve

[Pascal DI FOLCO]

Originally posted by Battlefront.com:

Yes, something along the lines of Jon's thinking is what we were looking into. Having a unique turret side texture, for example, doesn't add too much to the VRAM load. Currently CM's engine can't handle overlays as such, but I am sure the new engine will be able to do this because it will be 32 bit. And by the way... going to 32 bit vs. CM's current 16 bit means a HUGE increase in VRAM use without adding a darned thing

Steve

So why bother with 32 bits in the first place ? Additionaly perhaps you don't really have to manage "overlays", and can achieve the same results by just "splitting" the BMPs areas in 2 (or more) : one for the "standard" turret texture and another for the specific marking for example...

Would this work ?