Any updates on StreamX right now?
Yes, I’ve been working on the payment centee which should be done this week.
2 Likes
Hello,
I’m not sure if you guys are aware of this or not, but I did seem to find a bug in the system.
I joined the StreamX and every part was visible in the map and took a minute for the server to respond, then it deletes every part in the game, then 15 seconds later, it starts doing its job properly.
That’s expected behavior. Turn down your refresh time.
1 Like
Will you offer free trails when the paid memberships come out?
No, because people can abuse it easily.
1 Like
Yeah but I ain’t paying for something that I don’t know and I don’t know if I will use it.
We’re going to have the code on GitHub when I get the payment center done. Free trials are just way too easy to abuse.
Something you could try and do is adding a system where it detects the same client trying to get a 2nd free trial and then ban them from that specific URL, but idk.
Not how it works, I’ll talk with crcoli
1 Like
Not possible since Roblox server IPs change very, VERY often, too often to judge a place itself.
2 Likes
Also Roblox didn’t say it “has” to be free
The client side code is open sourced on GitHub right now. So technically the distributed code is open-sources.
The only paid thing is the api key to use it.
Wait but shouldn’t you link it in the topic? I think it needs to be in the topic otherwise people will think you’re lying.
Sorry for the confusion, I was in class.
The GitHub will be published when I finish the payment center.
If you wish to browse it now, it’s at GitHub - darkpixlz/StreamX
2 Likes
According to the client source code, it isn’t encrypted at all other than the default encryption provided by SSL. Are you going to offer any kind of guarantee that parts aren’t being recorded on your servers?
Considering this is Cloudflare we’re talking about, why would proxying anything help your security claims? Stopping people trying to steal game parts thanks to free SSL I understand, but that doesn’t help the actual “security concerns”, ie. the fact that you guys get all part information in plain JSON on the server.
Additionally, have you done any long-term measuring on the bandwidth usage from sending literally EVERY descendant of the assets folder to a Flask server? How are you going to guarantee that StreamX won’t increase loading times when it’s sending this much data to a Flask server (which isn’t handling just one game) every server launch?
Bandwidth Testing
Using your JSON serializer, sending 500 copies of that brick, resulted in using 253kB of data.
Rerunning that test with 2000 bricks resulted in 1.5MB of data usage, and that isn’t a very complicated brick.
Since the default waiting value is 10 seconds, it would use 1.5MB of data (for a 2k brick game) every 10 seconds for each player until the game is shutdown.
So with a 12 player game, with 100 active servers, with 2000 bricks in each server, you get 108000MB (10.8GB) of data usage every 10 minutes of operation.
Mathematics
10 minutes = 600 seconds
(1.5MB / 10 seconds) = (600 / 10) = 60 * 1.5MB = 90MB / 10 minutes per player
90MB * 12 = 1080MB / 10 minutes per server
1080MB * 100 = 10.8GB / 10 minutes per game
It is worth noting that since you guys are streaming parts in/out, it wont be quite as much data as I calculated, but it will still have a very significant bandwidth usage.
The code that I used to generate said JSON (pulled straight from your repo):
local http = game:GetService("HttpService")
local part = game.Workspace.Part
local splitMaterial = string.split(tostring(part.Material), ".")
local splitShape = string.split(tostring(part.Shape), ".")
local propertylist = {
["Anchored"] = tostring(part.Anchored),
["BrickColor"] = tostring(part.BrickColor),
["CFrame"] = tostring(part.CFrame),
["CanCollide"] = tostring(part.CanCollide),
["CanQuery"] = tostring(part.CanQuery),
["CanTouch"] = tostring(part.CanTouch),
["CastShadow"] = tostring(part.CastShadow),
["Name"] = tostring(part.Name),
["Material"] = splitMaterial[3],
["Orientation"] = tostring(part.Orientation),
["PivotOffset"] = tostring(part.PivotOffset),
["Position"] = tostring(part.Position),
["Reflectance"] = tostring(part.Reflectance),
["Rotation"] = tostring(part.Rotation),
["Shape"] = tostring(splitShape[3]),
["Size"] = tostring(part.Size),
["Transparency"] = tostring(part.Transparency)
}
print(http:JSONEncode(propertylist))
So in short, how do you think you’re going to pull this off without long-term issues?
4 Likes
I unfortunately cannot reply to very much because I don’t handle the backend, but I’ll try.
Through our beta testing period, we tested multiple games with StreamX in it.
The storage on our cloud and local instances never ran low even.
I can assure you that once the connection is closed, all details of your game are wiped besides your API key, and there’s no way for us to recover any of it. Eventually you’ll be able to wipe all records of yourself via the payment center, we’re offering a delete key service which will come at a later date.
If we need more storage, we’ll just get more SSDs, which is another reason that starting today you will have to pay for your API key.
The payment center is ready, however it’s not polished enough to let the public have it. Your data in the game will be protected by an encrypted password by the way, so only you will have access to it.
Open Source implies the meaning “free for everyone with no copyright”…
nah i wont be mad about this but this is misuse how is this not taken down?
1 Like
This isn’t misuse. It’s a resource which we are giving out to people, with like 60+ beta testers, the payment center will be ready today