Check out Half-Life Re-imagined competition results!
Check out Skewing textures in Hammer, our newest tutorial!
Welcome, kesizewi, our newest member!

logo

Site Stuff

Reference

Maps

Community

ShoutBOX

Poll

Feeling Blue

What's your favourite shade of blue?

Azure

17

Cobalt

32

Turquoise

11

Cyan

12

Royal

11

Teal

3

Onliners

21 secs

Stojke

2 mins

JeffMOD

6 mins

Tetsu0

7 mins

SourceSkyBoxer

20 mins

Solokiller

21 mins

James Luke

27 mins

The Mad Carrot

Affiliates

A gaming and technology blog by TWHL admins Penguinboy and Ant. A music blog by TWHL users Ant and Hugh.

Half-Life Enhanced

[1] 2 3 4 5 6 7 8

Forums > HL Engine Discussion

15 Jul 16, 19:57
By Solokiller
avatar
Member
As some of you know, i've been working on a mod called Half-Life Enhanced (no relation to the ModDB version).

So far it's been mostly code cleanup, documentation and bug fixes.
However, today i've added Angelscript scripting support to it.

It's just bare bones stuff at the moment, but the essentials are there. You can create map scripts and load them by specifying the script name in worldspawn's "Map Script" keyvalue, and use the exposed API for simple things.

At the moment it has core library features like strings, dictionaries and arrays, but also the scheduler and limited reflection support.

The library version is newer than Sven Co-op's, so there are some differences and bug fixes not available to them. Given the nature of the changes, i doubt they'll be upgrading their version any time soon.
As i said before, they can use the code i've written if they want to. It's well documented and has some good example code already, and is much more efficient than their existing implementation.
I've eliminated unnecessary memory allocations in wrapper classes, duplicate pointers and generalized some special case code, like hook execution. If they have the time and skill, they should upgrade to this.

I added it mostly to field test the new utility code i've been working on this week, but that doesn't mean it isn't already quite powerful. Once i've added the entity base class CBaseEntity you'll be able to manipulate any entity in the map, and once custom entities have been added, you can do even more.

If anybody's interested, here's the latest (debug) build: https://dl.dropboxusercontent.com/u/4604897
9/hlenhanced.rar


You can also check out the Github repository: https://github.com/SamVanheer/HLEnhanced

If you ever wanted to see how a scripting language could be implemented, this is a fairly well documented version. The starting point for Angelscript itself can be found in this file: https://github.com/SamVanheer/HLEnhanced/bl
ob/master/game/shared/Angelscript/CHLASMa
nager.cpp


The utility library i wrote handles most of the hard stuff, so you won't see much low level code in the actual game codebase. Its repository is under the same account, called AngelscriptUtils.

I'm still in the middle of cleaning up the SDK, so lots of stuff is subject to change. I can't promise that maps and scripts made for this will continue to work. Documentation will have to wait until i've finalized the code it's supposed to be documenting, so if it seems a bit barren, that's why.

There is a lot of work to do in this codebase, and scripting is only a small part of that. However, once it's done, it should provide you with enough customization support to do just about anything (within the engine's limits).

I'm planning to add support for custom player classes, so CBasePlayer instances specific to a map. The CBasePlayer interface would still be used, but you'd be able to add your own stuff, and solve problems that SC's version just couldn't allow for, like special case player model animations. If you want to add a set of animations to make players kick enemies, you'll be able to, as long as the player models have the animations.
Again, that code will probably need some cleaning up first, since it's hardcoded to a set of constants.

You'll also be able to create your own gamerules instances. Gamerules classes govern things like item respawn rules, player respawn delays and respawn spots. As with everything, it'll need cleanup.

Basically the idea is to be fully generic with low to zero overhead, with maximum customization.

Client side scripting is possible, but largely dependent on getting the list of scripts from the server to the client.
There is no 100% reliable way to do this that can't be used to break clients, but the new design it's using should make it easier than SC's version.
Since this version only loads 1 script, not many, and doesn't allow entities to load additional scripts, voiding the need to preprocess the map's entity data, it's as simple as sending the one script filename to clients.

I'm planning to convert this codebase to CMake at some point to allow for easier cross-platform compilation. The AngelscriptUtils repository uses it, and now that i've got the hang of it, it's relatively easy to take care of.

