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-08-24 18:17:12 UTC Post #331417
I know, that's why i'm saying that. impulse 101 gives you everything except the Penguin. I think you might have misunderstood me :P
Posted 1 year ago2016-08-24 19:21:16 UTC Post #331419
:P Seems so.. Anyway good job on getting all the weapons in.

What will be next on your agenda regarding priority?
Posted 1 year ago2016-08-24 20:16:56 UTC Post #331421
Tested out everything, it all checks out fine and acts flawlessly except the melee weapons - not sure how/when this bug cropped up, but the animation call for the attacks seems to be called twice - it will only do damage once, but each press of the attack button creates two quick, concurrent swings on all three of them.
JeffMOD JeffMODCall 141.12
Posted 1 year ago2016-08-24 20:55:20 UTC Post #331422
@23-down:

I'm going to look into cleaning up the monster code. There's a lot of room for improvement there.

@JeffMOD:

Thanks for trying them all out.

That might have something to do with how melee weapons handle swinging after the first swing. I'll take a look at the code tomorrow.
Posted 1 year ago2016-08-25 02:55:57 UTC Post #331425
you beta testing some custome code HL mod? have dll download?
Posted 1 year ago2016-08-25 09:32:27 UTC Post #331427
I fixed the double animation issues for melee weapons. As i suspected the manner it uses to swing again was responsible. It uses think functions, and since client side weapons can now use those, it was being run on the client as well.

@2muchvideogames:

You can download the game repository here: https://github.com/SamVanheer/HLEnhanced-Game
Posted 1 year ago2016-08-27 14:45:55 UTC Post #331430
I've done a couple of things, so going to list them one by one.

First off, i moved the commented out code in the Pipe Wrench to inside the ifdef as suggested by Shepard62700FR.

I added a missing weapon damage assignment for the Desert Eagle. It was doing 0 damage before.

I've refactored the skill system: values are now accessed using methods instead of accessing the skilldata_t members themselves. The members have been changed to cvar_t pointers. RefreshSkillData will now cache the cvar pointers themselves instead of caching the values, allowing you to modify skill cvars and have real-time changes.

Additionally, the multiplayer skill value overrides have been changed into cvars of their own. Previously, the damage values for some weapons, as well as the amount of juice in suit chargers were hardcoded. Now, if the cvar has a multiplayer override, there will be a <cvar name>_mp<skill level> cvar that can be used to set the value.

I've noticed that the Pipe Wrench secondary attack has some animation glitches, so that'll need looking into. Sometimes the charge animation plays multiple times, and when hitting monsters it doesn't play the hit animation at all.
Posted 1 year ago2016-08-27 18:21:45 UTC Post #331431
I've also fixed a bug with trigger_camera. When using cameras, any effects handled by events would use the wrong angles. I've corrected this, so now things like gauss guns work properly.

I've also debugged the issue where using a camera that's outside your PVS doesn't render anything. I was unable to fix it, but i did find a possible cause of the problem and reported it. You can find the issue here: https://github.com/ValveSoftware/halflife/issues/1745
Posted 1 year ago2016-08-27 22:43:14 UTC Post #331441
I've fixed some bugs with killtargeting monsters. Monsters didn't inform the monstermaker that created it when it got removed so it broke the internal counter. I've also fixed monster effects not being removed.

The following monsters now remove their effects:
Alien Controller
Alien Slave
Gargantua
Tripmine
Turret
Nihilanth

If there are any other monsters that spawn effects like sprites or beams that stay behind, let me know and i'll deal with them as well.
Posted 1 year ago2016-08-28 07:54:33 UTC Post #331444
hey!
would u like to add FOG?
Posted 1 year ago2016-08-28 08:42:58 UTC Post #331445
Sure, but it'll only work in OpenGL.
Posted 1 year ago2016-08-28 17:30:19 UTC Post #331451
Maybe it's a stupid question, but:

