Info_location

iddqdiddqd Join Date: 2002-11-07 Member: 7596Members, Constellation
<div class="IPBDescription">a bit confused.</div> ok, so with info_location it's a brush-based entity.

so, do I make a huge brush and tie it to the entity, or do I make a wall-like thing? because it's going to be a hassle with some of my rooms that arent exactly square.

and: if you do have an area that curves, or has a corner and you need the same brush, do you just clone it and place it next to the other brush?

thanks

Comments

  • ChromeAngelChromeAngel Join Date: 2002-01-24 Member: 14Members, NS1 Playtester, Contributor
    Yes it needs to be a big brush mot just dooway covering as it only shows your location while your in it.

    For irregular rooms it seems you can make your info_location extending outside the room without leaking, so long as the origin is inside. Or you could use multiple info_locations with the same name as you suggested.
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Members
    edited March 2003
    There is much to improve in the info_location entity.
    At first there is the problem, that its used memory (and so the mapfile size) depeds on the sum of the volume of all info_locations.
    Changing the height of all info_locations of ns_eclipde 1.0 from "room height" to "8 units" (and using the NULL texture on them) makes the map 1mb smaller.

    Second there is the problem with large info_locations not giving their name to the hive inside of it.
    But when you make info_locations just 8 units high you will need a small extra info_location for the hive model and not get this problem.

    Third there is the problem that each info_location will fill a cubic volume no matter what volume the brush entity has.
    When you have 2 different rooms with a long diagonal (or whatever not straight) wall between them, you coukd get problems with overlaying info_locations.
    Info_locations do not know boolean operations.

    When you get "alloc block Full" the reason can be a too high volume of too many info_locations.
    cover each info_location with the "NULL" texture to make the map file size and R_speeds smaller , and compiling faster.
  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    hadn't thought of the NULL, Ollj - a great tip if there are no problems!
  • KungFuSquirrelKungFuSquirrel Basher of Muttons Join Date: 2002-01-26 Member: 103Members, NS1 Playtester, Contributor
    edited March 2003
    Bah, read the post where I referred to Merkaba referencing that idea my way. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->

    Now that I'm back in Lincoln for the last part of the semester, I'll be writing up a guide on the changes to info_locations in effect for 1.1 - Just want to get all the information in one place rather than scattered around various forum posts as it is now.

    Also, I do believe you can clip/vertex manip boundaries of info_locations as necessary if you have any problems with possible overlap problems. I'm not aware of any restrictions to rectangular brushes, though I've not had the occasion to use any non-rectangular brushes thus far.
Sign In or Register to comment.