Note to anyone trying to compile this: i haven't committed all of the code it references. I'm using Source SDK code, which strictly speaking can't be used in any non-Source engine mod projects. Unless there's an exemption, or if it plain doesn't matter, i'll have to find another way to sort that out.

It's used by VGUI2 code, which i'm going to use to replace the UI. It has much better support for UI design, and since the engine provides support for it, i don't see why i shouldn't. It should also allow me to access UI elements defined in GameUI.dll, like the Options menu. Being able to get to that code would be a great advantage.

I'd love to hear any suggestions and/or feedback, but remember that i've got a lot of work on my plate already. This isn't the only project i'm working on, and i've got exams in August to worry about, so if i take some time to reply or get something done, that's why.
15 Jul 16, 21:15
By Shepard62700FR
avatar
Member
That's quite interesting, I will likely contribute to the project.

Quote:
It's used by VGUI2 code, which i'm going to use to replace the UI. It has much better support for UI design, and since the engine provides support for it, i don't see why i shouldn't. It should also allow me to access UI elements defined in GameUI.dll, like the Options menu. Being able to get to that code would be a great advantage.
I would suggest a define set up in the projects configuration like "USE_VGUI1", if true, you would use VGUI1 and have no dependencies on Source SDK, if it's not defined, then use VGUI2 but Source SDK is a dependency. Speaking of that, is it Source SDK 2013 ?
15 Jul 16, 21:21
By Solokiller
avatar
Member
It uses Source 2006. The later versions are incompatible with it. Even 2006 has issues, since it's one or two interface version ahead of GoldSource, but it's manageable.
15 Jul 16, 23:07
By JeffMOD
avatar
Call 141.12

I get a big white section in my view while ingame that renders over everything including the HUD (but not while paused) Let me know if this is unknown behaviour so I can give you my GPU specs.
EDIT: Also I know this is technically an art issue, because the ACT defines in the model are swapped, but the M40 still has the bug from Op4 where it's calling the reload bolt animation after firing and the regular bolt animation when reloading. tongue - :P
16 Jul 16, 05:08
By DiscoStu
avatar
Member
That looks like a placeholder for the HUD in CS.
16 Jul 16, 07:55
By Solokiller
avatar
Member
Both of those white rectangles are VGUI2 panels. They're just tests, and i left them there to remind me that VGUI2 support is unfinished. I can disable them if they're a problem.

I deliberately left the M40 animation bugs in it. I reverse engineered the implementation from Op4's server library, including any bugs there may be. I can fix it easily enough.
16 Jul 16, 12:44
By JeffMOD
avatar
Call 141.12
Well then, everything seems to be in order. Disregard.
16 Jul 16, 22:25
By Solokiller
avatar
Member
I cleaned up the client side a bit. The entire cl_dll directory is gone, with files either being moved or removed altogether.
Also dealt with some dll specific code, server headers should now work fine when included into files that have client headers. It's almost completely clean now.
17 Jul 16, 00:33
By Loulimi
avatar
Member
So, this is basically an improved base for mods? It looks very useful. Thanks for that Solo and good luck with your exams!
17 Jul 16, 22:12
By Solokiller
avatar
Member
Yeah, it's supposed to be easier to use and actually have documentation.

I've reworked a lot of stuff today, so most of the SDK now uses CBaseEntity instead of entvars_t and edict_t. I'm adding getters and setters now, once that's done all direct references should be gone. It'll make implementing parenting a lot easier, though i'll need to hack around the lack of an EndFrame function.
Most of the utility code works in both dlls now too, with some obvious exceptions.

It should be headache free soon enough.
17 Jul 16, 23:18
By Instant Mix
avatar
Horton hears a who?
I'm glad to see the stuff going down with Sven and Sniper hasn't killed your enthusiasm for HL. I'd also XPost this on facepunch, people there will be glad to see you still working on things.
Keep it up, this stuff is really interesting, it might make me eventually attempt to learn Angelscript!
18 Jul 16, 07:15
By Solokiller
avatar
Member
If anything, it's only made me more motivated. While i was still on the team Sniper complained about my efforts quite often. Now that i can work without complaints i can do a better job. If i'd done this in SC's codebase he'd have had an aneurysm. He complained when i did stuff as simple as removing obsolete void parameters.