Would you be able to integrate Vulkan API?
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-08-28 18:26:26 UTC Post #331452
That's a lot of work, and it needs engine level support to work properly. I might be able to override the engine entirely, but it won't be pretty in any case. I've never worked with the API before, and i've heard it's quite verbose, so it's definitely not something i can just do on a whim.
Posted 1 year ago2016-08-28 18:34:32 UTC Post #331453
@Alberto : Making a Vulkan renderer is do-able if we have the engine code but I think it's a no for implementation because it's only supported by very modern hardware. I think the priority would be to either update or make a new OpenGL renderer (ver. 3/4 based on shaders) to overcome some flaws with the "immediate" OpenGL 1.2 (AMD/ATI users are mostly concerned by this)

EDIT : Ninja'ed by Solokiller xD IMHO Vulkan under Gold Source would be overkill, it's like ordering 50 burgers at a restaurant for a 2 years old kid (hourray for the exemple xD)
Shepard62700FR Shepard62700FRHalf-Cat is watching...
Posted 1 year ago2016-08-28 18:57:58 UTC Post #331454
I personally don't think we need these fancy graphic updates. Simple fog as seen in cs1.6 or so sure but everything that goes beyond that what for?

Half-Life FX - Xash3D the list goes on. The engine can't handle that stuff. For fancy graphics and effects people should work with the Unreal Engine and not a 17 year old game engine. Not to mention it wouldn't feel much like Half-Life anymore. Of course this reflects only my personal opinion regarding the Vulcan API set.
Posted 1 year ago2016-08-28 19:23:31 UTC Post #331455
A newer renderer does not have to mean better graphics. Just getting the performance up for video cards that don't support immediate mode would be enough. I made a prototype renderer that can use OpenGL 3.x era shaders to do exactly what GoldSource does, just better. Rendering an entire map (bootcamp) ran pretty well even without vis calculations.
Posted 1 year ago2016-08-28 22:51:54 UTC Post #331460
I've overhauled the monster schedules code. Previously, if a monster needed custom schedules, you had to do this:

Class declaration:
CUSTOM_SCHEDULES;
Source file:
DEFINE_CUSTOM_SCHEDULES( thisClass )
{
//Schedules here
};

IMPLEMENT_CUSTOM_SCHEDULES( thisClass, baseClass );
This has been changed to this:

Class declaration:
DECLARE_SCHEDULES();
Source file:
BEGIN_SCHEDULES( thisClass )
//Schedules here
END_SCHEDULES()
Aside from requiring less code, it also simplifies a few other things.
The old code would override ScheduleFromName so it could find schedules for the monster. This has been changed so that the monster stores a pointer to its base schedules list as well. CBaseMonster can then loop through the monster's schedules, derived to base.

This also allows you to check which schedules a monster has, which previously wasn't possible.

The syntax matches the data descriptor version, so it's all nice and consistent now too.

There's a slight increase in memory usage to store the pointer to the base list and number of schedules in the list, but that's minor. Since ScheduleFromName is no longer virtual it doesn't need an entry in the vtable, so it ends up balancing out a bit at only 4 extra bytes per monster class that needs custom schedules.
Posted 1 year ago2016-08-29 14:38:55 UTC Post #331463
I've done some minor cleanup in the monster code and am looking around for more stuff to clean up while i figure out what needs to be moved to CBaseCombatCharacter.

I've got a question: would anyone want it to be possible to spray decals, toggle the flashlight and use items while reloading? I can change some code around to make that possible, or make it controlled by a cvar.

I've also made it so that turning on godmode also blocks armor damage. That has bothered me for years, so i changed it.
Posted 1 year ago2016-08-29 16:47:28 UTC Post #331467
Oh but the purpose of having Vulkan with Goldsource isn't for fancy graphics, is for having more performance and compatibility with AMD/ATi cards.

I mean think about it, we could create a map in Goldsource that's detailed as much as a one made on Source, but the engine wouldn't be able to support all the details, forcing us to make less detailed maps due to the old render and probably because of NO multicore rendering.

Second question then:

