Half-Life Enhanced Created 1 year ago2016-07-15 18:57:29 UTC by Solokiller Solokiller

Created 1 year ago2016-07-15 18:57:29 UTC by Solokiller Solokiller

Posted 1 year ago2016-09-05 04:23:10 UTC Post #331575
Oh reading about rockets targeting something could you also add an entity follow entity script?

Not sure if you played my mod but in the final outro map you can see an Osprey going down and I wanted explosions and sprites following while going down (just as seen in Point of View) ofc something like that worked only with Spirit. And Spirit therefore lacked most opfor entities a devils circle... Kinda sad.
Posted 1 year ago2016-09-05 08:19:53 UTC Post #331577
You can use MOVETYPE_FOLLOW to attach entities to other entities. It should also work with attachment points so you can at least fake attachments to something other than the entity origin. Eventually parenting will be added, but the codebase needs more cleaning up first.
Posted 1 year ago2016-09-07 05:10:27 UTC Post #331593
Ya MOVETYPE_FOLLOW is what I was thinking about, exactly.
Posted 1 year ago2016-09-10 09:31:10 UTC Post #331624
On my fork, I have added support for the AppVeyor CI in the "appveyor" branch.

For those who don't know what a CI is, it's some kind of "build bot", every time I push a commit, that "build bot" perform the compilation (in both Debug/Release and in all configs with and without AngelScript, Opposing Force stuff...). It will tell if X commit can be built successfully or not, we can also ask the bot to deploy (publish) the binaries if a build is successful too (but I've disabled it for the time being) and perform tests (also disabled because we don't have tests).

AppVeyor is for Windows only, if you look at the "travis" branch on my fork, you will see that I still have trouble getting Travis to work for Linux (because of the SDL2 i386 dependency) and maybe OS X in the future.

To see more clearly what I'm trying to achieve, look at OpenRCT2's GitHub README (an open-source implementation of RollerCoaster Tycoon 2).

@Solokiller : If you are interested to have AppVeyor merged in "upstream" (your repository), tell me and I'll make the PR.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-10 09:45:27 UTC Post #331625
That looks really nice, great job :)
Does it also support Mac builds? It would be helpful in getting any Mac specific issues fixed it if does.

If you think it's ready to be merged you can make a PR for it.
Posted 1 year ago2016-09-10 10:53:32 UTC Post #331626
A bit off-topic but I have a really minor suggestion I don't remember having seen here: Is it possible to disable the automatic selection of the new weapon just picked up? It's an extremely frustrating HL1 feature that stuck with most mods like a curse.
Posted 1 year ago2016-09-10 11:33:37 UTC Post #331628
Yup, that's possible. The rules for this differ slightly between singleplayer and multiplayer, but you can add a higher level check to override all of that.

This is where it does that: https://github.com/SamVanheer/HLEnhanced/blob/master/game/server/entities/player/CBasePlayer.weapons.cpp#L292

Adding a client cvar check here should do the trick just fine.
Posted 1 year ago2016-09-10 12:24:16 UTC Post #331629
So here are the lines which used to make me suffer for so many years... evil eyes

Thanks! Now I know what I will have to remove!
Posted 1 year ago2016-09-10 20:17:25 UTC Post #331631
@Solokiller : I've made the PR, AppVeyor is for Windows only, I'm working with Travis for the Linux builds and OS X (Mac) in the future. But I need to find a way to deal with that "libsdl2-dev:i386" dependency that unfortunately is not whitelisted.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-12 16:24:23 UTC Post #331637
I've merged in your pull request and pointed the readme to the account i made. Both debug and release have succeeded.

I'm going to test out the weapons code using fakelag, i've noticed some issues with some weapons not behaving quite right.

EDIT: fixed some issues, will push them out later.
Posted 1 year ago2016-09-13 09:34:46 UTC Post #331646
I've fixed some issues with the weapons code, in order of resolution:

The ammo_* variables in CBaseEntity have been removed. All code now directly references CBasePlayer::m_rgAmmo's values for ammo in both the server and client versions. This fixes some prediction issues where code wasn't referencing an ammo_* variable.

TabulateAmmo has been removed since it no longer did anything, which simplifies some code as well since it no longer has to synchronize values.

Spore ammo is now networked as well in vuser4[ 0 ].

The M249 now tracks the reload time using the weapon time base, which is now networked to fix animation glitches.

The Pipe Wrench now networks its big swing state to prevent animation glitches from happening due to the server's animation being forced onto the client. That can happen if the client is ahead of the server by a few frames, networking that state ensures that the client stays in sync.

There are still glitches, but i can't fix them because they happen as a result of how the prediction system works.
When there is a certain amount of ping (noticeable at 100+) it starts to skip weapon attacks if they have a short interval. For example, the Glock and Desert Eagle can end up skipping animations and sound effects. I've experienced extreme cases where the weapon no longer predicts any attacks for whole seconds.

This happens in vanilla HL as well, and is a consequence of the engine rewinding frames, and skipping over some moments in the process. It might be happening because the engine only stores up to 64 frames worth of data to rewind, so if you have a high ping it can forget data.

Additionally, melee weapons don't predict hits on the client, so they'll play a miss animation first, then switch to a hit animation when the server data gets processed. The more ping you have, the more visible this will become.
I might be able to add hit detection to the client, but it might make things worse in competitive games if the client predicts a hit that ends up missing.

I've got some stuff planned for the near future, so i'll elaborate a bit on those:

I'm going to rework the save/restore code to separate the engine and server save/restore versions. Currently, the engine asks the server to handle the saving and restoring of some data, which requires the code to remain compatible with the engine's TYPEDESCRIPTION data.

By separating it, i can completely rewrite the server's code if needed. I'm going to take advantage of this to add new fields to TYPEDESCRIPTION.

For starters, you'll be able to add fields that will be automatically initialized by DispatchKeyValue. For example, if you have a float that is initialized like this:

[quote]
if( FStrEq( "my_keyvalue", pkvd->szKeyName ) )
{
m_flKeyValue = atof( pkvd->szValue );
pkvd->fHandled = true;
}
[/quote]

You'll be able to automatically have it be initialized by adding it to the datadesc like this:
DEFINE_KEYFIELD( m_flKeyValue, FIELD_FLOAT, "my_keyvalue" )
This will add the field to save it and initialize it. There will also be an optional parameter to disable saving:
DEFINE_KEYFIELD( m_flKeyValue, FIELD_FLOAT, "my_keyvalue", false )
I'm not 100% sure i can add this optional parameter, i'll have to do some macro magic to make this work.

Second, Think, Use, Touch and Blocked functions will be stored in the datadesc as well. Currently, these functions need the EXPORT keyword to dllexport the symbols so the engine can look them up. This requires the use of platform specific code since different platforms have different name mangling rules. It's also more expensive since it routes through the engine, and represents a 32 bit dependency that has caused problems in the past. You can't compile the game for 64 bit without breaking support for the engine's function lookup.

This will remove that dependency, and centralize all metadata for entities in one place. You'll be able to look up any functions registered in the datadesc, though i might not store the type of the function, since it should be type safe by design, and supporting more function types in the future requires an abstract design.

This also means that you'll be able to look up any entity's keyvalues by name as long as it's in the datadesc. I'll also add a way to define fields that are neither automatically initialized nor save/restored to allow it to be used for purely metadata storage for a variable.

I can probably add 64 bit data type support as well.

