It was actually my fault all along

Bug Reports Engine Bugs
1

see my last post for details of the issue

[strike]Here’s the skinny: I’m trying to convert my cool valve gear animations from server to client-side, but I have a serious issue. When driving forwards for about 40 studs, no matter the speed, the locomotive simply vanishes and anyone sitting in the loco gets a white screen. The really weird caveat is that driving in reverse can be done indefinitely with no problems. The errors started occurring when I switched the animation from a script to a module.

It appears that the conventional rule that the tree with the smaller mass gets moved according to the larger mass tree is reversed when traveling forwards: instead of the small, animated parts getting moved, it’s moving the entire train.

To see this happening you can go to this place: [NEW locomotive] Railroad Technology Demonstratio - Roblox

The locomotive with the issue is the one with the colorful rods (it’s the one in the thumbnail), it has the module script in it. The other one animates as part of its main code and has no problems.
[/strike]

2

any news on this?

3

I got into the front train and reversed until I connected to the rear train. After driving forward for about 5 studs, the train did indeed disappear and gave me a white screen. So I can verify this isn’t just you.

EDIT: If you put it on full throttle forward and jump out really quick, the train will disappear along with the server having a huge lag spike. After that, there is a massive shadow caused by nothing that randomly appears.

Example of the shadow:

L78YI5K.jpg1920×1017 169 KB

4

the shadow isn’t just you. I believe it occurs to whoever is controlling the physic when it goes.

5

I spent some time looking at this and it isn’t related to FE. If you disable FilteringEnabled, the train still explodes. I dug through the scripts some and it’s caused by the animate() function in the ClientModule. In there, the speed is getting set to #NAN. I didn’t look through the math too deeply to figure out what’s causing that, but doing math with NAN and then setting CFrames using the results never ends well.

6

I also did some looking and I also found that it isn’t related to FE, it’s related to the module somehow. I tested it with the server controlling the module and it still messed up. Before, I had the code integrated with the main script (server side) and breaking it out into the module is causing the error. I will definitely be doing more investigating, but it seems that I was hasty in putting the blame on Filtering. Currently, the (believed) cause is the module.

EDIT: continuing the investigation, putting the code back in the main script isn’t the issue. Right now I’m checking to see if the cause is updating it on Stepped or RenderStepped and putting it on a while wait() do loop

EDIT 2: it lasts for a longer time but it still is not the cause, it seems.

EDIT 3: I am going to be pouring over the differences between what I have right now (which I expected to be in a configuration the same as the last known working version) and the actual last known working version.

EDIT 4: the first difference that caught my eye was the difference in calculating the delta time. The known working version (which I confirmed to work) uses

local dt = wait()

while the trouble version uses

t1 = tick()
--loop begin
t2 = tick()
local dt = t2-t1
t1 = t2

if tick() is not precise enough, it may return a delta-t of 0, which potentially is causing these errors.

EDIT 5: somehow that still isn’t it

EDIT 6: I believe I finally found it: a half-assed attempt to better-handle cases where the train travels a great distance in a short time (i.e. because of latency). Below is the code in the working version:

if LeftAngle > 2*math.pi then
	LeftAngle = LeftAngle-2*math.pi
elseif LeftAngle < 0 then
	LeftAngle = LeftAngle+2*math.pi
end

and here is the broken code:

if LeftAngle > 2*math.pi then
	LeftAngle = LeftAngle-(math.floor(LeftAngle/math.pi/2)*2*math.pi)
elseif LeftAngle < 0 then
	LeftAngle = LeftAngle+(math.ceil(LeftAngle/math.pi/2)*2*math.pi)
end

the additional irony is that the original edit 6 (this is edit 6.5) included a broken [code bbcode tag
The irony is that I do not even think I need anything more complex than the working version, even if the loco travels a great distance in a single frame. In my head, the working code will automatically decrease or increase the angle every frame that the calculated angle is outside of [0,pi] and wind up in a couple of frames within that range, and that forcing the value to be within the range immediately is not absolutely necessary.

EDIT 7: edit 6 is correct, that difference was the entire reason. case closed

CodeWriter, thanks for inspiring me to take another look at the problem like I should have, and I’m glad that I got it all straightened out finally.