I'll post it on Facepunch if i can find the right forum. They've got a fair number of them.
18 Jul 16, 10:12
By Instant Mix
avatar
Horton hears a who?
It's a complete shame that sniper acts the way he does towards the SC team; it seems that it's his superiority complex that's slowed down the updates on SC, and left game breaking bugs in. I hate to say it, but it feels like he will be the death of Sven Coop.
Do a small explanatory post in the Half Life thread in GGD, and also one in the programming forums' What Are You Working On.

Is there any particular benefit or hindrance from using a single file defined by the Map rather than many separate ones? Could this also then mean it may be possible to include the code as part of the .bsp file itself?
18 Jul 16, 11:12
By Solokiller
avatar
Member
Sven Co-op is more about politics than game development these days. It's a shame, but it's been like this for a long time. All that talk about releasing updates faster because of Steam didn't end up going anywhere.

You can #include other scripts in the main script file. I haven't added include resolving yet, but it should be simple enough. Since i documented IFileSystem, i can actually use the right method this time around.
I remember struggling to find the right one while working on SC, and it doesn't handle includes across different content directories properly. I'll be checking for that problem specifically.

Embedding scripts in maps is possible, all i have to do is add new lumps. The problem is that engines that also have other lumps can end up having problems. I'd have to hack around it, probably append a lump after the end of the entity data string and add a worldspawn keyvalue to indicate its presence. It could be a pain to do every time you compile a map.
18 Jul 16, 11:56
By fuzun
avatar
Member
You are doing great work man! I hope you will get enough support and contributors on your project.

Is there anything we can do about laserspot(rpg.cpp) lag? It is defined with #ifndef CLIENT_DLL. Maybe removing this solve the issue?
18 Jul 16, 12:14
By Solokiller
avatar
Member
The lag is caused by a lack of client side prediction. you'd have to simulate the entity on the client side to fix it, which isn't possible without some major reworking, if it's even possible at all.

You might be able to do that if you skip sending the dot to the owning client and then create a high priority temp ent, but i'm not sure if that would work well. I'll have to review the temp ent reallocation protocol first to verify that it doesn't destroy them at will.

EDIT: seems like high priority temp ents are never freed on demand, only low priority ones. I'll add this to my TODO list and look into it later.
18 Jul 16, 12:35
By fuzun
avatar
Member
I work sometimes with Xash, can I call the entity creator function which is defined in Xash from client?
18 Jul 16, 12:43
By Solokiller
avatar
Member
I have no idea what Xash does so i doubt it. Xash probably doesn't support VGUI2, so this won't even run under it.
18 Jul 16, 15:13
By Shepard62700FR
avatar
Member
Xash3D is just a Quake engine with HL compatibility stuff and some rewritten leaked HL2 2003 save/restore code. The GitHub source code of Half-Life (and also HL:Enhanced) won't work due to Steam & SDL2 dependencies. Trust me, I tried.
18 Jul 16, 18:14
By Solokiller
avatar
Member
Alright, well then Xash is out of the picture.

BTW, i just fixed the sniper rifle reload animation. I guess whoever wrote it made the same mistake i made when rewriting the code. The animation was calculated as 3 - ( iClip < 1 ), where 3 is the last round animation, and 2 is regular reload. The result is inverted. I rewrote it and inverted it by accident. Que surprise when it worked properly.

Also, somebody asked me a while ago how the CS shield works, apparently the gamestate entvars_t member is used to signal this. Setting it to 1 disables that particular hitbox. It probably has to be set on the player, since the player model has that hitbox.

EDIT: i've also bumped up the number of weapon slots to 10, and set the number of buckets to MAX_WEAPONS.
You no longer need to override iItemSlot to put weapons in the right slot, it all uses the same definitions now. This also means that 1 fewer array entry is required for weapon lists on the server side, since index 0 is now used.
18 Jul 16, 18:27
By JeffMOD
avatar
Call 141.12
Something I just noticed - while it doesn't do it to living monsters, the M40 can gib them once they're dead, which it doesn't do in Op4.
18 Jul 16, 22:37
By Solokiller
avatar
Member
Thanks for the report, i've fixed this just now. The cause was that 762 bullets deal a lot of damage per shot, and damage above a certain amount would always gib corpses. I've added in checks to prevent this from happening.
19 Jul 16, 10:03
By Solokiller
avatar
Member
The materials code has been overhauled. The duplicate list in sound.cpp is now gone, and since it now uses the sorted list lookups are faster.
The list that was in pm_shared.cpp is now a class, and uses dll agnostic code.

