[enh] Transport hub

[jpcsupplies]

Ok, all my mad science tests on this are done, and I think I may be able to use it.

Basically: In the backstory of the MOTD - Miners are being transported (as passengers) to the Blue Mining Inc Base near Jupiter. (This means no ship of their own) This means the server hopping code I was testing could be used by players to "catch a ride on a passenger ship" to another sector. (connect to another frontier server) Basically we build a space station with some ships perminently docked there, on those ships we have a button or just an LCD showing a command line code or a list of codes, which when invoked by a player, retrieves a steam server address, and runs the connect to server command with that server. This from a story perspective can be explained. (ie the no ship part) Only downside here is ideally the player should have a way to access at least his/her money on the new server. Short of generating some hash code we get them to write down and invoke on the target server (like the old game console "save codes") which would be open to abuse unless we had some way to prevent more than one use, and this would not change balances on the other server; there is no way to do that. This could work however, if we allow a player to create a code that /converts/ his balance into the code - but in return all or part of his balance is then removed. This would work similarly to cold wallets in crypto currency.. but the challenge remains how to make it only usable once.

Second option here is in-system transport. Some sort of scripted way to catch a lift in-server to a location (such as another trade base) this could work as a player teleport event, or a jumpdrive event, or getting in a cryo and logging in later having arrived, after auto pilot flies it there. This scenario has been tested too, I set my blue mining ship auto pilot at 1 million metres to fly to blue mining, got in a cryo and logged out. It was at the nav point the next morning.

Third Option - Evil incarnate. The player catches a ride to "another server" in his own ship - but makes use of a certain client caching limitation which permits him to paste in his ship on arrival.. in effect travelling to the new server in his old ship. Assuming both servers run economy this opens up certain interesting possibilities - When invoking the transport event on server 1 1: Clears the players bank balance on server 1 2: Applies some special code to the ship name representing his bank balance. 3: removes the ship into memory/cut-paste buffer etc. 4: initiates the connection to the new server 5: New server(2) Somehow detects either by player invoked command, or the cached things... that he should have arrived in a ship. This triggers the script to use a certain client cache limitation to recreate the ship in the new server 6: the economy mod scans the created ship name detecting the bank balance code, and applies it to his balance on server (2) and removes the code from name 7: the mod then removes/alters the cached instance so he cannot join another server and get his balance there too.

Advantage is it is semi-transparent to the user. They dont need to know about the code. It just works, and cleans up after itself.

Disadvantage is it makes the "process" involved a little more obvious to anyone who disects the code. There is also the danger of an offline server resulting in the loss of your fortune - although if they reconnect to the original server having failed to connect to the new server, the cached ship should still be readable and recreate his/her balance.

Although given we can make certain client side assumptions with the client side code of our mod - it is likely that it only connects to another economy running server; and the option for travelling in ships on or off could be an admin setting anyway.

Even if we dont add this option to the economy mod, i think it is worth making a proof of concept mod to try testing it out.. it sounds kind of cool..

[midspace]

Closing accounts, or at least removing all balance wouldn't be advantageous if the player has a market.

As discussed previously, this wouldn't work currently unless both servers are running on same server instance. This allows both running game servers to access the same file storage.

All the steps listed above would work. I'm going to suggest some changes, and how it would technically work.

1. [Player] Initiate transfer command. Optional commands to transfer all bank balance or a part of the balance. Optional commands to transfer currently occupied (and owned) ship. Optional commands to transfer all other owned ships/stations.
2. [Server] Player is ejected from ship (required).
3. [Server] Command copies specified ship grids.
4. [Server] Details or bank balance and ships are stored into a common .XML file accessible by the same mod, used for transferring to a different server.
5. [Player] Initiates player to connect to new server.
6. [Server] deduct bank balance, and delete ship grids.
7. [Server] Server save game.
8. [Player] Player connects to new server.
9. [Server] Player spawns.
10. [Server] The sequence that runs at the same time as MOTD, would check the common .XML file for a transfer for that player.
11. [Player] Prompt user to transfer onto that server.
12. [Server] Ship grids would be spawned in available free space.
13. [Server] Balance would be added to server.
14. [Server] Server save game.

This process allows some guarantee of prevention of loss, or duplication. Also, they can change their mind, and join back on the original server. One issue with this is, the player can find a different spawn location on the same server and use this as a method for relocating everything for free.

[jpcsupplies]

I understand the same physical server thing.

