Two Possible Solutions To Info_location....
Reese
Join Date: 2003-05-08 Member: 16143Members
Join Date: 2003-05-08 Member: 16143Members
<div class="IPBDescription">may enable level over level locations</div> I was thinking about different ways that info_location could be coded that would get it to work in level over level environments and I came up with some ways that may do it AND not require ANY entities whatsoever.
The first is using visleafs.
Basically my idea is to have mappers compile a table that links brush numbers to location names. Then when visleafs are made a new NS-only attribute is added to them that would declare them to be a member of brush X. The player's computer (or server for the purposes of showing locations of team members in chat) would then reference that table with the player's current brush number and get a return of their location.
Why Visleafs:
My answer to why visleafs should be used (instead of the current method) is that it A) allows for level over level play with locations and B) uses a technology already provided for in half life to do it. Right now the computer runs two constant checks for player location one to determine your visleaf, the other to determine your info_location status. If it's possibly to utilize the former to determine the latter then why not do it?
Potential problems:
<i>Impossible to implement:</i> I don't know much about the .bsp file structure, or what's available as a resource for a half life mod developer. It could be the case that A) this information is not anything that can be stored in a .bsp or B) Flayra just doesn't have access to this kind of information.
<i>Extended time to make map locations:</i> Basically players would have to individually determine the number of every single brush that would need to bear a location. (including walls and ceilings for skulks) Then use that number to compile the naming table. Any changes to the map would cause changes to the brush numbers, which would mean fixing the table again..... Possibly this idea could be tied in with VHE visgroups for easy use.... but I don't know about it.
<i>Difficult Locationing:</i> Any areas in which run brush runs through two locations would have to be reworked so that the locations are self contained. In addition measures would have to be taken so that any TEXTURE running through two locations that is perfectly aligned does not generate a location splitting visleaf. AFAIK visleafs have no problems cutting textures that run aligned across multiple brushes who all are in one plane. This would cause locationing problems.
<i>Increased r_speeds:</i> The use of additional brushes to create visleaf splits, or hint brushes to do the same will probably increase r_speeds. All of the extra brushes needed to get the job done definitley will, and hint brushes will probably do the same.
*****************************************
My second idea involves restructuring info_location to be a portal. In mapping entity use think of it as a trigger_presence that targets the location name and changes it to whatever name you want. Basically info_location would be turned on it's side. Any doors/vents/etc that lead into a room would have to be locationed and the act of passing through them would cause the change. Phase gates could pick up the location name resident on the player who builds them, and spawn points for all players could get them automatically at map start. Since aliens teleporting back to hive through movement chambers actually come in at spawn points that would solve the problem there... and the phase gate could be modified to act as another location portal for the player. Textures could be used to define an entrance/exit face (think hint and skip) so that one info_location can both enable and clear the location.
Advantages:
<i>Allows for z-axis independant locations:</i> (level over level locations) That is the point of this post after all.
<i>Ease of use:</i> Significantly easier to use than the first idea. Probably both on the computer and the mapper.
Disadvantages:
<i>higher entity count:</i> This would change it from one entity per room to one entity per entrance. Probably a four to fivefold entity count increase... if not more.
******************
I think the best solution would be a combination of the two. Basically use the visleafs at doors/vent openings/etc to determine a location name. This would keep mappers from having to evaluate their entire map on any changes AND keep any entites from being needed for locationing. It still has all the problems that visleaf based locationing does above, although to a smaller degree because it uses so many fewer leafs for the process. I will repost this in the S&I forum as well, but I wanted to get some input here too.... especially from Cagey who probably would end up stuck with the visleaf implementation if that ends up happening.
The first is using visleafs.
Basically my idea is to have mappers compile a table that links brush numbers to location names. Then when visleafs are made a new NS-only attribute is added to them that would declare them to be a member of brush X. The player's computer (or server for the purposes of showing locations of team members in chat) would then reference that table with the player's current brush number and get a return of their location.
Why Visleafs:
My answer to why visleafs should be used (instead of the current method) is that it A) allows for level over level play with locations and B) uses a technology already provided for in half life to do it. Right now the computer runs two constant checks for player location one to determine your visleaf, the other to determine your info_location status. If it's possibly to utilize the former to determine the latter then why not do it?
Potential problems:
<i>Impossible to implement:</i> I don't know much about the .bsp file structure, or what's available as a resource for a half life mod developer. It could be the case that A) this information is not anything that can be stored in a .bsp or B) Flayra just doesn't have access to this kind of information.
<i>Extended time to make map locations:</i> Basically players would have to individually determine the number of every single brush that would need to bear a location. (including walls and ceilings for skulks) Then use that number to compile the naming table. Any changes to the map would cause changes to the brush numbers, which would mean fixing the table again..... Possibly this idea could be tied in with VHE visgroups for easy use.... but I don't know about it.
<i>Difficult Locationing:</i> Any areas in which run brush runs through two locations would have to be reworked so that the locations are self contained. In addition measures would have to be taken so that any TEXTURE running through two locations that is perfectly aligned does not generate a location splitting visleaf. AFAIK visleafs have no problems cutting textures that run aligned across multiple brushes who all are in one plane. This would cause locationing problems.
<i>Increased r_speeds:</i> The use of additional brushes to create visleaf splits, or hint brushes to do the same will probably increase r_speeds. All of the extra brushes needed to get the job done definitley will, and hint brushes will probably do the same.
*****************************************
My second idea involves restructuring info_location to be a portal. In mapping entity use think of it as a trigger_presence that targets the location name and changes it to whatever name you want. Basically info_location would be turned on it's side. Any doors/vents/etc that lead into a room would have to be locationed and the act of passing through them would cause the change. Phase gates could pick up the location name resident on the player who builds them, and spawn points for all players could get them automatically at map start. Since aliens teleporting back to hive through movement chambers actually come in at spawn points that would solve the problem there... and the phase gate could be modified to act as another location portal for the player. Textures could be used to define an entrance/exit face (think hint and skip) so that one info_location can both enable and clear the location.
Advantages:
<i>Allows for z-axis independant locations:</i> (level over level locations) That is the point of this post after all.
<i>Ease of use:</i> Significantly easier to use than the first idea. Probably both on the computer and the mapper.
Disadvantages:
<i>higher entity count:</i> This would change it from one entity per room to one entity per entrance. Probably a four to fivefold entity count increase... if not more.
******************
I think the best solution would be a combination of the two. Basically use the visleafs at doors/vent openings/etc to determine a location name. This would keep mappers from having to evaluate their entire map on any changes AND keep any entites from being needed for locationing. It still has all the problems that visleaf based locationing does above, although to a smaller degree because it uses so many fewer leafs for the process. I will repost this in the S&I forum as well, but I wanted to get some input here too.... especially from Cagey who probably would end up stuck with the visleaf implementation if that ends up happening.