SendSignal fixes without changing generated files #9

ryan-linehan · 2025-11-05T04:48:13Z

When debugging my godot game I was noticing that the SteamNetConnectionStatusChangedCallback_t callback was giving odd/garbage data when I tried to print:

private void OnNetworkConnectionStatusChanged(SteamNetConnectionStatusChangedCallback_t param)
    {
        ulong steamId = param.m_info.m_identityRemote.GetSteamID64();
        ESteamNetworkingConnectionState oldStateEnum = param.m_eOldState;
        ESteamNetworkingConnectionState newStateEnum = param.m_info.m_eState;

        GD.Print($"[SteamMultiplayerPeer] Connection status changed: {oldStateEnum} -> {newStateEnum} (Steam ID: {steamId})");
    ... shortened for brevity
}

I believe this fixes #7 as I can seemingly now connect between my mac and my windows machines and play the demo game at this repo https://github.com/ryan-linehan/Godot.Steamworks.NET through steam p2p networking. I tried to follow how the files were being generated.

It seemed to me that since ISteamNetworkingConnectionCustomSignaling was skipped in the interfaces.py that the correct way to add the pack awareness call would be to implement it right in the template. Similarly I edited the nativemethods.txt to add the marshalling for the SendSignal call that I used in the ISteamNetworkingConnectionSignaling.cs.

Lastly, I added "SteamNetConnectionInfo_t" to the g_SequentialStructs so that the SteamNetConnectionInfo_t struct gets generated with:

[StructLayout(LayoutKind.Sequential)] instead of [StructLayout(LayoutKind.Sequential, Pack = Packsize.value)]

I am unsure if these are the correct changes for this fix or if I am just misunderstanding all together. Happy to help implement this the proper way if this is not it.

Thanks!

Also, here is a video of the game being played between my arm64 mac and my windows machine:

Godot_v4.5.1-stable_mono_win64_VVrRyCT863.mp4

… struct

Akarinnnnn

Looking good, I will continue to investigate steam SDK parser to see if there some problems.

Akarinnnnn · 2025-11-05T10:19:30Z

CodeGen/templates/nativemethods.txt

 		[return: MarshalAs(UnmanagedType.I1)]
 		public static extern bool SteamAPI_ISteamNetworkingConnectionSignaling_SendSignal(ref ISteamNetworkingConnectionSignaling self, HSteamNetConnection hConn, ref SteamNetConnectionInfo_t info, IntPtr pMsg, int cbMsg);

+		[DllImport(NativeLibraryName, EntryPoint = "SteamAPI_ISteamNetworkingConnectionSignaling_SendSignal", CallingConvention = CallingConvention.Cdecl)]


Don't forget to guard with #if STEAMWORKS_ANYCPU

Not sure my Pr ever got updated with this. I should go back and add this still right? Or was it covered in another commit that this was merged into perhaps?

Akarinnnnn · 2025-11-05T10:24:47Z

com.rlabrecque.steamworks.net/Runtime/autogen/SteamStructs.cs


 	/// Describe the state of a connection.
-	[StructLayout(LayoutKind.Sequential, Pack = Packsize.value)]
+	[StructLayout(LayoutKind.Sequential)]


Pack = Packsize.value is still necessary since steam using a different pack to platform default.

I think I tried it both ways and it only seemingly worked with this change. I was trying to follow how MatchMakingKeyValuePair_t struct worked that's why I made the change to interfaces.py so the generator would make this change

I'll put it back and test again and let you know the results later today

I attempted to put this back to how it was and now I am back to getting in a endless 'connecting' state.

Logs from the windows x64 machine:

