Forum posts

I've reworked the command system to make things a little safer and easier to use.

The old system worked mostly like the original: one command system that contains both server and client commands, where you could execute client commands when running a listen server, and where commands would be forwarded to the server as needed.

The new system separates the system into 3 pieces: the queue, contexts, and the overarching system.

The queue contains all commands to be executed. This works the same as it did before, only now you can only execute commands from the same context that your own command is being executed from.

A context contains a set of commands and aliases (defined with the alias command). There is a shared context whose commands are accessible from all contexts, but these commands can only execute commands that are in the context that this shared command is being executed from, so if you execute such a command from the client, it cannot execute server commands, but you can also execute the command from the server.

This helps protect against abuse by not allowing direct execution of arbitrary commands, but will not protect against things like slowhacking, which relies on servers being able to make the client insert commands into their local queue.

Command registration, queuing and execution remains the same, you won't notice any real difference in code. The big difference is that you no longer have to account for where a command comes from in the command handler, you are guaranteed that the command was either executed locally or was explicitly sent to from client to server or server to client.

This allowed me to remove the CommandSource enum, which was part of the original command system. It was a really inflexible way to detect if a command was forward to the server (needed so you can execute server commands from the client).
The new way to handle this, which isn't implemented yet is to use a helper to automatically forward these commands. You'd register a server command or variable, and register a client side forwarding command so the server can receive it.

The case where you're hosting a listen server and need to directly access server commands will probably be solved by adding an option to the console to switch to the server command context so you can directly perform server administration. Otherwise, you will need to use rcon to execute those commands.

An alternate option is to add a second input area for server specific commands.

Most cvar flags have been made obsolete with this change, of the 10 flags only half are still required at this time.
Further changes may make more of them obsolete in time.
Edit: Make that 3 required flags. The other 2 are now filters.

Edit 2: only 2 flags are part of the command system now, the third flag has been changed into a user defined flag since it's only used to save config cvars.
Commands can now have user defined flags added to them, so it can be flagged with specific boolean values.
In addition, commands can have tag objects associated with them to add arbitrary data to them. For instance, the map cycle cvar could store the map cycle manager object as a tag.

I've implemented a basic networking system now. Servers will set up networking, clients can connect to servers.

Message sending works up until the client receiving the message containing server info, including the map name, which it uses to load the BSP now.

In theory you could just launch with a different +map command to load any map, but i haven't tried that yet.

For those interested in seeing how much it takes to add a new message, these are the steps you have to take:

• Make sure your dev environment is set up first by adding the path to protoc (Protobuf compiler) to your PATH environment variable. The tool is included in a NuGet package that's a dependency of the SharpLife.Networking.Shared library, so it will be located in your .nuget/packages directory. You can also download the tool from Google's Protobuf website

• Create a .proto file in SharpLife.Networking.Shared.Messages (can be in a child namespace) containing your message definition, make sure to specify the package name

For example, here's the message that the server sends to the client to give it basic server info: https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Networking.Shared/Messages/Server/ServerInfo.proto

• Rebuild SharpLife.Networking.Shared to automatically generate the message class. This is done using a pre-build step that executes a PowerShell script

• Add your message to the message list: https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Networking.Shared/NetMessages.cs#L42

You need to add the descriptor to the list, and adding new messages post-release should also come with a change to the protocol version constant: https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Networking.Shared/NetConstants.cs#L46

Depending on whether it's a server-to-client or client-to-server message you need to add it to either list.

The order of the messages is important, since it's used to generate the IDs used to identify incoming messages.

• On the receiving side you'll need to register a handler:

https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Engine.Client/Host/EngineClientHost.Messages.cs#L40
https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Engine.Server/Host/EngineServerHost.Messages.cs#L38

Message handlers implement the IMessageReceiveHandler<TMessage> interface. TMessage is the class type of your message. The same class can implement multiple handlers. If a handler is not implemented, an exception will be thrown when a message for it is received.

• That's about it. You can send messages pretty easily:

https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Engine.Client/Host/EngineClientHost.Messages.cs#L76
https://github.com/SamVanheer/SharpLife-Engine/blob/23f235a39ca16423d35ab6007731d9df2a5c3f7f/src/SharpLife.Engine.Server/Host/EngineServerHost.Messages.cs#L66

Adding a message will immediately add it to a list of outgoing messages and serializes it to a buffer. The message object is not kept after that.