Instead of Vulkan API, would you be able to add multicore rendering? That would certainly help a lot imho.
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-08-29 18:05:32 UTC Post #331472
That would also require engine level support. It's not designed to handle multiple threads at once, so you'd end up with dangerous race conditions. At that point, without engine access you're almost better off making a new engine.
Posted 1 year ago2016-08-30 16:03:21 UTC Post #331479
can u tell me something more about angelscript with half-life 1? does it work now?
Posted 1 year ago2016-08-30 18:11:33 UTC Post #331480
That depends on how you define work. The implementation works just fine, aside from release builds currently failing to due compatibility issues with the static libraries, but that'll be sorted out soon.

The API is pretty bare at the moment because it's not a priority. I'd prefer to first finish refactoring the codebase before exposing anything else. Otherwise it'll be a cycle of having to update the API to match internal changes and breaking scripts in the process.
Posted 1 year ago2016-09-01 15:41:48 UTC Post #331499
What do you mean with "you'd end up with dangerous race conditions"?
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-09-01 15:59:32 UTC Post #331500
The engine loads the models so if one thread were loading models and another were accessing that data you could end up accessing data that isn't fully loaded yet, or has just been freed. Similar issues exist all over the place, anywhere where data is accessed by multiple threads. Since you can't go into the engine to change it you're stuck with that setup.

Source solves race conditions in file loading code by using asynchronous loading with callbacks, so you can only use that data once it's all there. Threading support in the engine ensures that nothing can go wrong there, although there are always restrictions to take into account when running code in other threads.
Posted 1 year ago2016-09-01 16:30:18 UTC Post #331501
Ah I got it.

Shame on Valve not releasing the source code of an 18 years old engine...

What about letting the engine to use more RAM?
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-09-01 16:45:55 UTC Post #331502
the goldsrc codebase is filled with comments about how sleazy it is. no surprise.

while we're on this topic, do you know what causes that glitch with the 9mmAR failing to show the reload animation sometimes?
Posted 1 year ago2016-09-01 16:56:57 UTC Post #331503
@Alberto309:

You can do that by specifying a higher heapsize using the -heapsize parameter. It specifies the size of the heap used for most of the allocations, in kilobytes. The maximum heap size is 128 MB, unless you're using Svengine, which increases that limit. It's hardcoded, though easily changed if you were to have the source code for it.

Not all allocations use this heap, so some allocations are limited by the size of the heap assigned by the OS, which is usually ~3.5 GB if you have at least 4GB of RAM and if it uses virtual memory, which it always should. You'll have to subtract the size of the heap allocated using -heapsize from that number, since it counts as an allocation from the OS heap.

There is no unified allocator so you can't make everything use the same heap, so some waste will always occur somewhere. The problems with it can only be solved by using engine access to redesign the allocator. Valve probably won't bother with that.

@2muchvideogames:

I've seen that happen when the player's current ammo count isn't being networked and the client relies on it to check if it can reload. If the client thinks it can't reload, it won't simulate the animation. Weapon prediction has to be enabled for this to work, though if i'm not mistaken the server can update the client if simulation is disabled.

