Razmataz

done

done.

appear will announce you bypassing their appear disable if they're in the same phase as you and you are an officer of the phase.

Those materials cannot be communicated to your client alongside the gossip menu request. You're thinking of pages, of which only these options are available: https://wow.tools/dbc/?dbc=pagetextmaterial&build=9.2.0.42174#page=1 We'll have to create them in a completely different way to gossip, with something like a book forge, and then assocaiting it to an object, or item.

Evidently we've fixed it, cause I can't replicate.

I believe this is fixed now following discussions in Discord, so closing it. Let us know if this is not the case.

We're aware of this bug! Sadly happened with some phase refactoring regarding permissions. It's on the agenda, just not immediately. Sorry!

Sorry for this, missed the context of a .clear() when refactoring this code. Have a fix lined up for it.

This is why I introduced spell based skyboxes, accessible with .lookup spell lightdata and applicable to areas/zones with .phase shift area/zone skybox #spellid. There are a lot of fundamental oddities with phase set skybox that are difficult to explain. Trial and error with a bit of luck seems to be the best way about it.

Why don't you just .aura it? Then you don't have to have two macros or a convoluted equip process.

idk either ? I keep prodding and poking about it.

Thread necromancy ? this thread is over a year and a half old, so chances are it won't work because it was designed for 7.3.5.

Sounds like you're missing the vc_redist install. It's inside your Epsilon folder. Alternatively, check the #tech-faq in discord.

This is meant to go into the other customisations thread.

This is meant to go into the other customisations thread.

if you are not seeing any changes when you do .phase shift doodad adt, chances are you're at the maximum doodad shifts beyond which the command behaves with instability. this happens at around 16. you can try to alleviate it by migrating from .phase shift doodad adt, to .phase shift doodad zone - so all 20 adts in the zone are now handled as one shift rather than 20.

could you screenshot the output of your .gps command? if you have too many terrain swaps, they won't take. 16 is the cap. you can alleviate some of the issues wit this by migrating from adt shifts to zone shifts.

If you're based in the US, you need to wait it out or acquire a VPN. The downloads are horribly slow due to the lack of net neutrality over there. Alternative methods were available in the past but were not configured correctly, so they had to be taken down. May be put up again eventually.

Hiya, roleplay only!

the fix is typically to start over with ".phase reset skybox all CONFIRM" unfortunately the skybox system is a bit complicated

