Page 3 of 11 FirstFirst 12345 ... LastLast
Results 21 to 30 of 109

Thread: Decompiler in C# with source for MOHAA

  1. #21
    Administrator James's Avatar
    Join Date
    May 2010
    Location
    on the intraweb
    Posts
    3,180

    Default

    I'm not very good at mapping, but this is too familiar when I was working on the very first "anti-wallhack" POC. I would decompile the BSP, then adjust the brush and add the "hint" texture parallel to all walls, and I remember running into the vis limitation of 4096. I think this is because it requires too much server calculations and it would just lag the hell out of the game because it can't compute all the information fast enough.

  2. #22

    Default

    I think the first limit is more important
    Well the active entity limit (1024) is important for the actual game (also upon connecting to a server),
    the overall entity limit in the map-source-file is important, because the bsp, level-editor and the compiler have limits.

    I've always assumed this means those that are rendered inside the player's PVS at any given time
    No, these are the maximum number of all entities that are calculated(updated) within one server frametime (0.05 sec on sv_fps 20)

    The visibility of the entities is managed clientside, the bsp plays a important role in it, as does farplane (scripted fog...)
    In this tutorial this is explained how it relates: https://www.moddb.com/tutorials/bsp-...d-game-engines

    /*QUAKED static_obstacle_barbwire-post (0.5 0.0 0.5) (0 0 0) (0 0 0)*/
    This is for the level editor and not used by the game.
    Everything that is commented out like this is not phrased and will not be used as far as I remember.

    never thought the classname was hugely important personally
    The classname could be important, because some classes might have specific attributes in the game that other classes do not have,
    but I can't tell at this time how it is with mohaa.
    HOW EVER, I can tell you that the right classname in the mapfile could be important for the level editor,
    UNLESS all static model have the same options in the entity menu.

    But my gut-feeling tells me that the classname is irrelevant (as long as it is static as well) if the right model is shown in the level editor
    after the decompile.
    This could be easily tested by altering some classnames in the map-file via text-editor
    and loading it into the map compiling it and decompiling it and once again loading it into a map editor
    Last edited by chrissstrahl; July 17th, 2018 at 03:08 PM.

  3. #23

    Default

    Quote Originally Posted by James View Post
    then adjust the brush and add the "hint" texture parallel to all walls, and I remember running into the vis limitation of 4096
    Ouch, hurts me just to read that, because I know how bad this is for the engine to handle, this is not how it was meant to be used.

    I can recommend you the same tutorial:
    https://www.moddb.com/tutorials/bsp-...d-game-engines

    I attached the tutorial linked above and a different one that was actually more a kind of resarch-log as pdf files

    Ow, here is some more stuff from my old research into the bsp vis stuff.
    (the image might not be fully accurate because I have never tested a map in this exact configuration )
    q3-engine2.gif
    Attached Files Attached Files
    Last edited by chrissstrahl; July 17th, 2018 at 03:23 PM. Reason: added image

  4. #24
    Administrator James's Avatar
    Join Date
    May 2010
    Location
    on the intraweb
    Posts
    3,180

    Default

    You're absolutely right, I was just determined to try and stop wallhacks, and chams; and actually it worked, BUT as you already know there was a BIG limitation. I did a lot of trial and error and noticed during testing that certain areas blocked chams even if someone was just on the other side of you. After decompiling the map and looking through it I noticed it was the hint texture that was applied that made this possible, so I figured why not apply the hint texture to all walls; and that's what I "attempted" to do.

    Razor and I have discussed trying to improve upon the antiwh. Right now our concept works well, but there is the "glitchiness" around corners when users quickly go in and out (are visible and not visible)... It's all about optimizing the algorithms that calculate this; however what we considered is potentially introducing a neural network that learns as you feed it information. Basically the more data it has the better it will know when to render an opponent and when not to.

    Sorry don't mean to steer off subject.

  5. #25

    Default

    Quote Originally Posted by chrissstrahl View Post
    Well the active entity limit (1024) is important for the actual game (also upon connecting to a server),
    the overall entity limit in the map-source-file is important, because the bsp, level-editor and the compiler have limits.
    Of course they are important generally speaking. I meant more important for me, as I'd find it very difficult to reach the upper limit.

    Quote Originally Posted by chrissstrahl View Post
    No, these are the maximum number of all entities that are calculated(updated) within one server frametime
    Yeah, it makes more sense.

    Quote Originally Posted by chrissstrahl View Post
    (0.05 sec on sv_fps 20)
    Indeed.

    Quote Originally Posted by chrissstrahl View Post
    The visibility of the entities is managed clientside, the bsp plays a important role in it, as does farplane (scripted fog...)
    In this tutorial this is explained how it relates: https://www.moddb.com/tutorials/bsp-...d-game-engines
    Indeed, I know all this. I regularly check the tris in my levels by careful placement of structural boundaries, tweaking farplane, and using hint brushes where needed to help the partitions.


    Quote Originally Posted by chrissstrahl View Post
    This is for the level editor and not used by the game.
    Everything that is commented out like this is not phrased and will not be used as far as I remember.
    It corresponds to the classname in the .map file is all I meant.

    e.g.

    Code:
    // entity 101
    {
    "origin" "1812.08 -1521.40 110.37"
    "angle" "270"
    "testanim" "idle"
    "model" "static/barbwire_long_two_post.tik"
    "scale" "0.70"
    "classname" "static_obstacle_barbwire-long-two-post"
    }

    Quote Originally Posted by chrissstrahl View Post
    The classname could be important, because some classes might have specific attributes in the game that other classes do not have,
    but I can't tell at this time how it is with mohaa.
    HOW EVER, I can tell you that the right classname in the mapfile could be important for the level editor,
    UNLESS all static model have the same options in the entity menu.

    But my gut-feeling tells me that the classname is irrelevant if the right model is shown in the level editor
    after the decompile.
    This could be easily tested by altering some classnames in the map-file via text-editor
    and loading it into the map compiling it and decompiling it and once again loading it into a map editor
    Of course the classes are important in general. I was talking specifically about static models. They do indeed have the same options as far as I know. I tried renaming some in my map and compiling earlier and everything stayed the same in-game.

  6. #26

    Default

    Quote Originally Posted by 1337Smithy View Post
    I tried renaming some in my map and compiling earlier and everything stayed the same in-game.
    Excellent, so we can assume that the classname does not matter as long as it is any static classname.

    Quote Originally Posted by 1337Smithy View Post
    I regularly check the tris in my levels by careful placement of structural boundaries, tweaking farplane, and using hint brushes where needed to help the partitions.
    I think we should talk about this some time, I am curious how others do it

  7. #27

    Default

    Quote Originally Posted by 1337Smithy View Post
    I tried renaming some in my map and compiling earlier and everything stayed the same in-game.
    Cool, that sounds promising. I'll want to take a closer look at that to make sure nothing weird is sneaking into compiles with different static model classes, but if it looks good then I'll just take that approach.

  8. #28

    Default

    Yeah, I'd proceed with caution. I'll take a look at some others and see if I can break anything.

    Quote Originally Posted by chrissstrahl View Post
    I think we should talk about this some time, I am curious how others do it
    I was in a bit of a rush last night, but thanks for providing documentation, I'm going to take a look at the stuff you posted out of curiosity. I may quickly draw up a map with the same layout as your diagram. I want to see if several locations will be culled naturally because of the player's location and the automatic partitions, but I suppose that also depends on the scale of the rooms I guess. That's enough derailing from me!
    Last edited by 1337Smithy; July 18th, 2018 at 02:32 AM.

  9. #29

    Default

    the thing is this, the classname in the bsp is used to apply specific attributes like (for example):
    • actor
    • player
    • item
    • effect
    • script-entity
    • static-entity


    Static-models are static-models, so it doesn't matter as long as the tiki is keept.
    It would be bad if it would change to player class.

  10. #30

    Default

    After checking q3map, any entity's classname starting with "static_" will be converted into a static model in the BSP, the only problem is that Radiant won't be able to draw a bounding box with a custom classname, because the size of the bounding box resides in the QUAKED data

Posting Permissions

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