complexoJoin Date: 2009-01-07
Post Count: 1547 |
How do I do this?
The Changed event seems to not fire for changes in this property. |
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
loop |
|
complexoJoin Date: 2009-01-07
Post Count: 1547 |
Anyone whose first answer to a problem is a loop to keep checking a property should probably not be scripting.
I see this way too often, and it's grossly inefficient. |
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
No it's not, and have fun finding another way for this |
|
|
Loops might not be pretty, but they aren't inefficient.
|
|
|
complexoJoin Date: 2009-01-07
Post Count: 1547 |
I find it hard to believe that there is no way to listen for a position change. |
|
|
I find it hard to believe that a loop is as inefficient as you think it id.
In the outside programming world, you need to use loops all the time. Events don't exist for everything, same as in Roblox.
The reason why the changed event doesn't fire is because the changed event doesn't get fired when a property is changed in the C++ code.
C++ changes positions, rotations, and so forth because it's the physics engine.
If you did part.Position = Vector3.new(1, 2, 3) then the Changed event would indeed fire.
|
|
|
when i was beginning out in scripting, i thought loops were to avoid, and they are but that doesn't mean they have uses other then being "inefficient", they are only as inefficient as you make them. |
|
|
"Anyone whose first answer to a problem is a loop to keep checking a property should probably not be scripting."
Anyone whose first reply to a serious answer is an ad hominem should get out.
|
|
|
"when i was beginning out in scripting, i thought loops were to avoid"
Indeed, I see it way too often. Novice scripters thinking that infinite loops are not an okay thing to have.
|
|
TaaRtJoin Date: 2009-04-26
Post Count: 5070 |
It's funny though that events are based on a looped polling mechanism with attached handlers; calling loops as practice bad while relying on them as alternative.
Also if .Changed were to fire each time a positional property changed it'd be impossible to handle for every instance that isn't anchored in any decent size game. |
|
|
Its a misconception that loops are to be avoided; inefficient loops are to be avoided, not all loops.
Like if you wanted to check if a part changed from anchored to unanchored I wouldn't recommend a constant check with a loop because an event is more efficient. |
|
|
"It's funny though that events are based on a looped polling mechanism with attached handlers"
I was going to say that, but I wasn't sure.
Wouldn't it make sense to just fire it directly? Surely the C code can detect when Lua tries to change something and then fire related Lua events? Or does it still get compiled to machine language as a looped polling mechanism? I only know the bare minimum of how assembly works, but I'm pretty sure that it doesn't get compiled like that?
|
|
|
Hope this helps ;
x:GetPropertyChangedSignal("Position"):Connect(function()
end) |
|
TaaRtJoin Date: 2009-04-26
Post Count: 5070 |
@Jarod I'm not sure whether it's a very satisfying answer, but loops in assembler are goto lbl directives; the result in machine code are sequential with each step 1 instruction for the cpu to execute. If you were to make for instance an endless loop in C
for(;;){
a++;
}
in asm, the result will look similar to (leaving out a lot of non-relevant instructions)
L2:
addl $1, 12(%esp) // add 1 to the register we store the int
jmp L2 // goto label L2 (above)
So in short, I'm not sure whether that answers your question, since in a way the result is a continuous check for the property state within the game. The main difference is that the loop that checks it is compiled and the results are forwarded in run-time via the Lua virtual stack |
|
|
I realise that, but the question is, why loop at all?
C handles all of Lua, and when a property is changed in Lua, C knows about it. More especially since Roblox Instances are created in C. Thus, when Lua wants to change the Transparency property, C knows about it immediately, it kinda has to or the game wouldn't work. And if C knows about it immediately, what's to stop C from immediately firing some events in Lua, with no loops involved?
|
|
TaaRtJoin Date: 2009-04-26
Post Count: 5070 |
That all boils down to where the loop is, really. Any C-program while running is a looped state machine basically or it only executes once.
In its essence you are right though, there's no loop between C noticing the change (apart from the program listening to the interrupts from the OS for user input, but that's OS-dependent as well and more complicated than I make it sound) and the program (after determining the user input changes a property) calling another C-method to push a Lua function onto the virtual stack (as handler for the given event).
Note that there is more than a single virtual stack (presumably 1 per script) and said method has to figure which Lua environments to push it to
In the end, any program is looped (or executes once), handling events is within such loop but the action of reacting to the events itself is not an additional loop |
|