In my opinion, it may do the opposite. It may encourage people. I've never used C#, but from what I hear and see here, it seems easier than C++

Then there's the question of doing it from scratch. If the HL SDK is ported to C#, do we replicate the changes which we made to our C++ HL SDK code over to the C# HL SDK, or something else?

// Might be wrong here
TYPEDESCRIPTION CTWHL::m_SaveData[] =
{
    DECLARE_FIELD( FIELD_BOOLEAN, CTWHL, m_bStatusSent )
};
IMPLEMENT_SAVERESTORE( CTWHL, CBaseEntity );

// Might be wrong here too (feel free to correct me Solokiller if I messed up)
class CTWHL
{
    [Persist]
    bool StatusSent;
}

• Black Mesa: Xen
• Rage 2
• Wolfenstein: Youngblood
• DOOM: Eternal
• Serious Sam 4: Planet Badass

Any recommendations for a good launcher that'll deal with the mods & skins & whatnot

SourceSkyBoxer said:Wait please Ubuntu 18.04 is buggy.

SourceSkyBoxer said:Please rollback to gcc6! ( Possible for gcc5.4 )

SourceSkyBoxer said:But please please add more shadow mapping like mod AM by SysOp.and realistic reflection for water and more.

DON'T

1. The concerned code uses "legacy" also known as "immediate" OpenGL which is totally different from the "shaders based" OpenGL used by Veldrid (and by extension SharpLife) and modern AAA games (modern Wolfenstein games).
2. The concerned code has a HARD dependency on PARANOIA's OpenGL renderer which uses the same "legacy/immediate" OpenGL.
3. Even if you do waste your time porting the code as-is, you'll get a massive performance loss.
4. It pains me to say this because I'm a developer of Arrangement but please for the love of God, don't use any of it's code from any public source code(s), the quality is so poor that rewriting the entire thing by yourself will be better.
5. IIRC, Solokiller said that SharpLife's goal is to provide a "better vanilla GoldSrc modding/playing experience". If you want any kind of graphical enhancements, then fork the project and DIY (Do It Yourself).

PenguinBoy said:https:/blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications

They utilize the wait command in the command queue to delay a level change when you enter a changelevel trigger, then they save the game with different relative position to the land_mark (being able to move around the level before it changes) once the other level is loaded they load the game and poof you are somewhere else on the new level or something like that, that's how I understood it.

• You need to make a Windows only desktop application.
• You need to make a Windows 10 UWP application (like the Windows Store).
• You need to use a NuGet package or library that doesn't exists yet in .NET Core.
• You are using technologies not yet supported by .NET Core (mostly Visual Basic, F# and some ASP .NET stuff).
• You are developing on a platform that doesn't support .NET Core.

• It's cross-platform: it works on Windows, Linux and Mac. Something that .NET Framework doesn't do.
• It's faster and optimised: if your application is strict on "performance budgets", this is way better than using .NET Framework.
• It has "microservices" in mind: enterprises will love this for sure when migrating big applications.
• It integrates nice with Docker containers: because a lot of people love Docker for building, testing and deployment and it's used by many continuous integration services.
• It's open-source: everyone can see the code and contribute to it unlike .NET Framework.

net standard 2.0 is shit because it can't bundle as single executable. So sadly who forgets requiered net assemblies than it "can't work".

The Mad Carrot said:I used the word fishy a lot.

• Read the shouts (obviously).
• Automatic shouts list refreshing whenever someone shout (or time based if it's not possible).
• Post shouts.
• Hide the application in the system tray and be notified whenever someone shout.
• Maybe more that you would like to see.