I'm writing Yet Another HAM Editor For Descent II. aaa
I've gotten support for subcall32 working in the importer and my model previewer, I'll get the patch tested tomorrow. My exporter currently automatically measures data size and generates which instruction is needed, in case backwards compatibility is needed.
okay, I'm sorry, I didn't get the subcall32 patch tested today, oops. I got a little too distracted on editor programming and I was doing stuff with folk tonight.

So the skinny on this whole thing: I'm dropping HXM and probably V-HAM support in the editor. After ages of trying to get all my systems for managing things working with them, I ran into a nightmare of managing ids. In particular, HXM files that used V-HAM elements crashed. I can potentially try to enable bringing in a V-HAM to also add to the list of available items, but this whole thing is just driving me insane. I'm finding myself in two camps here, I don't want to support HXM files because I can't easily make them work with my fancy features, and in practice with D2X-Rebirth supporting HAM files there's not much reason to make HXMs, but on the other hand, HXM files are the only way to edit robots in Descent 1 and it bugs me knowing that I can't make my editor do something that HAXMEDIT could do two decades ago. Of course, HAXMEDIT didn't do the things I do with models and the like, so I dunno.

I guess I'll give a brief description of why I'm having trouble with this. When you load a HAM file in my editor, after loading the file into memory I go through every every model and build a texture list for it. Internally my editor doesn't use ObjBitmaps and ObjBitmapPointers beyond that, to make replacing models very easy. In addition, beyond that I also remove all the guns from robots, reactors, and the ship and tie them to the model too, and also remove the animation data from robots and tie that to the model. When you save out the file, based on what models are assigned to what, I regenerate the gun information, I regenerate all the robot joints, and then regenerate all the ObjBitmaps and ObjBitmapPointers. This can mostly be ported to HXM files, but problems occur if a HXM file references Vertigo information. This poses a problem, since I don't have any models to regenerate all that information from.

A simple solution might be just to regress to the HAXMEDIT way of doing it, not caring about joints and guns at all except maybe at model import time, but I really don't like this solution that much. Managing joints and object bitmaps really sucks hard, so I dunno. These reasons are why my previous Descent2Tool had really lacklustre HXM support. All I ultimately wanted to do was make generating new HAM information easier, which can go against working with HXMs.

V-HAM files, I guess I can still support. All my systems work perfectly with them, since they can only append elements, not replace them, and I don't have to worry about inaccessible other information.

EDIT: I just had an idea for what to do with Descent 1, I will potentially make a tool that's dedicated solely to making HXM files for Descent 1. Given that Descent 1 has a much different set of ObjBitmaps and ObjBitmapPointers, in practice this should be a more sane option.
I pushed a change to truncate the model on invalid opcodes. This lets suzanne load, but makes it invisible since the very first operation is an invalid opcode. I also print a diagnostic to the console when a truncation happens.
Alright, that's a good solution. I've been a bit more busy lately so I haven't gotten a chance to test the patch as I've wanted, but I was able to quickly form up an example mission (just an edit of the previous one with the faulty model replaced):


