Juno: New Origins | You can't set input to broadcasted data.

Set 2 command chips on a single craft.
Set a program on command chip A that braodcast [throttle] with [input:throttle] to craft.
Set a program on command chip B that recieved [throttle] with [data] -> display [data] -> set [throttle] to [data]
Set an engine controlled by command chip B

Observe the display block correctly displays "throttle" input but the engine connected to command chip B doesn't fire.

This is not a problem of broadcast or recieve block: If you change the last block to set [throttle] to [1] then the engine fires with full throttle when you input throttle on the command chip A.

Bug Done Found in 0.8.500.0 Fixed in 0.9.202.0

Sandbox	View

4 Comments

Log in to leave a comment
9,660 AnotherFireFox

@AndrewGarrison Glad to hear that!

+0 4.8 years ago
Dev AndrewGarrison

We should have a beta out soon and you can try your code with my new changes. At the very least you could see if the thread queue is filling up. You can also increase the maxThreads attribute on the FlightProgram modifier on your craft. Currently, it is set at 50.

+1 4.8 years ago
9,660 AnotherFireFox

@AndrewGarrison Glad you were able to repro this problem. I followed your solution, which made it almost solved, but not completely. With this craft and your solution I can relay throttle, translate up/forward/right but can't relay pitch/yaw/roll. This also needs the REO of this version.

PS: I didn't delete CM Command Pod's other codes than in question. Deleting all other codes but the code in question resulted in far less frequent input relay. Maybe this is also related to the filling the thread que problem.

+0 4.8 years ago
Dev AndrewGarrison

I was able to repro this issue with this craft. The problem (in this case) is one command pod is generating messages faster than the other command pod can receive and process them. This causes its thread queue to fill up which prevents new messages from ever being processed.

I've fixed this by capping the thread queue size and spitting out an error message when the thread queue is full. However, this can also be addressed in your program by limiting how many broadcasts you do per frame. Ideally, you should not broadcast this "throttle" message more than once per frame. You can accomplish this using a "Wait 0 Seconds" instruction between subsequent broadcasts.

+1 4.8 years ago

1 Upvote