I just committed a few additions that cover an interface i found in the engine. The engine will ask the server for an interface that takes over the studiomodel bone setup code. Apparently it's needed so clients that have non-standard blending will have proper hitbox and bone positions on the server.
Valve never provided any sample code to use there (as far as i could tell), and my attempt to use the client code for it failed. I've left the interface disabled, but implemented so it should be easy for anyone to go in and activate it as needed. If anybody knows how to implement it, that would be greatly appreciated.
Posted 1 year ago2016-09-01 23:29:22 UTC Post #331512
Yeah I know about the -heapsize command, though (quoted by Valve Wiki):
-heapsize <kilobytes> - Specifies the amount of heap(or free store - cache, an area of memory used for dynamic memory allocation) the engine will use. Minimum value is 14336(14 MB). Maximum value is 131072(128 MB). By default this is set to 40960 (40 MB) and automatically adjusted to suit your system.
Now, I have 6 GB of system RAM on a 64 bit OS (Win 7), and I always use -heapsize 512000 which is already over the maximum value. Does this means that a Goldsource game cannot use 3 GB of RAM (-heapsize 3072000)? I always felt that 128 MB is a bit low.
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-09-01 23:44:18 UTC Post #331513
Ya - keep in mind the code was written when Pentium II were the none plus ultra. Nobody had gigabtyes of RAM back then.
Posted 1 year ago2016-09-02 02:05:15 UTC Post #331514
I know that, 23-down. But Goldsource titles did have updates in the course of time, so you never know.
Alberto309 Alberto309GTX 660 Ti OC
Posted 1 year ago2016-09-02 08:26:21 UTC Post #331516
If Valve were to reply to my emails/Github issues i could ask them to do something about it. If they open sourced the engine anyone could take care of it. Quake uses the same memory allocator so there are plenty of examples on how to do that already.
Posted 1 year ago2016-09-02 18:30:06 UTC Post #331523
I fixed the compilation issues for release builds, but another problem has shown up for Linux builds: the client segfaults once the engine calls the client's Initialize function. Strangely the line number is the opening bracket, which doesn't make sense. It might be an issue with the calling convention, i'm not sure.
Posted 1 year ago2016-09-03 08:04:53 UTC Post #331531
A thought just occurred, inspired by that other thread going at the moment. How feasible would altering the direction of gravity be? I mean, like, you jump in this trigger and then you're running around on the walls/ceiling.
Jessie JessieLadytype
Posted 1 year ago2016-09-03 08:21:52 UTC Post #331532
You might be able to get away with that if all of the player's movement is handled in pm_shared. If the engine handles any part of it, it won't work. I'm not 100% sure about that at the moment.
Posted 1 year ago2016-09-03 20:31:19 UTC Post #331538
I found and fixed the cause of the Linux segfaults. An update made to the CHudSayText class replaced a #define with a static const integral.

A std::max call took this integral, but since static const integrals initialized in their declaration do not have an address on Linux, it was taking garbage. That caused the weird segfault behavior.

You can check the commit to see how it was fixed: https://github.com/SamVanheer/HLEnhanced/commit/eb42b15d0eb5df16a9e3fc5083762cca7e7e6cb6

I asked for help on Reddit in case anybody has more information about it:
https://www.reddit.com/r/cpp_questions/comments/510sdc/strange_segfault_under_gcc_using_stdmax_and

Despite the odd behavior of this bug, the hardest part was finding the commit that caused the problem. Linux compilation takes a lot longer than Windows compilation due to the use of a virtual machine.
Posted 1 year ago2016-09-03 21:39:30 UTC Post #331543
Glad to see you're making constant progress. With this speed of yours this project of yours will be done within the next couple months.. Wow! :)
Posted 1 year ago2016-09-03 22:04:11 UTC Post #331544
Is this anything special?