The maximum texture name length now matches the maximum WAD lump name length (16), ensuring that similar names don't cause any incorrect material types to be returned.
19 Jul 16, 11:09
By Instant Mix
avatar
Horton hears a who?
You really seem to know your way around the engine. Has this been through loads of research or just a lot of trial and error?
19 Jul 16, 11:16
By Solokiller
avatar
Member
I worked with it for 2 years while working on SC. I worked on the engine itself for a little under a month, mostly removing obsolete code, and i've spent the past few months reverse engineering its code when needed. The Linux libraries contain symbol info, so you can pretty much get the entire engine's source code from it.
19 Jul 16, 15:41
By Shepard62700FR
avatar
Member
One of these days I should learn how to "read" from Linux librairies.
19 Jul 16, 18:08
By Solokiller
avatar
Member
I use IDA to read it. Just open the Linux library and it will pull all of the functions, classes, enums and vtables out of it. Even the game libraries have this information. I'll be getting the Op4 rope code that way to implement it in HLEnhanced.
19 Jul 16, 21:32
By Shepard62700FR
avatar
Member
I do have IDA and I did tried to read the Linux library, the only thing I've managed to get so far is assembly code and I have no experience in assembly, is it possible to get a "reconstructed" C/C++ code with IDA or do I have to do the assembly -> C/C++ translation ?
19 Jul 16, 21:39
By Solokiller
avatar
Member
You have to use pseudocode in IDA to see readable code. Pressing F5 should open it if you're currently in a function.
View->Open Subviews->Pseudocode also opens it.

I've cleaned up the dll specific code some more. I think i've made all of the non-edict code compatible with the client now, so i'll change my focus to simplifying entity code. I've also eliminated most duplicate constants, though there are some more magic numbers to deal with.

The CBasePlayer code has been split into separate files, since it was a 4000 line source file before.

Still a few TODO items to take care of, but it's getting there.
20 Jul 16, 20:03
By Solokiller
avatar
Member
I've cleaned up the client interfaces, you can now see return types and parameters in IntelliSense, and it's easier to read the interfaces themselves.

I've also found a way to be notified of new map start events on the client side. I reported the lack of proper support on Github, and linked to the workaround: https://github.com/ValveSoftware/halflife/i
ssues/1726


So i could extract the name of the map script from worldspawn if i wanted to.

EDIT:
Most of the client side engine APIs have been documented, just have to do the effects API.
22 Jul 16, 15:19
By Solokiller
avatar
Member
Thought i'd give an update:
The client side engine APIs have mostly been documented, just missing some flags and type parameters. Have to double check some functions that modify input vectors so they're marked as non-const.

I've pretty much eradicated float arrays used as vectors, matrices are structs now.

Some per-map setup code has been moved to better handle edge cases. I've fixed a problem where ammo types weren't getting sent in singleplayer after map changes. Apparently ClientPutInServer doesn't get called again, one more thing to document.

The client side user message reading code has been refactored into a class. This eliminates the global variables used by it, saving a grand total of 13 bytes. It also uncovered an incorrect use of reading operations: https://github.com/ValveSoftware/halflife/i
ssues/1731


Unlikely to ever be triggered since benchmarking isn't exactly functional, but still.

The player hornet gun damage cvar has been added: "sk_plr_hornet_dmg". Was not present due to time constraints during Half-life's development.

The materials list now checks for duplicates and warns about them, replacing old material types with new ones in the process. There are several duplicates in the vanilla version.

The node graph generation code has been tidied up. It used to work like this:
First node creates test hull. Test hull drops to floor and walks the graph during physics simulation time, generating the links.
When the first player spawns, if the graph pointers weren't already set, they are set now.

This has been changed so graph generation occurs in ServerActivate. Pointers are set right after. It should all happen before a player ever finishes connecting. This should prevent any issues with graph pointers being set when a player connects. Valve had a note added to the code indicating that it should be moved, which is why i did it.

Finally, a bunch of pev-> accesses have been changed to use getters and setters. It's easier to read, and it will make adding features like parenting easier since you don't have direct access to variables that may need to be synchronized with parents or children on change.

Eventually, all uses of entvars_t and edict_t will disappear, so code that currently looks like this:
EMIT_SOUND_DYN ( ENT(pev), CHAN_WEAPON, "agrunt/ag_fire1.wav", 1.0, ATTN_NORM, 0, 100 );

