I’ve paid for a renderer mod to be developed for WotLK 3.3.5a, and there is already some very interesting functionality; there are exterior day/night and interior day/night variables exposed to the mod’s shaders, so that they can be changed in accordance to the time of day.
Now, there is a possibility of developing zone-specific shaders. In order to do this, there has to be unique mesh data in each zone, so that the mod can identify it and switch to that zone’s settings. The best way to do that, would be to have a mesh that is as big as the zone be enabled for the player when they enter it, and disabled when they’re not in the zone. So when player enters ZoneA, all of the proxy objects except ProxyA will be disabled for that specific player. But when that player moves to ZoneB, all of the proxy objects except ProxyB will be disabled.
Does TrinityCore have support for something like that? If not, even though I have no C++ knowledge (though I can program in C# and Pascal), if such a thing would be fairly simple to implement, this would be a good chance for me to learn and implement such a feature.
If you have a renderer mod this means you are working on modding the client, not server - and client does know (by itself) in which zone/area your player currently is, you don’t need to involve the server at all
The problem with that, is it kills performance to hook shaders, replace them with the mod’s framework, read from the process memory, and send that data back to the framework. Keeping it all on the GPU means there is a much lesser performance drain, that is also not worsened by the CPU’s current workload. Not only that, having an easily identifiable object that’s always rendered in a zone (that is then made invisible by the mod) is much easier to detect, and is completely compatible with custom zones.
Unfortunately for you, zone wide objects are not something that is supported in current visibility system, it is always done using distance from object (which also has an upper cap for server performance reasons)
Hmm. What about having multiple objects (so instead of 1 big object with unique mesh data, have 4, 16, or whatever number is required to cover the zone), that are toggled on/off depending on the zone the player is currently in?
Failing that, what about a buff that is hidden from the player, that place an mesh in front of the camera? And depending on the zone, a different buff is applied that does the same thing but with a different mesh? Would that be possible? So something like:
Event OnPlayerZoneChange
if Player.GetZone() == iDunMoroughID
Player.Cast(iBuffDunMoroughZoneFXID)
endif
if Player.GetZone() == iStormwindID
Player.Cast(iBuffDunMoroughZoneFXID)
endif
EndEvent
Auras? Easy, create spell in spell_dbc db table and add it to spell_area (you might want to dig in code to find what conditions make server send the aura to client in the first place)
Actually, I take back what I said about adding to spell_dbc. You will need to modify clients own Spell.dbc file and ship it to your users, otherwise the game can’t display anything
To have aura display only for a specific player you will need to modify parts of code that send out auras, its doable but not implemented (no spell needs it)
Editing the client dbc files is perfectly fine. But why would the aura sending code have to be changed? I figured it would be a client-side dbc change; the client would only render the proxy aura for the player’s character, with the proxy aura of other players not being displayed at all. Is it because of a specific packet that needs to be sent to the client?