Servers can send both reliable and unreliable data, to allow you to send non-critical data that can be lost or ignored without consequence (e.g. visual effect creation).

The engine will send messages automatically, but you can force the immediate sending of all pending data if you want. That's generally reserved for engine code that needs that done, and will not be exposed to game code.

Game code will also be able to register messages the same way, the only difference will be that message handlers will get an object that represents a client rather than a connection.

Note that the message IDs are internal and should never be used for any persistent uses. They can change easily and are normally handled entirely by the message transmission and dispatch systems. Unlike GoldSource, game messages won't require you to store off IDs, so you only have to make sure that your code uses the same list of message descriptors on the client and server.

There is currently no hard limit to the size of messages, but that will be needed to avoid issues later on.
The only hard limit is the number of clients, and that can easily be made a configuration variable.

SVC_BAD should not be possible with this system since message sizes are sent along, and messages are always parsed fully. Only malformed packets could cause it to happen.

Now the next things to do are:

1. Build a simple UI to display the console and accept commands
2. Implement a system to network arbitrary add-only string lists with binary data

The first is straightforward, i'll be implementing it in the game codebase so all UI code is there.

The second will take some doing. I'll have to look into a good way to network strings because sending them uncompressed could be a problem.
I don't want to just send whole lists at once, that could easily use a ton of memory and take a long time when there's packet drops happening.
Sending lists so each packet contains a self-contained section to process would be the best way to handle this. Whatever system i come up with should also be usable for game data networking to ensure that the client gets what it needs without having to wait to reassemble the packets containing the data.

The binary data will simply be Protobuf messages, it's the most efficient way to handle that.

Once that's done i can create a couple lists to store model, sound and generic precache data in them. Then i can implement proper resource precaching and let the client load everything up.

That's a fair amount of work, so i'll keep it at that for now.

Of course, the other aspect of this is that, assuming we're still talking sticking as close to vanilla as possible, is that it still would be deathmatch at its core. I don't know how much coding it would require if you wanted to disable or restrict friendly fire, respawning, respawning ammo, etc.

You can disable friendly fire pretty easily: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/multiplay_gamerules.cpp#L527

if (pAttacker && pAttacker->IsPlayer())
{
    return FALSE;
}

Basically if the attacker is a player you ignore the damage. You could add a check here to see if the owner is a player (shouldn't be an issue unless a monster spawned by a player is doing damage) or do team checks instead.

You should probably create a new gamerules class though, otherwise it'll have all of the rules of regular deathmatch.

https://discord.gg/8uyTp76

We're kind of missing an administrator though.

You can modify changelevel entities to work in multiplayer: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/triggers.cpp#L1466

Disable the deathmatch check and add a g_pGameRules->IsMultiplayer() check to disable the transition volume check. You may also want to disable transitioning of entities since that's not really going to work well in multiplayer.

Did you mark the door to start open? Decals are applied after all entities have spawned, but this means that doors with start open set or trains that are set to be moved elsewhere won't be where they are in the editor when the decals are applied.

I built an event system so UI, client and server code isn't all over the place. The engine updates the UI state directly and some server code will directly call client code when running as a listen server. To avoid this all of the code will dispatch events that can be listened to.

Events are registered before use and can have a data type registered along with them that carries that event's specific data, for instance when a map starts loading an event is dispatched containing the map name, previous map name, whether it's a changelevel or a new map, and whether it's being loaded from a saved game.

This makes the event system type safe, allowing data to be easily passed around.

It's pretty easy to register listeners for specific events, if the event has data you can register a listener that takes that specific data type and just register it, it'll figure out the event name from that.

I'm designing the engine with the possibility that systems will be separate between client and server, so for instance there can be separate command systems so the server can't just execute client commands directly when running a listen server.

Still working on networking, i've been trying to figure out how exactly the engine does things, it's slowly getting there.

At the moment it's hardcoded yes, this is still early in development and i haven't gotten to the point where map loading is done like the original. Please remember that it will take months if not years for this to get to a playable state.

Half-Life can't be converted to 64 bit because parts of it depend on it being a 32 bit application, like for instance function lookup where pointers are cast to a 32 bit int.

SharpLife can't be ran as 64 bit since it has to be in the same process space, which forces the use of 32 bit.

You need to install the 32 bit Net Core runtime and SDK.

If you're having problems even getting it to launch then go to sharplife_full/cfg/SharpLife-Wrapper-native.ini and set DebugLoggingEnabled to true, then look in SharpLifeWrapper-Native.log in the Half-Life directory, it might tell you some useful things.

Your problem is probably that it's trying to run as 64 bit so it fails to load 32 bit binaries.

What are you trying to use SDL2.dll for? You shouldn't need to compile the native wrapper yourself, if you do you should just use the one in Half-Life. There shouldn't be any need to reference the file explicitly though.

The wrapper does only one thing and that's bootstrapping the Net Core host. You shouldn't need to touch it unless there's a problem with it or if you need some interop with the engine somehow (you probably won't).