Will look like this:
EMIT_SOUND_DYN( this, CHAN_WEAPON, "agrunt/ag_fire1.wav", 1.0, ATTN_NORM, 0, 100 );

Essentially, all references to entities will use CBaseEntity, so there will be no confusion as to whether you should pass CBaseEntity, entvars_t, edict_t, EOFFSET, or entindex. Unless changing code would cause performance issues, that's all going away.

I've found several problems in the SDK while cleaning it up, which have been reported: https://github.com/ValveSoftware/halflife/i
ssues


It also looks like all library specific code is now safe to include in the other library as well, so server code works in the client. There's no reason to use client code in the server library, but it probably works.

On the topic of customization, i've been thinking about a few things. Model and sound replacement is easy to add, making some entities have customizable settings isn't hard.

Client side scripting shouldn't be that hard to add now that i can get the map name at a good and early time, which should open up some possibilities like client side effects, custom HUD elements, and VGUI panels.
I'll have to investigate how easy this would be and how to clean up a script's instances on map change, but i don't expect many problems.

I also have to consider cheating as a possibility. In competitive multiplayer mods allowing any random script to run is a risk, so i'll have to make sure all scripts are verifiably secure. Sending over CRCs from the server is one option, but not scalable as-is. I might port the ENet client-server prototype i made to transfer any bulk data i need on the client, including CRCs.
The scripts will still be able to initialize and run, but at least the player won't get very far before being kicked out for cheating.
Alternatively, scripts could use the .txt extension and be precached with ForceUnmodified calls to make the engine check it. That just leaves making sure that #included scripts and scripts specified through some external manner can't be compromised.

Still lots to do, but it's getting better. It would be nice if i could get some engine support, since i've bumped into a few more limitations that would be trivial to solve with access. Documenting stuff would be a lot easier if i didn't have to figure out what magic number flags do.

If anybody wants to try it out, i can upload a new version. It's pretty much the same as the last one, so don't expect any changes in performance or gameplay.
22 Jul 16, 17:02
By JeffMOD
avatar
Call 141.12
As satisfying as it would be to use the newly-fixed M40, I'm not gonna bug you for a build just yet.
Keep up the good work on fixes and reorganization smile - :)
22 Jul 16, 19:46
By Solokiller
avatar
Member
Thanks smile - :)

I just reverse engineered the VoiceTweak API. It's largely obsolete from what i can tell - since the Steam voice API is being used - but you can use it to manually start and stop voice recording, so that's something.
25 Jul 16, 19:31
By Solokiller
avatar
Member
I decided to do something different and spent the weekend implementing Opposing Force's ropes and electrified wires. You can now use them just like in Op4.

There are 2 known issues:
1.) You might get stuck in geometry if swinging close to it and jumping.
2.) It doesn't support multiple players.

I'll look into supporting multiple players, or preventing problems when more than one player touches a rope.

The physics used by ropes is quite interesting; it uses an RK4 integrator with dampened springs. This allows it to simulate physics with velocity that changes over time, and the springs keep each rope segment in place. The dampening effect gives it more realistic motion.

I had to completely re-implement the physics for it, since getting the code for it out of the library was too hard. If anybody wants to learn more about it, i referenced these articles:
http://gafferongames.com/game-physics/integ
ration-basics/

http://gafferongames.com/game-physics/sprin
g-physics/


I've got some cleanup to do, after which i'll upload a new build.

I suppose Sven Co-op could use ropes in its Op4 campaign, so if they want to use it, they're free to do so as long as they credit me for the work i put into replicating it.
25 Jul 16, 20:34
By Solokiller
avatar
Member
And it's done: https://dl.dropboxusercontent.com/u/4604897
9/hlenhanced.rar


Note that you'll see some red particles at the world origin if developer mode is enabled. When i reworked the node graph code, some old debugging code that highlights bad nodes with particles got reactivated. I added a check to prevent it from showing up unless developer is non-zero.

Some official maps have no nodes, like ofboot3, so you'll notice them there.
25 Jul 16, 23:48
By fuzun
avatar
Member
You are doing great work! Although I will likely test this after a while, I am more interested in bullet smoke effect.

Shoot a brush and you will notice a sprite like smoke effect.(Iam not sure but it may use a fixed pattern) What is the backend of this? Particle manager? Tri API?

