SharpLife - Dot Net Core based modding p Created 1 year ago2018-05-06 19:15:02 UTC by Solokiller Solokiller

Created 1 year ago2018-05-06 19:15:02 UTC by Solokiller Solokiller

Posted 11 months ago2018-07-19 17:46:41 UTC Post #340197
If you test under Ubuntu 18.04 under VMWare Player xD Good luck. But Ubuntu 18..04 external slow :o in VMWare Player I really don't understand why does it happen with newest version of Ubuntu 18.04 because it removes Unity Desktop format is gone. And uses only Gnome/ Gtk Please remember use Gtk Sharp 3.22 for Net core by Cra0zy ( MonoGame Developer )

I think you need 2. computer or laptop for testing SharpLife.
Posted 11 months ago2018-07-19 18:02:34 UTC Post #340198
Alright i think we've talked enough about Mono, this project uses NET Core so all that's irrelevant anyway.

Progress update:
User posted image
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.
Posted 11 months ago2018-07-19 19:18:55 UTC Post #340199
Wow how did you load bsp and wad?? Do you use assimp-4.1 right?

Because assimp 4.1 is best strong loader for mdl and smd and obj and more any formats like blend fbx and more - if you like than you can merge more unknown formats into Half-Life with fbx files like Unity or Unreal Engine.

You mean door or camera control? It is very old and it has possible from Quake 2 with C# I found https://github.com/jacqueskrige/quake2-csharp-xna ( I don't know if you found func_door than you can copy from old c# files into new :) If you don't know how is parser for entities

And how is collision? Like I found https://github.com/livinamuk/OpenTK-simple-scene
Posted 11 months ago2018-07-19 19:43:24 UTC Post #340203
I wrote the code to load both file types.

I've only completed these two things, i haven't even started on entities.
Posted 11 months ago2018-07-19 19:45:10 UTC Post #340204
Than good luck I hope your sharplife works fine until we play under sharplife with more rendering like Unity or Unreal Engine.
Posted 11 months ago2018-07-19 21:32:45 UTC Post #340206
You have admirable patience to keep engaging him, Solo. Endlessly contrarian is the impression I've gotten.
Jessie JessieLadytype
Posted 10 months ago2018-07-20 13:40:24 UTC Post #340207
Yeah I found example but it is really old. You can check "custom collision" written from C# only. ( No helping by c++/c dlls via DllImport )

I think you can download subversion tool and check svn of https://code.google.com/archive/p/csharpgameprogramming/source/default/source?page=2

You can see how did writer with old initial Game Programming book and he uploaded to google code page.