Changelog (Patch 830.2f - "F(ph)ase Refactor & Tidbits") Release date: 19 November 2021 Here you'll be able to read up on changes, big and small, made to various parts of the server. Legend • White - This was not changed. Also used for contrast. • Green - This was added. • Red - This was removed. • Yellow - This was changed. Highlights Phase Permissions Refactor We've done some rework in the backend in how phase permissions work. Chatbot Improvements The chatbot link between ingame announce and the #main discord channel has been reworked. Spell Skyboxes A suite of spells that apply screen effects & skyboxes permanently (until the aura is removed) have been added. Phase Shift Map You can now apply terrain swaps for non-doodadless data over the current map you're in, e.g. phase in ruined Theramore, Sargeras' sword in Silithus, HD Arathi Highlands, etc. Preamble Hi guys! Thanks for your patience with this one. The initial deployment was indeed bumpy but we got through it in the end! : ) There is not much in the way of features, but the groundwork for lots of cool stuff has been going on behind the scenes and we can't wait to share it with you. 8.3.0-2g is hot on the heels and the changelog for that is also posted. Please take a look at it. New Commands and Features .phase Subcommands added: .phase shift map #map_id [#map_id_to_affect] Superimposes the given #map_id onto the map you are currently on. This will allow you to shift in maps like the Arathi Highlands Darkshore warfronts, the Silithus Sword, the Uldum Oasis, etc. into the main continent, This command contributes to the maximum number (16) of shifts you can have active in a phase before the shifting system becomes unstable. This command is dangerous! If you apply an inaccessible map, you will be disconnected and unable to re-enter the map until you use the #map_id_to_affect parameter to remove the shift! .startspell These commands can only be used by a game master! Subcommands added: .startspell list Lists all spells and auras that can be cast while in the main phase Dranosh Valley. .startspell list next Displays the next 50 results of the previous command. .startspell add #spell_id [$comment] Adds the given #spell_id to the list of spells and auras that can be cast while in the main phase Dranosh Valley. If a comment is provided, this will be shown in the startspell list command. #spell_id can also be a chat-link. .startspell remove #spell_id Removes the given #spell_id from the list of spells and auras that can be cast while in main phase Dranosh Valley. Command and Feature Changes Phase Permissions Under-the-hood changes have been made to the phase permissions system to make it more robust for development purposes. Message Stream Improvements Under-the-hood changes have been, and are continuing to be, made to the chatbot system to reduce its impact to the server stability. Pandaren Neutral pandaren will now get prompted to use the command .character pandaren alliance / horde if they are still part of the neutral faction. World State Overrides The WorldStateZoneSounds db2 file has been emptied and will no longer interfere with .phase shift area/zone/wmo music and ambience changes. This was prominent in Quel'danas. .phase .phase shift area skybox #skybox_spell Applies the skybox_spell to all players who enter the area. -1 will result in no adjustment to any skyboxes on the player, while 0 will result in all skybox spells being removed. The CDNS update has occurred so this now available. .phase shift zone skybox #skybox_spell Applies the skybox_spell to all players who enter the zone. -1 will result in no adjustment to any skyboxes on the player, while 0 will result in all skybox spells being removed. The CDNS update has occurred so this now available. Bug Fixes Crashes Fixed a crash that occurred with objects spawned close to map boundaries, e.g. at coordinates ±16,000. Other Fixed a numerical error in the area/zone music hotfix. Fixed an issue where blueprint chat links were using the wrong ID. Fixed an issue where blueprints did not properly apply supervisible status to objects that were meant to have it for the current server session. End of Changelog Glossary Below is a list of common terms you will encounter when reading changelogs and using commands on Epsilon, to help you understand how a command might work. Syntax The structure of a command, composed of strictly arranged words (arguments and/or parameters) required to be met for the command to be performed. Think of it as the grammar of programming, where all computers are grammar nazis who won't do what you ask if you don't write perfectly. How you see Epsilon's changelog and in-game use of syntax is not what it tends to look like in actual programming. Parameter Parameters in our case are used to structure the specific command it is you wish to perform. Argument Arguments in our case are used to tell the parameters which data type(s) to use when performing the command. Example: Syntax = .phase forge npc displays add #display_id %scale %weight In the case of Epsilon, is the same as: Syntax = .parameter parameter parameter parameter parameter argument argument argument .phase forge npc displays add 100 2 5 The arguments (green) tell the preceding parameters (white) to: "Add" #display_id "100" at %scale "2" with %weight "5" to the targeted forged NPC. Data types Floating Point - Symbol % A real number, accepts decimals. World of Warcraft does not count more than 6 decimals. .mod scale %scale = .mod scale 1.063523 Integer - Symbol # A natural number, does not accept decimals. .gobject spawn #display_id = .gobject spawn 175490 String - Symbol $ A sequence of characters, typically forming one or multiple words. .summon $name = .summon Bob the Builder Optional - Symbols [ ] When a single data type is encased in brackets, it means it's an optional argument and is not required in the syntax for the command to function. .phase forge npc displays add #display_id [%scale] [%weight] #display_id is required but [%scale] and [%weight] are optional. When two or more data types are encased in brackets, it means that though they are optional, if one is specified then both are required for the command to function. .gobject teleporter add [#guid] [#icon "$text"] [#x #y #z] [#orientation] No argument is required as the command uses player position by default, however [#icon "$text"] requires both arguments to be specified to work.

You're on Windows 7 - those features are disabled because the OS isn't really supported by Epsilon.

Short term fix: /console wmoLodDist 9999