[SteamMultiplayerPeer] CreateClient called with remote Steam ID: 76561198191562071, port: 0 [SteamMultiplayerPeer] ConnectP2P succeeded, waiting for connection callback [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_None (Steam ID: 0) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_None (Steam ID: 0) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> 7102840 (Steam ID: 0)

Note that everything goes from none -> none I assume because something is not right. The steam ID being 0 should not really happen here either. 7102840 is not a value that this enumeration supports so it seems something is not right when on windows with the

[StructLayout(LayoutKind.Sequential, Pack = Packsize.value)]

Back to using this change with no pack size declared:

[StructLayout(LayoutKind.Sequential)]

Gives the following logs on the windows machine:

[SteamMultiplayerPeer] CreateClient called with remote Steam ID: 76561198191562071, port: 0 [SteamMultiplayerPeer] ConnectP2P succeeded, waiting for connection callback [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_Connecting (Steam ID: 76561198191562071) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_Connecting -> k_ESteamNetworkingConnectionState_FindingRoute (Steam ID: 76561198191562071) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_FindingRoute -> k_ESteamNetworkingConnectionState_Connected (Steam ID: 76561198191562071) Peer Connected: 1Self id: 1350075199

Which actually show the connection state and steam ids properly and I am able to successfully connect again.

If this struct is using platform default alignment(in case of Packsize.value omitted), we may not need large pack version. Let me check parser.

Have you tried add Packsize.value back on your Mac? I suspect this is a pack-size aware struct but is not auto generated.
If Mac with Packsize.value connected to Windows without that modifier, I think this is a alignment issue and can be manually fixed like what generator did.

Yeah actually I deploy it to both PCs when testing it. So they have always been the same version of the pack size param when testing

Any updates on this? Trying to use the package in one of my games and I am currently building the package myself with my changes. Think we could get a new beta branch up with these changes soon?

Akarinnnnn · 2025-11-05T10:55:44Z

Seems our parser detected it's a pack aware struct, I'll check generator later.

ryan-linehan · 2025-11-05T19:07:38Z

Yeah the parser seems to catch it but the generator doesn't because it's one of the few "custom templates" that aren't generated but rather they're copied straight from the template file from what I could tell

Let me know what you find!

Akarinnnnn · 2025-11-06T04:18:30Z

I'll check this tonight(in utc+8)

…

---Original--- From: "Ryan ***@***.***> Date: Thu, Nov 6, 2025 11:43 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [Akarinnnnn/Steamworks.NET.AnyCPU] SendSignal fixes withoutchanging generated files (PR #9) @ryan-linehan commented on this pull request. In com.rlabrecque.steamworks.net/Runtime/autogen/SteamStructs.cs: > @@ -453,7 +453,7 @@ public struct GameID_t { } /// Describe the state of a connection. - [StructLayout(LayoutKind.Sequential, Pack = Packsize.value)] + [StructLayout(LayoutKind.Sequential)] I attempted to put this back to how it was and now I am back to getting in a endless 'connecting' state. Logs from the windows x64 machine: [SteamMultiplayerPeer] CreateClient called with remote Steam ID: 76561198191562071, port: 0 [SteamMultiplayerPeer] ConnectP2P succeeded, waiting for connection callback [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_None (Steam ID: 0) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_None (Steam ID: 0) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> 7102840 (Steam ID: 0) Note that everything goes from none -> none I assume because something is not right. The steam ID being 0 should not really happen here either. 7102840 is not a value that this enumeration supports so it seems something is not right when on windows with the [StructLayout(LayoutKind.Sequential, Pack = Packsize.value)] image.png (view on web) Back to using this change with no pack size declared: [StructLayout(LayoutKind.Sequential)] Gives the following logs on the windows machine: [SteamMultiplayerPeer] CreateClient called with remote Steam ID: 76561198191562071, port: 0 [SteamMultiplayerPeer] ConnectP2P succeeded, waiting for connection callback [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_None -> k_ESteamNetworkingConnectionState_Connecting (Steam ID: 76561198191562071) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_Connecting -> k_ESteamNetworkingConnectionState_FindingRoute (Steam ID: 76561198191562071) [SteamMultiplayerPeer] Connection status changed: k_ESteamNetworkingConnectionState_FindingRoute -> k_ESteamNetworkingConnectionState_Connected (Steam ID: 76561198191562071) Peer Connected: 1Self id: 1350075199 Which actually show the connection state and steam ids properly and I am able to successfully connect again. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

Akarinnnnn · 2025-11-08T23:59:24Z

Well, I'm away from my testable machine which installed Windows and Ubuntu in WSL2. Next time I have holiday is 2 weeks estimated. If you think this one is a good fix and ready for previrw, please imform me so that I will push it as 2025.162.6-b .

…

---Original--- From: "Ryan ***@***.***> Date: Sun, Nov 9, 2025 03:25 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [Akarinnnnn/Steamworks.NET.AnyCPU] SendSignal fixes withoutchanging generated files (PR #9) @ryan-linehan commented on this pull request. In com.rlabrecque.steamworks.net/Runtime/autogen/SteamStructs.cs: > @@ -453,7 +453,7 @@ public struct GameID_t { } /// Describe the state of a connection. - [StructLayout(LayoutKind.Sequential, Pack = Packsize.value)] + [StructLayout(LayoutKind.Sequential)] Any updates on this? Trying to use the package in one of my games and I am currently building the package myself with my changes. Think we could get a new beta branch up with these changes soon? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

Akarinnnnn · 2025-11-09T14:04:38Z

FieldOffsets-Microsoft Windows 10.0.26200.txt
FieldOffsets-Ubuntu 24.04.3 LTS.txt
I have scanned memory layout based on your branch, they are the same. Next I want to use some c++ tools to scan native layout.

ryan-linehan · 2025-11-09T15:20:11Z

Well, I'm away from my testable machine which installed Windows and Ubuntu in WSL2. Next time I have holiday is 2 weeks estimated. If you think this one is a good fix and ready for previrw, please imform me so that I will push it as 2025.162.6-b .

No worries. I'm fairly confident in the changes but I can wait a bit longer so you can have the proper time to review.

FieldOffsets-Microsoft Windows 10.0.26200.txt
FieldOffsets-Ubuntu 24.04.3 LTS.txt
I have scanned memory layout based on your branch, they are the same. Next I want to use some c++ tools to scan native layout.

Sweet, keep me posted! Thanks for digging in with me 😀

Akarinnnnn · 2025-11-18T13:51:53Z

#1 (comment)

According this analysis, SteamNetConnectionInfo_t should have same layout across large and posix pack. Your solution is a good workaround, but it also discovered there are some bugs in our parser/generator.

ryan-linehan · 2025-11-18T22:18:42Z

Sounds good, if I can help somehow please let me know.

In the meantime, do you think you could try out the GitHub action I pushed in a previous PR and publish a new beta branch build? Hoping to have a usable nuget package for myself and other Godot users even if it's not production ready yet for me it is seemingly "good enough" while the rest of the issues are hashed out.

Appreciate it!

Akarinnnnn · 2025-11-19T04:13:02Z

Oh, I forgot gh actions... Try it next time. Preproduction package is already online. Have a try if you need fixes.

…

---Original--- From: "Ryan ***@***.***> Date: Wed, Nov 19, 2025 06:19 AM To: ***@***.***>; Cc: ***@***.***>;"State ***@***.***>; Subject: Re: [Akarinnnnn/Steamworks.NET.AnyCPU] SendSignal fixes withoutchanging generated files (PR #9) ryan-linehan left a comment (Akarinnnnn/Steamworks.NET.AnyCPU#9) Sounds good, if I can help somehow please let me know. In the meantime, do you think you could try out the GitHub action I pushed in a previous PR and publish a new beta branch build? Hoping to have a usable nuget package for myself and other Godot users even if it's not production ready yet for me it is seemingly "good enough" while the rest of the issues are hashed out. Appreciate it! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

ryan-linehan · 2025-11-19T16:38:57Z

Btw new nuget package with fixes are working great for my use case! Thanks again!

ryan-linehan and others added 5 commits November 4, 2025 20:48

update sendsignal to be pack aware with manual edits

8b21508

Move loader hook fix to source generator's template.

01d6df4

update structs.py to include SteamNetConnectionInfo_t as a sequential…

a1520ae

… struct

update send signal template to be pack size aware

0484eda

update nativemethods.txt to have pack aware dll import

5db56bb

Akarinnnnn reviewed Nov 5, 2025

View reviewed changes

Akarinnnnn merged commit d1aea9d into Akarinnnnn:anycpu-packable-fix-align-by-conditionalmarshal Nov 18, 2025

SendSignal fixes without changing generated files #9

SendSignal fixes without changing generated files #9

Uh oh!

Conversation

ryan-linehan commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Akarinnnnn left a comment

Choose a reason for hiding this comment

Uh oh!

Akarinnnnn Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ryan-linehan Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

Akarinnnnn Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ryan-linehan Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ryan-linehan Nov 6, 2025

Choose a reason for hiding this comment

Uh oh!

Akarinnnnn Nov 6, 2025

Choose a reason for hiding this comment

Uh oh!

Akarinnnnn Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryan-linehan Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryan-linehan Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Akarinnnnn commented Nov 5, 2025

Uh oh!

ryan-linehan commented Nov 5, 2025

Uh oh!

Akarinnnnn commented Nov 6, 2025 via email

Uh oh!

Akarinnnnn commented Nov 8, 2025 via email

Uh oh!

Akarinnnnn commented Nov 9, 2025

Uh oh!

ryan-linehan commented Nov 9, 2025

Uh oh!

Akarinnnnn commented Nov 18, 2025

Uh oh!

ryan-linehan commented Nov 18, 2025

Uh oh!

Akarinnnnn commented Nov 19, 2025 via email

Uh oh!

ryan-linehan commented Nov 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ryan-linehan commented Nov 5, 2025 •

edited

Loading

Akarinnnnn Nov 6, 2025 •

edited

Loading

ryan-linehan Nov 6, 2025 •

edited

Loading

ryan-linehan Nov 8, 2025 •

edited

Loading