Those who are familiar with Source will notice that some of this is also available in that, and has similar names. That's intentional to make it easier to understand. I came up with these ideas in response to problems i encountered, which also happens to be what Valve did. Rather than name it differently for the same of being different, i'm keeping them similar to make it easier to find information on the subject.

The aforementioned client side redesign for predicted entities will happen sometime after this. I think i might be able to completely replace the engine's temporary entity system. From what i can tell, the effects API is used by the engine as well, and uses the same object instance.

This means that i might be able to swap out the functions with my own, and control the list of entities. That will allow me to control the number of temporary entities, how they're allocated, and how they're designed. The engine accesses some member variables, so that limits things a bit, but as long as the beginning of the base class has the same layout, it should be fine.

This will hopefully allow me to better control temporary entities, sidestep the overflow issues and possibly even use a common interface for some temporary effects for the server and client versions.

There are still limits in the engine regarding the number of visible entities and beams, but this should make things a bit easier to work with.

It'll take some more research and experimentation, but based on what i've seen so far this is perfectly possible.

After that i'll return to monster code updates, there's still much to do there. I'll probably do some smaller stuff here and there if i find anything that needs doing.

On another note, last week i made a small test project to try out an idea i had. I figured that you could create a new engine that runs as a mod under GoldSource, so i set out to figure out how to do this. It took a few hours, but i got it to work.

The engine i made is pretty minimal, all it does is hijack the client or server and run itself, then hides the engine window and creates its own. It also extracts the command line and has support for console commands, cvars and command execution. This code is based on Quake, which is why the readme and GNU license for it is included.

You can check out the code here: https://github.com/SamVanheer/PrototypeEngine

I hope this will prove useful to anyone wanting to create an engine that runs under GoldSource as some form of enhanced GoldSource engine. It would take a lot of work, probably a year or more, but you can probably replicate the engine's features and use the engine's access to Steamworks to implement master server support and authentication. The engine itself authenticates the local user before loading game libraries, so you cannot run this if you don't own a copy of Half-Life that can run mods.
Note that i currently cannot legally tell you how to access Steamworks, since i haven't received word from Valve on the matter. You'll have to figure that out on your own.

Remember that Quake's license requires your work to be open sourced, so if you don't want to do that, you'll need to remove any Quake code that's being used. Currently, only the code in the console directory uses Quake code, so it's easy enough to remove.
Posted 1 year ago2016-09-13 11:58:05 UTC Post #331650
That's a long list of changes ! Especially that prototype engine, great work ^^

I see you were trying to get Travis CI to work too, I have refactored some parts of the file along with your changes, the build still fail but one day we will arrive. ^^
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-13 12:53:47 UTC Post #331651
Thanks, i'm trying to improve things as much as possible so as long as i keep finding things i will keep working.

I'm still working on travis support, i just got it to compile without failing to find include files, so maybe it'll link correctly as well.

EDIT: Good news, it compiles and links successfully. I'm going to clean it up a bit so it doesn't have unnecessary parameters and see what the minimum requirements are for it to compile successfully.

EDIT2: The removed parameters weren't needed, so it's all good now. Essentially it needs an i386 library to be installed, and the SDL2 and VGUI libraries to be local to link with them.
Posted 1 year ago2016-09-13 16:49:29 UTC Post #331659
I can provide a few hints, cause I spent months fixing the monster navigation code. It's really broken. I can show you some of my fixes too, if you want, but maybe you could actually come up with better solutions than mine.

Anyway, few things I noticed:
  • CheckLocalMove is inaccurate, and because of this, RouteSimplify erroneously simplifies paths that end up being invalid. For example, on stairs npcs will try to approach targets via a straight line.
I solved this by not letting RouteSimplify remove paths with a certain difference in height. This alone should make for less bugs on stairs. Also in BuildRoute I don't let it create a straight path with the same condition, and just turn set it so it goes straight to build a node path.

In the same regard, around line 801, this else clause will cause monsters to fail moving to a target, because of the same precision error:
https://github.com/SamVanheer/HLEnhanced/blob/53d9a4eabfbd37cde5c92a087a97f11b496ce43b/game/server/entities/NPCs/Monsters.cpp#L801

I changed my code to try and optimize paths in Move, whilst I only optimize straight between nodes in RouteSimplify.
  • In Move, I changed the check distance to be shorter, because sometimes the smaller npcs can fail in vents due to some weird false error with CheckLocalMove. My solution isn't really a complete fix, and there's bugs.
I'll try to remember what else I changed, but it's a massive rework, I'm still doing it, and the monster navigation code is really horrible.
Posted 1 year ago2016-09-13 17:11:25 UTC Post #331660
Thanks for the assistance. I'm eventually going to refactor the navigation code so it can be used to order monsters to a specific location, optionally using a set of nodes or path entities, when i do i'll review the rest of the code to see if there are any navigation issues anywhere in it. I'll keep your notes in mind.
Posted 1 year ago2016-09-14 07:43:28 UTC Post #331669
I've completed the first step of the save/restore overhaul. You can now define keyfields that are automatically initialized, and you can optionally not save/restore them. They can also be marked as not needing automatic initialization, turning them into fields that can be looked up by name, without any automatic behaviors. I was able to add optional parameters to the macro, so it's all very nice and simple.

I've also tidied things up a bit, and removed FIELD_POINTER. it was unused, and the comment for it stated that it should be removed anyway. Its purpose was already covered by FIELD_CHARACTER, since it is supposed to be used to store arbitrary binary data.

Next up is adding support for storing function addresses. This will eliminate the EXPORT keyword requirement.
Posted 1 year ago2016-09-14 15:07:51 UTC Post #331675
All Think, Use, Touch and Blocked functions are now stored in the data descriptor for the associated class, EXPORT has been removed. Save/restore now uses it exclusively to perform name and address lookups.

In addition to completely replacing the existing code, and making it platform agnostic, this now adds an extra safety check: if an entity sets a function that isn't part of its class hierarchy, it'll show an error in the console (debug only), since it can't find the entry in the entity's data descriptor. This helps prevent mistakes.

At some point i'm going to update the Set* macros to be template functions, allowing this check to be performed at compile time instead using std::is_base_of, and even when compiling release builds.

I've also fixed a rare crash in the CHudAmmo class where a dangling pointer was being accessed.

I also encountered a very strange crash that occurs in the engine; when i save the game right after blowing up a barrel in c2a5 and reload it, the game crashes after restoring. This doesn't appear to be caused by anything i did, since it also happens when running vanilla HL with AMX mod enabled. If AMX is disabled, it restores just fine.

I can't debug it due to the problem only occurring on Windows and not Linux, so if i ever find out i'll report the cause. Since it doesn't happen in vanilla HL, i can't report it yet, since they don't respond to issues concerning modded versions of the game.
Posted 1 year ago2016-09-14 20:39:26 UTC Post #331679
So I think we are almost done with CIs. Everything I'll say below is alrady in place since a few hours ago at the time I'm writing this, I just didn't had the time to explain because I had to go to university ^^

One of the huge improvements is that we have OS X VMs with working build processes, meaning that one of these days, HLEnhanced may get OS X compatibility in the future. However, I don't consider OS X as a priority right now because it seems that OS X relies on the Clang compiler (even if you try to use GCC like Linux), if you have the courage to look at the build logs of OS X, you will see a lot of warnings and errors to deal with.

