DCEmulation

I have many questions to ask but I will start with that on the ships
blue crab told me that there are bugs in different shipps (Iselia and vega)
but how is that possible? there's only one panel Comtrol
already had a server and when a ship had failed or was incomplete I just replace the files from one to the other because it does not happen here?
what bugs or errors from one ship to another?
if the ship is perfect altima is not just copy the files and move to those who are flawed? thanks for reading await answers

Different ships can be running different versions of the server. As of right now, all the ships should be just about synchronized on the same version (it may be off by one or two revisions, but they don't contain any real new bugfixes that would concern anyone).

I only can control what version Iselia and Altimira run. Those are the only two that I personally host myself. Vega is hosted elsewhere on a machine that I don't control or have access to.

Also, all the ships can be configured separately, so they can (for instance) have different sets of quests and allowed versions and whatnot. For instance, Altimira only is configured to allow DCv1, DCv2, and PSOPC clients to connect. PSOGC is not allowed, nor would PSOBB be allowed. Thus, Altimira only has quests configured for those versions that are allowed, whereas all the other ships also have PSOGC quests configured.

I could continue on about the architecture of the server itself, but that's probably out of the scope of this question.

(. Vega is hosted elsewhere on a machine that I don't control or have access to.)
as well as telling me that vega is in a separate VPS? if that even then the sylverant allows the entry of Shipps parallel to the other server is ... is it?

Vega is hosted on a separate machine than the rest of the ships, yes. Ships can connect from the outside, but only with permission (this is part of the architecture of the server itself)... I guess now is as good of a time as any to explain it...

Sylverant is divided up into a few separate programs. The simplest of these is patch_server. patch_server is the only one that doesn't do any communication with any of the other parts. Basically, patch_server exists to provide patches for PSOPC and PSOBB. Its self-contained and can (in theory) be run on a machine all its own, if you wanted to do so for some reason.

The next of the Sylverant programs is ship_server. ship_server is what you actually connect to when you're playing online. This is where games are hosted and all of that stuff. The only other portion of the server that ship_server communicates with is the one called shipgate. Each ship has a unique Ship ID (which consists of an integer ID as well as a cryptographic certificate) that it uses to communicate with shipgate. In order to connect, a ship must have a certificate that is signed by the shipgate keychain. This is much like an SSL certificate that is used by a webserver to do https (in fact, that's exactly how it works now). Each ship can be hosted on separate machines from any other parts of the server. You can also host ships on the same machine as the rest of the server (and you can have multiple ships on the same server).

The last piece of the Sylverant server setup that your game client has any contact with is called login_server. login_server is what maintains the list of guildcards and presents your client with a list of ships that it can connect to. This is done through a database that login_server shares with shipgate. login_server itself does no communication directly to ships, and in fact doesn't directly communicate with any of the other parts of the server. Everything it does is basically through the MySQL database that it shares with shipgate.

shipgate is the only part of Sylverant that game clients do not ever communicate with directly. Ships connect to shipgate with their cryptographic certificates. If a ship that is unrecognized tries to connect, the shipgate will not allow it to do actually connect to the server at all. As mentioned above, shipgate shares a database with login_server. In this way, shipgate is responsible for quite a bit. For instance, when you do some commands on the server (for instance /login, /save, /restore, /restorebk, /gbc, and the /gban family of commands), the ship will communicate with the shipgate to actually do the command itself. Also, the shipgate is what keeps track of where users are on the server and whether or not they're actually online at the time. Because of this setup, when you do a guildcard search, if the ship you are on cannot find the user searched for, the shipgate takes care of the rest.

Basically, since shipgate and login_server have to share a database, they should usually be run on the same machine (although this isn't necessarily a requirement). All the other parts can be run on separate machines.

Hopefully that explains things well enough.