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.
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.
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 to StreamX
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.
I’ve updated the payment center to allow mobile traffic. Please note that you should still use desktop for all things in there, but it works fine and you can get an API key.
The current beta code is very inefficient. I’ve been working with @anon61048460 to make the v2 code much cleaner, efficient, and easier to understand for the end user.