A few days ago, if you wanted to see why a build was failing, you had to select the right VM and scroll the huge log to see which configuration failed and such, it was quite painful. Now with the revised build matrices for both AppVeyor/Travis, you can easily distinguish which VM is compiling for a specific OS with a specific compiler for specific options (Opposing Force/AngelScript/MariaDB), the best thing is that it will makes programmers lives easier, you can easily tell things like "building HLEnhanced for Linux with GCC 6 with Opposing Force and AngelScript is a success".

While this is a very good benefit, this comes with a bad one: timing. Because HLEnhanced allow you to switch between vanilla/Opposing Force and/or without/with AngelScript and/or without/with MariaDB, that makes 4 jobs to test them all, multiply that value by 2 because on Windows we are testing both Debug/Release configurations and on Linux we test with GCC 5/6 that makes 8 jobs for both Windows/Linux. From what I see so far, it takes around for both CIs to build everything. I've considered using the CIs caching option but that would be pointless because between each build the VMs are reset (you can't change that, that's how CIs works) and downloading the cache would take more time than downloading over and over again the dependencies and tools, even the documentation tell you that it's not recommended for that.

But the fact that it takes an hour to build isn't a big deal, CIs don't (and shouldn't) replace the traditional "build/debug/test on your own PC", they "validate" that modifications and/or code suggestions (as we call PR for "pull requests") aren't breaking any build for the platforms/tools/configurations/options we are targeting. I also hope that Travis will help a lot with porting to OS X since developing for OS X without a Mac is extremely hard.

About OS X, for the time being, there are 2 jobs for them which is vanilla/Opposing Force and they are "allowed to fail". When I'll get home at the end of Friday, I'll see about building an OS X VM with VMWare on my desktop PC and compile HLEnhanced's dependencies myself such as AngelScript, MariaDB, SQLite3... The build matrix might get updated again in the future to add more OS X related jobs. The day the OS X builds are a sucess, we will remove the "allowed to fail" function.

But, the most important thing is that I'm quite happy with how AppVeyor take care of the Windows builds and also how Travis does the same for Linux and OS X. It took a lot of time (and some help from Solokiller for Travis/Linux) to get them working properly but they are doing great jobs for HLEnhanced so far, I hope this will continue.

When HLEnhanced will reach a reasonable state, I might look at the deploying function of both CIs, in other words, as soon as the source code of HLEnhanced is updated and the build is a success, you could download the built binaries on the "Releases" section of HLEnhanced (or even HLEnhanced-Game).

Also, I have considered the idea of writing a new wiki page that explain the transition between Valve's work and HLEnhanced, I'll see what I can do on that part.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-15 10:28:52 UTC Post #331685
Great job getting the CIs up and running, it all works really well.
I just spent the past few hours getting the OSX build to succeed, and now it does :D

I had to fix a Windows specific header include and some library paths, now it works.

I'll fix the warnings it reports, it's mostly if statements that declare or assign to a variable without having a set of parentheses surrounding them, and operator new overloads not being declared noexcept.

Once we get it to compile without warnings or errors, we can have somebody try to run it on a Mac to see if it actually works.

I've also thought of making wiki pages for the updates, anybody that wants to use this to make a mod will need to know about the changes. Valve's documentation was never quite that good, but that doesn't mean we should skimp on it either.

We should probably reconfigure the CIs to make nightly builds, the current approach can result in far too many builds being made. Committing new game libraries every time a push is done can bloat the git repository quite fast, since binary data can't be compressed as well as text data.
Posted 1 year ago2016-09-15 14:42:07 UTC Post #331686
Great job for OS X Solokiller ^^

The vanilla configuration seems to work correctly, however, this isn't quite the case for USE_OPFOR :

/HLEnhanced/game/server/entities/rope/CRope.cpp:637:21: error: use of overloaded operator '+' is ambiguous (with operand types 'Vector' and 'double')
vec = ( vec * 10.0 + 0.5 ) / 10.0;

I'll see this weekend for building MariaDB, SQLite3 and AngelScript on OS X.

About the deployment, it seems we can tell both AppVeyor and Travis to deploy only if the commit is tagged, we could use this as "nightly builds". I'll make some tests on my fork.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-15 15:57:00 UTC Post #331687
That's probably happening because Vector has a constructor that takes a single float, which operator+ uses, since there is no operator+ for scalars.

I'll make that constructor explicit, since it's always been unsafe, and add operators for scalar addition and subtraction.

EDIT: This is now fixed.

Those deployment options sound good.

I just fixed a bug in the Egon gun's sound playback code. Basically it would sometimes continue playing the looping sound; you can find out what caused it and how it was fixed here: https://github.com/SamVanheer/HLEnhanced/blob/19396936af13e417e7f9eaf48c48c49699da03fb/game/client/ev_hldm.cpp#L1378

I'm going to take care of some small stuff now first, my todo list is getting a bit too long for my taste.
Posted 1 year ago2016-09-15 19:40:09 UTC Post #331688
I've fixed the following issues:
-The Egon gun would sometimes keep playing its run sound after stopping
-Vector scalar constructor was used for operator+ with scalar, didn't compile on OSX
-Tripmine weapon viewmodel used the wrong body when weapon prediction was turned off
-Weapon prediction now uses the body that is currently being used by the predicted weapon, rather than forcing a hardcoded body when synchronizing animations with the server version
-The M249 now networks its body, uses the correct body value when reloading to avoid suddenly changing number of bullets left. The number of bullets when playing the reload animation is unchanged, it looks kinda bad when you swing one bullet over it
-Hornet Gun and Shock Rifle no longer instantly recharge after loading a saved game
-Fixed ammo hud showing the magazine count for the last active weapon when all weapons are removed (weapon strip)
-Fixed multisource counting all multi managers as targeting it, rather than just managers that actually target it (bug caused by me)
-Shotgun pump sound now plays when holding down attack buttons, also plays when the last shell has been fired (was deliberately disabled before)
-Fixed the RPG and Python constantly playing their empty sounds when dry firing
Posted 1 year ago2016-09-15 22:29:49 UTC Post #331690
(was deliberately disabled before)
Sometimes I don't understand what Valve's programmers were thinking.
JeffMOD JeffMODCall 141.12
Posted 1 year ago2016-09-16 04:46:28 UTC Post #331691
They probably did that because they wanted it to only pump if a shell should be ejected. if you look at the HL2 shotgun it doesn't pump after shooting the last shell, and doesn't play the animation either. HL1's codebase was a WIP when it was released, so they may have been working on that feature at the time.
Posted 1 year ago2016-09-16 09:42:30 UTC Post #331694
I've changed the struct and enum declarations in the entire codebase to use a more modern approach. The old version looks like this:
typedef struct name_s
{
//Variables here
} name_t;
Variations exist where the typedef is done separately.

It's now done like this:
struct name_t
{
//Variables here
};
This has a few advantages:
-Reading declarations is easier, since the type name is always at the top
-Forward declarations are simpler (struct name_t vs typedef struct name_s name_t)
-Structures with no name_s can now be forward declared
-Using Go To Definition in Visual Studio goes to the actual definition, not to a forward declaration
-IntelliSense can find function definitions that were previously considered to be different due to the declaration using the struct name_s type and the definition using name_t
-Fewer type names are in the global namespace, which reduces the number of autocompletable type names, probably reduces the size of the IntelliSense database too

I've also standardized some struct names that were using name_s as their typedef'd type name.

This change exposed a fair number of cases where types weren't being forward declared and were instead using the struct name_s type name where the type was being used, which counts as both a forward declaration and a use of the type.

In some cases, function parameter lists have shrunk by a fair amount, for example:
Old:
void DLLEXPORT HUD_TxferPredictionData ( struct entity_state_s *ps, const struct entity_state_s *pps, struct clientdata_s *pcd, const struct clientdata_s *ppcd, struct weapon_data_s *wd, const struct weapon_data_s *pwd )
New:
void DLLEXPORT HUD_TxferPredictionData ( entity_state_t *ps, const entity_state_t *pps, clientdata_t *pcd, const clientdata_t *ppcd, weapon_data_t *wd, const weapon_data_t *pwd )
This syntax is easier to read, eliminates information you rarely need and is easier to use, since you never have to worry about the name_s variant.

I also corrected a forward declaration that was using the wrong name (cl_enginefunc_t was called cl_enginefuncs_t), which only worked because the type system only checks the struct name, not the typedef'd name.
Posted 1 year ago2016-09-16 19:40:30 UTC Post #331699
I've started writing some documentation for the wiki, I will admit that I'm not very good when it comes to explaining stuff (especially to a wider audience) but that's better than nothing.

Here is my W.I.P. version (from Markdown to PDF so that everyone can enjoy the power of Markdown) : http://shepard62fr.free.fr/hlenhanced/Documentation.md.pdf

For those who want the Markdown file to update/fix stuff or whatever :
http://shepard62fr.free.fr/hlenhanced/Documentation.md

Now onto OS X, it looks like Mac can also uses *.a files for libraries which is saving us the trouble of compiling AngelScript and SoloKiller's AngelScriptUtils, something I have discovered is that I can use Homebrew (the should have package manager for OS X) to install MariaDB with it's development stuff and "cherry on the cake", it also install a recent CMake version meaning that the "if/else" condition about CMake could be simplified. I'll keep digging around that and be sure to report any progress made on the matter.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-17 13:30:02 UTC Post #331708
That documentation is looking good, but i have a few notes:
-Entity classes require DECLARE_CLASS in order for datadescs to work properly. They rely on the ThisClass and BaseClass typedefs to get the right information at compile time.
-FIELD_POINTER isn't a duplicate of FIELD_CHARACTER, but FIELD_CHARACTER does the same thing, which is saving an array of bytes.
-The engine prototype i made isn't directly related to HLE, while i might expand on it to provide some more features i don't think i can legally develop it as an entire engine. Valve can tell me what is legal and what isn't, but i haven't received any communication from them yet.

It's looking good, it's already better than anything that Valve ever provided :D

The OSX compatibility with *.a files is good news, that'll cut down on the amount of cross-platform development requirements. I'll have to set up some automated builds for those repositories as well when i have the time, it'll help keep things simple in the long run. Adding unit tests will help too.

The CMake version requirements can be probably be lowered a bit since 3.6 is only needed for the Windows startup project configuration, which doesn't seem to be working anyway. As long as no other CMake 3.6 features are in use it can probably be lowered to 3.3 or 3.4.

I did some more work yesterday, i'll make a short list:
-The duplicate IVoiceTweak API has been removed, documentation has been transferred to the original one.
-Duplicate enums in ev_hldm.cpp have been replaced with definitions in the weapon headers.
-Most of the remaining float* usages have been changed to Vector&, pretty much all remaining uses are casts.
-The studio API returns Matrix3x4 pointers now, instead of pointers to pointers to pointers (to pointers) to float. Some matrices have one additional level of indirection, but the struct version has the same syntax for both.
-Duplicate types have been removed, such as an RGBA struct that was used only once and had identical layout to the new Color struct.
-GiveNamedItem will print out the name of the item it failed to create, so in cases where you programmatically give items it'll tell you which one failed.
-The map cycle code has been moved out of CHalfLifeMultiplay.cpp and refactored into a class. It's easier to understand now.
-Constants that were in CHalfLifeMultiplay.cpp have been moved into common headers, some of them could be considered game specific so putting them in the right header helps to locate them.
-MonsterEvent_t has been renamed to AnimEvent_t since it applies to non-monster classes too, and the HandleAnimEvent parameter is a reference now. Small stuff, but it makes things easier to understand (pointer can be null, reference shall not be null).

The list of things to do is getting smaller, but there is still enough to do to fill the rest of the year. At some point i'm going to have to decide whether to focus on further developing the engine prototype or working around engine issues in game code, since there will be overlap there.
Posted 1 year ago2016-09-17 21:55:25 UTC Post #331711
Posted 1 year ago2016-09-21 18:28:35 UTC Post #331747
It's looking good, i'll add some changes that i have in mind when i have some time.

I've added Co-op gamerules. There are 2 types of Co-op gamerules, implemented using the curiously recurring template pattern (see https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).

Singleplay rules are based off of singleplayer rules, which means you spawn with nothing, items don't respawn, etc. Multiplay rules spawn you with an HEV suit, crowbar and Glock, stuff respawns, etc.

The minimum changes that are needed for online co-op to work have been added: dying doesn't restart the level, you can't injure teammates unless mp_friendlyfire is enabled, and monsters can spawn in multiplayer.

I initially intended to implement this using the coop cvar, but the engine resets it between setting it during server startup and creating worldspawn, so i've instead added a cvar called sv_coop. For backwards compatibility purposes the coop cvar and gpGlobals->coop are set to 1 if any coop mode is active.

Strictly speaking setting coop to 1 uses singleplay rules and setting it to 2 uses multiplay rules, but since constraining cvar values isn't cheap (brute force checking every frame) any value other than 0 and 1 uses multiplay rules.

The listen server dialog has a dropdown for these options, co-op will override any other game modes so set it to "No" to disable it completely.

Once i get the Angelscript API going you'll be able to implement completely custom gamerules for co-op behavior with it, so any restrictions that exist at this time are temporary.

I've also converted all gamerules documentation to Doxygen and added some missing documentation. I've also moved CBasePlayer::PlayerRespawn to gamerules to allow the respawn logic to be overridden by gamerules.
Posted 1 year ago2016-09-23 09:54:50 UTC Post #331749
Sounds great. Since I think you've made some optimizations to the way the game handles multiplayer, do you have an idea if the multiplayer will run better than with HL's one and Sven Co-op's one?
Posted 1 year ago2016-09-23 10:36:48 UTC Post #331750
It will definitely run better than Sven Co-op since it has lower limits and handles stuff on the client that is server side in SC. It'll also be more efficient than HL since less data gets sent over. Overall the performance won't be that different from vanilla HL though.
Posted 1 year ago2016-09-27 21:20:39 UTC Post #331781
Here's my little "status report" if I may call it so.

I want to clarify some important stuff about what I said earlier, so I'm just going to quote myself:
Now onto OS X, it looks like Mac can also uses *.a files for libraries which is saving us the trouble of compiling AngelScript and SoloKiller's AngelScriptUtils, something I have discovered is that I can use Homebrew (the should have package manager for OS X) to install MariaDB with it's development stuff and "cherry on the cake", it also install a recent CMake version meaning that the "if/else" condition about CMake could be simplified. I'll keep digging around that and be sure to report any progress made on the matter.
And this is where I say that I am partially right and partially wrong at the same time. Yes, OSX can use *.a files, but I'm deadly wrong about not having to compile Angelscript and such because OSX can't use *.so (they only use *.dylib), even someone that know nothing about programming would have been smarter than me on that subject. As for saving one "if/else" for CMake and Travis, I'm going to forget that idea too, it causes more problem that it fixes.

My "newer experiments" on my OSX VM are going well so far, if everything stay stable and works, then we should be good.

No progress on the documentation/wiki as I don't really know what to add/change, I think I saw some grammar/typo/missing word problems that could be fixed by anyone.

I also have to dedicate most of my time to Half-Rats: Parasomnia (I do have a deadline to respect) and university so I don't have much time to give to HLEnhanced.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-28 18:33:35 UTC Post #331789
Sounds good, i'll get automatic builds up and running for the other repos to get error checking for Mac builds.

For documentation there's a fair amount that can be covered but relying on Doxygen will help here. You can write most documentation in the source files and autogenerate them, then link to them from the wiki. This means you'll have to upload them to the gh-pages branch to host them. I'll have to do this myself since creating branches can only be done by me.

I appreciate the assistance you've been giving, but there's no rush so if you have other things to do then by all means you should focus on them first :)
Posted 1 year ago2016-09-29 18:58:42 UTC Post #331807
I've enabled automatic builds for the AngelscriptUtils repository. One compilation issue occurred when using Clang, easily fixed though. It's a bit slow to start the OSX builds, but it's not that big of a deal.
Posted 1 year ago2016-09-30 21:00:09 UTC Post #331831
Wow nice job SoloKiller :) Did you add more features like Spirit of Half-Life, right? env_fog in our Half-Life Enhanced. Vanilla SDK?

