DescentBB

As per the title. Is it possible to insert a HAM file into a mission archive so that the game reads it in precedence over the regular HAM file? If it's possible, is it only for Rebirth, or also for vanilla?

Also, for Rebirth only, if you make a DXA addon file with the same name as the mission's name, will the same functionality be achieved?

Not familiar with DXA, but loading HAM files from the mission HOG is a Rebirth-only feature, yeah. Except for Vertigo-format HAMs, which only replace the Vertigo stuff.

Sirius wrote:Not familiar with DXA, but loading HAM files from the mission HOG is a Rebirth-only feature, yeah. Except for Vertigo-format HAMs, which only replace the Vertigo stuff.

So the only way to play a mission with replaced HAM assets in DOS is to use a HXM file or to replace the game's native HAM, I take it?

Correct. Yes, you are pretty limited. Well, kind of - the most common thing you'd actually want to change but can't is the weapons.

Sirius wrote:Correct. Yes, you are pretty limited. Well, kind of - the most common thing you'd actually want to change but can't is the weapons.

Exactly, HXMs only let you change robots. Well, DXA would be an acceptable option for Rebirth, but I'm not sure if Rebirth can recognize that a DXA is only supposed to be used with a single mission if their names are identical. But no harm done, you said Rebirth could accept HAM files inside HOG missions anyway.

If you're not familiar with DXAs - that's just what you rename regular ZIP archives to, so that Rebirth can make use of extra assets, such as hi-res textures etc. I think the abbreviation develops into "descent x addon".

I've always gotten around the DXA problem with a simple batch file: where mission.dxa/zip is the filename.

LightWolf wrote:I've always gotten around the DXA problem with a simple batch file:

Code: Select all

if exist mission.dxa ren mission.dxa mission.zip else ren mission.zip mission.dxa

where mission.dxa/zip is the filename.

What does the order of putting them in change? In both cases you have both zip and dxa :O

BTW, I tried running The Enemy Within in DOSBox D2. The mission obviously makes use of drastically altered assets, and yet vanilla was able to run it no problem. I did get a hang-up after finishing the first level - black screen and nothing else - but the game did render the new robots and cockpit just fine. Is this all HXMs? I thought the cockpit can only be changed by altering the base HAM. That leads me to believe that TEW does indeed have a HAM in it, and Descent 2 was able to read it. Of course going black after exiting every mine doesn't mean it's playable but well, it's a start

The cockpit is actually a graphic asset. You'll find it in the POGs.

You can do the batch in either order - just make sure the order is opposite on one side of the "else" than the other.

You will also want to make sure you don't say "if the DXA exists turn the ZIP into a DXA" or else it won't do anything.

Right, it's all HXMs and POGs. POGs can replace practically anything you want - they just can't add textures. TEW is supposed to be able to run in DOS, and mostly does, but there are some glitches we never really figured out.

Ok, so vanilla Descent can indeed read V-HAMS embedded in the HOG. Haven't tried with a regular Descent2.HAM, but I'll take your word and assume it doesn't work. Still, for D1,5, we'll need both a d2x.HAM and a replacement descent2.HAM, both at the same time. How to go about doing this?

Vanilla: Embed the d2x.HAM in the HOG, replace descent2.HAM entirely
Rebirth: Embed the d2h.HAM in the HOG, create a DXA with the altered descent2.HAM?

I... think so. It's been a while. Though I don't think you call the V-HAM "d2x", just missionname.ham.

Sirius wrote:I... think so. It's been a while. Though I don't think you call the V-HAM "d2x", just missionname.ham.

Yeah, that one I know

The DXA works - it's how the Rebirth version of my mod works

@Sirius What glitches?

The main one I recall is that a few of the robots seem to be prone to graphical artifacts, specifically that it looks like one of the vertices jumps way off into space at certain angles. My guess was that there were problems with the normals, but attempting to recalculate and fix them didn't seem to have any effect, so either the fix was wrong or the problem was something else.

Do you mean that it winds up 326(ish) standard cubes away or it renders in the wrong order? If the latter, BSP crap is your answer. If the former... I dunno.

I don't know the distance - it just looks like random spikes - but it's more like the former.