[quote]void CBigMomma::NodeStart( int iszNextNode )
{
pev->netname = iszNextNode;
CBaseEntity *pTarget = NULL;
if ( HasNetName() )
{
	if( CBaseEntity* pTarget = UTIL_FindEntityByTargetname( nullptr, GetNetName() ) )
		pTarget = pTarget; // <<<<<<<<<<<<<<<<<<<<
}[/quote]
Posted 1 year ago2016-09-03 22:15:35 UTC Post #331545
@23-down:

That remains to be seen. I have some ideas that could improve a few important things, but they'll take a long time to develop.

@fuzun:

Nice catch, i've fixed that.
Posted 1 year ago2016-09-03 23:25:17 UTC Post #331548
@solokiller

There are many more things reported by PVS Studio. I have enough time to fix the reports if you don't want to install it.
User posted image
Posted 1 year ago2016-09-04 11:03:13 UTC Post #331553
I installed it and am looking through the warnings now. It's too bad that it's only a trial, but it still provided useful information on potential issues and confusing code.

EDIT: i've fixed some of the warnings, but since the trial is used up i can't see where the remaining issues are. If you have a complete version you can fix issues if you want. I'm currently using Visual Studio's code analysis tool to find some other issues.

I've also corrected the Shock Rifle's idle animations. Previously, the idle animation was stuck on the first frame due to using the wrong time base, and only played IDLE1, which only played at all if you held down secondary fire.

Now it uses IDLE3 most of the time, and plays IDLE1 25% of the time.

It seems that Opposing Force was converted to the client predicted weapons system fairly late in development, which explains these mistakes. Several weapons had problems like this.
Posted 1 year ago2016-09-04 12:18:14 UTC Post #331556
I want to add prediction to laserspot and I reserved client vuser3 for this purpose (I know it is occupied for opfor but just for testing. I did not define USE_OPFOR).

In CClientPrediction I added:
((CRpg*)m_pPlayer->m_pActiveItem)->laserPos = from->client.vuser3;
and
to->client.vuser3 = ((CRpg *)m_pPlayer->m_pActiveItem)->laserPos;

In Client.cpp I added:
cd->vuser3 = ((CRpg *)pl->m_pActiveItem)->laserPos;

And

Vector laserpos; //->CRpg.h, public

laserPos = tr.vecEndPos; // CRpg.cpp, Updatespot()
m_pSpot->SetAbsOrigin(laserPos);

But nothing happened. These are executed but no prediction. Maybe I should remove #ifndef CLIENT_DLL at CRpg while updating spot somehow. Or maybe I need to modify ev_hldm?

I tried to do this but it crashed:

((CRpg*)m_pPlayer->m_pActiveItem)->m_pSpot->SetAbsOrigin(from->client.vuser3);

Is it becuase of client_dll definitions?
Posted 1 year ago2016-09-04 12:22:00 UTC Post #331557
The client doesn't have a CLaserSpot entity so you're accessing a null pointer. What you're trying to do is not quite that simple, you'll need to exclude the server side spot from being sent to the owning client and locally create a high priority temporary entity to render the spot for that client.

I was already planning to deal with this issue, but some changes are needed in the server's AddToFullPack function to properly exclude entities without making a mess. If you can wait a bit longer, i'll have this dealt with soonish, hopefully this week.
Posted 1 year ago2016-09-04 12:54:03 UTC Post #331558
Yes we have already talked about that but I still can not understand how client-server structure works for the engine. I could not find any documentation about this.

For example, why it crashes if I remove defines from laserspot related stuff?

Does not seperating codes with defines makes the codebase a mess?

HL project is server and client project is for clients right?

And can you please take a look at this snippet, it is from ev_hldm, egonfire:

[quote]void EV_EgonFire( event_args_t *args )
{
const int idx = args->entindex;
Vector origin = args->origin;
const int iFireState = args->iparam1;
const int iFireMode = args->iparam2;
const int iStartup = args->bparam1;
if ( iStartup )
{
	if ( iFireMode == FIRE_WIDE )
		gEngfuncs.pEventAPI->EV_PlaySound( idx, origin, CHAN_WEAPON, EGON_SOUND_STARTUP, 0.98, ATTN_NORM, 0, 125 );
	else
		gEngfuncs.pEventAPI->EV_PlaySound( idx, origin, CHAN_WEAPON, EGON_SOUND_STARTUP, 0.9, ATTN_NORM, 0, 100 );
}
else
{
	if ( iFireMode == FIRE_WIDE )
		gEngfuncs.pEventAPI->EV_PlaySound( idx, origin, CHAN_STATIC, EGON_SOUND_RUN, 0.98, ATTN_NORM, 0, 125 );
	else
		gEngfuncs.pEventAPI->EV_PlaySound( idx, origin, CHAN_STATIC, EGON_SOUND_RUN, 0.9, ATTN_NORM, 0, 100 );
}
//Only play the weapon anims if I shot it.
if ( EV_IsLocal( idx ) )
	gEngfuncs.pEventAPI->EV_WeaponAnimation ( g_fireAnims1[ gEngfuncs.pfnRandomLong( 0, 3 ) ], 1 );
if ( iStartup == 1 && EV_IsLocal( idx ) && !pBeam && !pBeam2 && cl_lw->value ) //Adrian: Added the cl_lw check for those lital people that hate weapon prediction.
{
	pmtrace_t tr;
	cl_entity_t *pl = gEngfuncs.GetEntityByIndex( idx );

	if ( pl )
	{
		Vector angles = gHUD.m_vecAngles;
		Vector forward, right, up;

		AngleVectors( angles, forward, right, up );
		Vector vecSrc;
		EV_GetGunPosition( args, vecSrc, pl->origin );
		Vector vecEnd;
		VectorMA( vecSrc, 2048, forward, vecEnd );
		gEngfuncs.pEventAPI->EV_SetUpPlayerPrediction( false, true );	

		// Store off the old count
		gEngfuncs.pEventAPI->EV_PushPMStates();

		// Now add in all of the players.
		gEngfuncs.pEventAPI->EV_SetSolidPlayers ( idx - 1 );
		gEngfuncs.pEventAPI->EV_SetTraceHull( 2 );
		gEngfuncs.pEventAPI->EV_PlayerTrace( vecSrc, vecEnd, PM_STUDIO_BOX, -1, &tr );
		gEngfuncs.pEventAPI->EV_PopPMStates();
		int iBeamModelIndex = gEngfuncs.pEventAPI->EV_FindModelIndex( EGON_BEAM_SPRITE );
		float r = 50.0f;
		float g = 50.0f;
		float b = 125.0f;
		if ( IEngineStudio.IsHardware() )
		{
			r /= 100.0f;
			g /= 100.0f;
		}


		pBeam = gEngfuncs.pEfxAPI->R_BeamEntPoint ( idx | 0x1000, tr.endpos, iBeamModelIndex, 99999, 3.5, 0.2, 0.7, 55, 0, 0, r, g, b );
		if ( pBeam )
			 pBeam->flags |= ( FBEAM_SINENOISE );
		pBeam2 = gEngfuncs.pEfxAPI->R_BeamEntPoint ( idx | 0x1000, tr.endpos, iBeamModelIndex, 99999, 5.0, 0.08, 0.7, 25, 0, 0, r, g, b );
	}
}
}
[/quote]

If I make cl_lw 0 beam becomes like laserspot, which is laggy. After you make cl_lw 1 it becomes like you are playing on lan as expected.

But here what I do not understand is ev_hldm.cpp is not included in HL. How does server know if clients create a beam? Maybe because of pEfxApi?

I looked into pEfxApi and saw that there is a thing named CL_TempEntAllocHigh. You mean this?

And I recommend this tool for testing prediction.
Clumsy: https://jagt.github.io/clumsy
It is very small but useful and will help you if you want to generate fake lag, tamper, etc.
It uses a digitally signed driver called WinDivert (Open source), and it is also worth looking if you interested.
Posted 1 year ago2016-09-04 13:13:33 UTC Post #331559
There is no client side version of CLaserSpot, so you're just accessing a null pointer all the time. The spot entity is networked, but the client doesn't have a CLaserSpot copy that will be synchronized with it. There is a cl_entity_t instance for it, but it's not supposed to be modified for things like prediction.

The server does not care if clients create beams. Those are purely visual effects. The server itself is responsible for handling the damage dealt by beams, and can perform lag compensation in PvP situations so that the client doesn't have to lead its targets.
It does this by resetting the positions of other clients to what they were when the client fired their weapon, allowing it to perform tracelines in the past. This only works up to a certain amount of time, so if you lag a lot it won't help you that much.

Events are triggered for both the client that is firing the weapon as well as other clients, but only the local client runs first person viewmodel effects. If code fails to check that, you end up with every client seeing effects when any other client triggers them, which has happened in some mods.

cl_lw is the weapon prediction cvar, so turning it off causes it to use the server side beams instead. It does this by setting the FL_SKIPLOCALHOST flag and setting the owner of the beam to the client. That's how the laser spot should be handled as well.

I'll take care of this issue now, then you'll be able to see what i mean.
Posted 1 year ago2016-09-04 13:43:46 UTC Post #331560
If you will do anything about laserspots consider adding these:

*Make a spot think function just like in source 2013 and add a scale handler (You may also need to check CRpg and other laser attached weapons). Default 16x16 spot sprite in hl1 becomes very large if you point laser to your feet and duck. I tested scaling with same as this and it got better.
Also for example if some mod use 128x128 sprite for laserspot, showing it without scaler leads to pretty bad visual effect.

[quote]
void CLaserDot::LaserThink( void ) //Source sdk 2013, hlenhanced contains these except Remapval (I could not find in hlenhanced, maybe it exists). Google it and you will find the magic function.
{
SetNextThink( gpGlobals->curtime + 0.05f, g_pLaserDotThink );
if ( GetOwnerEntity() == NULL )
	return;
Vector	viewDir = GetAbsOrigin() - GetOwnerEntity()->GetAbsOrigin();
float	dist = VectorNormalize( viewDir );
float	scale = RemapVal( dist, 32, 1024, 0.01f, 0.5f );
float	scaleOffs = random->RandomFloat( -scale * 0.25f, scale * 0.25f );
scale = clamp( scale + scaleOffs, 0.1f, 32.0f );
SetScale( scale );
}
[/quote]

*I also noticed that in hl2, spot is distorted where ever you put the spot. I think it is because there is a DIRTYMATERIAL mark in some of sdk files.

I think this is a good effect so adding something like this would be cool. But unfortunately we dont have material system so I tried to make a similar effect in a bad way but test it, it makes better :)
//In think function:

