AlexRyder

You can easily compile to both 32 and 64 bit with Unity and release both versions.
 
Also, it's probably time to update from the very outdated Unity 5.5 to the recent version

Lol, dude, I'm the one who made that 64-bit patch XD
And there is not that much outdated API used in the game's code that wouldn't be compatible with Unity 2018, as far as I remember. Probably also some shader code, can't check that with a compiled game.

Lol, dude, I'm the one who made that 64-bit patch XD
And there is not that much outdated API used in the game's code that wouldn't be compatible with Unity 2018, as far as I remember. Probably also some shader code, can't check that with a compiled game.

Uhm, what issues? People on old computers can still use the 32-bit version. And how is GPU even related to the OS bitness?

You can easily compile to both 32 and 64 bit with Unity and release both versions.
 
Also, it's probably time to update from the very outdated Unity 5.5 to the recent version

You can easily compile to both 32 and 64 bit with Unity and release both versions.
 
Also, it's probably time to update from the very outdated Unity 5.5 to the recent version

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

Hey gizmo,
 
I'm probably the one to care about the ignore system the least, but since everyone's so much into it why not do it this way?
The ignore lists are stored and checked server-side only. The client can only request the server if a certain char is ignored or not (true/false). The server should check the ignore lists before sending messages and not send them to those who shouldn't receive them anyway. The server shouldn't also send ignored chars data to the clients who are ignoring them / are being ignored (i.e. room lists, etc.) This way the server can perform any kinds of checks without exposing the process to the clients, so account wide ignore system won't be causing any issues.

It's not possible to read other people's PMs, the server only sends those to their intended receivers, so in order to do that one would have to hack the game server and intercept messages there.
 
It's very unlikely there is a way to read a person's friend/ignore list without knowing their login password either. Probably authentication wasn't needed in earlier versions, but it is certainly required now.
 
Keep in mind though that when you share a game log (in case of a bug report or something), the list of your chars, your friend and ignore lists are also there, so if you just post the logs on the forum, anyone can read those.

Right now the values are saved as (int) = (float) * 10000, which introduces a rounding error every time the file is saved/loaded.
Why not just write raw float values you get from Unity? Json serializer can read/write them just fine, and you can always code a simple custom serializer if you wish to fix values to a specific precision.

373 patch will save values as float. It will also be able to correctly load the old format.

Right now the values are saved as (int) = (float) * 10000, which introduces a rounding error every time the file is saved/loaded.
Why not just write raw float values you get from Unity? Json serializer can read/write them just fine, and you can always code a simple custom serializer if you wish to fix values to a specific precision.

Ok, seriously, why add this:
if (pname == "shell_1") { result = null; } instead of just fixing the stupid sink, it should probably take a minute %)

Giving away ideas too soon. I still wanna embed the CEF browser engine into the game 

It may seem to be the most obvious first glance solution, but then we should think of a reverse situation — when someone holding a grudge on someone else is trying to abuse the system by claiming a fake theft. To be able to verify the theft, the server would need to keep a full history of each single world server upload with a respective timestamp so that a diff comparison could be performed later "in court". It would bloat the server data storage requirements enormously, and still is not error prone due to the fact that a user can work with offline files and the theft may happen even without the server involvement (well, in such case the claim can probably just be discarded, but it still does not solve the data amount issue).

BlackVelvet, what you're suggesting is nice, but knowing the game's code, I'd think it would be easier to just rewrite most of it from scratch than to try and modify it in a way that would be compatible with this solution. Starting with the server code.
Actually, there is a little bit of security in there which requires unique user's credentials for certain stuff, mostly it is used for uploading so that other users won't be able to "inject" stuff into other players' accounts.
But the downloading of any data that needs to be read by random people for the most part lacks any security.
 
What you're suggesting for the world editor in particular would require to invent a couple of completely different incompatible editor/play mode world file formats that need to be so different it won't be possible to figure out how to convert between them in a manageable amount of reversing time (and since all the game's code is client-sided, it is always prone to reversing).
 
 
That is pretty much back to "rewriting most of the game from scratch", or at least the World editor part. Which is an Asset store item by the way
Also, apart from the ridiculous amount of traffic that approach would generate, it's not how Unity normally works. Usually it has a number of predefined resources or assets it can load simply using an asset name, and then you just need to set object parameters like position, scale, etc — stuff that you see in the .world file.
Working with raw meshes is possible, but complicates things by a number of magnitudes (also prone to performance props), so we would probably wait for a new secure 3dxChat 3.0 till 2050 or something
 
There is probably a way to make the server and client exchange a new pair of security keys every time a data package is received, but still not much point in it since the client side executable is not secure.

Unity can easily compile a game to both 32 and 64-bit binaries (for the Windows platform all the game data files will actually be the same and only the player/mono executables will differ).The only issue may be the native plugins which also have to match the client bitness.
3dxChat uses Oculus OVR and BASS libraries, both are available in 32 and 64-bit versions, so there won't be any problems making an x64 version.
 
Actually, I have already made 64-bit patches for the game, you know where to find them

Unity can easily compile a game to both 32 and 64-bit binaries (for the Windows platform all the game data files will actually be the same and only the player/mono executables will differ).The only issue may be the native plugins which also have to match the client bitness.
3dxChat uses Oculus OVR and BASS libraries, both are available in 32 and 64-bit versions, so there won't be any problems making an x64 version.
 
Actually, I have already made 64-bit patches for the game, you know where to find them

Well, a 64-bit client will also allow the game to eat up all of your computer's memory therefore expanding the time before the crash 
With a potential small chance of a BSOD as a little bonus 

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?