I don't remember this effect in hl1 campaign. Is this added with opposing force? Needs implementation on engine?

For the Sven coop. I think it must be partially open source for sake of the community. Its full of bugs and they are making things worse even with this state.
Dude tell me what is this. Jump and duck and do this constantly in hl train. After a while you will be outside of the damn train lol &#128512;
This is too obvious why release it with this annoying bug?

Something must be done for this game or it will be fucked up very soon &#128546;
26 Jul 16, 01:48
By Penguinboy
avatar
Haha, I died again!
Awesome! Adding the rope is excellent, I don't think I've seen any other custom mod try and add the rope into the HL SDK. Can someone post a video of it in action for us lazy people? >_>

Do you plan on making it compile-able for everyone at some point? Adding the missing code you mentioned before?
26 Jul 16, 08:50
By Solokiller
avatar
Member
@fuzun:

You mean the particle effects? That's the efx API, R_BulletImpactParticles. I'm not seeing any smoke, just the black particles and spark effects.

The HL train issues are caused by setting the player's solid state to SOLID_NOT. It caused collisions to stop working properly and players and up clipping through walls more easily. It was disabled so players wouldn't collide with eachother. I tried to make a proper alternative, but i couldn't get it to work.

IMO the team doesn't have the manpower to get the job done. Sniper was trying to sell the idea of CEF again yesterday, posting a 4 year old mockup (again). I've heard that story too many times, and it pisses me off that he keeps trying to draw interest with things that will probably never happen. Just use CEF1, it's in the engine and it actually has an implementation. And it actually works...

@Penguinboy:

It looks pretty much the same as it does in Op4.

I'm going to write CMakeLists with builds for VGUI1 and 2 so you can compile the VGUI1 version. That should deal with any compilation issues you're having. It'll also deal with Linux and (hopefully) Mac build configs.
26 Jul 16, 09:43
By fuzun
avatar
Member
Yes I meant that. Sorry for broken English.

Currently ev_hldm.cpp -> void EV_HLDM_GunshotDecalTrace(...) contains this:(In hlsdk 2.3 and hlenhanced)

gEngfuncs.pEfxAPI->R_BulletImpactParticles(
pTrace->endpos );


And in Xash or goldsource engine its implemented like this:
Quote:

void CL_BulletImpactParticles( const vec3_t org )
{
particle_t *p;
vec3_t pos, dir;
float vel;
int i, j;

// do sparks
// randomize position
pos[0] = org[0] + Com_RandomFloat( -2.0f, 2.0f );
pos[1] = org[1] + Com_RandomFloat( -2.0f, 2.0f );
pos[2] = org[2] + Com_RandomFloat( -2.0f, 2.0f );

// create a 8 random spakle tracers
for( i = 0; i < 8; i++ )
{
dir[0] = Com_RandomFloat( -1.0f, 1.0f );
dir[1] = Com_RandomFloat( -1.0f, 1.0f );
dir[2] = Com_RandomFloat( -1.0f, 1.0f );
vel = Com_RandomFloat( SPARK_ELECTRIC_MINSPEED, SPARK_ELECTRIC_MAXSPEED );

CL_SparkleTracer( pos, dir, vel );
}

if (r_oldparticles->integer == 1)
{
for (i = 0; i < 12; i++)
{
int greyColors;
p = CL_AllocParticle(NULL);
if (!p) return;

p->die += 1.0f;
// Randomly make each particle one of three colors: dark grey, medium grey or light grey.
greyColors = (rand() % 3 + 1) * 32;
p->color = CL_LookupColor(greyColors, greyColors, greyColors);

p->type = pt_grav;
for (j = 0; j < 3; j++)
{
p->org[j] = org[j] + Com_RandomFloat(-2.0f, 3.0f);
p->vel[j] = Com_RandomFloat(-70.0f, 70.0f);
}
}
}
else
{
for (i = 0; i < 12; i++)
{
p = CL_AllocParticle(NULL);
if (!p) return;

p->die += 1.0f;
p->color = 0; // black

p->type = pt_grav;
for (j = 0; j < 3; j++)
{
p->org[j] = org[j] + Com_RandomFloat(-2.0f, 3.0f);
p->vel[j] = Com_RandomFloat(-70.0f, 70.0f);
}
}
}
}