float random = UTIL_RandomFloat(0.0f, 30.0f);
pev->renderamt = (255.0f - random);
In fact, there is a better way to do this but I came up to engine restrictions. It is that if you set renderfx to kRenderFxDistort instead of kRenderFxNoDissipation, it makes a similar effect but kRenderFxDistort is same as kRenderFxHologram in terms of fading. Spot becomes invisible if you spot long distances (50-100 units).

Also, in xash3d kRenderFxDistort and kRenderFxHologram are same thing. Maybe in goldsrc they are identical as well.
Posted 1 year ago2016-09-04 13:50:56 UTC Post #331562
And I must ask. Why there is "public Fire_Glock()" in every sc file? It looks like a quake c thing which is not used in retail hl.

What is this about?
Posted 1 year ago2016-09-04 14:01:10 UTC Post #331563
Source can do things that GoldSource cannot do. One of those things being scaling sprites differently for each player, which you're asking for.

The .sc files are unused, only their names matter. The contents are examples for how you could write a script, but Valve never got around to writing a scripting language.
Posted 1 year ago2016-09-04 15:52:07 UTC Post #331566
I've made the Rpg laser spot predicted if cl_lw is enabled. The current code is a bit ugly since i had to drop it in there, but i'll be reworking it to make using client side entities easier to use.

