I had asked him about this earlier and he said “because it’s not setup”. It was set as online previously though
Ah yes I wish it was a bit more descriptive
The ones with Unknown are because they aren’t available quite yet. We have scheduled maintenance this weekend to setup load balancers and get those instances up and running.
It would be awesome if you could configure which parts are being streamed, and which aren’t
That’s already how it works. Put what you want in the “ASSETS” folder and what you don’t outside of it.
Oh, wow!
This is perfect for me, I’m trying to build New York City (you should definitely visit New York City, it’s so worth it), and it would cause lots of lag, but this seems perfect!!!
Ooh. I’ve never been but I’m not too far away.
Anyways I hope to see NYC in Roblox. With our infrastructure there should be no problems with lag.
Quick question: Does StreamX support the ModelLevelOfDetail
property?
As of right now, no but it will likely be in the rewrite.
Alright! It would be good since you can combine StreamX with StreamingEnabled so this property would probably be important to those who combine StreamX with StreamingEnabled.
Haven’t tested but I dont know if this is a great idea. StreamX will paste in the parts before Roblox can get to it, and it will cause duplicates.
StreamX Rework Update
Hey developers,
We’ve been hard at work to bring you all a new and improved experience for StreamX. This rework update will include many new features and improvements to StreamX, including but not limited to faster rendering and loading of parts, less downtime, and further instance support (including MaterialVariant, Custom Materials, Meshes, and LocalScripts). Even though this rework will improve the StreamX experience, it will require some action on part of the customers. First of all, customers will need to update their script to the latest version located on our GitHub when it is released. Second, customers must update the assets in their ASSETS folder to include all of the instances StreamX will support. Third, if streaming parts with embedded local scripts, you will need to enable LoadString support. Although if you are not streaming local scripts, or don’t feel comfortable with enabling LoadString, you can leave it disabled. Do note that if you disable LoadString, local scripts WILL NOT WORK.
The actions in this post should not be taken right now, but only when the new version of StreamX is released.
We hope you all will understand and make the necessary adjustments and modifications to keep your StreamX instance running smoothly.
Happy Streaming!
This is going to be the best update in history ever with StreamX.
I know it depends but in the future if its open source, i just wanna know, is streamX optimized for lowend servers?
i know it depends depending on the map you want to put in, but lets say i want a normal map for the service to host in a lowend servers, like 1 gb and maybe possibly 512 mb ram?
In its current state, StreamX is a very load intensive software, so it wouldn’t be a very good fit for low end servers. Each of our instances are running no less than 8 gigs of RAM and 4 CPU cores. StreamX is very RAM intensive because of the database software we use. It also is very CPU intensive because of the algorithm which produces the parts to be streamed. In the future it could even be GPU intensive for Artificial Intelligence and Machine Learning to find which paths the player is likely to take and preload those parts into memory.
When we produce the lightweight version of StreamX, which will be for people to self-host. It will be much more lightweight but will come at a performance disadvantage as it will have a lower functionality to increase support for lower spec machines. But note that we use MongoDB which requires about 1 GB of memory for every 100k parts.
Would it be faster if you have a Xeon CPU? It has about 6 cores and 12 threads with 12 MB cache and max turbo frequency of 3.73 GHz.
Also, as of now its $30 dollars for a Xeon CPU, I have one myself and it’s a really good CPU, its the X5690
To add to what @Crcoli737 said:
Upload/download Streaming Tests
Tested game had 49500 parts.
Current StreamX Performance
Took 6.412 seconds to fully upload all parts;
Took (on average) 0.534 seconds to redownload chunk;
Throttle was set to 30%;
UpdateDelay was set to 10;
Rewrite Performance
Took 3.917 seconds to fully upload all parts;
Took (on average) 0.508 seconds to redownload chunk (had a .8s outlier);
Throttle was set to 10%;
UpdateDelay was set to 4;
Rewrite is around 2x faster for uploading, download is around the same.
(more optimizations to come though)
Configuration Changes
- Part folder has been moved from
ASSETS
toStreamX
-
ASSETS
will continue to work for now, but will be later removed.
-
- Failover URLs have been added for your game to check on
- If the primary server is down, your game will pick the next server that’s available.
-
EnableReuseComp
has been added to configuration- Allows duplicate part computation, which can normalize game performance at the cost of more lag spikes.
- Recommended to leave off for large games, but you have to test it to find out.
-
ChunkAmount
has been added to configuration- The amount of parts to send in each upload request (so now you can bump it up from 1000)
Security Considerations
In order to allow script streaming, StreamX will eventually require the use of loadstring()
. This WILL BE a configuration option and is completely up to the game developer. It’s also worth noting this testing isn’t complete, for all I know I might not be able to stream scripts at all.
In addition, the StreamX payment center will soon have a game whitelist, so you can ensure people can’t use their API key and stream to your game. (which is part of the reason why the release is being delayed slightly)
The release should be coming out soonish*, but please don’t quote me on that.
I spent ages trying to get the backend to work, and so far it seems to be much more stable then the old one.
@HistoricalPooPantsz, a Xeon is perfectly capable of hosting StreamX at full capacity for a couple of games. I’m not sure when we’ll be open source but I do know we plan on sending out selfhosted packages of StreamX for those who want it. The only thing StreamX really needs is RAM; but we’ll most likely have an option to enable compression for MongoDB.
If I could, I would actually buy you guys 128 GB of RAM and send it to you, but I don’t have the money for it sadly.
It’s all good, all three of us are chipping in some to help host this behemoth of a program.
Way ahead of u boss
i got 2x Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
hopefully will be more soon when we get more usage.
Also got 64 Gigs of Registered ECC DDR3 memory
“StreamX v3 is still very much in beta.”