I've removed the need to use a local NuGet package source, all assemblies are now either from the standard NuGet package source or a local assembly reference in sharplife_full/assemblies.

I've also implemented the basics for client-server stuff, up to loading game assemblies. Before i can continue i need to get the networking system done so that all works, since map loading relies on it to load the data on the client (clients always use data from the server to load content, even if it's a listen server).

This'll probably take a while so don't expect it to work from the start.

As far as using local assemblies goes, when ImageSharp is updated i'll use the NuGet version, same for Veldrid. The assemblies will still be committed to allow anybody to run it though, so it only really changes how the dependencies are managed.

I've also upgraded all projects to use Net Core 2.1.

I'll get the package stuff sorted out, right now there's a couple beta versions in use and the SDL2 library is a custom build to work around a problem in the older version used by the game.

I think we've established by now that nobody's using Mono or Gtk.

@Solokiller, how is your work in process? Rendering nsp and wad and can we have sources

I'm working on implementing the client-server architecture so there's nothing new to show.

The source code and game files can be found in these repositories:
https://github.com/SamVanheer/SharpLife-Engine
https://github.com/SamVanheer/SharpLife-Install

Put SharpLife-Install in Half-Life/sharplife_full and define the STEAMCOMMON environment variable to point to the steam/steamapps/common directory.

Veldrid is .NET Standard, not .NET Core so it should work fine with .NET Framework based projects: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

Veldrid does make it easy to swap backends, but you will need to account for backend specifics quirks, like for example using samplers in OpenGL requires you to add the sampler to resource sets in a specific order to make it affect rendering, and shader outputs may be flipped vertically, requiring you to change the shader to output something different. You will generally also need shaders specific for a given backend, but SPIR-V intermediate compilation may make that relatively simple.

BSP rendering isn't terribly difficult once you get the data part going, but if you're making an editor you'll need to make sure to mark buffers as dynamic. I don't know what the best approach is for that kind of stuff, it depends on the cost difference between static and dynamic buffers.

I'm trying to modularize my code as much as possible, so BSP rendering should be standalone for the most part, but it's probably still going to have some dependencies on the file format. Still, the shaders can be reused for drawing in-editor. The current LightMappedGeneric shader is pretty much what you'd use in an editor, aside from maybe simple light shading like Source does to show the difference between face normals.

I have thought about maybe having some kind of support added to Sledge to add some new stuff eventually, but that'll require a new map format. I haven't looked at its source code yet so i don't know how easy that would be, but given that it's open source and written in C# it's the best way to open up new possibilities for content creation.

Code conversion from one language into another happens very often.
Besides, the ASM is only the sped-up 256 color software-renderering code so that's really irrelevant.

My point is that you'd have to heavily modify the code just to make it work and not be the ugly mess that Quake code is. I won't be doing anything like that so it doesn't matter.

So far i've just been making it all from scratch since the original version is such as mess. Thanks for bringing this up before we got any Quake code in there.

I forgot one item on the list of systems: User Interface. That'll probably be a custom design, unless i can find a library for that.

I'm not using Quake code directly, i'm referencing it to rebuild parts of GoldSource. I can't change the license because i'm using code from the SDK to rebuild parts.

You won't find actual Quake code in this because it's C code and pretty outdated. You wouldn't be able to to see any matching code as a result since it's still completely rewritten.

EDIT:

We've talked this over and we've concluded that no actual Quake code is in use at all, and the Quake license states this:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

SharpLife is based on GoldSource, and is largely designed from scratch, with reused code from the SDK.

From now on i won't reference Quake anymore when working on this project, so there will be no legal issues with that codebase.

I've taken this opportunity to make a list of systems that are needed to make a working GoldSource engine, and how Quake relates to it:

