Closed WikoCode closed 1 week ago
Hi, Thanks, your welcome.
So it must certainly be that the game is using the wrong interface for discovery.
I don't have feedbacks from people using hamachi yet so the first thing i would do if it is possible for you would be to try with radmin as it is known to work.
I would need the output of the terminal openned by the scc_lan_helper program when doing discovery.
Now to debug further more you will need to install wireshark on the pc discovering and capture on all interfaces and filter for udp packets with port 46000 while doing the search for hosts session. When you catch a packet the source IP would the IP of the interface used by the game.
-------- Message d'origine -------- Le 9 mai 2024, 23:03, Giorgi Tsiklauri a écrit :
Firstly, thank you for creating this for a very nostalgic masterpiece, pretty cool of you to give us a chance to play co-op in this old but gold game.
Me and my homie did everything that was written in your readme file but the only thing that we could do was get past the "no server connection bla bla" screen. When either of us hosts, we can't see eachothers game to join.
We are using Hamachi for lan connection.
We used every version, from the steam community post to your recent (jan 5) update, but none of them worked.
I feel like we're just missing one tiny detail but can't figure out what that is.
FYI i got an Intel CPU and he has an AMD one.
Please if you could help us out we would heavily appreciate it.
Thank you in advance.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
@Ododo
I'm using ZeroTier and the experience is very random. I have scc lan restore working on both machines but I've only managed to get into a couple of coop matches, while it doesn't work 90% of the time. When it fails to work, one instance of the game cannot find the other and it doesn't show up as an open lobby. When I manage to get them both into a lobby, it seems to work from there. When it works, it seems to be asymmetrical - one machine works as a host and they can discover each other, but the other machine hosting does not. It seems to flip between them, I've managed to host at least one game on each machine, but only after tons of attempts.
I have two machines, A: 172.27.31.10, B: 172.27.31.20. The trivial issue I discovered is that the game sends only one discovery packet and does so on the ipv4 interface with the lowest metric. I made sure to set the ZeroTier iface metric as the lowest on both machines.
It's confusing that machine A is displaying the wrong src address for IN[]
, but I don't think it affects anything? In the packet capture below, you'll find that the last packets are sent correctly anyway and reach machine B.
The wireshark capture below was taken on machine B and it covers, IIRC, two quick successful sessions and some that didn't work, especially right at the end. Even if the server host advertises itself properly, the lobby did not show up on the other client.
@farnoy the program filters inbound udp packets so it is fixed in the machine discovering. As you get logs in machine A, this tends to indicate that machine A receives its own broadcasts packets. This is weird behavior to me, i don't think it should happen and i'm not sure of the consequences. This may highlight a potential issue with your network configuration. I'm not very familiar with zerotier.
one thing to try is to block the udp packet in machine A by deleting L23:
# w.send(packet)
Which VPN would you recommend, if any? I think those logs may be from earlier attempts where machine A was hosting, but I'll pay attention to this next time I test.
I'm using the .exe method, so commenting out a line is not possible. I'll see about setting up python
Yes machine A was hosting. I don't recommend a VPN in particular, my tests were done using radmin, however you could try wireguard based VPN such as tailscale or even plain wireguard.
Thanks for the feedback and for creating the tool in the first place!
What works for me is running scc_lan_restore on the client just to enter the LAN menu and lobby search, then killing scc_lan_restore and refreshing the games while in the LAN menu. And on the server, I modified the python code to use a hardcoded IP of the client I expect to play with instead of packet.ipv4.src_addr
. This seems to work consistently. I'm not sure why the src addr as seen by pydivert (?) was incorrect and needed to be hardcoded, they look fine in wireshark.
Now, if I could figure out how to have that FPS unlock fix without a general protection fault crash after the lobby starts 😄
ok if it works for you consistently fine . However it does not make sense to me : ) The packets are fixed in the client when it receives game infos from the host before forwarding them to the client game. They are not patched before going out of the host interface. In the client if you quit scc_lan_restore before refreshing then no packet will be patched. The packet hook part is no use to the host and could actually be commented out. So i doubt patching the IP in the host had any impact at all. _You could try to comment the packethook totally on both side and see if it works the same, maybe your lucky and you don't need that part but i doubt that Assuming the logs corresponds to the last wireshark session where A is the host and B is the client then the src address seen in the host logs was equal to the host ip, as the program filters for inbound udp packets with length > 500 (discovery replies from host) this was consistent with the possibility that the host interface receives its own broadcast messages, thus disturbing the game netcode. If the client also receives its own broadcast messages then there is a possibility that the client netcode is also disturbed.
I can't explain it, but it does work consistently this way. I don't think the machine sees its own broadcast and I don't understand why you'd think that, is it based off the wireshark capture? But the issue of a mistaken src address seems convincing, and would explain why my code change helps for that. I don't know if that's ZeroTier or some other cause :shrug:
Firstly, thank you for creating this for a very nostalgic masterpiece, pretty cool of you to give us a chance to play co-op in this old but gold game.
Me and my homie did everything that was written in your readme file but the only thing that we could do was get past the "no server connection bla bla" screen. When either of us hosts, we can't see eachothers game to join.
We are using Hamachi for lan connection.
We used every version, from the steam community post to your recent (jan 5) update, but none of them worked.
I feel like we're just missing one tiny detail but can't figure out what that is.
FYI i got an Intel CPU and he has an AMD one.
Please if you could help us out we would heavily appreciate it.
Thank you in advance.