I think it is recommend for SharpLife with sometimes like door or entity or teleport I have found book in live-book ( It has up to 40 pages for test in ebook. I have readden that

My brother bought for me book Game Programming Serious Game Creation ( I know it is very old ) But it is important to understand. I hope you have to get or to merge more details of C# files from svn If you tried... Good luck
Posted 10 months ago2018-07-20 14:14:56 UTC Post #340209
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.
Posted 10 months ago2018-07-20 14:36:59 UTC Post #340210
Reminder that Half-Life SDK code is not compatible with the GPL2 (Quake 1/2 source releases) and that projects like Xash3D, that violate those two licenses by mixing them have had disapproval by Valve.

So if you can (if you don't use Valve code directly), change the license on your code that's on git repo to be licensed under something GPL compatible instead.

That is, if you want to use Quake code.
eukos eukosOriginal Cowboy
Posted 10 months ago2018-07-20 14:48:17 UTC Post #340211
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.
Posted 10 months ago2018-07-20 15:04:45 UTC Post #340212
Your lack of care and knowledge in regards to software licenses is worrying.
Valve may not care about these projects but the Free-Software-Foundation and Zemimax might.
Valve doesn't approve of Xash because they used leaked code, not because of the license.
Sure, Xash3D may use leaked code in addition to GPL and HL1 SDK code. That doesn't change the fact that the GPL prohibits merging code with a license like the one in the Half-Life 1 SDK. This is not just a concern for Valve, but also Zenimax and the FSF.
Even if they don't approve, if they don't send a cease and desist it doesn't matter anyway.
It may not matter to you, but it matters to anyone that is using your software (which is what this is all about, right?). Some may depend on it and get screwed later down the line because you don't actually own the rights to the code.

I know people who actually dealt with Zenimax in regards to the Quake engine license (This was for Xonotic's standalone release). They still license it (for about 10 grand) and they'll negotiate a license with you. However they'll gain ownership over any changes you make and you start off with the original Quake 1 sourcecode release (you can't expect to buy a license and use something like the Darkplaces engine, because of the GPL code).

They have dealt with C&D's over the past decade, in both the Quake and Doom community. Don't push your luck.
eukos eukosOriginal Cowboy
Posted 10 months ago2018-07-20 15:22:03 UTC Post #340213
@SoloKiller okay no problem - I thought you have not books :D

@Original cowboy,

I didn't push his luck just I support for Solokiller If I have found somethings...
Please don't shoot mw! I am innocent German.
Posted 10 months ago2018-07-20 15:54:58 UTC Post #340214
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.
Posted 10 months ago2018-07-20 19:17:08 UTC Post #340215
@SoloKiller you're right. I think I need learn with veldrid. :/

How did you have success if you have experiences of veldrid? It looks very hard like very close to VulkanGL's commands "commandList". Did you have found many example written with veldrid.

I really want learn and I will help to expand with SharpLife if I have to add more details like Unity's or Unreal's features
Posted 10 months ago2018-07-20 19:27:48 UTC Post #340216
Quake is C with some assembly, which can't be used in C#.
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.
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.
I beg to differ. The game-logic from Deathmatch Classic, although it may be C++, is actually converted from the Quake 1.06 progs code.
A language that doesn't even have a concept of integers.

If Valve didn't own the licensed Quake code, that'd be, for example, a breach - if it was based off the GPL-released code and they didn't adjust their license properly to comply.
and the Quake license states this:
What you quoted is from the paragraph about modification of GPL2 code.
This does not allow you to take Quake code and put it into non-GPL works under any circumstances. It applies to your own modifications and when you can relicense them as something else. The license clearly states that once your code depends on working with GPL code, your code has to, I quote: "be on the terms of this License"
Thus, no licensing issues.
As long as you don't use any Quake code (converted, reformatted, copy&pasted etc.) you'll be fine.
eukos eukosOriginal Cowboy
Posted 10 months ago2018-07-20 20:17:04 UTC Post #340217
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.
Posted 10 months ago2018-07-22 10:44:35 UTC Post #340224
I'm seriously considering swapping to Veldrid for Sledge. The API is way better than the half-assed OpenTK wrapper I've rigged up, and you get Vulkan/DirectX11 support for free. I've been doing a few tests and it embeds into Winforms with multiple viewports very easily. It's a bit inconvenient to require both .NET Framework and a bunch of .NET Core DLLs at the same time, but I can wait until .NET Core 3 is out which will ship with Winforms support out of the box.

Your last screenshot inspired me to try and write my own BSP renderer, I'm running into a lot of walls at the moment with Sledge and I need something different to play with for a while.
Penguinboy PenguinboyHaha, I died again!
Posted 10 months ago2018-07-22 12:14:42 UTC Post #340225
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.
Posted 10 months ago2018-07-22 12:48:52 UTC Post #340226
@PenguinBoy I think you need use Gtk Sharp 3.22 because GUI for Net Core

And if you want know how do you embed Veldrid into Gtk Sharp 3 just use UniversalBackend It is my Github repository for MonoGame But I will try for Veldrid's embeddirator to Gtk Sharp 3

For Windows 10 Users:
Do not forget to install Msys2 ( x64 or x86 )
If you don't like with msys2 than you make sure same github Gtk Sharp 3.x Installer ( x64 ) If you check same - But you need make sure themes and style ( I think up to ca 100 or 200 mb )into bundle.

Example:
Environment.CurrentDirectory = System.IO.Path.Combine("x64", "bin"); It is bundled runtime in Net 2.0
For Gtk Runtime 3.x 64 Bit or 32 Bit.

For Linux ( Ubuntu or CentOS whatever )
Please remember install libgtk3 or libgtk3-dev

For Mac OS Users:
Install JHBuild and compile it.
Posted 10 months ago2018-07-22 14:23:07 UTC Post #340227
Yeah it works in Winforms, but pulling .NET Standard into a .NET Framework project adds about 100 extra DLLs, at that point you might as well just use .NET Core to begin with. (Though I suspect the extra DLLs may just be shims to the framework, since they're all pretty small)

Sledge will support extra formats with the plugins in the latest branch, but at the moment it's... not too great, stability wise. Which is why I'm looking into doing some side projects to polish up my 3D rendering skills.
Penguinboy PenguinboyHaha, I died again!
Posted 10 months ago2018-07-22 15:27:41 UTC Post #340228
@PenguinBoy, so sad because WinForms is died now. WinForms is never released to NetCore. We use for Windows simple UWP/WPF I think sure If you try Veldrid Rendering into UWP or Gtk Sharp 3.

But UWP supports only DirectX ( SharpDX ). I hope you have to try with veldrid and user interface.
Posted 10 months ago2018-07-22 21:37:19 UTC Post #340229
Posted 10 months ago2018-07-23 02:19:40 UTC Post #340231
@Penguinboy thanks I am surprised. I have luck that I bought Paint.net from Windows Store. I will look out if it has net assembly. ) you can try Paint.Net's WinForm.

@Solokiller, how is your work in process? Rendering nsp and wad and can we have sources :P
Posted 10 months ago2018-07-23 06:28:17 UTC Post #340232
PenguinBoy said:https:/blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications
Oh boi, I can't wait to see this in action in Sledge.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 10 months ago2018-07-23 06:55:12 UTC Post #340233
@Separd: Yeah if you don't like to want wait for next release - I recommend you can try with Gtk Sharp 3 net standard version - If you have enough experience of C# than you can try with MonoGame or OpenTK. MonoGame has binding to Gtk Sharp 2 / 3 and WinForms. or OpenTK with Winforms ( same Sledge ) or Gtk Sharp 3 ( my latest journal ).
Posted 10 months ago2018-07-23 07:59:50 UTC Post #340234
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 :P
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.
Posted 10 months ago2018-07-23 19:14:57 UTC Post #340239
Thanks but I got many errors of many assemblies if I open Visual Studio 2017 ( very latest version ) shows me many unable to find assemblies like Sixlabers or any incompatible net assemblies

How do I fix?

What is your using nuget or myget server if you use almost.

EDIT WOW you use only myget, right?

I see sdl2-cs from nuget but it throws error and I try to add from sharplife/assemblies/sdl2-cs.dll
It works fine.
Posted 10 months ago2018-07-23 19:47:52 UTC Post #340240
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.
Posted 10 months ago2018-07-23 20:19:56 UTC Post #340241
Yes It is very nice. Sorry I forgot to say before I have got update than It seems not working.

How do I fix? Where is working directory of sdl2.dll ?
Just Half-Life\sdl2.dll or sharplife_full\cl_dlls\sdl2.dll ?
Posted 10 months ago2018-07-24 14:40:43 UTC Post #340246
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.
Posted 10 months ago2018-07-24 15:16:04 UTC Post #340247
Oh @SoloKiller, I already upgraded Net Core 2.1 too

I really don't know why does Half-Life stopped to work if I call hl.exe -game sharplife_full +developer 2

than it closes fast and goes back very short time with window shows and quits.

Why does it happen? That is why I am using net core x64 - It is wrong or correct?

Happens with SharpLife
Posted 10 months ago2018-07-24 16:11:02 UTC Post #340248
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.
Posted 10 months ago2018-07-24 17:14:23 UTC Post #340249
That is correct - I am sorry for my bad because I am typical 64 bit lover.

Because I saw many creators like MacOS Users no longer support for x86 because Mac OS was since new powerful intel with 64 bit version and Linux uses only 64 bit version. That is why I should use 64 bit . It happened now. And why do Valve Software workers not convert Half-Life in 64 bit? I think Americans are lazy.

Thanks for explanation!

Hahaha! I have luck because I need SDK of x86 bit and copy to sharplife_full\assemblies than it works

Yay wow excellent work - hehe I will help you about width and height parameters in veldrid.
Posted 10 months ago2018-07-24 18:05:22 UTC Post #340250
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.
Posted 10 months ago2018-07-24 21:06:27 UTC Post #340251
@SoloKiller, thanks!

Why does SharpLife not load custom map file. If I load other map into SharpLife.

Example your test_empty_map replaces into my map and I show - eh? Lol you have embedded map into net assemblies right? But it doesn't see to load other maps.
Posted 10 months ago2018-07-24 21:57:55 UTC Post #340252
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.
Posted 10 months ago2018-07-24 22:39:24 UTC Post #340253
Okay okay i am sorry for forcing that. I will try to make own....
Posted 10 months ago2018-07-25 15:55:46 UTC Post #340257
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.
Posted 10 months ago2018-07-28 11:20:29 UTC Post #340303
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
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.
Posted 10 months ago2018-07-29 10:52:44 UTC Post #340316
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.
Posted 10 months ago2018-07-29 20:54:38 UTC Post #340325
User posted image
Added a console.
Posted 10 months ago2018-07-29 22:43:13 UTC Post #340329
Wow nice implementation of command system. Keep work! Don't give up! Until parsing to entity and loading with detailtextures and bumpmapping - We are hopeful that you know how does engine in C# work.
Posted 10 months ago2018-07-31 19:37:11 UTC Post #340349
User posted image
I improved the console a bit so text can be selected. Auto scrolling doesn't work quite the way i want it; when text is added it will scroll the frame after it's been added because ImGui doesn't know the new content size yet, so it has to be delayed. This also means that a constant flow of text will delay scrolling by quite some time.

I've also reworked networking to make sure clients are fully disconnected before allowing them to connect again, and server shutdown and restarting with the map command works properly now.

I added in network message trace logging to help debug things, as well as logging state changes.

With that all done, i can now begin to work on networking the string lists. Once that's operational, i can add in the code to precache resources on both the client and server side (ideally using the same code).
Posted 10 months ago2018-07-31 20:45:41 UTC Post #340351
Wow nice job! Yeah ImGUi has more feature you can check github and ImGui
Or More details for GUI?

I hope I can help you about GUI....
Posted 10 months ago2018-08-01 15:12:19 UTC Post #340361
I'm not going to worry about anything UI related for a while.

I've implemented network string lists. These are lists of strings that can be networked to clients. Any number of these can be created with any number of strings in them.
Once a string has been added, it cannot be modified or removed.

The purpose of these are to send large amounts of indexed strings to clients. For example, the model precache list is currently being sent this way.

New strings can be added at any time, and they will be sent to clients as well. This allows late precaching to be implemented.

One important feature is that every string can have binary data attached to it. This data comes in the form of Protobuf messages.
Every message type that you want to add to lists must first be registered so that it can be sent efficiently.

Different strings in the same list need not use the same binary data type, or any binary data at all.

Binary data can be changed at any time, which is useful when updating data. For example, you could send the map cycle and include basic information about it, such as how many players are required for the server to switch over to it. Another example is a map vote, and the current number of votes for each map.

You can add event handlers to respond to the adding of new strings on both the server and client, which can be useful to load models automatically when they're needed.

With this functionality being available, i can now implement proper resource precaching to enable the loading of the map as it should be, as well as loading other models and sprites. Adding support for sound precaching should also be simple.

On the subject of sound, i contacted Firelight Technologies about using FMOD, since their non-commercial license had some confusing wording. They gave me the green light to use FMOD in this project since it's non-commercial, which means there are no legal issues regarding the use of FMOD. I may implement a basic sound system soon to have that operational as well.

As far as networking goes, the only remaining major feature that requires implementing is networking objects. This requires a bit more work since this relies on delta encoding (sending only changes to the client), and i want to avoid hardcoding the engine's networking to an entity based system, so i'll probably come up with a generic system that can also be used to send any other list of objects to clients, whether using delta encoding or just sending the entire object.

That shouldn't be too difficult, and combined with C#'s reflection facilities it should be relatively straightforward to make classes serializable this way.

I'll begin working on object networking after i have a rudimentary entity system up and running in game code.
Posted 10 months ago2018-08-02 11:59:04 UTC Post #340377
Do you mean FMod Wrapper Click here? If I am wrong than you can skip...

How does Half-Life detect current port of server like 27015, 27020 etc... ? Can you try with server example from Half-Life online game server than you can try with SharpLife. Good luck. I understand you know that...
You can read of lidgren.network - wiki
Posted 10 months ago2018-08-02 13:21:04 UTC Post #340381
There are source files in the FMOD studio API installation that can be used to dllimport FMOD functions. I'm sure those are better maintained than any third party wrapper, but it seems that that wrapper is a more complete wrapper. I'll see which one's best for what's needed here.

I am going to change how SharpLife loads the game libraries so that it's hardcoded to the ones used now. This change is for the following reasons:
  1. The game libraries will be built as needed, without needing a manual build before running
  2. Modders should use distribute SharpLife as a whole mod, not as a mod for SharpLife
  3. The most important reason: the FMOD non-commercial license does not allowing distribution of the library in a game engine
To keep SharpLife as a mod and not an engine, the engine and game parts must remain tied together so that it counts as one entity.

This won't really affect modders since they'll want custom engine code anyway, and it'll simplify the code that accesses game code.

Edit: i discussed this with another programmer who has some experience with both FMOD and OpenAL and it seems that using OpenAL may be the better way to go here. FMOD's definition of a game engine fits SharpLife, even if it's running as a mod. OpenAL on the other hand has a modern and free implementation that has no licensing restrictions.

I found 2 C# wrappers that could be used:
https://github.com/flibitijibibo/OpenAL-CS
https://github.com/opentk/opentk

OpenTK is the more well known and used one, and both have .NET Core support.

At this point no code has been written yet, so the biggest issue is making sure it's all legal.

If anybody has any thoughts on the matter, i'd love to hear them. Audio support won't be required for some time, so we can figure this all out.

As far as reworking access to game code is concerned, i'll change that regardless to make things easier for everybody.
Posted 10 months ago2018-08-02 14:17:59 UTC Post #340382
@SoloKiller!

I am using only OpenTK and Gtk Sharp 3.22

But it is very same like MonoGame because OpenTK's and MonoGame's implements and classes are very close same like enum Boolean.True or method GL.GetUniformLocation() etc

MonoGame's Github
MonoGame's OpenAL is soft_oal = Software's Open's Audio Layer. I think you need generate with vcpkg as OpenAL for! x86 Bit. And find DLLImport to OpenAL.dll from MonoGame-Audio's source. But I don't test it. Because I am deaf. I forget to say how do you hear with soft_oal.dll - MonoGame has support net core too - Just find in nuget / myget!
Posted 10 months ago2018-08-04 11:32:23 UTC Post #340411
I recently used Alure to manage OpenAL and I found out it is a lot easier to be used than using OpenAL directly. It uses the ZLib license so it is permissive.

It is coded in C++ and currently there is no wrapper to .NET Core, but it may be worth a look. Here: https://github.com/kcat/alure
Posted 10 months ago2018-08-09 06:36:37 UTC Post #340457
I looked into Alure, i don't think it's of much use in managed code since OpenTK already wraps the native API. I've built a basic program for playing sounds, it looks like it should be straightforward to use.

The only problems are that there is no file loading provided in the library itself and that there's stuttering on shutdown if the OpenTK AudioContext is disposed immediately after a sound has stopped playing. It only seems to happen with the wav test file i'm using (scientist/c1a0_sci_crit2a.wav from Half-Life), the mp3 file i tried (media/Half-Life11.mp3) didn't have that problem.

I can leverage other libraries to load various file types, so it's not that hard to implement.

I've also got a basic object list networking system up and running. I can serialize properties from an object to a stream and de-serialize them into another copy. It supports delta encoding and networking arbitrary length lists, as well as generics. It needs more work to be fully functional, but the important parts are working now.

Once the object list system is finished, i can implement a basic entity list and implement sky name settings. That should cover loading the BSP file itself, and once i've got the entity class hierarchy going i can put brush entities where they should be.

I've also committed the change to directly reference game assemblies in engine code, and i've merged what's left of the game config file (game name for display purposes) into the engine configuration.

I'm a bit busy with college work at the moment, so it'll be a few weeks before i can wrap these things up. Things are moving though, so it should work out.
You must be logged in to post a response.