Ok, maybe it isn’t because of that. But its kinda like this:
--here is a remote event for firing protectiles because its a shooting game (and it causes extreme lag)
coroutine.resume(coroutine.create(function()
while task.wait() do
for i, v in pairs(game.Players:GetPlayers()) do
--a bunch of stuff like reloads and stuff
end
end
end))
while task.wait(1) do
for i, v in pairs(game.Players:GetPlayers()) do
--a bunch of stuff like unlocks, upgrades, stuff
end
end
end
it’s all in one script pls help should i separate them?
Hi. Thank you for responding, but someone introduced my to Script Performance windows and it helped A LOT. I found it’s actually from the client and sometimes it take up up to 20%! I think it’s because of a very complex function which has lots of other smaller functions in it with lots of for loops. Thanks for replying!
Hey, it seems like the beta is completely broken (unless behavior changed?). Running @Elttob’s raytracing demo crashes for me: RaytraceWithLibraryDemo.rbxl (27.6 KB)
I have decided to take a look at this myself, my PC can handle it without crashing due to the error spam, here is the cause error.
GetService appears to not work with this system, not sure if it’s bug due to me knowing nothing about this.
They actually have been usable in live servers, and also a ton of other properties have been labeled as parallel-safe to index - it’s just that staff almost always forget to update these posts
To clarify though, parallel lua is enabled in live servers through fast flags - you shouldn’t use them in live games yet, since the fflags could be disabled at any time, and your games would instantly break.
I swear this shouldn’t be in beta and should be in something eariler than beta, because I’ve crashed at least 15 times in a single hour when I tried to make a UI renderer using raycasts.
For example: Making a thread for each collum to render all pixels in said collum, but of course when I try and click playtest, it just crashes with no error message at all.
I have some feedback, Actors are not great to use.
Actors require the script to be inside it, meaning exploiters can clone the code that is within the actor.
Please make it possible to tie actors to scripts without them needing to be a child of it.
Are there any plans to introduce some way to store atomic data so multiple threads can act on it? Not being able to do this seems pretty limiting with the need to drop out back into serial execution to be able to do much of anything.
Yeah I understand why you can’t but like, my brain runs so many circles trying to do anything really useful on actors without having to immediately re-serialize to do anything
Honestly if actors are already basically models can’t we just put parts and stuff in them to act upon? that’d be pog, idk if that’s viable lmao my brain is too small
I would love to be able to do computing on the GPU in Roblox.
Things like machine learning and intense math are currently too slow, even with all the Luau optimizations.
I’d love to do simulations and machine learning if Roblox ever allows parallel GPU computing.
Edit: You actually can do GPU computing with Node.js JavaScript.
JavaScript math function gets JIT compiled/interpreted to a GPU shader and then computed, returns the result right after and it’s pretty fast.
So I don’t see why this couldn’t be done in Lua.
Python is incredibly slow comparing to anything and yet AI, ML, and data science is conducted using it (I don’t know either man) so it shouldn’t be a problem.
The problem is why, their servers probably don’t have GPUs and you can’t guarantee the client has one.
That’s really smart actually, it’s somewhat like a mutex.
Mutex means mutual exclusion, and it allows a value to be mutated or changed in other words exclusively by one thread, the way it works traditionally is for the thread to place a lock on the mutex, which tells any other thread that this data is currently in use by another thread and to please wait till the lock is lifted.
So if scripts in actors could only change properties of instances inside their actor and they could change the parent of instances to their actor somehow the problem would be solved, of course unless actual mutexes are implemented.
The actual heavy lifting and training code isn’t in Python, it’s usually in C/++ or a faster language. Python just serves as a nice interface for quick designing and prototyping. It’s not unlike how Luau is a nice interface over the Roblox engine.
With that said, this process also seems unfit for Luau because you don’t get those native bindings with it and the ML ecosystem is non existent.
If GPU computing through Luau is somehow not possible, it is still possible to do it through HLSL or GLSL shaders which are quite easy to interpret/compile at run-time as far as I know.
Really wish Roblox allowed us to do GPU computing and custom shaders through HLSL and GLSL for developers who want to get more into graphics or generally use more math/GPU acceleration for intense tasks in games.
Shaders and GPU computing are slowly becoming a must in the modern day of game engines and such now.
Not only machine learning and graphics but also things such as inverse kinematics, physics and other simulations could be calculated real time on the GPU using shaders or parallel computing and gives the CPU so much more breathing space for important and bigger tasks.
Yeah, and I was honestly surprised this isn’t how it’s already handled. Actors were first described as being derived from Models, so my guess was that anything in an actor was actor-locked.
I’ve been trying to make a sort of low-res raytracing system and so far I’ve not found it at all easy to run this on different threads due to the need to exit back to synchronized to change any ‘pixel’ ui color.
With Actor acting more like a folder for restricted use like mutex, I could really easily divide the raytraced screen into actor sections which then otherwise would literally need no code change to work with multiple threads, as they can basically just handle the pixels identically and change them as needed out of sync. It’d be so lovely.
Well that’s true, I still think that a higher level interface isnt’ necessary and that it’s enough to just use the lower level langauge and cut the middleman, but it’s unsafe of course, as you can’t sandbox C/C++ as easily and buffer overlow/indexing out of range can easily cause security vulnerabilities.
So it’s really out of our hands to do this without Roblox taking charge, which, you still can’t verify that the client has a GPU and Roblox servers probably don’t have GPUs, you might still be able to implement it with Luau by downloading it on its own and writing C/C++ to do the heavy lifting and using an FFI (which there are many for standard Lua which could work with Luau with some [significant] tweaking).
Any chance to get at least, e.g. Actors on live servers?
