The reason I gave it that name is because it's frighteningly similar in many ways to an assembler/disassembler - all it does is convert stuff to and from the raw data into a (slightly) more human-readable, and editable, format.
Don't get me wrong, you'll still need to know a LOT about the IDTA specs to use this thing at all... but it's better than a hex-editor, and doesn't restrict you as much as HAXMEDIT/DOS did. Thus, if you have any odd really nagging problems with polymodels that you can't seem to fix, it might help you.
Theoretically... theoretically you could design robots with it, but it's very much a bad idea. Yes, it's about as powerful as you can get, but there are a few things in there I simply couldn't figure out and left them in a usable, but not very useful, form; for instance you'll still need to figure out by yourself what the offsets listed under SUBCALL should be, since I'm not completely sure how they are supposed to be calculated, and thus didn't implement that stuff myself...
Ideally, when I get a bit more time and figure more of the workings out, I'd like to remove as much of the redundant data as practical so that it's fairly easy to modify stuff to a significant degree without having to scratch your head over what those pointers are doing. But at the moment, except for the pointers and file size figures in the header of the polymodel, all of the block data is in there, so you have to be very careful how you tread.
Talking about the pointers in the polymodel header, I'm also not convinced they work perfectly but they seem to so far. The reason is that I made consecutive submodel offsets point to consecutive D_DEFP_START blocks, which I'm not positive is necessary in D2 polymodels. If I find a counterexample I'll try to get it sorted out.
But yes, early days yet - but you may find it useful for something. Excuse the lack of any documentation, but since the field names are just abbreviations for the sake of tidiness, they're not too hard to figure out.
Download