Hola comunidad,

Presentamos MuOnlineHttpApi, un proyecto que permite monitorear PvP en tiempo real desde MU Online. Cada kill/death se registra en memoria y se expone vía HTTP para que un frontend pueda mostrarlo al instante.

Cómo funciona (diagrama de flujo):
GameServer: detecta un evento PvP
→ HttpApi: procesa y guarda el evento en memoria
→ Servidor HTTP: escucha en el puerto 8080
→ Frontend / App: consulta /events y muestra PvP en tiempo real
Nota: La API escucha en todas las interfaces disponibles, por lo que puede ser accesible desde otras PCs si el puerto está abierto y configurado correctamente. Para producción conviene agregar seguridad (token, IPs permitidas, HTTPS).

Ejemplo de JSON entregado por la API:

Code: [Select]

{
  "events": [
    { "killerName": "DarkKnight", "deadName": "ElfArcher" },
    { "killerName": "MagicWizard", "deadName": "SoulMaster" }
  ]
}

Video demo:

Link del proyecto:


Gracias :D <3

What about security?

What about security?

Good question. Right now the API is intentionally minimal because it was designed as an internal event layer for a future external client (web/app companion), not as a public-facing service.
For production use, it should be placed behind a firewall and extended with authentication (token/API key), IP filtering and optionally HTTPS.
This release focuses on the in-memory PvP event architecture; security hardening would be the next step depending on deployment scenario.

What about security?

Good question. Right now the API is intentionally minimal because it was designed as an internal event layer for a future external client (web/app companion), not as a public-facing service.
For production use, it should be placed behind a firewall and extended with authentication (token/API key), IP filtering and optionally HTTPS.
This release focuses on the in-memory PvP event architecture; security hardening would be the next step depending on deployment scenario.

I really not sure why you do it like this? Why just dont add new table in SQL 'KillLogs' and DataServer save there all kills/death..

What about security?

Good question. Right now the API is intentionally minimal because it was designed as an internal event layer for a future external client (web/app companion), not as a public-facing service.
For production use, it should be placed behind a firewall and extended with authentication (token/API key), IP filtering and optionally HTTPS.
This release focuses on the in-memory PvP event architecture; security hardening would be the next step depending on deployment scenario.

I really not sure why you do it like this? Why just dont add new table in SQL 'KillLogs' and DataServer save there all kills/death..

is just another way to do, i think is fine

What about security?

Good question. Right now the API is intentionally minimal because it was designed as an internal event layer for a future external client (web/app companion), not as a public-facing service.
For production use, it should be placed behind a firewall and extended with authentication (token/API key), IP filtering and optionally HTTPS.
This release focuses on the in-memory PvP event architecture; security hardening would be the next step depending on deployment scenario.

I really not sure why you do it like this? Why just dont add new table in SQL 'KillLogs' and DataServer save there all kills/death..

This is not a replacement for SQL logging. It’s an in-memory event layer designed for real-time consumption (dashboard, overlay, mobile companion app, etc.).

If you kill a character right now, can you see that reflected immediately in the database without logout?
For example, if you run this in SQL Server while both characters are still online:

Code: [Select]

SELECT Name, PkCount
FROM Character
WHERE Name= 'NombreJugador'

Does PkCount update instantly after the kill?

In most MU setups, character data is flushed to the database on logout, not in real time. That means the DB is not a live event source — it’s a persistence layer.

HttpApi works directly at the GameServer memory level. The moment the PvP event happens, it’s available via HTTP. No logout. No waiting for DataServer sync. No polling delays.

That’s the architectural difference:
SQL is persistence.
HttpApi is real-time runtime event exposure.

Both can coexist, but they solve different problems.

What about security?

What about security?

lo mejor que se puede hacer en este caso es modificar Api usuario contraseña y token's  si lo quieres llevar mas alla puedes usarlos que las consultas tengan que tener un cert