Page 2 of 11 FirstFirst 1234 ... LastLast
Results 11 to 20 of 109

Thread: Decompiler in C# with source for MOHAA

  1. #11

    Default

    Static models don't require too much work :


    struct BSP::File_StaticModel
    {
    char model[128];
    vec3_t origin;
    vec3_t angles;
    float scale;
    int32_t firstVertexData;
    int32_t numVertexData;
    };

    void BSP::LoadStaticModelDefs(const GameLump* GameLump)
    {
    if (!GameLump->Length)
    {
    return;
    }

    if (GameLump->Length % sizeof(File_StaticModel))
    {
    return;
    }

    size_t NumStaticModels = GameLump->Length / sizeof(File_StaticModel);
    if (NumStaticModels > 0)
    {
    staticModels.resize(NumStaticModels);

    const File_StaticModel* In = (File_StaticModel *)GameLump->Buffer;
    StaticModel* Out = staticModels.data();

    for (size_t i = 0; i < NumStaticModels; In++, Out++, i++)
    {
    Out->visCount = 0;
    Out->angles = In->angles;
    Out->origin = In->origin;
    Out->scale = In->scale;
    Out->firstVertexData = In->firstVertexData;
    Out->numVertexData = In->numVertexData;
    Out->modelName = CanonicalModelName(In->model);
    }
    }
    }


    Once you got them, just generate them as if they were entities

  2. #12

    Default

    I got feedback from will:
    Just made a few commits which should solve a few issues:
    m3l2 should decompile now.
    Translucent and sky textures shouldn't be getting replaced anymore.
    Detail brushes should be properly marked now.

    Let me know how things look. I've filed issues in the GitHub repo for the terrain and static models as well, hopefully I can knock those out soon.
    I will send him a mail with your feedback in it.

  3. #13

    Default

    This gave me an excuse to download Visual Studio again so I could look at his work and generate the executable. Not used it since uni...

    So far it's looking much better. Transparent textures are looking good. I can decompile the problematic map now. Detail brushes persist.

    I'll keep looking for bugs!
    Last edited by 1337Smithy; July 16th, 2018 at 01:17 PM.

  4. #14

    Default

    Sounds great.
    From the notes on git there have been quite some improvments based on the feedback from this forum here.

    I think terrain and static models are still a issue.

    Is there a list for the static models or something how do we know which is which or where to read the data from the bsp in the right way ?
    This is what he wrote me back earlier. (Note: I have edited this quote a little )

    I've looked into static models a bit more and... they actually made a new entity class for every static model in the game.
    The model is stored in the BSP but the entity classname is not! So it looks like I'd have to made a list of every model and map them to the proper entity.
    The best way to figure this out is to have a .map created in the editor that has one of every type of static model entity in it, but there's hundreds of them.
    I'm starting to see why the other decompiler doesn't support them...
    Last edited by chrissstrahl; July 16th, 2018 at 04:14 PM. Reason: added ?

  5. #15

  6. #16

    Default

    Quote Originally Posted by chrissstrahl View Post
    Is there a list for the static models or something how do we know which is which or where to read the data from the bsp in the right way ?
    The lump for static models is the 25th, and the struct for for an element is :

    struct
    {
    char model[128];
    vec3_t origin;
    vec3_t angles;
    float scale;
    int32_t firstVertexData;
    int32_t numVertexData;
    };


    Just read it as you do with shaders, brushes, surfaces, etc... Static models aren't entities, they were implemented to avoid filling entities list with static models, and also to optimize rendering.
    You can convert this data into an entity for map files :


    {
    "classname" "quaked_tiki_class"
    "scale" "scale"
    "model" "model"
    "origin" "x y z"
    }

  7. #17

    Default

    Hmm, so static entities won’t make me hit the entity limits in a map?

  8. #18

    Default

    Hmm, so static entities won’t make me hit the entity limits in a map?
    Um, there are two limits, one that is the active entity limit that usually is 1024 but can be changed saftly to 2048 (as far as I can tell)
    and there is the actual overall map source-file entity limit, which should be arround 4096 to my knowlage (Includes also light/static entities).

    Yes, these should not affect the active entity limit in the game.
    How ever, they matter with that map-file source limit of 4096, at some point you can't compile the map (or even load it in the editor anymore).
    Last edited by chrissstrahl; July 17th, 2018 at 08:34 AM. Reason: me do no good spelling :D

  9. #19

    Default

    Ahoy there. So I was pointed to these forums by mister Chris here and thought I'd chime in.

    The issue with static models that I'm having is not that the format is hard to read or anything, it's pretty straightforward. It's that, in the editor, regardless of how they are used in the engine, they are each given unique entity classes. For example, here's two static model entities from the m4l0.map included with MoHTools.
    // entity 1526
    {
    "testanim" "idle"
    "angle" "180"
    "origin" "4944.00 2214.00 536.00"
    "model" "miscobj//hidden_cabinet_b.tik"
    "scale" "1.0"
    "classname" "static_furniture_hidden-cabinet-dark"
    }
    // entity 1527
    {
    "origin" "-780.00 7216.00 176.00"
    "testanim" "idle"
    "model" "static//woodbucket.tik"
    "scale" "1.0"
    "classname" "static_item_woodbucket"
    }
    Their classnames are unique to each model, and there's no way to pull them directly from the BSP file itself.

    Now, it could be that these are irrelevant, and I could stick them all into "static_item_woodbucket" entities and it would be fine. I honestly don't know.

    And regarding another piece of feedback passed on to me from here:
    VIS comes back as a world brush instead of a leafgroup.
    I don't have much experience with mapping for MoHAA so I'm not quite sure how these entities work. But looking at m4l0 again, I'm not sure there's any way I could recreate them. They just come out of the BSP as world brushes. The data for them might be hidden away somewhere in another lump, I don't know. If anyone has any insight on these I'd really appreciate it!

  10. #20

    Default

    Quote Originally Posted by chrissstrahl View Post
    Um, there are two limits, one that is the active entity limit that usually is 1024 but can be changed saftly to 2048 (as far as I can tell)
    and there is the actual overall map source-file entity limit, which should be arround 4096 to my knowlage (Includes also light/static entities).

    Yes, these should not affect the active entity limit in the game.
    How ever, they matter with that map-file source limit of 4096, at some point you can't compile the map (or even load it in the editor anymore).

    Yeah, I guess these are the standard Quake 3 limits? Not sure if it was changed at all with this modified engine, though I seem to remember even Source has similar or same values, at least with brush and face count. I think the first limit is more important (I've always assumed this means those that are rendered inside the player's PVS at any given time) as I find it difficult reaching the overall entity limit. My last map only had half that and it was pretty heavy with static models.

    Quote Originally Posted by MofoMan2000 View Post
    Ahoy there. So I was pointed to these forums by mister Chris here and thought I'd chime in.

    The issue with static models that I'm having is not that the format is hard to read or anything, it's pretty straightforward. It's that, in the editor, regardless of how they are used in the engine, they are each given unique entity classes. For example, here's two static model entities from the m4l0.map included with MoHTools.

    Their classnames are unique to each model, and there's no way to pull them directly from the BSP file itself.

    Now, it could be that these are irrelevant, and I could stick them all into "static_item_woodbucket" entities and it would be fine. I honestly don't know.

    And regarding another piece of feedback passed on to me from here:

    I don't have much experience with mapping for MoHAA so I'm not quite sure how these entities work. But looking at m4l0 again, I'm not sure there's any way I could recreate them. They just come out of the BSP as world brushes. The data for them might be hidden away somewhere in another lump, I don't know. If anyone has any insight on these I'd really appreciate it!
    I never thought the classname was hugely important personally (though it may cause errors in the log if not right). Inside the .tik often a classname isn't even specified, and it simply defaults to the quaked name (though these may be two separate things). E.g. with:


    TIKI
    setup
    {
    scale 0.52 // Set default scale to 16/30.5 since world is in 16 units per foot and model is in cm's
    //scale 1.33 // Convert from inches to game units
    path models/static/barbwire
    skelmodel barbwire_post.skd
    surface bwirepost shader static_bwirepost
    }

    animations
    {
    idle barbwire_post.skc
    }

    /*QUAKED static_obstacle_barbwire-post (0.5 0.0 0.5) (0 0 0) (0 0 0)
    */


    The classname becomes static_obstacle_barbwire-post.

    I assume that is why Ley0k's code is the way it is. Anyway, one of the other guys will need to provide an answer as they have experience in this stuff, and not to mention, they've seen behind the curtain as it were lol.

    Oh, and I wouldn't worry much about the VIS objects. It was just an observation. If it isn't fixable then I wouldn't worry.
    Last edited by 1337Smithy; July 17th, 2018 at 10:12 AM.

Posting Permissions

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