Forum :: EO Server Building :: need help with game showing online

OP, you could modify your host file to redirect the eosource domain to apollo's.

Suirad posted: (5th May 2017, 03:44 am)

OP, you could modify your host file to redirect the eosource domain to apollo's.

Did you test that yourself?

http://eosource.net/SLN/sln.php/ -> results in not found.

Basically, the SLN URL embedded into eosource probably requests a page different than where Apollo's SLN is located, so maybe the hosts patch will redirect the SLN requests to Apollo's webserver, but Apollo will have to have to implement a compatibility to accept SLN check-ins from URLs other than his SLN/sln.php

Take a look at the source code for SLN in EOSERV:

1. request->url += std::string(this->server->world->config["SLNURL"]);
2.     request->url += "check?software=EOSERV&v=" EOSERV_VERSION_STRING;
3.     request->url += std::string("&retry=") + HTTP::URLEncode(util::to_string(int(this->server->world->config["SLNPeriod"])))

It uses pure HTTP requests to do SLN stuff, not custom data packets.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Maybe I should make a couple of things clear. EOSource developers used an ego-block on non-eosource SLN hosts. It was essentially a stand against Sausage not adding core feature completion to EOSERV and thus trying to pull the community to the sites and services. As far as allowing methods to circumvent a direct connection from your server to the SLN, there are checks in place to prevent check-ins from anywhere that the server you are checking in does not exist. This is to prevent garbage requests that should never exist. Probably my best suggestion would be to create an SLN-EOSource bridge program and run it on the same machine as your server or maybe if you ask Sausage he might even make one for you.