AlexRyder

Uhm, whoever came up with the "Oasis" name apparently never expected people to actually try googling for it. Especially after the "Ready player one" release %))

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 %)

The game doesn't use cache.

I have tried Curio, but it was laggy and buggy as hell. Also, they're using this stupid CCBill payment system which doesn't accept cards from Russia. Well, I guess I could poke into Curio's dlls to see how it's made, but their code base is really huge, can be hard to find anything specific %) From the page you have provided it looks like they're using a web wrapper hosted on their server to process your urls, so Unity only need to know how to play streams from their site, and their server handles the rest. I may be wrong though.

I didn't say this is impossible Do those players synchronize web browsers (including navigation and stuff) or only videos? (Or maybe they require direct video urls?) I have tried playing with video playback and synchronization a bit, and so far only YouTube has been reliable since it has public API to control the video playback. For other video sites you need to reverse the scripts and figure out how to tap into their player controls, and yet that may still not work, or the API can change frequently. For now the most reliable way for me seems to use a combination of a web browser to browse and an embedded VLC engine to play selected videos on TV. The browser part should be able to parse pages to get direct video links, and VLC should handle video playback and synchronization. This is also not very reliable and will require writing parsers for each specific page, but should at least allow to play/stop/seek videos. Another approach would be to have partner agreements with video site so that they would provide an API, but this is something for SGD to think about

Embedding a browser is the easy part. Synchronizing it between clients - that's the tricky part.

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).

Unity can do that, but the whole point of Unity is mostly to free the developer from dealing with all that low level stuff and just use the user-friendly editors and API It's possible to just read the triangle and vertex data and store it as an array or something, plus add object properties, colliders, materials, etc., etc... Instead, it would be easier to just serialize the object using Unity's internal system, but you should be ready to send and receive 500...1500 Mb data packs every time you save or load a user room then Point is, most of those safeguards rely more on bans and legal prosecution rather than trying to make an unhackable security system. This can be easily simulated, or one can just use the vanilla client to manage this stuff.

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.

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

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

Uhm, with some coding. Though if you're asking how I got another person's room — they are all publicly available since they need to be accessible when you share a room. It is possible to simply download the room file in a browser with a POST request plugin installed.

This room also loads fine. Looks like a default one though.

There is nothing wrong with the room file. Unless, is "Kisha" the correct character name? I'm not quite sure I got the message right.

Default game executable is a 32-bit app and can't use more than ~3 Gb of memory in any case.

The room file for character "Kisha" is fine (or at least it's a valid JSON). I would think that your game runs out of memory, but the file is not very big either, weird...

There are some functions in the Object selection scripts that allocate small arrays or lists and re-sort objects on every frame, which may overload the heap faster than Unity mono's (pretty outdated) garbage collector can deal with. You can try using the x64 patch, it will allow you to use more memory, though no guarantee it will make any difference.

Is it the "Runtime Editor" by Vadim Andryanov you're basing the World editor on? Looks very like much it, but I'm not quite sure... But the gizmo handles are certainly from this publisher https://assetstore.unity.com/packages/tools/modeling/runtime-editor-64806

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

All looks super awesome I suppose you could also add a mirror material

I have been playing around with adding full browser and video support to 3dx, lol O:) I've tried using Awesomium with a modified AwesomiumUnity as the base engine, but the major issue with it is that Awesomium is so seriously outdated it has problems opening web sites. Was thinking of integrating CEF (Chromium Embedded Framework) instead and playing videos using VLC libraries, but hasn't had time to try it... The main idea was to have support for most of the well-known video sites and for the videos to be synchronized across users (i.e. if the room host changes the video position, it should be set accordingly for everyone in the room, etc.), and that is not possible for every site, but should be doable with VLC. https://i.imgur.com/Gg2RWOp.png https://i.imgur.com/kL8dJi2.png A little preview, be wary it may have some porn in it. Also, the recording is kinda laggy https://www.youtube.com/watch?v=G-YNOOPIv5M Unity has built-in video support since version 5.6, but its features for online playback seem to be pretty basic...

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials. There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.). Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

It's not like anyone is forcing you to go there. And how is it even related to tech support? XD