Here's what the model should look, from my polymodel previewer:
[Image: v85N07W.png]
well, I didn't think I'd ever see this moment in my lifetime, but as of right now, the HAM editor is officially complete. It can now through some means edit every last bit of editable data within the file. Inserting and removing new datablocks is possible where relevant, though at the moment you can only add and delete the last element of a data type (so you can't go delete robot 32 or something). This is to avoid having to manage all the references, so if you delete robot 32 I'd have to go to the Spider robot and decrement its drop type by 1 so that it still drops Spawn as intended. Something also can't be deleted if it has any references whatsoever to it.

In practice, I'm intending to add "hardcoded" references so I can tell the game that weapon #9 is supposed to be the concussion missile, weapon #32 is the gauss bullet, and so on. In the offchance an engine allows changing this kind of thing descent 3-style, there will probably be a way to disable the hardcoded references in the options. I'm also still yet to add warnings if you go over the static limits imposed.
Alright, it's time for the weekly Linux compatibility check.

[Image: riz6415.png]

well uh, it's better than crashing, at least!

Some other notes from recent development:
  • The way a model's radius is calculated has been changed, I was basing it on the model's AABB (which bounds the model) but Descent itself appears to have measured the furthest point from the origin. There was a bug in parallax's own tools where it didn't consider the entire chain of chains of subobjects, so bounding boxes aren't 100% right. Since it makes the code simpler, I'm emulating this bug. The old algorithm used to overestimate a lot, now models should be given the same overall size as their vanilla counterparts, and the radius better bounds the model... when possible.
  • There's more error checking in the model exporter now. I don't give a clear warning yet if something goes wrong (everything's stuffed away in the console window right now...), but all the common script errors I was running into while making models have been handled.
  • I've added tooltips to the UI. there's a lot of fields that don't really have descriptive names, so I give the precise effect of a given number where possible. I also note what fields that parallax ended up abandoning but never removed from the data format.
  • I just fixed up that polymodel previewer problem on linux, it's now positioned right. This should now run on all major desktop operating systems, though as always you'll need a .NET framework (mono is tested on Linux and should work on macos). 
  • Elements in big lists (mostly robots and weapons) have been regrouped to fit better. So weapons now have a "Visuals" block, a "firing information" block, and so on.
  • Elements can be named. Names are going to be saved into another file when you save out the HAM file.
I mentioned before I was having problems with GLOW instructions on player models, it turns out I found the culprit comparing my model's IDTA to the original ship. The original ship sticks the glow faces at the very end of the object's IDTA data, and my hunch is that if a face isn't rendered due to the camera being on the other side of its plane, the glow instruction instead applies to the next instruction. I've modified the exporter to save faces tagged with GLOW for the very end.

I'm still trying to investigate why the quad lasers aren't firing right.
For collision purposes, Descent considers most objects to be spheres. This simplifies the logic, but causes plenty of weird looking results. I've always meant to fix this, but never started on a prototype.
(03-11-2019, 07:16 AM)InsanityBringer Wrote: The original ship sticks the glow faces at the very end of the object's IDTA data, and my hunch is that if a face isn't rendered due to the camera being on the other side of its plane, the glow instruction instead applies to the next instruction. I've modified the exporter to save faces tagged with GLOW for the very end.

Correct. As I read the code, there are exactly two places where glow_num can change. First, it is written by the model with OP_GLOW. Second, it is reset to -1 when op_tmappoly renders a polygon with a glow effect. (If there is no glow effect for that polygon, glow_num is not reset.) This is essentially unchanged from past releases, although my rewrite did add a sanity check that prevents using out-of-range glow values.

Useless uses of OP_GLOW are permitted, so you could also fix the problem by explicitly clearing the glow after the conditionally rendered face.

I think I saw the quad laser fire all four shots, but it looked like two were almost on top of each other. I didn't look into why that would happen.
If useless uses are permitted, I will probably modify the exporter to add a -1 GLOW at the end of the glow faces block, since I don't know how this interacts with submodels at the moment (not that there's much use for submodels in a ship model...), so I'd rather be safe than sorry.

Anyways, with the HAM editor portion pretty much completed (I'm tweaking the reference counting code to not suck so much, but that's almost finished), I'm evaluating where to go next. the HOG editor is probably going to be high priority since it's a sort of vital thing to do, but it's also pretty mundane. As mentioned before, I've had some desires to write a new editor, and I was investigating the level format from the game's source code. One thing I quickly realized is that the map format is a lot more flexible than what most editors allow, and this goes beyond just my basic discovery of OBJ_CLUTTER types, I've noticed pretty much every parameter of any object can be tweaked. How much value tweaking anything is up in the air, and some object types, especially robots, spend a lot of time validating their parameters so you can't mess with them too much. But on the other hand, clutter types and powerup types are basically completely free to imprint on. So, I wrote some code to open and export levels. I have a level editor working now, if you consider breaking into a debugger and letting you directly manipulate the data structures an editor, but it's allowed me to test if any of my theories will work.


It's a neat effect. Does it warrant a new editor? I dunno, they don't work on dropped items since those revert to the sprite defined in the HAM file, but it gives a cool look to the preplaced ones and you could even do further things like make them part of the environment (a bunch of missiles laying on the floor? I dunno). Will it revolutionize mapping? Probably not. But I like cool effects, and the fact that literally everything I'm doing here is vanilla compatible is a really nice feeling. This engine is more flexible than I've always assumed.

Other things I discovered is that CLUTTER types can drop items like robots. Descent 3 had a lot of crates and crap you could shoot up and rustle up a stray energy item or two. You could do something comparable. I imagine a mapset with like energy containment units you could shoot for energy, missile crates you could shoot for a few missiles, or perhaps even more nastily, a cool little "robot factory" setpiece that if you break it throws a live robot at you!

edit: Oh, I guess I should talk about the rewrite of the reference counting system. Basically, it's there to enable deleting of arbitrary elements. As I add more and more specialized models in my tests, I find that more and more I need to start removing unneeded models to free up space for my new models. (actually, I really don't, the polymodel static limit is 200 models and the game uses 166 by default, that leaves plenty, but better safe than sorry) so I do things like remove the redundant weapon polymodels, but it's hard to do that when you can't delete arbitrary models, so this new system makes that easier to implement.
it's been a bit quiet here

[Image: 9iBPnzc.png]

it turns out writing a level editor is a bit more involved than expected. heh

I'll probably focus back on the HAM editing side of things for a little bit in the coming days to fix up any remaining bugs, work on HOG editing stuff some (I'd like to be able to let you edit a HAM file that's already embedded in a HOG), and push out a testing release that probably won't have any of the level editor stuff exposed for now.

Forum Jump:

Users browsing this thread: 3 Guest(s)