A Few Technical Questions And Suggestion...
Reese
Join Date: 2003-05-08 Member: 16143Members
Join Date: 2003-05-08 Member: 16143Members
<div class="IPBDescription">Ideas for the co_ map info_location prob</div> Ok, I know there's a "question and idea forum" that handles this, but most of these are mapping related anyways so i'd like to know what you guys think.
1) fullbright texlights: I am curious if this is a half life engine thing or a compiler assigns them this light value thing. In other words is it something XP-Cagey may be able to fix in "the great compile tool rewrite" ™.
2) info_location: Is it possible to alter this for level over level editing. Possibly with the following changes.
A) Renaming the keyvalues to [1]Location Name, [2]Location name, etc etc and using the floors and ceilings to determine the bounds.
B) Doing the same as above but putting in a [1]zbounds keyvalue that tells ns the exact z coordinates of the location.
C) Not turning the location name keyvalue into an array, but giving it the z bounds keyvalue so that multiple info_locations could be used to outline names for level over level design.
I think the third option might actually be the best in that regular ns maps could be incorporated into it with no changes whatsoever as long as the z bounds were an optional thing. The only problems I see with the second idea are that it takes time to code it and it only really works for level over level when the profile of the rooms in z-space is rectangular. A set of stairs, for instance, would still be bounded by rectangular info_locations, which would make it difficult if you were trying to identify them by the door they let out to.
*edit general speeling adn whatnto*
1) fullbright texlights: I am curious if this is a half life engine thing or a compiler assigns them this light value thing. In other words is it something XP-Cagey may be able to fix in "the great compile tool rewrite" ™.
2) info_location: Is it possible to alter this for level over level editing. Possibly with the following changes.
A) Renaming the keyvalues to [1]Location Name, [2]Location name, etc etc and using the floors and ceilings to determine the bounds.
B) Doing the same as above but putting in a [1]zbounds keyvalue that tells ns the exact z coordinates of the location.
C) Not turning the location name keyvalue into an array, but giving it the z bounds keyvalue so that multiple info_locations could be used to outline names for level over level design.
I think the third option might actually be the best in that regular ns maps could be incorporated into it with no changes whatsoever as long as the z bounds were an optional thing. The only problems I see with the second idea are that it takes time to code it and it only really works for level over level when the profile of the rooms in z-space is rectangular. A set of stairs, for instance, would still be bounded by rectangular info_locations, which would make it difficult if you were trying to identify them by the door they let out to.
*edit general speeling adn whatnto*
Comments
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Its a compiler thing. I know theres a project going on but i don't know where its at. You can always ask kungfusquirrel (eclipse , veil) as he is at the head (i think) of the project. Up to now its only been released to ns and nightwatch official mappers.
For locations, at first there was a z value but it was taken out as there was no use for it (no level over level). this was done for server performance. bu8t its true that now with co_ maps it might have a new utility...
I think I get it, but, umm, yeah, not really. Help.
bob: Yeah, I figured that there was some kind of project going on. It always seemed like a compiler thing to me, was just wondering if anyone was going to be able to fix it.
btw if anyone comes up with any other info_location fixes that they think will work then by all means spit it out.
in version 1 info_locations only showed their locations when you were actually inside them.
ie: the top of the info_location brush was teh top of the location and the bottom of the brush was the bottom of the location.
Of cpurse this caused some huge brush entitites, which was a problem with big NS maps, might not be such a problem with smaller co_ maps.