Planet Descent
Development => Descent Development => Topic started by: SaladBadger on February 16, 2012, 04:16:32 PM
-
In the last couple of weeks, I've been working on converting PiggyDump to work with Descent II workshop. And in the process I've ripped out everything that makes PiggyDump run so I can add new code that works with Descent II into there. D2 is a completely different beast, and I need to rethink a lot of it for modding purposes. At a glance, here's what I'm doing
- Splitting the UI. There will be a separate window for editing .PIG files, .HAM files, V-HAM files, .POG files, and .HXM files. Each will be invoked when you open files of a different type.
- Adding support for D2 .PIG, .HAM, V-HAM, .POG, and .HXM
- Rethinking the storage methods. PiggyDump uses fixed size arrays, but this is not feasible for D2 Workshop. I will use dynamic sized lists instead, so you can freely add and remove elements at will (which is important)
- Rethinking the loading/saving methods. PiggyDump has one big class for information: BmData. D2 Workshop will have five classes: HAMFile, VHAMFile, HXMFile, PIGFile, and POGFile.
- PiggyDump loads a .HOG file at start to fetch a palette. D2 Workshop will require you to load a .HOG and .PIG since the graphics are stored separate. I might add a .HAM requirement too, for easy creation of new elements from existing ones
- No anti-cheat code. HAXMEdit doesn't let you edit .HAM files because apparently everyone wanting to edit a .HAM file is a cheater. This is the main reason why I wanted to write this tool in the first place
Currently, I'm focusing on getting the big three important data files loading: .HAM, .HOG, and .PIG. These three are required for everything to work as is. Once editing for .HAMs is in place, I will move to the other formats. That's all I have for the moment. Stay tuned for further updates, hopefully.
-
Oh man the fact that HAXMEdit didn't let you edit .HAM really really pissed me off.
I was really wanting to make custom weapons and stuff when I was younger but I didn't want to/didn't know how to:
-
Yes, I must admit that I was a fair bit disappointed when I realized that while I could open up and peek at the HAM file with HAXMEDIT, I couldn't edit it because I'm apparently a bad person who's only intention is to cheat online. Egh. For a while I did my experiments by manually adjusting the data in the .HAM as it was loaded via a hack to the Rebirth source code. This was messy and hacky though.
Anyways, I've finished up the .HOG and .PIG loaders, both of which were prereqs for doing the HAM editor. You can look at the files in the .HOG or .PIG files, and export them, but you can't edit them yet. You can load all the images in the game though (except for the last image in the .pig due to some weirdness in the data), and other windows can do the same so you can see previews of things like animations when you're editing V/EClips.
The HAM editor will take time. This thing is not exactly easy to implement by any stretch of imagination. Loading and saving it is easy. Updating the representation of it in memory is hard.
And, have a screenshot:
(http://basementnet.us/ryan/d2workshop/piggyedit.png)
-
Well .HAM editing is going a lot faster than I anticipated.
(http://basementnet.us/ryan/d2workshop/hamedit.png)
-
My favorite part of writing any software like this is when you get to the point where you can change a '6' into a '9' in any part of the data file, go view a different element, and then go back to the old one and see that your change has remained. This always makes me happy.
Now I just need to rebuild the HAM into a file on disk.
-
(http://basementnet.us/ryan/doingsomethingwrong.png)
It turns out that the submodel information is actually really important.
(http://basementnet.us/ryan/class1driller.png)
but to be fair this is the coolest class 1 driller I have ever seen.
Yes, I think I have rendering errors.
-
Hey, that hulk looks interesting also. :D
But yeap, submodel info is very, very important.
I don't make any programming, but in my modding experience I suffered a lot with submodel stuff due (precisely) to its importance while rendering (specially on original Vanilla versions of D2 like the DOS or Win95 versions). Thankfully Rebirth and XL are a bit less picky regarding some submodel specs, but still they are very important.
Anyway, now that I got the chance to comment, I must say your project looks more and more promising each day. I'm eagerly awaiting to see it done! :D
-
heh, I had a million faults resulting in what you saw there. in particular I was forgetting about the submodel positions and submodel parents resulting in a lot of ugly glitches. I really hope to make working with subobjects less of a pain when I start trying to make Blender export Descent models. With the availability of the current OpenGL renderers, which can use Z-Buffering, I might simply skip the BSP trees entirely. This will result in overdraw when used in software rendered environments, though :/
Getting Blender to export Descent polymodel data will be a huge chore, since the Descent environment is so different. The polymodel data is in effect, a little program that gets run by an interpreter every time the model gets rendered, and I have to convert the data to this. This will actually be pretty trivial, and thankfully Blender scenes already have a good object system, but things like animations will be a pain to do. In particular, I'm not sure what the best way of representing the robot joints yet. This, I will have to figure out soon.
-
So, erm, would anyone mind if D2W is unable to load HMELs from Descent Manager tools? I was looking at the specs for the format to see if it would be usable for my purposes.
However, I am VERY hesitant to introduce support for a format where the contents are read based on the file extension. This is a horrible way of doing things and I think it's only reflective of the coding quality featured in the Descent Manager tools :/
In any case, I will be using my own formats for exporting data, as well as common formats where it works better (such as images). All of these formats will be fully documented, and I will ship improved documentation with my program. If you want an idea to see what I'll be improving on, please read this (http://descent2.com/ddn/specs/idta/) and ask yourself if you could write a file loader based solely on that. If you say "yes", you're in for some surprises that they didn't think it was important to document. Because apparently the way the chunks are laid out is useless to the end user. :/
If you're wondering what kind of surprises you're in for, look at the first image in my post talking about polymodels. There's complex flow involved in the IDTA data. You can't just read it one chunk at a time. You have to jump around as you read certain chunks. They've failed completely to document this, and as a result I had to look at the Descent source code to see how it interpreted the polymodel data.
-
It would help if I knew what HMELs are exactly.
-
HMELs are HaM ELements. They're basically just dumped data from the .HAM file and relatives made by the Descent Manager tools. The format is simplistic, containing a minimal header saying what ID the element is, the version of the file (always 1), and how many blocks of data are in there.
The problem is, however, is that there isn't a single byte of format data in there. Tools are expected to guess based on the extension. And what if the extension is wrong? How do you recover your data? You don't know what's in there unless you start making educated guesses based on the size of the blocks. But Object bitmaps are just as large as cockpits! How do you tell the difference between the two?
The second problem is that .POL is also a HMEL format. I intend to use .POF (a format Parallax created themselves) for exporting models and working with them in blender or whatnot, but people are probably going to want to import .POLs from the old Descent Manager tools. As a result, I might make it capable of importing .POLs at least, but I doubt I'll be using any of the other formats. Other than .POL, there honestly aren't that many HMEL files floating around, and I don't think it should be a serious issue. Exporting data is still important to me, however, which is why I mentioned that I'm going to be creating new (fully documented) formats.
-
Well, in that case, I personally have no problem with it. :)
-
I remember when I was playing on my really old win98se box I tried to make models with polytron with no regard to what that crazy stuff about BSP Cutting Planes was and I'd get overdraw all over the place. Seemed kinda badly implemented since retail models were far more complex than a lot of the stuff you could try to make while preventing overdraw.
Nobody bothers with that stuff anymore thanks to Z-buffer though I love it when I play the old win95 version or the dos version and see Z-fighting all over all the custom models. :)
What I really wished back then was to somehow be able to have the ability to make complex models without the Z-fighting since that computer had all sorts of problems playing any of the Open-GL driven DXXs. Had to use software rendering - and since I had to do that, I pretty much just went with the vanilla versions. Fun days, those.
Not a problem now of course but it leaves me kinda disappointed, even if there's a lack of need for it. Ah well.
I'm just wanting to make multiple types of macross missile massacres available to the player more than anything else. ;D
-
Hmm, I can look into trying to compute the trees. I've seen hints of the code used to build them in the Descent code, and the basic way they work seems to be pretty trivial. I'll see what I can do. While it is unlikely to be a problem, I think I can add a solution in case it is.
Yes, PolyTron was horrible in how it represented these kinds of things. If it didn't dynamically generate them, I'm not really sure what to say :/
-
I'm currently working on getting the HXM Editor working, as it's a very important part of the editor for me. The modeling stuff is honestly going to give me a hard time, though :/
I have one thing to say, though:
I am very, very sorry for any developer who has had to rely on the descent2.com specs to implement their Descent file readers :/
-
I'm guessing those specs are very flawed/incomplete, then.
-
It's pretty much that. Honestly, I don't understand how tool development happened back then. Anyone implementing a reader for any format based on Descent2.com's specs was bound to run into some trouble. What didn't help either is that source releases were rare back then, so until the Descent source code was released (Jan 12th, 1998 -- three years after release which is pretty impressive actually, however, most Descent II specific tools were developed before the release of D2's source or any source entirely actually), you had to rely on these people and their documentation of the specs. And yet, somehow proper tools did get written. I'm wondering if Parallax put out their own specs at any point, but I can't find anything that hints at this.
-
Been a bit since my last update here, but rest assured progress is still being made. The only big problem so far is the modeling stuff, though, and I am still not certain how everything will work, but I hope to make it all work out in the end.
-
You probably already know this but Blaggert-I-Mean-Blarget wants you to hurry up because Blaggert-I-Mean-Blarget is impatient.
Meanwhile I bask in the glory of discovering how to get around what GXEdit supposedly does to the player ship in multiplayer.
-
Ah, where have I been? Why have I not done any work on this?
Blame college for my absence. And some minor lifestyle changes. I just haven't had the time or motivation for these things lately, sadly. Been busy trying to get good grades in classes, and improving my artistic abilities in particular. I haven't written any code in a while, and honestly after thinking about it I really don't want to write code for Descent .HAM tools as it exists as-is. (I'm sorry for this, but I'm picky)
I'm starting to come to the conclusion that binary files like what Descent uses for storing object info are horrible and really need to be avoided at all costs. A project I want to take up sometime in the future is a modification of DXX-Rebirth which completely kills off the .PIG files (aside from storing graphics and models) and make it revive the old BITMAPS.TBL file, where you can define your new robots and whatnot using text. Modifications will be able to load new files in addition to the main one (rather than having to specify a completely new .HAM file), and there's the possibility of an "extended spec" where you can have new features like D1 bosses in D2 without interfering with any current mission sets.
The work for something like this would be halfway done if I was to take it up, honestly. This is because the Bitmaps.tbl parser is still in DXX-Rebirth and it still works at least somewhat to the best of my knowledge, but it would still take a fair amount of work to get running, including the creation of a new spec for adding new elements and whatnot. A "decompiler" would also be required, to pull apart the current .HAM files to spit out text scripts that could be used to run the game. In the end though, the result is a fully extensible spec -- I could add new properties at will without having to jump through hoops to expose them to modders. This is just a dream though, and I just don't have the motivation right now to do such a major coding project. I'm really lost in the drive to extend my abilities of putting marks onto a canvas of some sort.