But when I play half-life, there is no such effect.

===

Is there any chance for using old menu instead of vgui1?

I think it would be very good if you make it switchable between vgui2 and old ui. Please take a look at this: https://github.com/FWGS/xash3d/tree/0bfac66
4a3de49044356a17515cdf8a17f5e2817/mainui


I think they are taken from quake codebase but its very lightweight and its open source instead of vgui.

===

What actually is CEF?

===

Although I think the angelscript for svencoop wont be finished without you, people are using it instead of amxmodx and metamod because they make the game very unstable.

There is a semiclip meta plugin available for svencoop. Can we do this with Angelscript's current form?

===

Can you add green-tint aka goldsource nightvision support (It should be controllable with a concommand)? Cs 1.6 has this. It is 15-20 lines of code and you can seek the implementation after decompiling linux library.
26 Jul 16, 10:07
By Trempler
avatar
Member
Great work Sam, this is getting better and better, now I wish myself the weather and fog system from CS 1.6 in hl:e smile - :) that would be awesome !
26 Jul 16, 10:35
By Solokiller
avatar
Member
@fuzun:

I'm guessing the Steam version of Half-Life doesn't use the HLDM tracer code. They're all labeled as HLDM, so that's probably it.

Do you mean the WON menus? You'd have to replace the entire GameUI library to do that. Might be possible, but i'd have to reverse engineer the entire interface to make that possible.

CEF, or Chromium Embedded Framework, is an open source framework to let you integrate HTML5 and Javascript into your program.

CEF1 is the original implementation. It's obsolete, but the engine uses it for HTML MOTDs in Counter-Strike.

CEF3 is the latest version. It's more powerful, but also a lot more expensive. It uses a multi-process implementation to run each subprocess, so while it's more performant due to being asynchronous, it's also harder to implement. Its off-screen rendering support wasn't working properly for a few years.

The team should just use VGUI2's CEF1 support. If they were to design their code properly, switching over to CEF3 later on would be easy. Instead, they suspended all VGUI1 issues and then didn't do anything about the CEF based HUD.

Big waste of time IMO, i don't think they even knew you could use CEF1 VGUI panels in game code. I figured it out pretty quickly, since i actually looked at the interfaces.

I honestly don't know where they're going with Angelscript. All i know is this, a quote from Sniper from when shit hit the fan:

Quote:

If so, it better be done very very well. I'd rather not lose what the current implementation is giving us.
Sniper - Yesterday at 9:11 AM
The current implementation is based off the idea of directly exposing HLSDK functions.
The purpose was to provide a second HLSDK to the public, on a mapper level.
If we were to start from scratch, the theory behind the implementation is certainly easy to reintroduce with a new code base.
That doesn't worry me.
My worry is from time constraints. I don't think I can be the one to do that level of work right now. My time is currently being spent on the new website.
Someone else needs to carry the torch
(Hopefully, a mentally stable person)


If i interpreted this correctly, they're going to scrap the entire thing and re-implement it. They haven't shown any progress since i've left, so they clearly aren't working on the existing version. Even the most trivial issues that were logged on the Github issues page haven't been dealt with.

I doubt you can implement a clipping plugin fully in Angelscript, but you're welcome to try. You'll probably need hooks in the player physics code.

For the record, adding hooks is usually no more than ~5 lines of code. The only reason the requested hooks weren't added on the spot is because i created a thread in the internal forums asking for discussion and feedback. There were no replies to that thread either.
I should've ignored the team and implemented them as needed, but then again, hindsight's 20/20. I'm sure i would've been yelled at for adding hooks that Sniper didn't want, he's always like that.

I'm going to add client side scripting support so you can add your own suit types, then you can implement the flashlight however you want. Whether that's EF_DIMLIGHT or some green tint, it'll be up to you. Can't say when that'll be though.

@Trempler:

I can probably reverse engineer that stuff as well. What are the entities/cvars named?
26 Jul 16, 11:45
By Jessie
avatar
Ladytype
I'm curious, since you seem to be busting goldsource right open in a rather impressive way:
Could you, say, implement inertia? And by that I mean specifically how, as is, jumping while on moving platforms does not function realistically.

I mean, just about everything in this entire thread is above my head in terms of scope and possibilities, so this is the least of my questions.

