Place the charchoicex1.xml in a custom gui directory (it needs to override the default one) and the hak where it belongs. The erf contains the important script gui_ap and ap_start which mainly shows how to start a transfer
Current limitations:
-Enabling localvault chars on a server may pose problem (not tested)
-Currently only works with the first five chars (this will be extended, but laziness prevails... you can do it yourself if you open the hak and think a few minutes)
-Chars must have a first and a last name(will be corrected soon, you can do it yourself too, in gui_ap)
-A player must not have 2 chars with the same name (not fully tested, but sure it's a bad idea)
-there may be some probleme under heavy lag ( > 1s, i can't test this one )
-Both servers do not "need" to have the same servervault but that would be a misleaded use of the system :D
-No destination waypoint (not actually sure if it could be done, will think of it)
-It doesn't check if the destination server Ip is valid/active, and therefore always disconnect the player from server 1 when the process is started. an addition to reconnect the player to server 1 in case of a problem is doable.
My guess is that there will be a much simpler way to do this with the 1.13 patch but the idea will be the same.
I don't see why it wouldn't work without MOTB, just rename charchoicex1.xml into charchoice.xml
It has only been tested on two small test-servers (well, the server don't actually do much), and on two installs.
any comment or bug repport is welcome :)
Edit 1: first (corrected) note,OnExit (Area event) is not triggered on server 1, OnClientLeave is
for patch 1.13
charchoice.xml and charchoicex1.xml are to be put in a custom gui directory, client side.
ap_cso.xml ap_gcn.xml and ap_dsc.xml can be put in a hak or in the custom gui dir.
ap_beta4.erf contains gui_fakeactivateportal and inc_fakeactivateportal
I tryed it on Arkalym (check your pms btw) and got some few problems. But I'm not sure we're doing that correctly :
- Empty button on the right of the player's character list (could be normal though...).
- Could not scroll down that list (so if one has a lot character he can't select the good one).
- Always having the first char of the list being connected on the other module (even if we have the second, third or any'th char on the first module).
Just to keep trace of that. Nice xml work, thanks !
It has been tested throughout the weekend on a french tri-server.
update:
-Enabling localvault chars on a server works, but may cause serious lag.
-Still only works with the first five chars of the player charcater vault
-probleme with having only one (first or last) name, removed
-if a player has two chars with the same name, it won't crash the system(it used to) but it won't certainly log the good one.
-on connection timeout, it will get back to the multiplayer menu (it used to freeze the client, for some players)
the erf now contains gui_fakeactivateportal and an include, inc_fakeactivateportal, wich holds 2 functions :
FakeActivatePortal(object oPC, string serverIP, string serverpass="", string destWPTag="")
and
FAPGetCharacterNum(oPC) wich needs to be called before the actual portal (i strongly suggest an area oncliententer event, as the server need to be able to display a gui screen)
this last function takes 6 secs to complete, but is transparent to the player. after that the fakeactivateportal function can be called
as the deconnection procedure isn't really clean, we ran into some trouble with a player with a very slow connection. you may want to consider adapting your code so that recurent event (onheartbeats or user defined) avoid treating player who are using the system (it solved the problem of the lag on the first version, i think the second one allows to not do that, but hey...)
have fun testing :)
You must be Logged In to post comments in this section.
10 - A Masterpiece, Genuinely Groundbreaking 9 - Outstanding, a Must Have 8 - Excellent, Recommended to Anyone 7 - Very Good, Deserves a Look 6 - Good, Qualified Recommendation 5 - Fair, Solid yet Unremarkable 4 - Some Merit, Requires Improvements 3 - Poor Execution, Potential Unrealized 2 - Very Little Appeal 1 - Not Recommended to Anyone