Location Relevancy; get around max-relevancy distance by location based relevancy
matso
Master of Patches Join Date: 2002-11-05 Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
Master of Patches Join Date: 2002-11-05 Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
Short summary:
You can use multiple location entities to build up a manual relevancy tree, freeing the mapper from any restrictions on distance.
Even if you don't modify the map, entities in the same Location as the player will always be visible to him.
Use with care.
Documentation:
// =======
//
// lua\LocationRelevancy.lua
//
// Created by: Mats Olsson (mats.olsson@matsotech.se)
//
// Adds the ability to make entities relevant by location.
//
// Background:
// For performance and bandwidth reasons, updates for entities in NS2 are only sent
// from the server to the client if the entity is "relevant".
//
// Relevancy is mainly calculated using distance (40m normally). Maps are usually carefully
// constructed to avoid longer sight ranges than this, though you can sometimes notice them
// (in Summit/Crevice, you will notice that if you go all the way west, everything around the
// resource node disappears and then blinks into existence when you get close enough).
//
// Some custom maps (Skyfall, Goliath) are built around very large locations where this
// problem is glaringly obvious.
//
// How it works:
//
// This mod uses a feature of the spark engine to make entities relevant depending on location.
//
// It adds the concept of a relevancyGroup and lets a location be part of one or more
// relevancyGroups. Whenever a player enters a location, everything in all locations that
// share at least one relevancyGroup with a players current location becomes relevant to
// the player (a relevancyGroup is just a name, bw, nothing fancy about it).
//
// By default, each location creates a relevancyGroup with the locations name, meaning that
// when a players enters a named location, all entities in locations with the same name becomes
// relevant to him. This is done automatically, and applies to all maps.
//
// For advanced uses, where the mapper want more control over relevancy, a new field has been added
// to the location entity in the Editor, location.relevancyGroups. This field may contain a
// comma-separated list of relevancyGroup names to which the location will belong.
//
// If a '-' is part of the list of relevancyGroup names, this location will NOT use its name
// as a relevancy group. No need to consider this unless you start running out of relevancyGroups,
// there is a maximum of about'ish 25 available (print out kMaxRelevancyGroups for exact numbers).
// There will be errors logged in the log if you run out. Oh, and you need to mark up all locations
// with a name that you don't want with a '-' to get rid of it.
//
// In order to see this field, you need to use the LaunchPad and open the LocationRelevancy mod -
// it is in your NS2 AppData file, workshop id m8bead14_... before starting the Editor from the
// LaunchPad. You should see a "Relevancy Groups" field when you select a location entity.
//
// You can turn on and off location relevancy by using the (cheats-guarded) "locrel" console command.
//
//
// Examples:
// Veil, Cargo (those large container walls were added to avoid long sightlines)
// A is a large location with two adjecent locations, B and C, and we assume that the view-distance from
// B into A is longer than max relevancy distance. Setting B and C relevancyGroups to "A" would make all of
// A,B,C belong to one relevancyGroup, "A". So as soon as you enter any of those three, all entities in all
// three locations would be relevant to each other.
//
// Notice that you could have the named location "B" be spread over two location entities - marked as
// "B" and "b" above, and only set the relevancyGroup to "A" for the B location.
//
// Example 2 (Goliath, Storage)
// trick as for Cargo would make all of them the same relevancy group, which would mean
// that everyting in the Top, Left and Right locations would become relevant if when you
// entered the Bottom location. May or may not be a problem; it would depend on how many
// entities you would expect to be in those areas.
//
// Assuming it IS a problem, and also assuming that there is no LOS between Top/Left/Right/Bottom,
// you can handle this by having creating four new relevancy groups "LS", "TS", "RS" and "BS",
// and using:
//
// Storage.relevancyGroups = LS,RS,TS,BS
// Left.relevancyGroups = LS;
// Right.relevancyGroups = RS;
// ... etc
//
// This means that if you are in Storage, all entities in all five locations are relevant. If
// you are in one of the entrance locations, only entities in your own location and in Storage
// are relevant.
//
// It is highly unlikely that this will be an actual problem - the cost of keeping 10-20 extra
// entities relevant is not likely to significantly affect your framerate and if you are in
// the Storage location, you would have them all relevant anyhow.
//
// You could go further, splitting the Storage into multiple entities, each having its own set
// of relevancy groups. This can quickly get quite complicated though.
//
// The best way of working is to design the map with location relevancy in mind.
//
// =========
You can use multiple location entities to build up a manual relevancy tree, freeing the mapper from any restrictions on distance.
Even if you don't modify the map, entities in the same Location as the player will always be visible to him.
Use with care.
Documentation:
// =======
//
// lua\LocationRelevancy.lua
//
// Created by: Mats Olsson (mats.olsson@matsotech.se)
//
// Adds the ability to make entities relevant by location.
//
// Background:
// For performance and bandwidth reasons, updates for entities in NS2 are only sent
// from the server to the client if the entity is "relevant".
//
// Relevancy is mainly calculated using distance (40m normally). Maps are usually carefully
// constructed to avoid longer sight ranges than this, though you can sometimes notice them
// (in Summit/Crevice, you will notice that if you go all the way west, everything around the
// resource node disappears and then blinks into existence when you get close enough).
//
// Some custom maps (Skyfall, Goliath) are built around very large locations where this
// problem is glaringly obvious.
//
// How it works:
//
// This mod uses a feature of the spark engine to make entities relevant depending on location.
//
// It adds the concept of a relevancyGroup and lets a location be part of one or more
// relevancyGroups. Whenever a player enters a location, everything in all locations that
// share at least one relevancyGroup with a players current location becomes relevant to
// the player (a relevancyGroup is just a name, bw, nothing fancy about it).
//
// By default, each location creates a relevancyGroup with the locations name, meaning that
// when a players enters a named location, all entities in locations with the same name becomes
// relevant to him. This is done automatically, and applies to all maps.
//
// For advanced uses, where the mapper want more control over relevancy, a new field has been added
// to the location entity in the Editor, location.relevancyGroups. This field may contain a
// comma-separated list of relevancyGroup names to which the location will belong.
//
// If a '-' is part of the list of relevancyGroup names, this location will NOT use its name
// as a relevancy group. No need to consider this unless you start running out of relevancyGroups,
// there is a maximum of about'ish 25 available (print out kMaxRelevancyGroups for exact numbers).
// There will be errors logged in the log if you run out. Oh, and you need to mark up all locations
// with a name that you don't want with a '-' to get rid of it.
//
// In order to see this field, you need to use the LaunchPad and open the LocationRelevancy mod -
// it is in your NS2 AppData file, workshop id m8bead14_... before starting the Editor from the
// LaunchPad. You should see a "Relevancy Groups" field when you select a location entity.
//
// You can turn on and off location relevancy by using the (cheats-guarded) "locrel" console command.
//
//
// Examples:
// Veil, Cargo (those large container walls were added to avoid long sightlines)
// AAAAA // AAAAA // AAAAA // B C // bbbB Cccc//
// A is a large location with two adjecent locations, B and C, and we assume that the view-distance from
// B into A is longer than max relevancy distance. Setting B and C relevancyGroups to "A" would make all of
// A,B,C belong to one relevancyGroup, "A". So as soon as you enter any of those three, all entities in all
// three locations would be relevant to each other.
//
// Notice that you could have the named location "B" be spread over two location entities - marked as
// "B" and "b" above, and only set the relevancyGroup to "A" for the B location.
//
// Example 2 (Goliath, Storage)
// TTT // SSSSSSSSSSSSSSSSSSSSSSSSSSSSS // SSSSSSSSSSSSSSSSSSSSSSSSSSSSS // LLLL SSSSSSSSSSSSSSSSSSSSSSSSSSSSS RRRRR // SSSSSSSSSSSSSSSSSSSSSSSSSSSSS // SSSSSSSSSSSSSSSSSSSSSSSSSSSSS // BBB //// The Storage location can be accessed from four different directions. Using the same
// trick as for Cargo would make all of them the same relevancy group, which would mean
// that everyting in the Top, Left and Right locations would become relevant if when you
// entered the Bottom location. May or may not be a problem; it would depend on how many
// entities you would expect to be in those areas.
//
// Assuming it IS a problem, and also assuming that there is no LOS between Top/Left/Right/Bottom,
// you can handle this by having creating four new relevancy groups "LS", "TS", "RS" and "BS",
// and using:
//
// Storage.relevancyGroups = LS,RS,TS,BS
// Left.relevancyGroups = LS;
// Right.relevancyGroups = RS;
// ... etc
//
// This means that if you are in Storage, all entities in all five locations are relevant. If
// you are in one of the entrance locations, only entities in your own location and in Storage
// are relevant.
//
// It is highly unlikely that this will be an actual problem - the cost of keeping 10-20 extra
// entities relevant is not likely to significantly affect your framerate and if you are in
// the Storage location, you would have them all relevant anyhow.
//
// You could go further, splitting the Storage into multiple entities, each having its own set
// of relevancy groups. This can quickly get quite complicated though.
//
// The best way of working is to design the map with location relevancy in mind.
//
// =========
Comments
(I wonder if there are cases in which overriding occlusion geometry might actually be a good/useful thing. Hmm...)
No, it does not override occlusion geometry - entities are loaded separately. You can already change the distance it loads entities at by using ExtraEntitiesMod.
Edit: at least I think these are working similarly. The difference is map_settings lets you set draw distance for entities, and this will let you spot treat rooms instead of using it for the whole map - which should preserve some performance in comparison.
Not really something I would recommend though - the potential win with lowering relevancy distance is probably not all that great.
It is really intended to help in cases where you happen to have a potentially long sightline like Summit Reception/Crevice, or really large locations (Skyfalls Helipad, Goliath Storage) where increasing the relevancy distance is not a good idea (covering all of Storage would require a relevancy distance of 130+m radius - THAT would be a bad idea).
It may be included in mainline if it shows itself to be stable and popular.