Wow keep our work!

Please do not forget to add realistic water like Trinity Renderer or Meta Renderer 1.5c or Flat-Life

We need important features for HL Vanilla.
  • realistic water
  • realistic fluids like lava, slims or color like feature from Portal 2
  • realistic weather ( if you would like to create high poly clouds
  • normal map and speculation map for textures like from wad , rain if sun or light moves to rain you will see rain looks realistic from aurora or whatever you would like to improve more features for vanilla
  • normal- and speculation-map and details to models
and more..

Because we want develop strongest mod hl vanilla.

Okay.. I will help if I have experience than I give you more

And do not forget to add limit lightmaps upto 4096 or more ... if you would like to optimize because we don't get error message "Allocbloc is full!" if you create largest maps example largest hallway or biggest warehouses if they like high detailed looks... Or long rail connections for examples. I hope you accept my idea....

And how do we get very stable high compilers csg, bsp, vis and rad upto unlimited space if you create biggest warehourse example 8192 x 16384 x 512 it is very big and more things like machines or whatever... than high vanilla compilers ( csg, bsp, vis and rad ) should compile completed without "Check problem was is an error..." It doesn't stop just compilers will "compile" until completed vanilla usable bsp files...

PS: You know if I create example 20.000 x 16.000 x 1.000 hollowed room from Jack hammer / Valve Hammer Editor than vhlt stopped to compile because it can't compile full cause many lightmaps that is why how do we crack "unlimited lightmaps" if vanilla compilers would like to compile over than 65.000 x 65.000 x 65.000 than it is whole completed bsp for example plane or helicopter flies unlimited biggest hollowed skybox or spaceship ( Darkstar without cuting map )

That is why we need to create advanced strong compilers for Half-Life vanilla
Posted 1 year ago2016-09-30 21:11:32 UTC Post #331833
Did you add more features like Spirit of Half-Life, right? env_fog in our Half-Life Enhanced. Vanilla SDK?
SoHL's fog code is ugly.

[quote]Please do not forget to add realistic water like Trinity Renderer or Meta Renderer 1.5c or Flat-Life

We need important features for HL Vanilla.
  • realistic water
  • realistic fluids like lava, slims or color like feature from Portal 2
  • realistic weather ( if you would like to create high poly clouds
  • normal map and speculation map for textures like from wad , rain if sun or light moves to rain you will see rain looks realistic from aurora or whatever you would like to improve more features for vanilla
  • normal- and speculation-map and details to models
and more..[/quote]

Unless Solokiller tell us otherwise, HLEnhanced's purpose is to modernize the working environment, fix bugs, document and optimise, so don't expect "huge" enhancements such as "renderers, particle systems, audio engines...". Also, weather is already there, it's the same as Counter-Strike.
And do not forget to add limit lightmaps upto 4096 or more ... if you would like to optimize because we don't get error message "Allocbloc is full!" if you create largest maps example largest hallway or biggest warehouses if they like high detailed looks... Or long rail connections for examples. I hope you accept my idea....
If you have "AllocBlocks" error(s), then it's your fault, not the engine's fault. Lightmaps up to 4096 are pointless.
And how do we get very stable high compilers csg, bsp, vis and rad upto unlimited space if you create biggest warehourse example 8192 x 16384 x 512 it is very big and more things like machines or whatever... than high vanilla compilers ( csg, bsp, vis and rad ) should compile completed without "Check problem was is an error..." It doesn't stop just compilers will "compile" until completed vanilla usable bsp files...
1) We already have some pretty powerful compilers, they are called VHLT.

2) In computer science, everything has a limit, so your "unlimited space" will never exist even on a modern engine like UE4.