For option 3 I was more suggesting we try (as a seperate proof of concept mod at least) to use a certain game "bug" in order to drop in a ship on a physically seperate server - but one which has been designed to permit such an action. (avoiding the odd ownership glitches that said bug normally causes by catering to this scenario) Because we are in a controled environment (as a proof of concept) we should also be able to do things like encoding extra info in block/ship names etc. too

Most of the really cool mods on workshop, huds lcd movies, explosions special effects, animations etc are all exploting wierd glitches or adapting things unusually to do something new unexpected and cool.. Like Draygos mod, I said entry effects would be cool, everyone lamented the lack of access to special effects, and I suggested an invisible floating light source.. thus Draygo now has entry effects.. which look pretty good given how they are created (with invisible floating lights!)

I was proposing we try something similar with the one glitch we are aware of that has previously only been used for trolling, and make something useful out of it.

Either keen will then cater to the ship to server scenario better - or fix the glitch. Either way a win for us.

[jpcsupplies]

Ok Ignore my last reply entirely, something just occurred to me.. after a few nights sleep, and messing around with my gateway lobby mod...

Correct me if I am wrong, I may have mis-understood your post - but putting aside the same physical server idea for a moment. (you heard me!)

But if that "xml file" is instead saved /locally/ on the players computer /client side/... instead of server side.. maybe with some optional hash or passkey or other unique ID representing the server group this file is valid for... On connect once we have our server-client link up we could on confirmation that our unique ID is legit by the server, then pull up that XML file, and inject it to the server for spawning the ship. Once spawned the xml file is purged client side.. to avoid duplication exploits.. we could even add a simple CRC check to confirm the ship data wasn't tampered with.

The server would probably need to have a designated "arrival" and "departure" zone (similar to my gateway lobby mod) for spawning the player or ships or for departing from the server - and some logic to prevent ships overlapping.. It would also need a strict block limit for the size of departing ships to avoid death star sized arrivals killing the server...

Now.. money wise --- how about bank balances work like each sector is managed by its own bank (which it sorta is) and to take money with you to another server, you specifically need to SPECIFY how much money you want to carry with you.. eg a little like #140 but probably a bit less secure.

The money transferred could be part of the /depart command as an option.

Since the possibility of exploiting this is an issue, we may need to use some crude RSA or simpler CRC algorithm to encrypt/validate the balance... but if this is only for transfers between collaborating servers, they could have a shared private key.. which is only kept server side and clients never see- this limits exploiting to server admins.. which I can live with - and is a lot simpler than all the other crazy hacky ideas ive been playing with..

I think this is F^&%&^%* do able... this could be epic! At the very least the money transfer thing could be done right now - all we need to do is add a server side xml field for the private key, and knock up a simple code/decode routine from stock RSA reference code. We could even expand it to transfer entire player trade zones if we are feeling ambitious.

Ideally the ship transfer part would make more sense in my gateway lobby mod, since a lot of players/admin want ship transfers and dont care about economy.. but we could add it to economy and just as easily make a stand alone version.. or vice versa..

Thoughts? Am i the only one finding this idea rather exciting a prospect?

[midspace]

Two ways I see this.

If the multiple world were run on the same physical box, then ship and bank information can remain on the server. They are simply shared by way of mod file sharing. No data is kept on the player's machine.

If the multiple worlds were run on different physical boxes, then ship and bank information will have to be stored on the player's computer, as a temporary transfer mechanism. CRC and RSA are insufficient, as there is nothing on the destination server to validate it against. It has to trust the data that player hands it. This is a big no no. PGP is your friend here. Each server must have it's own private key, and a public key that it has to provide to all other servers.

If the player is transferring to server A, we'll encrypt the data packet for server A. There is no hacking, or messing around then.

You'll need an open source PGP library that can be included into the mod code (licensing conditions). And, there is the possibility it will rely upon low level encryption classes which will not be whitelisted for use in the ModAPI. And finally, any security related call will not be performance friendly. It will have to be executed out of the main UI thread.

[jpcsupplies]

That's what I hoped to hear - Sounds like a confirmation - unlike my other wild ideas this one has nothing specifically preventing it from working .. other than performance. That's what i suspected. The ship porting code is beyond my abilities, but encryption on the other hand is something ive messed with before.. just never in C/++/#. If I have the time and concentration I'll see if I can come up with some proof of concept money transfer formula, or adapt some reference code.. doesnt matter if encryption isnt whitelisted.. pretty much everything can be coded using vanilla math if you know the basic principle of the formula - math certainly is available.. even if it just generates a code they have to write down and type manually for the sake of the test.. Just dont hold your breath my time and distractions are pretty random.. and numerous - might take me a while. Should be fun tho (in a geeky nerdy programming sort of way... or is that just me... lol)