Leaderboard

PHASE OPTIMIZATION You have just finished building your phase. NPCs, roleplay areas, fine details, lighting and all. Whether it took you days, weeks, months or more, you feel a certain satisfaction in a job well done, and you are preparing to unleash your build. However, you find that in your quest to manifest the perfect fantasy world, tavern or island, you have also created an environment that is conducive to severe frame loss, and the accessibility to your build is therein stunted by performance issues. How might you resolve this issue, might you ask? Don't worry, you won't need to shave off any of the hard work you've committed to your project by deleting anything. Let's talk optimization. In source games such as Counter-Strike, Half-Life or Team Fortress 2, "areaportals" are a way for the game to remove certain areas or objects from rendering when they are no longer able to be perceived. However, since World of Warcraft's engine and consequently Epsilon does not share this feature, your game is currently rendering everything within a set radius. Throughout the course of this guide, you will be able to emulate the function of areaportals to allow players in your phase to perceive what you want them to perceive, while leaving things that they cannot see from the spot they are currently standing in to go unrendered until they approach, causing your phase to be much more easily accessible to others throught a variety of hardware specs. The Commands The following will go into detail on how to to optimize your phase for better performance via a series of three commands: .gob set vis $visibility, .gob mass vis $visibility $entryID $radius, and .phase shift $zone/area vis $ultralow/low/med/high .gob set vis $visibility is our individual visibility command. It affects nothing but the gobject you have currently selected with .gobject select (or .gob sel). The $visibility variable is measured in in-game units, which you can measure for yourself by using .gps $direction (forward/back/left/right) $units. .gob mass vis $visibility $entryID $radius is the mass variant of the above. The first of the two new variables, $entryID, is a string used to identify a particular gobject (as opposed to GUID, which identifies a specific instance of an object in your phase) and you can acquire a gobject's entryID via selecting it and clicking "Copy Entry" from the textbox. The second variable, $radius, determines in what radius around you will this apply to objects that fit the criteria of your $entryID variable. The $radius is also measured by in-game units. In each of these commands, for each variable, if you use "-1" in place of a normal input, the command will translate that to infinite or all available targets. For instance, a -1 $visibility will make your object be visible from as far as the game engine will allow, a -1 $entryID will cause the gob mass vis command to target all objects within the specified $radius, and a -1 $radius will affect all objects on the map within the specified parameters of the $entryID variable. Suffice to say, this feature should be strictly used in moderation. The last command, .phase shift $zone/area vis $ultralow/low/med/high is a command that will modify the render distance of players within said zone. You can use this in conjunction with the above to adjust visibility on an area or zone basis to allow easier navigation in high gobject density areas of your phases. Visibility Priority So, what objects should receive -1 visibility? Landmarks: Discernable, unique objects that mark the area and can be seen from afar. A notable example of such an object might be the Stonewrought Dam in Loch Modan, or the world tree Nordrassil at Mount Hyjal. Buildings and structures, as they are just as important to see from afar. Water tiles. Terrain objects, such as Epsilon rock arches. Trees, depending on the density of your location. If your build features a sparse amount of trees with very few dotted along the landscape, having a -1 visibility on trees would be beneficial. If your trees are densely packed together, you may find that it would be wise to keep them only within a certain range of visibility to draw in the illusion of a dense forest without having to render in the forest entire. Once the -1 visibilities are out of the way, we can move on to the rest of the objects, which should be at your discretion. Keep in mind the comparison to areaportals above, in that you should decide object's visibility via the maximum distance that such an object could be perceived. In terms of objects spawned en mass, like foliage, rocks and such, the .gob mass vis command will come in handy and allow you to discern the visibility of these objects in specified areas or throught your entire phase with ease. Objects in buildings, as you might guess, should be limited to a visibility that would allow them to be seen from every corner of the rooms they are in, but no further for maximum optimization. Should you follow the instructions of this guide, I am certain you will find your phase to be far more accessible with far fewer performance issues when navigating your build. 🙂