(Incidentally, I apologize if this is already a thing. I sure haven't tried it out.)

Keep it up! It's all terribly interesting and impressive, what you're doing here. smile - :)
26 Jul 16, 11:53
By Penguinboy
avatar
Haha, I died again!
I might be entirely wrong about this, but I think it's very possible to change the player movement behaviour, Jessie. But I've taken a look at the PM code before and it's bloody awful. 3400 lines of Spaghetti code, I'd hate to have to work on that!
26 Jul 16, 16:32
By Solokiller
avatar
Member
I've cleaned up the PM code a bit, using Vector operators to trim the hedges a bit. It's only 3000 lines of code now.

It might be possible to add velocity when you jump to match the entity you're standing on. I'm guessing something like this:

Quote:

if( player jumped )
{
player->velocity = player->velocity + jump velocity + onground->velocity
}


I haven't checked the code so i don't know what it's doing, but this should help. If the player's velocity already includes the onground velocity (entity you're standing on) then it's unnecessary.
IIRC player velocity while on an entity is handled a bit differently, it also has to account for basevelocity (conveyors) so it'll probably have to wait until the PM code has been documented and cleaned up.

EDIT: Trempler reported invisible ropes in multiplayer. Turns out having the segments constantly be made visible and invisible makes them completely invisible in multiplayer. So as a workaround, in multiplayer the primary segments are always visible, and the alternate ones are always invisible. There will be a slight lag in the rope's movement, but it works.

EDIT2: New version: https://dl.dropboxusercontent.com/u/4604897
9/hlenhanced.rar


EDIT3: Movement handling for standing on entities isn't handled using velocity. The physics code will move entities that stand on them without applying velocity, which is why you don't have any inertia. Here's the Source SDK version of the code that does this: https://github.com/ValveSoftware/source-sdk
-2013/blob/master/sp/src/game/server/phys
ics_main.cpp#L235


EDIT4:

I was able to add inertia. Jumping while standing on moving entities now adds its velocity to your own. Jumping onto a moving platform causes you to sort of trip due to the difference in velocity.

There's a slight difference in velocity caused by imperfect calculations, nothing i can fix easily. If you jump, you'll keep going in the same direction as the platform, and when you land on it, you may bounce forward a bit.

You'll notice that when you jump, even if the velocity is being clamped, you'll keep moving forward. It's easy to test on c0a0 and the script test map, which has a train that you can keep up with only if you keep it at its lowest speed. Otherwise your velocity will be clamped.

Download: https://dl.dropboxusercontent.com/u/4604897
9/hlenhanced.rar
26 Jul 16, 18:46
By Solokiller
avatar
Member
I've created a new branch for the CMake build files. I'll be writing CMakeLists in it, moving files as needed to best suit the structure used by it. When it's done, you'll be able to generate project files for any supported platform and build system (VS, Make, etc).
It'll make cross-platform development much easier.

Once this gets finished, i'll merge it in and try to build the Linux version. I'll fix any problems there may be and check if older VS versions have problems building it (there will be problems).

You'll need to use VS2015 with the v140_xp toolset to support the language features used, and to target XP correctly. Gitignore has been updated to ignore projects_* directories, so name the generated directories as such so they aren't committed. You should always generate the projects locally, never commit them.

After that's done, i've got some work to do for HLMV.
26 Jul 16, 19:58
By Bruce
avatar
Member
most people are probably looking at this thread thinking WTF!?
26 Jul 16, 20:09
By Solokiller
avatar
Member
I have no idea what you're talking about.
26 Jul 16, 21:34
By fuzun
avatar
Member
Did you notice there are some updated files from hl1 sdk in hl2 leaked source?

They may be useful for this project. But they are adapted to source I think.
26 Jul 16, 21:45
By fuzun
avatar
Member
And I am looking forward for this: (These are from cs 1.6 client.so)



Pseudocode is pretty sensible. I think you can do this easily but you really need time or contributors.

Even 1 or 2 contributors may help this project greatly.
26 Jul 16, 22:20
By Solokiller
avatar
Member
I don't want to use leaked code, that's definitely a legal issue waiting to happen.

I'll look into the weather effects code, doesn't look like it's that much effort.

EDIT: also i finished writing the CMakeLists. Just need to move some engine headers around and check the rest of the settings and it should be good to go.
[1] 2 3 4 5 6 7 8

Forums > HL Engine Discussion

Login to Reply

You must be logged in to reply.