Page 10 of 11 FirstFirst ... 891011 LastLast
Results 91 to 100 of 109

Thread: Decompiler in C# with source for MOHAA

  1. #91

    Default

    Quote Originally Posted by chrissstrahl View Post
    Know that your work is appreciated
    It's not a joke or sarcastic or anything, either, I really do enjoy writing code.

    I added some stuff, mostly just for reading more of the CoD BSP. The only new feature is patches are supported now but for the moment their UVs are completely broken because they changed it so patches reference their own set of vertices that don't have them. So I'll need to find a way to match patch vertices with the regular ones and pull UVs that way.

    Terrain isn't supported yet, but they are implemented as a different type of patch. The way they're stored I can't easily get their dimensions, so I'm going to have to be a bit clever with how I figure that out. And then there's the same problem with the UVs.

    So there's still a lot to do, and they sure didn't make it easy for me.

  2. #92

    Default

    In my private library I have made for reading MOHAA content, I have fully implemented LOD Terrain support as patches, do you want the code?

  3. #93

    Default

    Hm, I don't know why it never occurred to me to try doing that. But now that the idea is in my head, I guess it should have. I see how it could be done, but not just with MOHAA terrains but the other ones too. I'll have to think on this for a bit since at this point I'm dealing with three or four engines' worth of different terrain formats.

  4. #94

    Default

    But you are not removing support for the terrain you already support in each game, right ?

  5. #95

    Default

    Oh, definitely not, my dude. I'll only do these kinds of conversions based on the limitations of the target editor. For example, MoHAA terrains are extremely limited in size and shape (from what I can tell, they must be 512x512) but you get around this by stitching multiple terrains together, and I'm pretty sure you can remove specific vertices individually (like the trenches in the Omaha Beach maps). EF2 terrains are less limited so MoHAA terrains can be converted, but not the other way around unless very specific conditions are met. That would probably be a better time to convert it to a patch so at least it's not completely lost. GTK Radiant has no terrain support, so that would probably be another good time to convert it.

    On a related note, I'll probably be separating Uberradiant output from GTK Radiant, since terrainDefs just completely crash GTK. So... yeah, there's that. I obviously did a lot of testing of that feature.

  6. #96

    Default

    I am glad to hear this.
    EF2 terrain does not work with dynamic lights, but it has a excellent collision and it can not be penetrated from the back-site like patches can.
    EF2 terrain has also be used to make caves (m11l1....), it can be smoothed so that it will be more acceptable for the ai.

  7. #97

    Default

    Quote Originally Posted by MofoMan2000 View Post
    MoHAA terrains are extremely limited in size and shape (from what I can tell, they must be 512x512) but you get around this by stitching multiple terrains together, and I'm pretty sure you can remove specific vertices individually (like the trenches in the Omaha Beach maps).
    Yeah, MOHAA terrain is pretty horrible when you compare it to other games (especially CoD with their arbitrary patches). Each segment does have to be 512 x 512, but they automatically snap to one another. You can hide and delete triangles (they still form part of the patch but just don't render in-game), as well as change LOD tolerance. I'd use only patches all day every day if they had as good collision and tools. I must admit terrain is a big time saver in that respect.

  8. #98

    Default

    Also, with CoD, you have to consider alpha blending which they introduced in the first, which may be a pain to decompile intact?

  9. #99

    Default

    I would really wish it would save my settings, I have to set the output format each time I start the program.
    Needless to say that I forget it each time and load a incompatible map-file into Überradiant, and that Radiant is not thankful about that.

  10. #100

    Default

    Sorry for being so quiet, working full-time really takes a lot out of you.

    I recently made a lot of changes to LibBSP, mostly to make the code a bit cleaner. There's probably a few things I forgot to do but it was already a large amount of changes. I've also just committed the adjustments to the decompiler to work with the new LibBSP, and from my testing the functionality still seems to all be there. I'd appreciate whatever testing you guys could do, I did some testing but it's already 1AM on a work night! I do have some things I want to do with this library so I'm going to be very glad I did this refactor, I think.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •