Half-Life Enhanced Created 2 years ago2016-07-15 18:57:29 UTC by Solokiller Solokiller

Created 2 years ago2016-07-15 18:57:29 UTC by Solokiller Solokiller

Posted 11 months ago2017-09-01 12:13:31 UTC Post #337213
Parenting would be really useful to have - That's one of the main reasons people still use Spirit of Half-Life despite it being so buggy. HL:Enhanced having it would be a huge selling point.
JeffMOD JeffMODCall 141.12
Posted 11 months ago2017-09-10 06:16:50 UTC Post #337365
I looked into this a bit more, i'll have to disable the engine's code in SV_Physics to stop it from wasting a bunch of CPU cycles and calling functions at the wrong time.

I can't do this using normal methods so i'll have to write a platform-specific hack to overwrite the return address passed to StartFrame so that it returns to wherever SV_Physics was called from.
This is assembly stuff so it'll be difficult, but it's not impossible.

Fortunately both SV_Physics and StartFrame are functions taking no parameters and returning nothing so it's pretty simple.

Something like this would probably do the trick:
void* pReturnAddress;

mov pReturnAddress, [ebp + 16]
mov [ebp + 8], pReturnAddress
Where ebp + 16 is the location on the stack containing the return address for SV_Physics and ebp + 8 is the location for StartFrame's return address. The actual offsets will need to be determined for all platforms but once that's done it should be pretty straightforward.

For future reference:

I'm going to ask Alfred if they can add in a callback for custom physics but i can tell you right now that's highly unlikely, but i can at least try.

Also, there has been talk of XML exploits using custom entities (not the kind you're probably thinking about) that allows for exploits, this can be disabled in Xerces-C: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#libxerces-c

So when this gets implemented in HLE this will need to be disabled.

While this is unlikely to cause problems in HLE due to mostly server side XML files, it could still happen if a malicious server downloads such a file to clients, who then run it locally and end up with crashes and instabilities.
Posted 10 months ago2017-09-20 20:33:06 UTC Post #337453
I've added some feature tracking stuff to the wiki: https://github.com/SamVanheer/HLEnhanced/wiki/Game-integration

Should make things easier for when this all gets added. If i've missed anything, feel free to add it or let me know about it.
Posted 10 months ago2017-09-21 12:54:57 UTC Post #337455
Posted 10 months ago2017-09-21 18:06:14 UTC Post #337457
Thanks for providing this :)

I've written down a bare bones description for a new feature i've come up with to add some flexibility: https://github.com/SamVanheer/HLEnhanced/wiki/Filter-system

Basically identical to Source's filtering system, only a bit more powerful due to not locking you into checking activators only. There will also be an option to add your own filters through scripting, once that stuff is implemented.

You'll notice that i refer to inputs a few times, that's because i'm planning to implement an I/O system using Angelscript.
I won't be able to integrate it into the map file itself due to various issues (no map editor support, no .map/.rmf support, no compiler support), but it will be possible to add this using Angelscript.
It'll be a bit clunky but at least we'll have it available.

Regular trigger support will eventually be reworked into calling a default input like Source does where it calls into Use(), converting the parameter value into the appropriate use type (as in trigger_relay's "Trigger State" keyvalue, most other entities will use toggle).

I might add a way to specify outputs using the XMLized version of map configs, basically like using Source's AddOutput input in usage where you manually specify the options. That should be easy to use, though it could end up messy.

As with most features this would require source code access to fully implement in map files, unless a separate IDE were to be made and the data embedded into the BSP file or somehow paired up (mapname.io file perhaps), but the only way to make it simple is full integration into the map editor. There's also the issue of save/restoring filters, especially if using custom entities.

The ultimate purpose of this is to have control over game events like so:
player->trigger_multiple{targetname=door_trigger}(Trigger)->filter_multi->[filter_has_item(Test, item_keycard)->filter_item_property(Test, item_keycard, color, red)]->[func_door(Open), trigger_multiple{targetname=door_trigger}(Kill)]
This probably makes little sense so i'll walk through it:
player triggers trigger_multiple named door_trigger
trigger_multiple trigger filter_multi to check if the player has an item called item_keycard and if that keycard has a property "color" with the value of "red"
If both match, open the red door and remove the trigger_multiple
filter_has_item and filter_item_property could be custom entities here.
Posted 10 months ago2017-09-22 12:17:32 UTC Post #337462
any chance we get the fullbright rendering for the textures on the models?
Posted 10 months ago2017-09-22 12:42:29 UTC Post #337464
That's an engine level feature, i'd have to completely re-implement model rendering to add that.
Posted 10 months ago2017-09-23 06:10:58 UTC Post #337486
That's an engine level feature, i'd have to completely re-implement model rendering to add that.
Too bad - the client-side stuff seemed to provide a lot of flexibility with regards to model rendering.
Posted 10 months ago2017-09-23 06:47:13 UTC Post #337488
It ultimately calls into the engine to do the actual rendering, and the fullbright flag isn't checked there. There is code that checks r_fullbright, but nothing for the per-texture flag.
Posted 10 months ago2017-09-23 15:28:28 UTC Post #337491
Hello @SoloKiller,

I ask about Half-Life Enhanced since I play it. Nice work! It works like Sven Coop. I am sorry. I don't want call again because you hate your hostile ex team.

1. Can I write angel script for env_model? If yes than I will try.
2. Can I write angel script for env_sky ( like sky_camera from Source Engine ) If not than I would like you have to add feature OpenGL into Angelscript?
Is it correct or wrong? Link Does it support for Half-Life with angel script? If no than.... How do they add reflection of water with MapInit() from angel script? I am sorry for bad English.
Posted 10 months ago2017-09-23 16:49:27 UTC Post #337492
What do you mean by env_model?

And no, you can't implement an env_sky for multiple reasons.

The first is that it requires client side scripting to do anything graphical, which is a pain in the ass to implement because it's missing callbacks. I may be able to hack it in using memory patching similar to how AMX mod hooks into stuff like cvar change events, assuming it doesn't trigger VAC. I'll have to ask Alfred about that, assuming he responds at all.

The second is that you can't override the engine's skybox rendering, so you'd have to handle rendering entirely in the client dll. As with everything in this engine that's a lot of work and possibly even illegal since replicating that code is against the EULA.

The code you linked is from a utility library that doesn't show how it's integrated into programs, if used in HLEnhanced you'd still need additional scripting API support to actually use it.

Even then it still depends on engine level code for things like supported features, since OpenGL context creation requires a version to be set first, and that's impossible to do from the client since that all happens before client code executes.
Though the linked code seems to be immediate mode only - which should always be supported - if you want it to run well you'll need shaders, which requires a newer OpenGL version than what is guaranteed to be provided.
The SDL documentation for this doesn't say which OpenGL version is used by default, so i'm assuming it uses whatever the OS chooses by default, which can be anything depending on your video card, drivers, OS, etc.

Reflection isn't easy to add either because that usually works by rendering the entire scene for the reflected plane, which while possible still requires the use of things like render-to-texture support to store off the reflection for rendering in the main scene. With all the above problems solved this one should be perfectly possible though.

Perhaps i should write a book's worth of reasons why we need the engine open sourced and send it to Valve, i'm getting tired of this turning into "spend half your life rewriting half the engine into Half-GoldSource while breaking half the copyright laws".
Posted 10 months ago2017-09-23 16:56:29 UTC Post #337493
I mean, PARANOIA works with the latest Half-Life version, just with some tweaks, an no skyboxes due to the depth-range setting from the hacked .dll. Look at ARRANGEMENT, albeit it’s all hacky, it works just fine. Just cross-platform and legality stands in the way.

env_model was a newer feature from SOHL which is essentially Source’s prop_static. It’s probably the easiest from the list to implement.

I think he misunderstands how AngelScript works and what it’s limitations are.

Also, you can do whatever you want, or you can submit a pull request if you think what you add makes HLEnhanced better.
Posted 10 months ago2017-09-23 19:05:47 UTC Post #337496
env_model is like prop_static or cycle like @James Luke explained..
So sad, I can not make render like reflection into Angelscriptz, Do I understand correctly?

But PARANOIA 's env_sky looks bad like Cry of Fear - Since it happens common behind background if you move near to sky wall like Garry Mod's bugged sky_camera.
User posted image
That is why I really don't like PARANOIA's source because it uses only glaux.h and is incompatibility to newest version my display card ( December 2016 , AMD Radeon RX 480 )

I didn't make criminal because I hold carefully.
Posted 10 months ago2017-09-23 23:19:51 UTC Post #337502
Oy, SSB, do we have to go over this again?

Source =\= GoldSource. What about that do you not understand?

Reflection requires some pretty advanced OpenGL stuffs ON TOP OF a rewritten OpenGL renderer. Also, env_sky wasn’t terrible, it was much better than the SOHL one. But Garry’s Mod implementation of env_sky (or its respective name) is completely different except for its core principle.

Also, what’s with this glaux.h stuff again? It also used the standard includes, if you graphics card is newer than 2008, it should work, you just have to modify the code to not use the .dll. If it isn’t, get a new graphics card, it’s about time.
Posted 10 months ago2017-09-24 06:08:06 UTC Post #337508
Using a custom opengl32.dll for stuff like this isn't an option for at least 2 reasons.

1: the engine removes it if it exists.
2: VAC may ban you if you use it on a VAC secure server. This has happened to MSC players using a bloom mod in the past.

We need engine level support to do it safely.
Posted 10 months ago2017-09-24 10:12:13 UTC Post #337509
Yeah you're right. I want safe too. You know that I never use criminal engine.
Posted 10 months ago2017-09-24 15:29:17 UTC Post #337511
Posted 10 months ago2017-09-24 23:37:02 UTC Post #337514
That video was a trip.
Posted 10 months ago2017-09-29 15:14:05 UTC Post #337590

This talk is about an advanced metaprogramming proposal for C++. It won't be available in mainstream compilers for half a decade at least, but it applies to game development in a big way. It would make save/restore, keyvalues, schedules, networking and a lot of other stuff a lot easier to implement.

Note that it's an advanced subject, so if you don't have much experience with C++ you probably won't make sense of it.
Posted 9 months ago2017-11-03 15:19:34 UTC Post #337948
I just committed a bunch of code cleanup changes to master.

It's mostly changing pev-> uses to use the CBaseEntity accessor methods, but i've also cleaned up some of the documentation for methods, usually when it was duplicated.
I've also done a small amount of refactoring to make the code a bit safer to use in some cases.

Most of this is preparation for work to be done later, i'll explain that when i'm sure i can actually do that stuff.

These changes make it harder to screw up by mistake, for instance some code would do pev->takedamage = 0 or pev->movetype = 4, making it hard to see what the code was actually doing, and making it easy to break things, for example by doing pev->movetype = 40 by mistake will shut the game down when the physics code gets to it with a message "SV_Physics: <classname> bad movetype 40".
Now you'd have to do SetMoveType( static_cast<MoveType>( 40 ) ) for this to compile, and sanity checks can be added to SetMoveType to catch these cases as they occur.

Right now i'm going to focus on figuring out if i can implement physics in game code, i've been looking around and it looks like i'll have to rely on a few hacks to do this.

Unfortunately the nature of these hacks will break Metamod support, since it involves rewriting stack data (specifically return addresses) and Metamod interferes with that.

Another hack will tie HLEnhanced to the current Steam version due to relying on the binary layout of internal data structures. I'll try to minimize the amount of code that uses these hacks, and allow for custom engines to provide the interface for it, but i doubt it will ever work under other engines.

On the plus side, once this is in place i'll be able to optimize the physics code a bit, implement custom handling for things like multiple think functions, implement parenting support and access data previously unavailable.

If i do the same on the client i may be able to implement late precaching support as well, but i wouldn't count on that being possible just yet.

I've also considered the possibility that engine commands like god, noclip and notarget can be implemented in game code by relying on a similar hack to modify the engine's list of commands. By removing these commands and adding them again from game code it will give control over those commands to modders, which can be quite useful.

I hope that once all of these things are taken care of i can move some data away from entvars_t and move it into CBaseEntity and derived classes. This will make the code that uses it more efficient and easier to understand.

In addition, i've also been thinking about making a program that can act as Ripent, using Angelscript to define transformations to convert entities. This could be used to convert maps to use newer entity APIs. It'll allow for reused entvars_t fields to be changed, which helps avoid confusion and prevents unsafe code from being written.

For example, func_train will happily accept any entity as a target to move towards, and will interpret its entvars_t fields as being used to indicate a path to follow. It will check the spawnflags for corner settings as well.

It will also continue to use paths that have been removed at runtime, meaning a specific edict could be used as a path, removed, and then reused as a completely different entity (e.g. Human Grunt spawned by monstermaker), causing it to read what is essentially garbage data as valid path data. Debugging this is difficult because edicts are only considered for reuse 0.5 seconds after being freed (unless the time is < 2, then it's instant), so it would be tough to notice such a bug.

By moving away from entvars_t, the func_train code will need to explicitly convert the entity to the right class to get the path data, preventing this from happening, and by using an EHANDLE to track the path it avoids the reuse issues.

Since so many changes are required, i'll also consider merging path_corner and path_track, since they are ultimately the same thing anyway.

This program will eventually be able to modify any map source file, BSP file and in-memory representation.
Unfortunately, this means that it can be used to take maps made for one mod and convert them to another mod. That's not intentional, but it's unavoidable when making the tool be able to convert maps from official singleplayer games.

Apologies for the info-dump, but i spent quite a bit of time doing this code cleanup and i've had time to come up with things to do next.
Posted 9 months ago2017-11-03 18:43:29 UTC Post #337950
One advantage that i didn't mention: i can override the engine's entity spawn handling and do it all in the server dll, which also lets me store off entity data for templates.

Think monstermaker, only every keyvalue can be set automatically without any special handling in monstermaker itself.

This also lets the modder choose whether the "Not In Deathmatch" flag has any effect.
Posted 9 months ago2017-11-03 21:09:16 UTC Post #337951
Sounds as usual outstanding.. I just wish you would come to an end soon. :)
So that I can start merging my mod(s) to your newer mega engine. :D

Keep it coming great work.
Posted 9 months ago2017-11-03 21:22:47 UTC Post #337952
I'm hoping to get this done soon, then get back to Op4 & BS compatibility work.
I just finished doing some refactoring to prepare for this, now i can access the list of models, sounds, generic precaches, the entity data string, the number of entities that are currently allocated, the map name, the previous map name, and shared datagrams for networking.

I'll need the list of models for physics (BSP & Studio model collisions), as well as the entity data string for control over entity instantiation. I'll need to take a look at AMX's Detour code to figure out how to hook into ED_LoadFromFile, other than that my code should handle most of this stuff just fine.

Having direct access means i can check if a model has been precached before calling for it, which means i could manually implement Source's error.mdl without needing a duplicate list of models.

And like i said, if i did this on the client side as well i could add late precaching by manually entering the required entries in lists, but it's tough without proper access to the codebase. I'll need to figure out how to get the addresses for functions that load models.

EDIT: or maybe not: https://github.com/ValveSoftware/halflife/blob/master/common/r_studioint.h#L18

I'll have to figure out if i can keep the lists in sync though.
Posted 8 months ago2017-11-20 22:45:45 UTC Post #338124
I've been working on XML integration, it's almost done. I've also added a logging system that uses spdlog to have per-system log settings to make it easier to debug specific areas of the codebase.

The reason i'm posting is because i was reading the Steamworks documentation and found this:
The Steamworks SDK is incompatible with some open source licenses, which may affect your ability to distribute open source software via Steam.

Keep in mind that according to the Steam Distribution Agreement you warrant and represent that you have all necessary rights to distribute the game via Steam. If your application contains third party open source code that is incompatible with the Steamworks SDK, then YOU MUST NOT DISTRIBUTE YOUR APPLICATION VIA STEAM.

Logically this means that open sourcing a Steamworks based engine would violate their own license agreement. So the only way to open source the engine would be to strip all of the Steamworks code, which would also remove any ownership checks and effectively turn it into Xash in terms of usage restrictions (i.e. none).

That still doesn't explain why they won't let modders license it though.
Posted 8 months ago2017-11-23 14:48:06 UTC Post #338167
So how does this affect your work? Did you use vast chunks of Steamworks code in your code?
Posted 8 months ago2017-11-23 15:40:40 UTC Post #338168
It doesn't affect anything i've worked on, they allow mods to use it.
The Source SDK has Steamworks headers and libraries included and accesses it for things like scoreboard avatars. I think it only applies to engine logic, like authentication and such.

I haven't used any Steamworks code in HLEnhanced yet, but i was going to add it in eventually, i'll need it if i ever have to force VAC off on servers (for using client side memory patching, if that's needed).
Posted 8 months ago2017-11-26 13:40:31 UTC Post #338218
That's good to hear...

Btw. check your pm for future reference...
Posted 8 months ago2017-12-01 16:37:50 UTC Post #338263
I've written up a proposal for a better way to handle plugin listing: https://github.com/SamVanheer/HLEnhanced/wiki/Plugin-manifest-(temp-page)

This should make things simpler in the long run, since you can add plugins without worrying about script filenames and command namespaces yourself and such, while still allowing you to change it easily.
It also lets plugin developers distribute their stuff more easily, just add in a manifest and tell people to add that to their main manifest and they're done.

There some new features like the command line that makes configuring plugins easier without having to rely on separate configuration files, and any future requirements, like for instance an option to disable custom entity registration or a forced log level can be easily added to the config file if needed.

Note that the CVarUtils.as file doesn't exist yet, it's part of the future documentation for this. If and when i get to this point i'll write that script.

Let me know what you think :)
Posted 7 months ago2018-01-10 17:59:23 UTC Post #338615
Posted 7 months ago2018-01-11 22:24:51 UTC Post #338623
Than what does Valve Software say you?

Or you wait for answer?
Posted 7 months ago2018-01-11 22:27:56 UTC Post #338624
Nothing so far, probably won't get a reply. It was worth a shot though.
Posted 7 months ago2018-01-12 08:14:49 UTC Post #338627
SvenCoop team got access and modification rights to Gold Source. I doubt Valve will give it to you or anyone else before SvenCoop team makes something with it plus some time passes.
Stojke Stojke= O P L - 3 =
Posted 7 months ago2018-01-12 11:37:39 UTC Post #338628
What makes you say that? They've had the engine for nearly 5 years now, i doubt Valve would just sit on it for that long.
Posted 7 months ago2018-01-12 22:43:02 UTC Post #338630
I'm not a big fan of sven-coop. I would love to see all of those enhancements that Solokiller sent to valve, available in half-life multi-player. Would be amazing! I have maps just waiting to be made, and some ready to go.
Posted 7 months ago2018-01-16 20:28:36 UTC Post #338654
What exactly don't you like about Sven Co-op? It's always good to know so i can avoid any problems or mistakes.

I've implemented the logging system, although it hasn't been merged yet (waiting for feedback). You can find the documentation here: https://github.com/SamVanheer/HLEnhanced/wiki/Logging-system

It's intended to make things easier in the future, with all the systems that will be implemented (XML, engine hacks, etc) that could spew out a lot of debug information.
If anybody has any thoughts on this, i'd love to hear about it before merging it in. Once that's done i can finish up the XML implementation as well.
Posted 6 months ago2018-02-04 20:25:13 UTC Post #338657
What exactly don't you like about Sven Co-op? It's always good to know so i can avoid any problems or mistakes.
It is a good game. I love the enhancements to the GoldSrc engine but I'm frustrated that I can't play deathmatch or even team deathmatch without adding a butt load of entities to force the map to make it happen. Honestly, my family I have been using Xash3d/XashXT to play Lan games on some of my maps that vanilla half-life won't run.

I just want to play deathmatch and make maps for a version of Half-life with an enhanced goldsrc engine. Increased limits for mappers. And I'm not asking for HL2, HL:Source, or Black Mesa Source either. There is too much taboo around sven coop and the idea of allowing deathmatch as a gametype out of the box.

looking forward to HL Enhanced, angelscript that is utilized to its fullest, and would be nice if servers ran nice as well :)
Posted 3 months ago2018-05-06 19:16:51 UTC Post #339508
I'm going to finish up the pending changes for HLE and then focus on SharpLife after that. It's still the same project on a fundamental level but the approach will be a bit different.

See this thread for more information: http://twhl.info/forums.php?thread=19494
Posted 3 months ago2018-05-07 00:06:44 UTC Post #339510
Good to this still being worked on.
You must be logged in to post a response.