3) The goal of a compiler is to compile, not to "make the coffee for you".
PS: You know if I create example 20.000 x 16.000 x 1.000 hollowed room from Jack hammer / Valve Hammer Editor than vhlt stopped to compile because it can't compile full cause many lightmaps that is why how do we crack "unlimited lightmaps" if vanilla compilers would like to compile over than 65.000 x 65.000 x 65.000 than it is whole completed bsp for example plane or helicopter flies unlimited biggest hollowed skybox or spaceship ( Darkstar )
1) Since the era of Quake, BSP has a problem, it wasn't well designed for outdoor environments (remember that Duke Nukem Forever was on Quake engine and they switched to Unreal because they had trouble to render the Nevada desert ?).

2) "The sky is the one thing that surround us (the Earth)" may be true in real life, but in video games, it's NOT, you are wasting your precious polygons/visleafs by making that huge giant box around of your map.
That is why we need to create advanced strong compilers for Half-Life vanilla
They are already strong, but if you have trouble with compilation, don't blame the compilers, blame your work and your map's design.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-09-30 21:45:40 UTC Post #331835
yeah @Shepard62700FR
Unless Solokiller tell us otherwise, HLEnhanced's purpose is to modernize the working environment, fix bugs, document and optimise, so don't expect "huge" enhancements such as "renderers, particle systems, audio engines...". Also, weather is already there, it's the same as Counter-Strike.
Really? But how any user want get mod simple with whole rendering engine like Unreal Engine 4.0 - I know it is hard to optimize... So sadly they don't like with realistic renderings...
If you have "AllocBlocks" error(s), then it's your fault, not the engine's fault. Lightmaps up to 4096 are pointless.
But it is not my fault. You know if your map has over than 120% from AllocBloc than "normal" Half-Life can't load because it shows always error message "AllocBloc is full."

But Meta Renderer and Xash 3D have nice crack from "limited" to "unlimited" lightmaps example: your map has 120 % from AllocBloc than you use command metahook.exe -game <vanilla-mod> -lightmaps 512 +map yourmap than your map will load to in-game yay that is trick.
They are already strong, but if you have trouble with compilation, don't blame the compilers, blame your work and your map's design.
Blaming??? I didn't say that. Just I want support advanced high level compilers - but vhlt stopped if map has many lightmaps than it can not compile finish. PS: Where is stdint.h from vhlt src

