Hi.

I have problems with my server controllers , xaseco and uaseco for example.
The command : /xlist does not work.
This shows the same list as MX , and can be used to add maps ( with mouse klick ) from MX to the server.

The server can not connect to MX somehow.
More people having this ?

As MX now redirects all traffic to https, a few controllers broke down (some controllers do not follow redirects). While this is an issue with the controllers themselves, for the time being broken controllers are "whitelisted" to not be redirected.
XASECO2 is whitelisted at least, UASECO isn't. If it also broke, tell the exact user-agent string and report the issue to the maintainers.

Well , for xaseco it doesn't work also , at my server.

Realy strange.

Only XASECO2 is whitelisted, XASECO (1) isn't.
UASECO is also whitelisted for the time being, so using that it'll probably work again.

TGYoshi says:
Only XASECO2 is whitelisted, XASECO (1) isn't.
UASECO is also whitelisted for the time being, so using that it'll probably work again.

I meand xaseco2 ofcourse , sinds this is MX and not TMX.

But still not working . my Uaseco not and my Xaseco also not.
I also tried expansion , it went fine untils I updated expansion.
Now also expansion can not connect MX.


Just strange that I'm the only one with this problem.
I rent the server at NC1.eu

The server is in the Netherlands/Friesland. ( fun with Derr )

( Op z'n Nederlands : schiet mij maar in de kerstboom )
I'm out of idea's


From log :

[UASECO Warning] Connection or response error on http://tm.mania-exchange.com/tracksearch?api=on&environments=2&page=



ok I found out that add by id nr works.

It sort of depends on how the controllers are programmed too, if they use a set of different user-agents for some weird reason, we haven't whitelisted them all. We've only targetted the user-agents used to download a map, which should work fine.
In the end it comes down to controllers truly fixing their logic to obtain data from the site, of course.

UASECO uses the same old "mxinfosearcher.inc.php" and that's why it doesn't run. Added a work-a-round into it (unreleased right now), but this class is still one that need to be replaced.

Btw.: It seems the whitelist doesn't work, in the unchanged version the redirect is forced.

Some more UA's just got added, some controllers think it's funny to use 3 different UA's or so instead of a single one.

hi,
The issue we are havin with switching to https, is we used to use and old class, that works very well that does the downloads in parallel. So while the map is being downloaded the controller continues to work and do stuff. XAseco, UAseco & eXpansion uses the same library which won't work with https even if it did fallow the redirect.

This same library is used for the Dedimania integration so the nice thing to do is to replace it everywhere. Therefore it can't just be done fast in a week. (Well if our daily jobs was to upkeep our controllers then of course)

Thanks for whitelisting the controllers but I think the https switch should have been announced? If it was I didn't see my fault

Thanks for whitelisting the controllers for now

Yea, it hasn't been announced as I simply assumed that the redirect would work everywhere (assuming all controllers used some sort of true http(s)/web client lib handling this, instead of manually creating sockets to work around another php limitation etc).
Which apparently was a faulty assumption .