Decompiling fails on setdefaults1, for some reason.

[HiImKyle]

That's because it has everything needed, after compilation it creates the whole .exe file which is easy to work with. VS has a nice autocompletion for the entire code, i find that better working than searching for some code I want to use in iLspy/dnspy. Anyways that's the only thing I know for now, as I just started playing with terraria code and it works pretty well. Do you have any better way that you can share with us?

I mean, yeah I guess decompiling helps for that aspect but there's no other reason. What if I told you, you could have your cake and eat it too, without decompiling said cake. You can use Visual Studio all you like, I use it too, but decompiling the entire thing is a waste of time.

General idea, without giving it all away, is you have a program that loads Terraria into memory, and you use Harmony(C# Runtime Patching Library) to patch any method you want within Terraria and all you need to dish out is your program, that way you aren't giving out the entire Terraria exe.

If you need me to clarify anything or go into more detail on anything, or you just don't like doing things yourself, my signature is there for a reason.

[blapanda2]

I imagine the code is 99% similar between the Steam and GoG versions, so it'd be easier to leave in the Steam stuff and just not have it initialize. If I had a GoG version I'd check the exact differences.

The Ionic.Zip.CF etc stuff should all be included. ILSpy extracts them as Libraries.Ionic.CF.dll or something similar. Dotpeek puts them into e.g. Libraries\Ionic\CF.dll. With them loaded into ILSpy I didn't even need to import them separately into Visual Studio. In ILSpy when you click on References under Terraria it should say that they were successfully found. If Visual Studio still complains, you might have to add them as references manually.

Good morning.

Yea, dnSpy and ILSpy are creating those files, but they needed to be renamed in this case.
It tried to call and fetch:

Ionic.Zip.CF.dll
Newtonsoft.Json.dll
RailSDK.Net.dll
ReLogic.dll
Steamworks.NET.dll

but those were altered from the extraction to:

Terraria.Libraries.DotNetZip.Ionic.Zip.CF.dll
Terraria.Libraries.JSON.NET.Newtonsoft.Json.dll
Terraria.Libraries.RailSDK.Windows.RailSDK.Net.dll
Terraria.Libraries.ReLogic.ReLogic.dll
Terraria.Libraries.Steamworks.NET.Windows.Steamwor ks.NET.dll

Renaming them fixed the compiler issue. And yes, the GOG and Steam version codes ain't that different from each other by the meta coding. It is just the archievement system and such which exclusively sticks towards Steam, what made me suspicious with that error yesterday. I used to decompile the v1.3.X.X in the past, but hell ... that was a long time ago �� I usually code, not decompile.

But for now:
Decompiles perfectly, re-compiles perfectly, executable runs as expected, but the actual game loading fails when trying to run.

Other than that, the post-event causes compiler issues.
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat" (my batch is somehow located over there, instead of the IDE)
editbin /largeaddressaware "$(TargetPath)"

[warbob5000]

Other than that, the post-event causes compiler issues.
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat" (my batch is somehow located over there, instead of the IDE)
editbin /largeaddressaware "$(TargetPath)"

Odd, mine is in the same location and the code I posted earlier worked fine. You can omit it and add the largeaddressaware flag manually - there are plenty of tools that can handle this (can't post links yet).
I had to add the largeaddressaware flag 'cos my configuration didn't do it automatically, and Terraria crashed with an OutOfMemory error if I didn't.