I want improve and fix for largest and unlimited maps.. If they don't want to get many changelevels - I really want they are happy for biggest maps if they have great ideas if they have dreamed about Half-Life Vanilla mappings

That is why many level designers want users play and are happy about nice awesome biggest mods from HL-Vanilla.

I don't blame that just I want good solution for hl-vanilla and they enjoy awesome biggest map example Counter-Strike like maps example expanded map from Italy or Assault or Dust or whatever....
Posted 1 year ago2016-09-30 22:32:12 UTC Post #331837
@SourceSkyBoxer:

[quote]We need important features for HL Vanilla.
  • realistic water
  • realistic fluids like lava, slims or color like feature from Portal 2
  • realistic weather ( if you would like to create high poly clouds
  • normal map and speculation map for textures like from wad , rain if sun or light moves to rain you will see rain looks realistic from aurora or whatever you would like to improve more features for vanilla
  • normal- and speculation-map and details to models
and more..[/quote]

If you truly wish for that then you still lack major knowledge about the Gold Source engine. Yes these features could get implemented through workarounds but they wont work very well. Remember Hl FX mod. That mod lagged as hell not just because the code was unfinished but simply because the engine couldn't handle it. If you're wishing for features the UT3 or UT4 engine could handle then you're simply put imaginative or out of mind. We're speaking about almost 2 Decades of technologically and coding breakthroughs here...

I don't think most of the things you wished for will ever be accomplished for HL1 gold source engine not unless Solokiller gets full access to Valves Gold Source engine that is. I personally would hope and grant Solokiller that permission but I can't speak for Valve. So he will have to make due with what he can get done by avoiding certain limitations.

Once again most things you wished for are possible but highly unlikely to work properly or at the very least smooth. So I agree with @Shepard62700FR here in every aspect. Besides if you do want all these features then conduct mapping for Black Mesa. Problem solved.

The only point I'm on totally with you would be about "Allocbloc is full!". I too encountered this problem far to often and it's very annoying to say the least. If there's any chance to get rid of it then I'm all for it as long as it wont break any other things along the road.
Posted 1 year ago2016-09-30 22:49:45 UTC Post #331839
What you're asking for is essentially a new engine, since things like AllocBlock are part of the engine's lightmap allocation code. I can't deal with those things in this codebase, i'd need to make a new engine. That's a legal issue waiting to happen, and i'm not quite ready to assume that Valve doesn't care anymore just yet.

Even if that were possible, there are fundamental limitations that you'll always have to deal with when using things like BSP, and for backwards compatibility purposes old file formats for things like models and sprites would always need to be supported, which limits some other things.

Unlimited size maps are not possible with this engine. Even if you built a new engine, you'd need to use a completely new coordinate system to track objects in an unlimited size area, which means using variable length number types, which still has memory usage issues. It's simply not possible to that in modern computing, not even Minecraft can handle that and it has near unlimited size maps already.

Even if it were possible, no existing games and mods could use it since it would break engine interfaces in every way that it is possible to break them.
Performance would suffer on any hardware that can't handle variable length number operations, and since no existing consumer hardware supports that, everyone will have performance issues. The further you go from the world origin, the worse it gets. Even if you use local offsets to cut down on memory usage, you will have to track long distances using large objects.

There are other limits that can't be raised due to backwards compatibility issues. The maximum player limit is 32 due to some cheap tricks being used to encode player data into 32 bit integers, so every game and mod would break.
The maximum networked entity count is 4096 due to beams encoding start and end entities in a 12 bit area, along with attachment indices. Sven Co-op raised that limit to 8192 but it won't work, any other engine that does the same will have at the very least visual glitches, and possibly random events occurring if they were to use those values for conditions.

The higher you raise the limits, the worse networking issues get. All entities use the same settings so they'll send unused bits to clients, increasing reliable buffer sizes, packet sizes and processing time. You'd need to completely redesign the delta encoding system to put a stop to that, which again breaks all existing games and mods since they won't be using the new system. And i don't even want to imagine how you'd encode variable length numbers, but it wouldn't be very efficient.

I do agree that compiler tools should handle errors better than "on error stop", but that would require a complete rewrite. I attempted that a year ago and stopped after i started to get slightly different results from code that should do the same thing. If you've ever seen the compiler tool code, you'll know what i'm talking about. Something as simple as error handling is made impossible because of hard exits being triggered everywhere.

Making engine limits configurable for compiler tools should be possible, but as always the way that the tools were written makes adding that a nightmare.

stdint.h is part of the C standard library and should be included in modern compiler installs (C++11 and newer: http://www.cplusplus.com/reference/cstdint/). Use Visual Studio 2010 or newer to get it.

Vanilla HL will never support large maps, large lightmaps or large amounts of lightmaps. Valve won't risk breaking their main engine build at this point. They won't even risk breaking game code by fixing known issues, even exploitable issues are being left unfixed.

They haven't responded to my emails regarding community access to the engine, so either they missed them or they don't care. I can try sending emails to a few other people in Valve but i doubt it'll help.
I could just reveal how to get a hold of Steamworks to let you mess with its settings; if anything will get their attention, that will. It will likely be through legal action, given how dangerous direct access to that can be if abused, and i don't want to get sued trying to give people a chance at improving the engine.

Their engine codebase is pretty large and full of references to anything from obsolete Steam Friends code and hardware surveys to game code, so even if they were to release it somehow, they'd have to go through and remove all of that first. Having done so myself, i can tell you that it's difficult even if you know what you're doing, and i doubt that there's anybody at Valve that cares enough to do that.

Ultimately, all i need is approval to rebuild the engine through reverse engineering to get something up and running, which will allow me to start dealing with engine limits, missing interfaces, bugs, etc. I can re-implement the networking pretty well, and use the engine-as-a-mod trick to use Half-Life's app ID to access Steamworks. It would basically be GoldSource, only not the same code.

Unfortunately, i don't have approval. Half-Life's EULA states that you cannot reverse engineer or derive the engine's code, and it makes special mention of the networking protocol, since that would enable cheating if it were made public. (packet interception to see through walls)
Alfred noted on Github that the Linux libraries have debug info so Metamod developers can debug issues (see https://github.com/ValveSoftware/halflife/issues/668#issuecomment-14297865), but that's as far as that statement goes. If you use it for anything other than debugging you're violating the EULA.

As much as i'd like to provide a better engine, i can't legally do that. The most i can do right now is develop an engine for private use only, and if they ever did give permission, only then could i release it.

I'd tell you to ask the SC team for help, but based on what i've heard about recent developments they can't even figure out how to enable a stencil buffer correctly, so i doubt they can handle such large scale upgrades, assuming they even want to do them. Valve gave them access and doesn't respond to bug reports anymore, so i guess that's it.

To put it in simple terms, we're fucked as far as engine level development goes.
Posted 1 year ago2016-09-30 23:30:14 UTC Post #331841
I don't blame that just I want good solution for hl-vanilla and they enjoy awesome biggest map example Counter-Strike like maps example expanded map from Italy or Assault or Dust or whatever....
Excuse me If I put my oppinion here, I´m not a coder you know, but making a big, big, BIG map for HL is a matter of how small is the character; I mean, if there´s a way to modify where the eyes of the player is and also modify the HULL size (or Collisionbox, I don´t know how to call it properly) so it is a 1/5th ot 1/10th of its size, and also let the engine can use larger textures so the architecture does not look strectched, you´re done, right?.

I saw examples of that in games like Natural Selection on where there is an alien that crawls and the POV is almost at the same level as the floor. Yes, I know it´s hacky, but for larger maps should work.I cannot imagine how to do such thing, but NS´s guys did it!.

I did something similar with some of the npcs of my mod, they are a 1/4th of the size of a regular player, so I was not pushed to build a 4:1 scale player model to fit 1:1 scale npcs on a 4:1 scale map/world. Tricky but it worked fine until now.

Also for big open areas you can use hi-poly props made of hundreds of low poly models, so you can cover a entire field with moving grass. I know is hacky, and a dirty way of doing things, but it could work with some other tricks made with brushes and proper light placement without the need of using a new engine, and risking to be sued by VALVE Warning, personal oppinion here: why suing people for wanting to make a mod/upgrade of the engine?, I´m sure nobody wanted to sell it or make money of that, just having fun, for all gods new and old´s sake!!

Although the "ed_alloc" thingy is disgusting together with the ALLOC_BLOCKFULL one (try sparse in the compiler, btw to bypass the 65000 limit, if you didn´t do yet). ;)
Posted 1 year ago2016-10-01 12:22:07 UTC Post #331859
I feel like there needs to be some disclaimer here that HL:E is not some visual overhaul mod or some strange version of SOHL; I assume that's mostly due to others' ignorance of what you're actually doing solo.

I'll be perfectly honest, most of what you are doing is over my head ( wether that's because I don't know any version or derivation of C / C# / C++ ), and it's amazing to see, but think most people will just see code and assume that means you can implement a brand new rendering engine or some form of particle system or physics engine, etc.
Instant Mix Instant MixTitle commitment issues
Posted 1 year ago2016-10-01 13:09:50 UTC Post #331864
@SourceSykBoxer:
Sounds to me like what you really want is a modern engine to work on. You will never get this level of quality with GoldSrc due to limitations in the map format, and overall architecture of GoldSrc.

No modern engine relies on BSP geometry for rendering anymore, at best they still keep it for collision detection. BSP rendering was good at limiting the number of processed polygons to a minimum, as most of the rendering processes ran on the CPU. Modern GPUs prefer if you render large amounts of triangles in the least amount drawcalls. That's not possible with GoldSrc, no matter how much you optimize the engine.

I'm sure if Solo ever wants to make graphics/visual changes, he will create a separate project for that and formally announce it. Most developers don't really care for fancy graphics anyway, and just want to have fun developing. There's not that big a demand for it to be worth it in my book.

Abaddon:
As for Valve suing developers, I think it only ever happened with anything that had to do with Xash. It's because Xash was built upon code from the 2003 leak, and Valve really seems to be sensitive about that incident in particular, seeing as most of the time they didn't seem to care about illegal content or activity in the modding community.
Posted 1 year ago2016-10-01 13:13:38 UTC Post #331865
Remember Hl FX mod. That mod lagged as hell not just because the code was unfinished but simply because the engine couldn't handle it. If you're wishing for features the UT3 or UT4 engine could handle then you're simply put imaginative or out of mind. We're speaking about almost 2 Decades of technologically and coding breakthroughs here...
ArrangeMode (the old ARRANGEMENT version) had every tutorial of every HL programming website implemented, if you can find a dow nload link to the old "AmMappersEd" or "ArrangeMode: REBIRTH" versions and you have some time to waste, play them with everything enabled and admire the huge FPS loss.
Unlimited size maps are not possible with this engine.
Unlimited size maps in any engine is not possible, end of story, if people think otherwise they are complete idiots, if that guy is a programmer, tell him/her to stop using any computer.
I'll be perfectly honest, most of what you are doing is over my head ( wether that's because I don't know any version or derivation of C / C# / C++ ), and it's amazing to see, but think most people will just see code and assume that means you can implement a brand new rendering engine or some form of particle system or physics engine, etc.
This is why we try to make our documentation (the wiki) non-programmers friendly ^^
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-10-02 08:08:51 UTC Post #331874
@Shepard62700FR and @SoloKiller, you're right - HL FX Mod I have tested and it is buggy for AMD Display Drivers because shadowdemo with modified shadow shader from HL-FX Forum

Arrangement made by Argentina ( South America ) [ Remember World Cup 2014 Germany wins again Argentina. ] Arrengement is but buggy for Half-Life STeam :/ If I remove protection glasses but it can't remove only hold.

Okay... Thanks for explanation I will learn C++ but I am not good advanced programmer for C++ - But I am only using AS3 and Haxe Codings Sorry.

Because Haxe makes all platfrom usable files like binary works under Windows, Linux, Mac OS X and TV, Android, Tizen and iOS ...

I am using only Haxe + NME ( latest version ) - Sorry I haven't experience about hard-coded C++.- I will learn more. C11 or C9?? Which C version of your HL Vanilla SDK?

I try C++/header to Haxe - If i have to know. If don't know - I will learn more more... Thanks for helps and discusses :)

I would like to continue my mapping processes with Xash.. Whatever I force to Valve because Valve gets our money if we have bought Half-Life that is why we want earn money.

If Valve strikes us than we have right to development with Goldsource Engine because we have experiences about modellings, mappings, texturings, scriptings and more... Example SoloKiller has decision to develop HL-E Vanilla for free game. It is okay. Example who want work own texture making than somebody want sell or release free download. Xash is same but whatever is illegal I know I have readden bad news from moddb.com That is why just is my race to Valve Software. You have race to Valve Software??? If yes than you're right what do you want. We want Russians are surprised.

Thanks everyone!
Posted 1 year ago2016-10-02 09:53:11 UTC Post #331875
HLE uses C++14. C99 and C11 are the C standards, not C++.

The original HL SDK uses C++98, the Github version uses C++03. The difference between 98 and 03 is much bigger than that between 03 and 11, so if you're thinking of working with the SDK, use the Github version.

C++11 includes things like rvalue references (&&), move operations (helps eliminate memory allocations), new library features (cross-platform threading facilities, regex, etc), the override and final keywords (saves headaches), and various other things.

C++14 is a smaller update but still has useful additions. constexpr is more relaxed than its C++11 version.

I suggest reading the wiki articles on each language version if you want to learn about the differences, you probably won't understand it though.

C++98: https://en.wikipedia.org/wiki/C%2B%2B#Standardization
C++03: https://en.wikipedia.org/wiki/C%2B%2B03
C++11: https://en.wikipedia.org/wiki/C%2B%2B11
C++14: https://en.wikipedia.org/wiki/C%2B%2B14

C++17 is coming soon, and includes more useful features. I'm already using the experimental version of the filesystem, which allows for cross-platform file operations in both the HL_Tools codebase and the prototype engine. It saves a lot of headaches.

It's mostly a cleanup operation, removing various obsolete language and library features, but there are some very useful additions. For example, you can write if statements that are evaluated at compile time, return multiple values from a function without needing to declare a structure, and declare a variable and evaluate it in an if statement.

One of the most interesting additions is inline variable declarations, which finally solves the problem of declaring constants in headers for non-integral types. It will allow #defines to be replaced without needing to initialize the variables in a source file. See this Stack Overflow article for more information about that: http://stackoverflow.com/questions/38043442/what-is-an-inline-variable-and-what-is-it-useful-for

For an example where those would be useful, take a look at this header: https://github.com/SamVanheer/HLEnhanced/blob/master/game/shared/GameConstants.h

See its wiki article for more information about it: https://en.wikipedia.org/wiki/C%2B%2B17

I don't know which parts of Xash are illegal. Aside from using leaked code they are also violating the Half-Life EULA:
A. Subject to the grant of license hereinabove, you may not, in
whole or in part, copy, photocopy, reproduce, translate, reverse engineer,
derive source code, modify, disassemble, decompile, create derivative works
based on the Program, or remove any proprietary notices or labels on the Program
without the prior consent, in writing, of Valve.
Xash definitely falls under the reverse engineer, derive source code, disassemble, decompile, and create derivative works parts of the EULA.

If i were to make an engine, it would also fall under these parts. I can avoid the majority of them by not relying on information i get from reverse engineering, but it's still going to be a derivative work. This wouldn't be an issue if Valve would respond. Even a simple yes/no would suffice, but i'm getting nothing.

I can make a tool that does what the engine does, since it would strictly speaking not be meant to play the game. A singleplayer only BSP viewer that also handles physics would cover much of the engine's functionality without actually being a game engine, but anything that enables networking and perhaps game library loading would change its purpose.

I've never heard of any legal action being taken against Xash's developers, and their Github repositories would certainly have been taken down if there had been any effort on Valve's part to stop it.

The big difference is that i signed an NDA, so if i were to do this it could be interpreted as using confidential information to make something that violates their EULA. That's probably worse than what Xash's developers are doing. Even though i barely remember what the engine's code looks like (aside from being a mess), lawyers aren't as forgiving as game developers.

Right now i'm thinking i can probably make that tool, what i've done so far isn't strictly game engine material. I can probably get away with accessing Steamworks as long as i'm using it for tool stuff, in this case doing things like locating game assets using its app API would be considered tool functionality.
The problem is that the Source SDK license requires you to only use its code for Source mods, so just like VGUI2 this would violate that license agreement if i used it in a GoldSource mod.

I've sent out the email again to their Source Engine SDK email, maybe i'll get a response from that. The NDA did say Source Engine, so maybe they don't check the older email addresses.
Posted 1 year ago2016-10-18 14:08:47 UTC Post #332054
I fixed the crash that occurs when weapon info is missing for a weapon and you pick it up. Simple to fix, but i've spent all of my time on other stuff so it took a month <.<

I'm going to take care of some Angelscript stuff now, i figure adding some of the planned stuff now will give people more to work with. Expect the basics needed for entities, maybe plugins too.
Posted 1 year ago2016-10-19 16:05:55 UTC Post #332057
That's good to know, I also saw the recent changes about AngelScript and such and they look great.

There are multiple things I would like to suggest :

1) This is very minor, you can delete the useless outdated "travis" branch on GitHub (and your local copy).

2) I made a PR for removing the "Debug" configuration for AppVeyor (Windows CI) and "GCC 5" (Linux) in order to speed up build times for both CI (see the PR itself for details).