Preamble Hi guys! This is a complicated announcement, so it has warranted its own thread. Also, this is marked as 8.3.0-2g because there's still an 8.3.0-2f update in the pipeline that ideally is done before this one. TLDR Up until now, all phases have shared the same container for object data. Following a maintenance period required for this change-set, we will divide the container up for each phase. This allows us to load phases separately from every other process in the server, allowing server startup to be a separate process from phase loading. Upon login after a crash, most recently active phases will be loaded first, and phases up to 30 days old will be added to the phase loading queue. Inactive phases can be manually re-activated after the queue is completed by an officer+. The server is currently scheduled to have extended maintenance on the 29th of November to faciliate this update. The window is expected to be 2 to 3 hours. Rollback steps are prepared and will be able to be performed on a much shorter time span. History Veteran members of Epsilon will remember a completely different state of server performance and optimisation. A time when server optimisations were unnecessary and performance was acceptable. Since then, the active population has grown substantially. We've gone through two major phases of player increase, and by incurring those additional players, bottlenecks have been made apparent and we've taken steps to address them. For the most part (at least, outside of the backup period) there is a low world latency so things feel quite responsive. However, the steps we've taken to address the long startup period has seen some successes, but with diminishing returns. We now face a startup time of an alarming 10 minutes. The breakdown of a typical server crash & restart is: 08:39 - Server session crashes 08:40 - Core file dumped & moved to high volume disk 08:40 - Startup of new server session 08:41 - Server session begins loading objects 08:47 - 6 and a half minutes later, objects are fully loaded. 08:48 - Server is now connectable That's a 10 minute process, of which three fifths are dedicated to objects. We already know how to deal with the core dump (and this should take off a whole minute off the process), but we need to address the object load time. This is not helped by the rate at which the object count in the server is growing incredibly rapidly. With blueprints and gobject group copys, and then with doodad imports, the fact that more players log in and build on the server is a catalyst for these numbers skyrocketing. In the past we had this issue with startup times, but were able to partially remedy it by switching the object loading process to a multi-threaded one. This issue is also apparent in the increasing times that backups take, and how long a degraded performance is noticeable on the server. So it's time to change something fundamental with how the server works. If you're interested in the technicals, I've gone into how it used to work, how it works now and how it will work: Old Workflow Every single object is stored inside a single container called the "GameObject Data Store", which contains an integer (the objects GUID) as a key, and the object data as the value for that key. You can think of it like a dictionary with the key "word" and the value "definition". When the server starts up, the server performs a query on the phase table to initialise all phases. Then, a query on the gameobject database asking it for every single object. The query eventually returns the millions of rows, and the server goes through each row and converts the numeric based data into the object data. Once completed, it adds this object to the GameObject Data Store, and proceeds onto the next row. Once all of the rows have been parsed, the server proceeds to the next step of initialisation. In Layman's Terms The server runs one big query on the gameobjects database, and spawns every object from that. Nothing can happen until this finishes. Current Workflow Every single object is stored inside a single container, which contains an integer (the objects GUID) as a key, and the object data as the value for that key. You can think of it like a dictionary with the key "word" and the value "definition". When the server starts up, the server performs a query on the phase table to initialise all phases. Then, it generates a list of all of the phase ids. It then creates eight separate threads (which can execute code simultaneously) to alternate between the two following steps: Query the gameobject database asking it for every single object in a given phase id; Go through each row, generate the object data, and add it to the GameObject Data Store. Each thread will check the list of all the phase ids, take one (and remove it from the list) and then handle it. Once the list of phases is exhausted, the server proceeds to the next step of initialisation. A key limitation of this is that the GameObject Data Store is one container; it is a very, very, very bad idea to attempt to have multiple threads adding data to it at the same time. (A few people might remember this incident where the server started up in a fraction of the time, but because of this limitation, very few objects were added to the GameObject Data Store and thus not loaded into the world). This limitation results in a significant loss of ideal speed in which the gameobjects are loaded. Even then, it was able to reduce the startup times by about 20% to 30%. The ideal speed would be by half. In Layman's Terms The server has multiple scripts running at the same time, making many small queries on the gameobjects database and spawning every object from that. Objects can be queried, but cannot be added simultaneously. Nothing can happen until this finishes. New Workflow Every single object is stored inside a container of containers. The top level container contains an integer (the phase ID) as a key, and the GameObject Data Store for that phase as the value for that key. You can think of it like a library, with a dictionary for each language. When the server starts up, the server performs a query on the phase table to initialise all phases, plus room for extras. It reviews the last time the phase was entered by an officer or above and determines if it is an active or inactive phase. Based on its activity, it is added into a queue. The server spawns up to eight separate threads to handle the global phases (main phase, NPE, etc.) and waits for them to complete. Because each phase has its own GameObject Data Store, all threads can query and load objects into memory simultaneously. Following this, the server spawns eight separate threads to handle phases as determined by the queue. These threads are detached from the main thread and do not need to be waited upon. Therefore, as soon as these eight threads are created, the server continues with initialisation. Each thread will take the next phase from the queue, drop it from the queue, load in the gameobjects, load in the gameobject groups (as this process attaches data to each gameobject) and change the state of the phase from queued to active. For phases that are inactive (not entered by officer+ for >30 days), gameobjects are not loaded. There are no queries done, and the phase is initially inaccessible. If I attempt to enter the phase as a player, I am told it is inactive. If I attempt to enter it as an officer+, it will spawn a separate, detached thread and load in both gameobjects and groups. After thats done, the phase is made active & accessible. This whole process of phases being loaded in optionally is thanks to the tiny change in the memory structure. Because we now have a container of containers, we can multi-thread write to each of the phase key GameObject Data Stores, rather than risk multiple writes to the global GameObject Data Store and risk a crash. In Layman's Terms The server has multiple scripts running at the same time, making many small queries on the gameobjects database and spawning every object from that. Objects can be queried and added simultaneously. The server can continue, and complete, server startup while this is ongoing, but an exception is made for global phases (main phase, NPE, etc.) and these have to be loaded before the server can proceed. Impact of New Workflow Because the server doesn't need to wait for your phase objects to load, the startup time is reduced by more than half and it will never be affected by the gameobject count again! When you log into the server, you spawn in the main phase. When you attempt to rejoin the phase you were just in, either you're too fast and it hasn't loaded yet (but will imminently) or it will already be accessible because it was high up in the queue due to a very recent last activity time. The Global GameObject Data Store controls the GUID of an object. This is a value of up to 2.1 trillion (so a number you won't ever hit). We're currently at a GUID of > 200 million and this is a number that each phase taps into. When we move into a Phase based GameObject Data Store, each phase will have their own GUIDs. You'd be hard pressed to get into 7 digits. Phases will be loaded over the next ~# minutes, in order of descending recent activity. This might result in your attempts to enter a phase being rejected initially, but this should rarely be the case. Additionally if you want to load into a phase that hasn't been active for a while, this has to wait until the initial loading is done. A bit more on 2: Because of the magnitude of data involved, this requires extended maintenance in order to reallocate GUIDs for every object in the game. This is estimated at a ~2 to 3 hour process, as detailed in the Deployment section. We are accounting for GUID changes in groups, in teleporters, in creature scripts, etc. Unfortunately we can't edit your macros for you, so you'll need to amend them if you specify GUIDs in there. In Layman's Terms The server boots up fast. Real fast. The required phases are loaded in under 1 second, so the server is no longer bottlenecked for 6 minutes loading in everyones objects. Because of the change in the gameobject container structure, gameobject GUIDs will be made unique on a per phase basis. Your first spawned object GUID of 200,000,000 will become GUID 1. This may cause your macros to no longer be aligned to the object GUIDs of which they refer to. Deployment The server is currently scheduled to have extended maintenance on the 29th of November to faciliate this update. The window is expected to be 2 to 3 hours. This is to permit me to do the following steps without interference: Run the reallocation of GUID script on all gameobjects currently in the database Import the gameobject table anew with the updated GUIDs. Run the database query updates on all of the tables that depend on the gameobject GUIDs to also specify the phase, since GUIDs are now only unique on a per phase basis Contingency Plans Every plan works until it meets the opposition. There is a chance that, like other releases, something is fundamentally broken with the way things are done and the changes have to be reverted. The previous iterations of the gameobject tables and all of the updated ones will be copied and retained for up to a week. If the performance is considered absolutely garbage, then we will revert the codebase changes and switch to the old versions of the tables. It is, fortunately, possible for us to recover any builds that are done after the migration but this will need to be manually done. Ideally, the reason for us to roll back these changes will either be apparent immediately or not at all, so there shouldn't be much of an opportunity for any new gameobjects to be added in a large enough capacity to warrant migrating them across the rollback. In Closing Hopefully this migration will go successfully! Hopefully it will have been worth it, and hopefully I won't be spending the following 8 hours pulling my hair out over new issues. I've done the whole migration on our dev box with a clone of the production database and it changed startup times from 12m down to 4m our dev server is a tad slower than production to begin withfor some reason, so this should reflect as a 10m down to 3m process on Apertus. Anyway, time for me to get cracking with the backup optimisations.

sounds good! i'll try and sort this kinda command out sometime.