I had to add some missing client side prediction features to make this work, specifically detecting when the client has picked up weapons that trigger weapon switches. This is extremely ugly and shouldn't be handled in such a hacky way, but until all weapons signal the client that they've been switched in a manner that the prediction code can handle well, this will have to do.

You can try out this new feature if you want, since i've committed new dlls.
To try this locally, set the fakelag cvar to 50 or more to simulate a ping of roughly fakelag * 2. Compare with the Desert Eagle laser spot and the Rpg laser spot when cl_lw is disabled.

Note that disabling cl_lw when you have the Rpg out and the spot active will cause it to duplicate the spot. Don't be surprised if the local version starts living a life of its own.

I'm going to write a proper client side entity management system to hide all of this ugly stuff, so it shouldn't be around for long. Meanwhile, feel free to try it out, try to break it if you can.
Posted 1 year ago2016-09-04 16:47:52 UTC Post #331567
I have tested it and it works good except a few caveats.

*fakelag cvar did not provide me a reliable fake lag (game crashed or hunged) so I used clumsy to make latency higher.
*Even with 400 ping, spot followed exactly where I pointed the gun as expected.
**Sometimes, I could not turn off the laserspot while using rpg. (Right click did not work)
*I know this is what it should be but rpg missiles goes to server's spot not predicted one. Can't something be done about this? What about egon shoots when cl_lw = 1?

Good work!
Posted 1 year ago2016-09-04 20:45:32 UTC Post #331569
Right click not toggling it was an issue i fixed, but it forgot to push the latest dlls out. Should be fine now.

There is no way to make it target rockets where you're looking on the client side. That data simply isn't available.
You must be logged in to post a response.