3) I don't know if it's really necessary and/or it could help but a friend of mine told me about Gitter, it's some kind of ShoutBox/Chat/MSN thingy but designed for GitHub projects.
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-10-19 17:41:11 UTC Post #332058
I've removed the travis branch and merged your pull request. I agree that there's no reason to have it build debug versions, just having the release build for the latest GCC is enough.

Gitter looks pretty interesting, we could get together on that so we can talk more easily about stuff.

I've done a fair amount of stuff so i'll sum it up:
-Added CBitSet: a class that acts like an int but also has methods to test for which bits are set. All CBaseEntity bit vectors have been replaced with this, so instead of AnyFlagSet() you now do GetFlags().Any().
This removes about 200 lines of code in CBaseEntity.shared.h and makes adding new features easier.
There is no performance impact resulting from these changes since the compiler optimizes out the entire class.

To prove that, here's the disassembly from the release with debug info build:
[quote]

mov eax,dword ptr [esi+4]
GetFlags() |= FL_CLIENT;
or dword ptr [eax+1A4h],8
[/quote]

esi is 'this', + 4 to pass the vtable and get to this->pev.
This code is rewritten as 'this->pev->flags |= 8;'

So in effect CBitSet is a smart int.

-Exposed Vector, Vector2D, integer & float min and max, PI to Angelscript.
-Exposed CBaseEntity's entire API to Angelscript, with the exception of a few to-be-removed methods. Some of these methods may end up being moved to subclasses since they only apply to specific classes, so the API will need to be updated as well.
-Exposed basic entity utility functions to Angelscript. Creating entities and finding them is now possible. This is done using global functions, not global variables that you call the methods on like SC does. This way is more efficient since it's not pointlessly passing the this pointer. You can also define your own functions in the same namespace.
-Exposed string_t to Angelscript, it can convert to and from string.

