It very subjective, but cross DC chat is an absolute no no for now. That's asking too much.
All I'm proposing is:
-you scrape and export the local PFs to a central database that both DCs refer to. Thats it, that's 95% of what I'm proposing.
-The local PFs import that DB, or present it
-If you join a DC pf, it sends a signal to the DC saying 'this place is taken.
-Then it auto starts your char for DC travel 'immediately', then you have to wait the 50 minutes for that PF to fill, 'on' that server. (You don't travel last minute, and you don't travel back automatically either, in between resets.
If that's going to take them years, they should hire me. I could do it in a year. A skilled developer who knows their languages and frameworks could do that in four weeks (no QA though granted, full of bugs granted)
No way that should take them years, or their overcomplicating it, for something that is frankly so critical and can't wait for TRUE, cross DC pf.
The problem... is increased travel, and tifthe current DC travel system can take the load and maintain current DC trael times.
For the time most PFs sit waiting to fill, the 110 seconds it takes to DC travel is NOTHING if you make people do it the moment they join PF. Lets add 20 seconds for forced logff.
All yur doing is making > loggoff > DC travel>,log on automated... thats all, and sending a signal to reserve the PF place while you travel. That's it.
The rest is basic data export, and go and buy a Microsoft SQL server Data centre license. It wouldn't even need very many CPUs or mh disk space.
You just have an agent that sits on each DC/server, pretending to be a charactre on that server, reading the PF info, putting up pfs, and pretending to request places. Not much different from the crossworld infrastructure.
I refuse to believe its much more complicated than that. Yes new code, but I don't see that existing code has to change much. Unless they've coded the whole damn thing in optimised assembly withouth and object orientated approach.


Reply With Quote