• Platform specific code used for window, input, graphics management: Provided by SDL2
• Platform specific code used for file input/output: provided by NET Core APIs
• Common code (tokenization, string utility functions): Tokenization code comes from multiplay_gamerules.cpp, string utility functions are provided by NET Core APIs
• Math functions: Provided by NET Core APIs
• Graphics: Provided by Veldrid, GoldSource specific code derived from public SDK code and completed by me
• Sound: Provided by FMOD SoundSystem library
• Memory management: Quake memory management is largely obsolete even in modern Quake derivatives, and C# doesn't allow that kind of control anyway
• File loading: Derived from SDK code
• Networking: I'll be using a networking system built using a NET Core library and ProtoBuf, completely different from Quake's QSocket and Quake 2's NetChan (used by GoldSource). GoldSource's networking code is pretty terrible so reusing any of it is a waste of time and effort anyway
• Various engine and game logic functions: derived from SDK code (parts of Quake engine code were moved into game code in Half-Life), missing parts can be re-implemented

Anything else is minor and can be reproduced without the use of Quake code.

Also of note: Quake is C with some assembly, which can't be used in C#. GoldSource has a C engine and largely C++ game logic. Quake code would have to be heavily modified to even be usable, to the point where it has to be redesigned from scratch to be useful. Since Quake and GoldSource rely on global variables in many areas, any properly designed C# equivalent would be drastically different.

Thus, no licensing issues.

Valve doesn't approve of Xash because they used leaked code, not because of the license. People have used Quake code in tools and mods before with no problems from Valve. Even Sven Co-op has some code taken from Quake in it, and that was before they got the engine.

Even if they don't approve, if they don't send a cease and desist it doesn't matter anyway. Projects like ReHLDS have been going for years doing things far worse than mixing the two codebases with no legal issues.

I think i'll stick to porting Quake's code and updating it to work like GoldSource does it, no need to start breaking stuff by using physics code from some book.

I wrote the code to load both file types.

I've only completed these two things, i haven't even started on entities.

Alright i think we've talked enough about Mono, this project uses NET Core so all that's irrelevant anyway.

Progress update:BSP & WAD loading is finished, currently rendering the entire map but the code can be adjusted to use VIS data pretty easily.

Now i'll have to make sure the camera angles are correct so movement is properly translated and everything, since at the moment the world is actually sideways.

NET Core runs on Linux and Mac natively, it doesn't run through WINE, it doesn't compile to native code like Mono does.

The --self-contained option packages the runtime along with the exe, but it doesn't embed assemblies into the exe. For reference, SharpLife references the default 32 bit installation directory at this time, though it may eventually change when i get to testing the Linux version.

That has to do with lightmap scale, which is tied to texture scale in GoldSource. You'll have to scale the actual textures to avoid that.

I set my projects to copy local assemblies so all of the required files are in the assemblies directory. It's a simple solution.

C# is managed code, so there is no need to make a native executable, not that it would matter in this case anyway since the executable is the original Half-Life executable which i can't replace. My code is all libraries, so combining them isn't an option either way.

The command you're using uses a Mono tool to consume a .NET Core executable, obviously that will never work.

Well i like it.

Veldrid uses ImageSharp for texture loading, no other libraries are needed.

Nothing yet, it's mostly backend stuff. I'm about to start implementing texture management, that's where things will change a bit. The original engine has a limit on the number of textures, how large they can be, etc. There's no reason why there would be any limitations here.

Finished the essentials of the renderer, added in skybox rendering.

Framerate's pretty good, should probably clamp it though.

Sure let me just write an entire GUI library before i can start drawing stuff on-screen.

ImGui is meant for debugging, not actual UI development. It's easy to use, fast and there's already a library for it.

If you need to show blocks of code use pre tags: https://twhl.info/wiki/page/TWHL:_WikiCode_Syntax#wiki-heading-16

Veldrid's working, along with ImGui on top. I'll need to simplify the code since the sample code is way too much for what's needed right now, but it's a good start.

Now i can start adding ImGui based menus and debug output to make things easier, and load 2D and 3D data to render it. That represents a sizeable chunk of what's needed in the engine.

RMF stores brushes as floating point, MAP stores as integer. If you have brushes with strange face angles the result could become invalid when converted to MAP. If you're using an editor that has the option to export to MAP with floating point coordinates, enable it to see if it works.

The problem has been solved, i can now continue implementing the renderer.

I've been working on getting Veldrid integrated, unfortunately i've encountered a showstopper bug: https://github.com/mellinoe/veldrid/issues/100

Basically Veldrid doesn't work in 32 bit applications (and it should), so i can't get this to work until that's fixed. I hope the problem can be found soon, but there's no telling where the problem is.