-Added plugin support. Plugins are currently loaded the first time the server loads a map, and loads from default_plugins.txt in all cases. Plugins can do everything that map scripts can.

Plugins will have the option to specify the minimum lifetime. The default, HotReloadable, lets you reload the plugin at any time. Useful for development and passive plugins.
Map lifetime plugins are identical to map scripts; they're loaded when the map starts and can be flagged to unload or reload them on map change.
Server lifetime plugins are loaded and stay in memory for the remainder of the server's lifetime. Useful for always-on plugins.

The idea behind these lifetimes is to ensure that plugins aren't reloaded when they're in active use.
For example, a plugin that provides custom entities shouldn't be reloaded because the old plugin will still remain in memory until all references have been removed. You could end up with 2 different versions of the same weapon being used at the same time, which could cause crashes.

By specifying a lifetime of map or server you avoid these problems. Both server operators and plugin authors can specify lifetimes, with the greatest lifetime being used. This ensures that authors can safeguard their plugins without needing to instruct server operators to do it, and server operators can make sure that admins don't accidentally unload or reload plugins that should remain active.

Existing code has been updated to call initialization functions in scripts for all modules, which also means that all future module types are automatically supported.

I've also included HL_Tools's keyvalues parser, i'll have to get all of my repositories to use the same code and setup so it can use the library version of the keyvalues code.

To that end, i'm considering merging HL_Tools, HLEnhanced and Prototype-Engine into one repository. I don't know if that's even possible, but it would let me share code more easily. It does create the risk of having to throw it all away if Valve decides to go legal issues and require the removal of the engine code though.

I had some time to kill yesterday while waiting for the Linux build to finish so i also went and debugged a problem in the Source SDK: https://github.com/ValveSoftware/source-sdk-2013/issues/385

In case anybody ever wondered why dropships don't point their guns at you anymore. Apparently the Source SDK is also pretty messed up, so it's not just GoldSource that got the short end of the stick from Valve.
Posted 1 year ago2016-10-19 17:56:24 UTC Post #332059
Gitter looks pretty interesting, we could get together on that so we can talk more easily about stuff.
I have no problems with using Gitter if it helps the project so again, it's up to you to decide, we could use Gitter for more "in-dev" stuff and keep TWHL (and the rest) to report update progress, I can't create the room otherwise it will be linked to my fork.
I've also included HL_Tools's keyvalues parser, i'll have to get all of my repositories to use the same code and setup so it can use the library version of the keyvalues code.

To that end, i'm considering merging HL_Tools, HLEnhanced and Prototype-Engine into one repository. I don't know if that's even possible, but it would let me share code more easily. It does create the risk of having to throw it all away if Valve decides to go legal issues and require the removal of the engine code though.
What about using Git's submodules function ?
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-10-19 20:05:15 UTC Post #332060
...
You must be logged in to post a response.