The fact that if you want to send complex data between worlds you have to use a file intermediary on both ends seems wonky.
Savefiles are really just an interface to serialized binary data that just happens to be stored in files, but if i wanted to have a variable that stores this that should be an option. If i wanted to send this directly down the wire to another world using world.export, that should be an option.
This all really just exposes one prime limitation in byond, there is no proper way to store binary data in a variable in byond. you'd have to store it as a string (something that has its owns issues) or an array of floats (list of nums)
So some sort of binary value type as well as a way to convert shit to/from it would be nice. (would also be the proper place to put common binary conversions like base64 as well as transforms like Endianness.)
Then you could layer savefiles around that so you can use savefiles natively without an actual file in the works.
and then after you do that, maybe some options about how savefiles are stored, giving the game the option to not compress it to shave that overhead.
and then finally if you documented (or created and documented new versions of) the exported functions in byondcore.dll for handling savefiles, you would have a way to transfer complex data between dlls and byond for moving complex systems (like ss13's atmos) off of byond in a performant way.
ID:2214937
 Feb 18 2017, 2:25 pm
|
|||||||
| |||||||
There would be no point of doing binary anything if it triggers string table lookups.
The end goal i have with this is two fold: Move atmos off of byond to a dll Make clients run a dmb in DS mode for the game, have it connect to the server over what ever (dll, world.export, what ever makes sense) and exchange game state back and forth so we can actually do more client side. I need a way to do serialized complex data in a way where it never touches a string tree or a file, and such that numbers come thru both sides as numbers so there is no atoi() overhead | |
MrStonedOne wrote:
There would be no point of doing binary anything if it triggers string table lookups. So you're wanting players to run a "client" (local byond server) that exchanges data with the server? (actual server) to run "client side" things? | |
yes
| |
You're insane and there's no way in hell that's ever going to work.
But if you want to try I'm not stopping you. | |
I certainly look forward to the test.
| |
I should look at doing such a thing with json just to see how feasible it would be
| |
So, we would have to adopt a project style similar to other client-server games?
SS13Client SS13Server SS13Common ? | |
That far I haven't gotten.
Ideally enough would be abstracted out that there would be ss13server, ss13client, and tgstationcommon, since this would need to be portable to other codebases without clients having to download a new client for each server. but that would depend on what we figured out. a auto-updating client that updated as it connected to servers could work if we ensured byond's sandboxing of ultrasafe dmbs was up to snuff. | |
Well yeah I figured common would be unique to each server, but PJ's here so I opted for "SS13" instead of "tgstation13" even though we're currently having this conversation with a 2/3rds majority :P
| |
I don't see the point, if you're going to rewrite the atmos sim itself in another language, you may as well go all the way
| |
You're proposing a complete rewrite of the client and server at this point.
| |
No, I'm proposing we not have to use a file (and slow disk io) to store serialized complex binary data we intend to send over the network and/or over to a dll.
In order to send a list of datums from one world to another both sides use a file intermediary. There is literally no reason for this to be the case. Arguing about the complexness of the use cases isn't relevant to this thread. Another edge case this could solve: Right now in order to parse ?format=text byond urls you have to save them to a savefile using ImportText() and then read from that file There is literally no reason why that couldn't work in memory and (optionally) a file. | |
If you want converting to/from bytes, DLLs are an easy solution.
Not that this request wouldn't be nice however.