Beyond that i can do some work writing libraries to load BSP, MDL, SPR, etc file types to make things easier down the road.

Windows Defender is marking Hammer as a password stealing malware, so i cant test it. I suggest you reinstall Hammer from a trusted source, such as this: http://www.slackiller.com/hlprograms.htm

EDIT: Seems that you installed some kind of modified Hammer, from the file "Readme_PACK.txt":

Hammer improvement Pack unofficial 3.5.2 // version 2.0       made by Cellulo aka Kato-yuen   www.flat2d.com    August 26 2012

- added Hammer 3.5 beta with some new tweaks in the interface based on CSM HAMMMER Editor 0.3.8.1 (http://cs-fun-pro.com/load/35-1-0-313)
  and VHE Neon ( http://gamebanana.com/cs/tools/5130).

This may be why it's not working as it should. Try using a vanilla Hammer first, then use any modified one, or better yet use Sledge or JACK.

Mediafire is blocking the download, you'll need to host it somewhere else.

The configuration looks good, nothing wrong there.

What i meant about Hammer was putting the entire directory in a rar and giving it to us. With that we can see if Hammer or the compile tools are broken somehow.

If that fails the only thing i can think of doing is using TeamViewer to check your installation directly.

It's definitely running them in the wrong order.

Go to your Hammer installation directory and give us the GameCfg.wc file you find there. It contains your Hammer configuration, we'll take a look at it and see if anything's wrong there.

If possible, try to provide the entire Hammer directory, containing the executable, configuration file and compile tools. That'll make replicating your problem easier.
You don't need to include any map sources if you don't want to.

Ok, then try this: compile the map 4 times, each with only one of the stages enabled. Show us the logs for each of those so we can see what it's doing for each. Make sure to add which tool you enabled for each log.

The idea is to see if having a tool enabled actually runs that tool or if it runs something else, that'll tell us whether Hammer is invoking the wrong tool or if something else is wrong.

Hammer can have multiple configurations so you can make maps for different games. Make sure the correct one is selected when you compile this map.

Ok so it's definitely running CSG last. Are you sure the build programs are correct, and that you're using the configuration you've showed us? Hammer can have multiple and you have to select it when you load the map.

If that's all correct then Hammer must be executing them out of order, which doesn't make sense. Do you use a custom compile configuration?

Use the latest tools, show us the compile log. We can't help you unless you do that.

Make sure you're using the latest tools, then show us the complete log. Make sure it's in order, so if CSG is really at the end then it shows that there's a problem.

You're not using the latest compile tools, the output differs from mine. Make sure you're using VHLT 34: https://twhl.info/thread/view/17830?page=1

The map will never load in the game until it can compile successfully, so that's the problem you need to look at first.

You forgot to show CSG, so either you missed it or it's not turned on.

You need to put everything in a path with no spaces in it, otherwise it will fail to open and/or copy files.

Try validating games files. If that doesn't work, delete the BSP file and recompile it.

I removed all of the env_sprite entities and then compiled it. It compiled fine using VHLT V34 and loads once i've placed vnam.wad in the game directory.

Aside from missing spawn points it works just fine.

Are you loading this in Counter-Strike 1.6 or Condition Zero, did you use different compilers and are you absolutely sure it's the correct bsp file?

That error can only happen in two situations:
1. A brush entity had its brush deleted from the map during compilation, causing the game to reference a non-existent brush
2. You're using a brush model name as a sound name somewhere

It's probably the first, so check if the compiler is doing any of that. Compile with verbose output set to the highest level, enable any additional output if possible.

Otherwise you'll have to check to see if there are any weird brush entities. Since it's complaining about the first brush model the map is either small or its brush model data is invalid somehow.

Also make sure that the compiler is actually putting your map where it's supposed to be, otherwise you could be trying to run an older version.

cl_gibcount was added to Sven Co-op, it doesn't exist in the vanilla game.

The number of gibs spawned is hardcoded: https://github.com/ValveSoftware/halflife/blob/master/dlls/combat.cpp#L303

The second value passed to SpawnRandomGibs defines how many are spawned.

The skybox does not have any clipnodes generated for it when using old compilers. Newer ones will generate them by default, but that can be disabled with -noskyclip. This thread has a bit more information: https://forums.svencoop.com/showthread.php/38059-ARCHIVE-Custom-ZHLT-by-vluzacn?p=478658&viewfull=1#post478658