Modern Client Functionality / Opcode Support about hermesproxy

[MaxtorCoder]

Highly unlikely, I don't see a reason to do this. If you want custom opcodes you would have the knowledge of using TC, patching the client, etc.

[0blu]

@MaxtorCoder
Custom opcodes == Modern client opcodes like thread api, warden3, get-early-off-taxi-button.
Mangos could forward support these opcodes.

[MaxtorCoder]

I don't see a reason for them to do that honestly, as it is the plan of CMangos to support Legacy clients

[insunaa]

Well someone has to lay the groundwork at one end of things, I guess. I can try bothering killerwife and Cyberium until they relent and let me put opcode handlers for some modern client features in, as long as they don't interfere with legacy clients.

They're probably not particularly enthused about it tho, because for some modern opcodes to be in CMaNGOS, there needs to also be Client/HermesProxy support. So, kind of a chicken & egg situation

[ratkosrb]

We should not implement such things unless they are made an official part of cmangos and other emulation projects. Having handlers for opcodes in the main hermes repo that only exist in your own personal fork of the core makes no sense. If it becomes official in cmangos, then we can make it official in hermes. But i can say as the vmangos maintainer, I wouldn't want such things in the core, as the project's goal is to emulate 1.12 vanilla not 1.14 classic.

[MaxtorCoder]

Exactly, so I don't see this happening, not now and maybe not even in the future.

[insunaa]

It can't happen unless one side does the first step, that's true.
The critical point for me imo: Would it hurt HermesProxy in any way to have optional handlers/forwarders for new opcodes?

[MaxtorCoder]

Of course not, but it's more that the original server would have to support the optional handlers/forwarders for new opcodes.

[insunaa]

Well they don't have to. New Opcode support should be optional on all sides and only enabled when agreed upon by both parties.

[ratkosrb]

@insunaa I am pretty sure it will not get accepted in cmangos, I know I would be against it if i was part of cmangos. So we will end up with support for functionality that only exists in insunaa/mangos-classic fork 😆

And in that case the hermes side support should remain in insunaa/HermesProxy as well.

[insunaa]

And when I talk with Cyberium and Killerwife about it they'll send me this screenshot and tell me that's why they're not going to support it

[ratkosrb]

I have no say what happens in cmangos. If they decide to add it in cmangos, we can add it to hermes as i said, but otherwise it makes no sense for us to have such custom stuff.

[insunaa]

I'll talk to them about it. 👍

[0blu]

I have no idea how modern warden works, but if we don't support WARDEN3 opcodes there will never be a popular vanilla server that supports Hermes. (looking at "Everlook")

[ratkosrb]

I don't think Warden 3 has been reverse engineered and implemented in any public core, but I bet @MaxtorCoder knows for sure.

[MaxtorCoder]

Warden indeed has not been reverse engineered for modern clients, 4.3.4 is the max reversed client for it

[insunaa]

CMaNGOS says no, so I'm closing the issue tentatively.
I'll start a fork of Hermes and CMaNGOS TBC and work on this issue separately.
I need a few weeks to months to get settled into my new job, then I can dedicate some proper time to this.