error code on netplay

[BuiiBuii1]

[jackpoison-prog]

Thanks for the screenshot — that is not a netplay error code, which is why it looks so strange. Aux FIFO not synced comes from the GPU FIFO code, and it can only fire in a mode this port switches on specifically for netplay: a deterministic GPU thread, which is what lets netplay run dual-core instead of the single-core it used to be forced into.

So it is netplay-related, and it is on my side rather than yours.

A workaround you can use now: set RINGOUT_NETPLAY_SINGLECORE=1 before launching. That turns the mode off entirely, so the warning becomes impossible. It costs roughly 12% netplay performance, which is the trade until this is fixed properly.

I could not reproduce it here — 8,000+ frames with that mode on, plus opening the in-game menu mid-session, stayed clean — so three questions would help a lot:

1. Are you running on Linux, or through Wine/Proton? The dialog in your screenshot looks like Windows, and there is no Windows build, so knowing which changes the answer.
2. Did it happen once, or does it recur? If it recurs, does it need a particular moment — a stage transition, opening the pause menu, one player pausing?
3. After clicking OK, did the game carry on, or did it desync or freeze?

The next release also writes a netplay log to userdata/Logs/netplay.log, so if you hit this again after updating, that file will say a good deal more than the dialog can.

[BuiiBuii1]

RingOut.log
every time i connect on net play it give me this error code i show above i been using the window fork https://github.com/Ell/RingOut
after clicking okay it bring up the same error message 9 times then crash the game
also how do i put in RINGOUT_NETPLAY_SINGLECORE=1 code?

[jackpoison-prog]

Thanks for the log — it changes what I told you earlier, so let me correct that
first.

The log doesn't contain the error at all. There's no Aux FIFO not synced
line anywhere in those 1173 lines, and no error or panic of any kind. What it
shows is the match running to about frame 703 and then:

netplay: connection lost
netplay: session ended because the peer connection was lost

with a lot of horizon fallback: waiting for authoritative input before it —
that's inputs from the other player not arriving in time, which is a network
symptom, not a GPU one.

And my suggested workaround wouldn't have done anything for you. Line 19 of
your log already says:

cpu/gpu threading: single-core (safe default)

That's exactly the state I was telling you to force. So whatever is producing
your dialog, it isn't the deterministic GPU thread I blamed.

The other thing I missed: you're on the Windows fork
(github.com/Ell/RingOut), and its netplay is a different implementation
from mine — the rollback live and horizon lines in your log don't exist
anywhere in my code. So I can't fix what you're hitting, and the maintainer of
that fork is better placed to read it than I am.

To answer your actual question anyway, for future reference — on Windows you'd
set it before launching, in PowerShell:

$env:RINGOUT_NETPLAY_SINGLECORE=1

or in a .bat next to the exe:

set RINGOUT_NETPLAY_SINGLECORE=1
start RingOut.exe

If you want to keep digging here, two things would help: whether that log is
from the same session as your screenshot, and the full text of the dialog. If
the log is from a different run, the one that produced the error is the useful
one.

[jackpoison-prog]

Worth retrying this on 1.6, if you still have someone to test with.

https://github.com/jackpoison-prog/RingOut/releases/tag/v1.6

I want to be straight with you: I never reproduced what you saw, and your log showed the connection dropping rather than the error in your screenshot. So I'm not claiming this is fixed. But two things changed that could matter for your case:

1. The audio DSP thread is no longer chosen from your CPU's core count. It was, which meant two machines with different numbers of cores ran audio emulation differently during a netplay match. That's exactly the kind of thing that shows up as an unexplained drop rather than a clean error.
2. Compatibility is keyed on the release version instead of on where each binary was built, so two machines both running 1.6 agree by construction.

Both players need 1.6 — mixed versions are refused on purpose.

If it still happens, the most useful thing you could send is the log from both machines rather than one, since a desync only shows up as a difference between them.