more notes

get the objectbuilder then serialize to xml

write the object builder to global storage read it from global storage

not quite, basically store a ship client side, delete it, then on connect if that file exists pull it up and spawn it in

you might not want to write the object builder then byte encode it instead.

How it would probably work is admins (of cooperating servers) have a shared key stored server side. When a player in a ship enters a departure zone, the server generates a code based on the shared key, and that is written most likely to a file client side. When a player joins a server running the mod - it checks client side for a transfer file. The client side then sends the file server side, the server then checks it against the key (however it encodes) and if the key checks out, spawns the ship in, ideally also pulling the player into the control seat

anyway phoenix a simple reversing of the byte order will probably be good enough. but keep in mind anyone can have access to the source code of your mod so they will know whatever you do and should be able to replicate it

still write it as binary because you should ship it to the server binary encoded huge .xml files are not fun for networks

just call .GetObjectBuilder(true) on the IMyCubeGrid then pass the result to rexxars seralize to binary. MyAPIGateway.Utilities.SerializeToBinary(grid.GetObjectBuilder()) that will give you a byte array representing your grid do note, that will not capture sub-grids attached by pistons and rotors you have a 4kB limit what I would do is take that array, invert the order, then write it to disk that's enough to stop most tampering

or actually you dont have to because it will persist in memory between server sessions so you could just hold it ina variable then send it to the new server.

security? 1: Shared key server side. 2: timestamp/time limit that discards files older than a few minutes 3: binary file

not really useful for this project, but here is a code snippet that took me a year to figure out how to do, for file operations, note its saving in the global file tho only handy for a file that all mods need access to, but handy if you need to read/write persistent data for a mod you make between reboots

(edit for formatting)

string text = "Test"; //write out crap using (TextWriter writer = MyAPIGateway.Utilities.WriteFileInGlobalStorage("test.txt")) { writer.WriteLine(text); writer.Write(" another test"); writer.Write(writer.NewLine); }

//read in crap using (TextReader reader = MyAPIGateway.Utilities.ReadFileInGlobalStorage("test.txt")) { text = reader.ReadToEnd(); MyAPIGateway.Utilities.ShowMissionScreen("test", "", "file operation", text, null, "Cool"); }

[SE] rexxar - Today at 4:46 PM public struct Grid { DateTime Timestamp; byte[] Payload; int CRC;

public Grid(byte[] payload) { Timestamp = DateTime.Now; Payload = payload; CRC = payload.GetHashCode; } } then serialize to disk and you're done

[SE] rexxar - Today at 4:43 PM what I would do is take that array, invert the order, then write it to disk that's enough to stop most tampering

so we pass that data to the server, it uses our secret shared key to alter it, then passes it back, write that to file with ship client side next problem is if servers are in different time zones the time stamp would be the second line of defence, ie, to stop someone copying the file between server worlds connecting if the file is too old, its rejected

For the time stamp to be useful tho need a way to syncronise times; i guess admins could be advised they need to configure a gmt offset or something in the final mod so timestamps can be trusted without timestamps we have a file that cant be tampered with, but it still has a potential duplication exploit any thoughts ? We could make the timestamp visable to the client side of the mod, and auto-delete old files instead of forwarding to the server. But that makes the timestamp a weak point. Only sending crc info to the server tho means ship must be spawn client side, which gives us a security risk again