Re: [hlcoders] Goldsrc pev->solid

[James Marchant]

Hi.
I'm not 100% sure what you're asking, but I think you mean making it so players 
don't collide with each other? I've come across this problem myself, and never 
really resolved it in a satisfactory way. 
The most recent method was setting pev->groupinfo to 1 in prethink on players, 
and using UTIL_SetGroupTrace( pev->groupinfo, GROUP_OP_NAND ); straight after. 
Then in postthink, use UTIL_SetGroupTrace( pev->groupinfo, GROUP_OP_AND );
I can't remember off the top of my head why this works as it's been a long 
time, I just know that it probably should work. I'll leave it up to you to do 
the research on grouptrace, as I cannot for the life of me remember anything 
about it. Therefore, I cannot guarantee what side effects or issues this may 
cause.

One other thing you can do that I remember better, is perform a 
UTIL_EntitiesInBox check (with a FL_CLIENT filter) to find all clients 
colliding in the player's bounding box. Do this every frame. This should fire 
when players touch (but there is a small latency where they touch each other 
for a short while before it fires) and at that point you can set the player to 
be non-solid with pev->solid = SOLID_NOT. Don't forget to check that the player 
is not colliding with himself. UTIL_EntitiesInBox is better as it only search 
within the player's collision, whereas UTIL_FindEntityInSphere will be really 
rough and inaccurate. Don't forget to set the player back to solid if he is not 
colliding with another player. However, this method is less than ideal as a 
non-solid player cannot be attacked by monsters, and they cannot trigger 
triggers. I believe there are also some issues with prediction if a player is 
not as SOLID_SLIDEBOX too? Expect problems.
There is also "ShouldCollide" but as far as I know, that does not apply to 
players.
Hope this helps.
James

Date: Fri, 5 Jun 2015 22:41:06 +0200
From: rimischo...@googlemail.com
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Goldsrc pev->solid

Hi guys, i have a question related pev->solid


so with pev->solid i can change the collision of the entity but i want to 
change it for the player on by collision basis.

Like if you hit another player change the collision to something else that you 
can pass thru.

if i do it into the spawn it stays forever.

But i dont have a clue on how to check the collision to the other player.

 Am i using the UTIL_FindEntityInSphere function to check for radius and if 
something is in range entity->solid? Or is there another easier way to do it?

Greetings 


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Half-Life 1 crashing on resolution change

[James Marchant]

Hello. Half-Life 1 seems to be crashing on resolution change. Can just change 
any video option from the main menu that requires a restart to reproduce this. 
You don't need to be ingame for this to occur. 
You can find a crash dump here: 
https://dl.dropboxusercontent.com/u/3246514/crash_hl.exe_20141011220719_1.dmp
Just raising awareness in case any of the Valve folks are reading this. 
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Sound issues

[James Marchant]

Yes, you shouldn't really be trying to play client sounds on the server. 

Date: Tue, 19 Aug 2014 15:55:04 +0900
From: omegal...@gmail.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Sound issues

That's not really a good way to do an announcer.
What you should do, is make a function on the client to play the announcements, 
via a byte or something (index in an enum)

and dispatch the message (ie: register a msgfunc) to players, and let them play 
the sound locally on the client.

You then also have the bonus ability to let clients override announcer sounds, 
like making announcer replacements, as they don't need to be precached to be 
played, plus, then you're not filling up the server with sound events.





On Mon, Aug 18, 2014 at 11:07 PM, Jan Hartung  wrote:

Hi list, 
Some weird things are going on with the sound in our SDK 2013 MP based mod. 
First, there is a map with a looped sound in it, the entity is placed in the 
center of the map and can be heard everywhere (it’s a small map and the volume 
is high enough). Now, it sometimes happens that when I kill a bot, this sound’s 
origin jumps to the place where I currently am. It may jump to its original 
position when the next round starts or stays there for a few rounds. At times, 
not related to any kill, the sound also duplicates, so you can hear it twice 
while the two “copies” are out of sync.
 The second thing is that we got an announcer in the game, so there are sounds 
which are played to every player. We loop through the players and use 
UTIL_EmitSoundSuit in order to do so. The announcer received an overhaul just 
recently, which also added multiple sounds for the same event, which are set up 
as rndwave in the sound script. Since then I notice, that whenever I stand 
close enough to another player, I can hear the announcer’s line, which is 
played to the other player. However, UTIL_EmitSoundSuit is supposed to play a 
sound audible to the player itself, judging by the function’s comment.
 Has anyone seen these issues?
 Jan 
___


To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders






-- 
-Tony



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] HUD/VGUI only in Render Targets?

[james . marchant]

Okay thanks. And to clarify, I meant render _some_ elements to a separate 
render target and the rest of the HUD to the main view. Still possible?

Thanks!


Sent from Samsung Mobile

 Original message 
From: Tony omega Sergi 
Date:06/08/2014  17:24  (GMT+01:00)
To: Discussion of Half-Life Programming 
Subject: Re: [hlcoders] HUD/VGUI only in Render Targets?

Yes, it's possible out of the box.



On Thu, Aug 7, 2014 at 12:10 AM, James Marchant 
wrote:

> Perhaps I missed something, but does anybody know if it's possible to
> render HUD or VGUI elements exclusively to a RTT and not to the main view?
> I'd rather not use shaders to do this, so was hoping this was something
> supported out of the box for Source 2013.
>
> Thanks!
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
>
>
>


--
-Tony
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] HUD/VGUI only in Render Targets?

[James Marchant]

Perhaps I missed something, but does anybody know if it's possible to render 
HUD or VGUI elements exclusively to a RTT and not to the main view? I'd rather 
not use shaders to do this, so was hoping this was something supported out of 
the box for Source 2013.
Thanks!   ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK 2007 mod - No crash dumps

[James Marchant]

Already done that. Unfortunately nothing useful comes up. Any other ideas?

Date: Sun, 16 Mar 2014 12:02:28 -0500
From: xnicho...@gmail.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source SDK 2007 mod - No crash dumps

search for recent .mdmp files in your steam directory


On Sun, Mar 16, 2014 at 10:42 AM, James Marchant  
wrote:




Yeah I knew about that folder, but they're still not generated for me. Perhaps 
there's some other step I'm missing?

Date: Sun, 16 Mar 2014 17:36:23 +0200
From: gunshi...@gmail.com

To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source SDK 2007 mod - No crash dumps

Oh, i see now, here they are. Thank you for quick response.



2014-03-16 17:32 GMT+02:00 Neico :


  

  
  
You might want to look into /dumps

this is where all the new source engine minidumps go.



it's gotten harder to find out which belongs to which game / mod
with that tough (regulary cleaning that folder should help tough)



- Neico





On 16.03.2014 15:45 GMT +1, Gunship
  Mark II wrote:



  Have the same problem, no dump files. I am using
latest Source2013 source code from GitHub.

  
  



2014-03-16 16:04 GMT+02:00 James
  Marchant :

  

  Ever since I got converted to the Steampipe
update way back where a lot of stuff moved around to the
"common" folder, I don't get any crash dumps when my mod
crashes. It's relatively clean code without many
additions. I'm compiling under debug and all that kind
of stuff. Does anyone have any ideas why I wouldn't be
getting crash dumps now? 



___

To unsubscribe, edit your list preferences, or view the list
archives, please visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders





  



  
  

  
  

  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders





  


___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  

___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK 2007 mod - No crash dumps

[James Marchant]

Yeah I knew about that folder, but they're still not generated for me. Perhaps 
there's some other step I'm missing?

Date: Sun, 16 Mar 2014 17:36:23 +0200
From: gunshi...@gmail.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source SDK 2007 mod - No crash dumps

Oh, i see now, here they are. Thank you for quick response.


2014-03-16 17:32 GMT+02:00 Neico :


  

  
  
You might want to look into /dumps

this is where all the new source engine minidumps go.



it's gotten harder to find out which belongs to which game / mod
with that tough (regulary cleaning that folder should help tough)



- Neico





On 16.03.2014 15:45 GMT +1, Gunship
  Mark II wrote:



  Have the same problem, no dump files. I am using
latest Source2013 source code from GitHub.

  
  



2014-03-16 16:04 GMT+02:00 James
  Marchant :

  

  Ever since I got converted to the Steampipe
update way back where a lot of stuff moved around to the
"common" folder, I don't get any crash dumps when my mod
crashes. It's relatively clean code without many
additions. I'm compiling under debug and all that kind
of stuff. Does anyone have any ideas why I wouldn't be
getting crash dumps now? 



___

To unsubscribe, edit your list preferences, or view the list
archives, please visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders





  



  
  

  
  

  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders





  


___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Source SDK 2007 mod - No crash dumps

[James Marchant]

Ever since I got converted to the Steampipe update way back where a lot of 
stuff moved around to the "common" folder, I don't get any crash dumps when my 
mod crashes. It's relatively clean code without many additions. I'm compiling 
under debug and all that kind of stuff. Does anyone have any ideas why I 
wouldn't be getting crash dumps now? ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Collision checking for vphysics objects

[James Marchant]

Fixed it myself. Make sure you set the collision group on the entity before you 
call CreateVPhysics.

From: james.march...@live.com
To: hlcoders@list.valvesoftware.com
Date: Tue, 4 Mar 2014 22:38:30 +
Subject: [hlcoders] Collision checking for vphysics objects




Hello!
I have an animated door in my mod that uses physics with bone followers, but I 
wanted some entities to be able to pass through this, and it be solid to the 
rest of them. I give the door and the entities that will pass through the door 
their own collisiongroups, but it seems CHalfLife2::ShouldCollide does not 
check the collisions of vphysics objects? I confirmed this theory by setting 
another non-vphysics object to have the door collision group and hooked up a 
debug message like so:
if (collisionGroup0 == HL2COLLISION_GROUP_DOORS || collisionGroup1 == 
HL2COLLISION_GROUP_DOORS) Msg( "Checking collision for doors!\n");
I got the debug message in the console only when touching the non-vphysics 
object. Where is collision checking done for vphysics objects, therefore?
Thanks,James  

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Collision checking for vphysics objects

[James Marchant]

Hello!
I have an animated door in my mod that uses physics with bone followers, but I 
wanted some entities to be able to pass through this, and it be solid to the 
rest of them. I give the door and the entities that will pass through the door 
their own collisiongroups, but it seems CHalfLife2::ShouldCollide does not 
check the collisions of vphysics objects? I confirmed this theory by setting 
another non-vphysics object to have the door collision group and hooked up a 
debug message like so:
if (collisionGroup0 == HL2COLLISION_GROUP_DOORS || collisionGroup1 == 
HL2COLLISION_GROUP_DOORS) Msg( "Checking collision for doors!\n");
I got the debug message in the console only when touching the non-vphysics 
object. Where is collision checking done for vphysics objects, therefore?
Thanks,James  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Access Violation in SDK 2013

[James J. Kelly Jr.]

I tediously merged the files manually, rather than using a tool to do it 
automatically, and was careful not to alter the SDK 2013 codebase except to add 
what was added in to the SDK 2007 version of the mod.

I only used WinMerge as a guide to show me what had changed between vanilla SDK 
2007 and the mod.

 

From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jacob "J*Rod" 
Salas
Sent: Sunday, February 09, 2014 2:37 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Access Violation in SDK 2013

 

What's possible is that you when you merged the branches, there were some files 
improperly overwritten. Especially if vital public interfaces were left in a 
different branch.

Do you see if some of them were left in 2007 when you followed the procedure 
you found?

--
Jacob "J*Rod" Salas
jsmedia.tk | @czfjrod
Sent from my Samsung Galaxy S4 on Verizon

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Access Violation in SDK 2013

[James J. Kelly Jr.]

Right after I connect, here are the particular lines I see just before the 
crash:

gamerules.h (185) : Assertion Failed: !IsMultiplayer()

James connected

 

From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 
tobias.kammersga...@gmail.com
Sent: Sunday, February 09, 2014 2:26 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Access Violation in SDK 2013

 

When does the crash happen? When you connect or can you even get that far?

 

 - ScarT

 

From: James J. Kelly Jr. <mailto:james...@gmail.com> 
Sent: ‎Sunday‎, ‎February‎ ‎9‎, ‎2014 ‎8‎:‎19‎ ‎PM
To: hlcoders@list.valvesoftware.com

 

Hey guys,

 

I’m experimenting with porting a Source SDK 2007 mod to Source SDK 2013; I 
found several other mod authors who said they were able to create a diff from 
the vanilla SDK 2007 and merge their changes into Source SDK 2013 without much 
problem.

 

I tried this myself and so far the server build seems to work (or at least it 
loads in SRCDS and starts the game without crashing) but I can’t get the client 
to work because I keep getting an unhandled access violation exception at 
AssertValidWritePtr and unfortunately the call stack is filled with code from 
mostly engine.dll which I obviously don’t have any symbols for so it really 
doesn’t tell me much about what might causing it.

 

As a diagnostic measure I tried running a dedicated server and connecting to it 
from the client and found the crash happened in the client but not the server 
which helps narrow it down to just the client.

 

Have you guys encountered this type of problem before and how did you solve it 
or do you at least have any ideas?

 

The particular error I’m getting is this:

 

First-chance exception at 0x10EEC050 (engine.dll) in hl2.exe: 0xC005: 
Access violation reading location 0xFFEEFFF6.

Unhandled exception at 0x10EEC050 (engine.dll) in hl2.exe: 0xC005: Access 
violation reading location 0xFFEEFFF6.

 

Call stack copied from Visual Studio is below if you want to see it:

 

engine.dll!10eec050()Unknown

   [Frames below may be incorrect and/or missing, no symbols loaded 
for engine.dll]  

   engine.dll!10e10d38()Unknown

   vstdlib.dll!0fbd3a47() Unknown

   vstdlib.dll!0fbd3a47() Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()Unknown

   KernelBase.dll!77220457()   Unknown

   KernelBase.dll!77220b0a()   Unknown

   GameUI.dll!2af31c36()  Unknown

   GameUI.dll!2af3d674()  Unknown

   GameUI.dll!2af8f12f()   Unknown

   GameUI.dll!2af8f57a()   Unknown

   engine.dll!10ff5c62()  Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()Unknown

   KernelBase.dll!77220457()   Unknown

   KernelBase.dll!77220b0a()   Unknown

   KernelBase.dll!77220b0a()   Unknown

   GameUI.dll!2af31c36()  Unknown

   GameUI.dll!2af3d674()  Unknown

   GameUI.dll!2af8f12f()   Unknown

   GameUI.dll!2af8f57a()   Unknown

   ntdll.dll!776615de() Unknown

   ntdll.dll!7769b83d() Unknown

   KernelBase.dll!771fc41f() Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0fe0() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0ce3() Unknown

   GameUI.dll!2af31c36()  Unknown

   GameUI.dll!2af3d674()  Unknown

   GameUI.dll!2af8f12f()   Unknown

   GameUI.dll!2af8f57a()   Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()Unknown

   KernelBase.dll!77220457()   Unknown

   KernelBase.dll!77220b0a()   Unknown

   GameUI.dll!2af31c36()  Unknown

   GameUI.dll!2af31c36()  Unknown

   GameUI.dll!2af3d674()  Unknown

   GameUI.dll!2af8f12f()   Unknown

   GameUI.dll!2af8f57a()   Unknown

   GameUI.dll!2af8f12f()   Unknown

   GameUI.dll!2af8f57a()   Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!7722582f()Unknown

   KernelBase.dll!772259c7()U

[hlcoders] Access Violation in SDK 2013

[James J. Kelly Jr.]

.dll!2af8f57a()   Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0fe0() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   tier0.dll!5c1fa845()  Unknown

   tier0.dll!5c1f3722()  Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0fe0() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbd3a47() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0fe0() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   tier0.dll!5c20cadc()  Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbe0fe0() Unknown

   vstdlib.dll!0fbe0e56() Unknown

   vstdlib.dll!0fbdc93a() Unknown

   KernelBase.dll!7722582f()Unknown

   ntdll.dll!7765ff66()   Unknown

   KernelBase.dll!77200d93()   Unknown

   vstdlib.dll!0fbd4d37() Unknown

   vstdlib.dll!0fbd76f5()  Unknown

   vstdlib.dll!0fbd4632() Unknown

   vstdlib.dll!0fbd4508() Unknown

   engine.dll!10ead104()Unknown

   engine.dll!10ead4c8()Unknown

   vstdlib.dll!0fbd3a47() Unknown

   ntdll.dll!776615de() Unknown

   ntdll.dll!7769b83d() Unknown

   KernelBase.dll!771fc41f() Unknown

   ntdll.dll!7765faca()  Unknown

   engine.dll!11076e83()Unknown

   engine.dll!1107700d()Unknown

   engine.dll!1107589f() Unknown

   engine.dll!110760ad()Unknown

   KernelBase.dll!771fc41f() Unknown

   KernelBase.dll!771fc41f() Unknown

   KernelBase.dll!772034e3()   Unknown

   vgui2.dll!0088b59d()   Unknown

   KernelBase.dll!7720c6e5()   Unknown

   tier0.dll!5c1f602f()   Unknown

   tier0.dll!5c1f6700()  Unknown

   KernelBase.dll!771fce62()Unknown

   FileSystem_Stdio.dll!0093f29d()Unknown

   FileSystem_Stdio.dll!00933a78()   Unknown

   FileSystem_Stdio.dll!00933b10()   Unknown

   FileSystem_Stdio.dll!00928e32()   Unknown

   FileSystem_Stdio.dll!00929764()   Unknown

   FileSystem_Stdio.dll!0093c03c()Unknown

   FileSystem_Stdio.dll!00939a23()   Unknown

   FileSystem_Stdio.dll!0092ae14()   Unknown

   FileSystem_Stdio.dll!0092ba6c()   Unknown

   vgui2.dll!0088b59d()   Unknown

   ntdll.dll!776615de() Unknown

   ntdll.dll!7769b83d() Unknown

   engine.dll!11076e83()Unknown

   engine.dll!1107700d()Unknown

   engine.dll!10ff2baa() Unknown

   engine.dll!10ff331b() Unknown

   002a92d0()  Unknown

> client.dll!AssertValidWritePtr(const void * ptr, int count)
Line 587 C++

 

 

I'm using Visual Studio 2012 with the 2010 toolchain.

 

Thank you for reading my post and considering it.

James

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Bone controllers in Source

[James Marchant]

Are they supported anymore? When I compile my model using a bone controller, 
using the bone controller slider in Source HLMV makes the model rotate but only 
by about 1 degree, no matter which values I use. Here's the controller line 
from my qc:
$controller 0 "camera" ZR 0.00 90.00
I've also tried using radians instead of degrees. Any ideas?

  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK Launch Issues

[James Marchant]

Even after verifying the integrity of the local cache? I had the same problem 
and it fixed it (although it claimed that basically every single file in the 
Source SDK needed "reacquiring".

Date: Fri, 18 Oct 2013 15:41:24 -0400
From: twincan...@gmail.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source SDK Launch Issues

Source SDK launcher still doesn't work for me.


On Fri, Oct 18, 2013 at 2:03 PM, Jan Hartung  wrote:

Hi,
 Checked it. For our 2007 based version Hammer starts up normally from the SDK 
launcher and compiles come out as they should. Do you still see the issue with 
your mod?
 Jan
 Von: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] Im Auftrag von Vincent Miceli

Gesendet: Donnerstag, 17. Oktober 2013 02:29
An: hlcoders@list.valvesoftware.com
Betreff: [hlcoders] Source SDK Launch Issues
 Hi, I haven't seen this reported yet on the mailing list, so I decided to 
share this. I found as of 10/16/2013 that I cannot launch Hammer Editor for the 
Source SDK 2007 from the SDK app. Strangely, before that happened, I couldn't 
launch the SDK app at all, but after restarting my computer and Verifying the 
integrity of the Tool Cache for the Source SDK, I was able to launch the SDK. 
But, not Hammer. When I was just able to at least launch the SDK before, (but 
not Hammer), I found that if I open Hammer from the exe file instead of from 
the app, it launched Hammer, but said it couldn't find a specific file, and it 
gave me a few errors, one error included my 2d viewports in Hammer showing 
pink/black checkerboard textures on 3d models. I apologize for not having the 
error messages handy, after having been able to launch Hammer and load and 
compile my map, I closed the SDK and now Hammer won't open at all no matter 
what I do. Also, the compile that I made while in that erroneous state produced 
a map with very strange black brushwork with almost no lighting from the 
skybox. I'm assuming it's trying to find a file that links stuff together with 
my mod, and since it couldn't find it, it was giving me those related errors.
Thanks for reading I hope that little bit of information was of value to 
someone and if more info is required I can respond as informatively as I can.
 -- Vincent Miceliwww.firearms-source.com

___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] How to set collision based on hitboxes?

[James Marchant]

Hello all. I have a custom entity with CBaseAnimating as its baseclass, and am 
having a lot of trouble setting the object's collision based on its hitbox (it 
only has 1)
I know about $collisionjoints but that doesn't seem to work really unless it's 
a prop or NPC, which I don't want it to be. I'd like to set the collision box 
at any time I please, so setting it just in Spawn doesn't really work, as the 
object animates sometimes and needs its collision changed to fit the last frame 
of said animation. If anyone could help me with this, it'd be greatly 
appreciated!
Thanks,James  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Error: setuparrayprops_r array prop '(null)' is at index

[James Marchant]

Looks like it's broken again. 
"Failed to start game (unknown error)" or occasionally "missing executable" if 
it feels like it. Anyone else getting this? Worked literally 15 minutes ago.
Date: Wed, 9 Oct 2013 11:42:27 +0200
From: m...@tobiasbaumann.net
To: jan.hart...@gmx.de; hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Error: setuparrayprops_r array prop '(null)' is at index



 
  
 
 
 
  
   Ok I didn't change anything and as of today everything works normal again. I 
didn't opt-into the steampipe beta.
   
  

   
  
   I'm guessing Valve fixed something internally or my machine/anti-virus was 
screwing up yesterday.
   
  

   
  
   Cheers,
   
  
   Tobias
   
  

   
  
   
   
   
   
   
   Jan Hartung  hat am 8. Oktober 2013 um 21:24 geschrieben:
   

   
 

Yup, contenttype is still 2. But Steam already told me that it has to 
convert the resources to a new, more efficient format. And therefore, it got 
moved out of the username folder into the common folder here. Anyway, with 
everything updated and 2007 subscribed to the SteamPipe beta I can launch mods. 
  
 
 Jan 
 
  
 
  
  Von: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] Im Auftrag von Nicholas 
Hastings
Gesendet: Dienstag, 8. Oktober 2013 19:51
An: Discussion of Half-Life Programming
Betreff: Re: [hlcoders] Error: setuparrayprops_r array prop '(null)' is at 
index 
  
 
  
Source SDK Base 2006 will not convert to Steampipe yet.

It looks like it's mostly set up for it, but it still has contenttype set to 2, 
which you confirm by using "app_info_print 215" in Steam's console. Once they 
flip that to 3, it will convert.

They did however recently flip over many of the mods that are on Steam that 
already had steampipe betas. 
 
 -- 
Nicholas Hastings
AlliedMods.net 
 


 
 
  
   

   
   
   Jan Hartung 
   
   
   Tuesday, October 8, 2013 1:45 PM 
   
  
 
 
 Are you sure you opted into the SteamPipe beta for Source SDK Base 2007? 
If yes, please try starting both Source SDK Base 2006 and Source SDK Base 2007. 
Most likely 2006 will be converted to SteamPipe without signing up for any beta 
when you start it. Once both tools use SteamPipe your mod should start up 
again. At least it does for our mod. 
   
  
  Jan 
  
   
  
   
   Von: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] Im Auftrag von Richard O'Brien
Gesendet: Dienstag, 8. Oktober 2013 18:32
An: hlcoders@list.valvesoftware.com
Betreff: Re: [hlcoders] Error: setuparrayprops_r array prop '(null)' is at 
index 
   
  
   
  
  Having this same issue with our mod too. Opting into the Steam beta 
doesn't seem to fix it. Like yourself, this only started today. 
  
  
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders 
  
 
 
  
   

   
   
   Richard O'Brien 
   
   
   Tuesday, October 8, 2013 12:31 PM 
   
  
 
 
  
  Having this same issue with our mod too. Opting into the Steam beta 
doesn't seem to fix it. Like yourself, this only started today. 
  
  
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders 
  
 

   
  
   
 
  
 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  <>___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc)

[james . marchant]

Yes, it's not ideal of course. Off the top of my head I don't know how to 
obtain the server ip and port but shouldn't be too hard. As for the extra 
overhead, I don't think that's an issue for a goldsrc mod. Of course it would 
have to be maintained in a smart manner so it doesn't grow huge... could you 
detail the problem further please? Why do you need to reconnect clients? 


Sent from Samsung Mobile

 Original message 
From: Adam amckern McKern  
Date:  
To: "james.marchant" ,Discussion of Half-Life 
Programming  
Subject: Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc) 
 
How do you know the last IP - this would cause more overhead as your going to 
need to store the IP/Port in an array

 
Sincerely
Adam McKern
KAP Candidate for Mitchel (Castle Hill)

From: james. marchant 
To: hlcoders@list.valvesoftware.com 
Sent: Monday, 12 August 2013 6:38 PM
Subject: Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc)

Can you not use "connect serverip" in place of "retry"?


Sent from Samsung Mobile



 Original message 
From: Tom Schumann  
Date: 
To: Discussion of Half-Life Programming  
Subject: Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc) 


Would it work to send a different command that when called just calls 'retry' 
and whatever else you need to call?


On 10 August 2013 22:16, Saint Thoth (hotmail)  wrote:
For about a decade now, we've had issues when multiple players try to reconnect 
to our mod's servers at the same time... And the solution, for about a decade, 
was to delay their reconnection, simply by having the server send the client a 
disconnect, some waits, and a retry command. Worked just fine...
 
But now that Steam Pipe is here, the retry command is illegal to send to 
clients. I thought of exec'ing a special cfg file on  patched clients instead, 
but exec is also illegal command. (Which seems silly, given that the server can 
send any number of commands to make your game unplayable. Hell, with client.dll 
commands, we could delete your Windows system  folder, re-write your registry, 
or crash your system any number of ways, if we wanted to... But gods forbid we 
send a "retry" command.)
 
So I'm wondering how we could go about adding a command to do a disconnect 
followed by a delayed reconnect. Hopefully something as simple as having the 
client send commands to his own console - and hopefully not something so hacky 
as grabbing the process ID and sending keyboard commands to it.
 
Thanks in advance for any advice you can provide,
- Thothie

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders




___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc)

[james . marchant]

Can you not use "connect serverip" in place of "retry"?


Sent from Samsung Mobile

 Original message 
From: Tom Schumann  
Date:  
To: Discussion of Half-Life Programming  
Subject: Re: [hlcoders] Delayed reconnect on Steam Pipe (goldsrc) 
 
Would it work to send a different command that when called just calls 'retry' 
and whatever else you need to call?


On 10 August 2013 22:16, Saint Thoth (hotmail)  wrote:
For about a decade now, we've had issues when multiple players try to reconnect 
to our mod's servers at the same time... And the solution, for about a decade, 
was to delay their reconnection, simply by having the server send the client a 
disconnect, some waits, and a retry command. Worked just fine...
 
But now that Steam Pipe is here, the retry command is illegal to send to 
clients. I thought of exec'ing a special cfg file on patched clients instead, 
but exec is also illegal command. (Which seems silly, given that the server can 
send any number of commands to make your game unplayable. Hell, with client.dll 
commands, we could delete your Windows system folder, re-write your registry, 
or crash your system any number of ways, if we wanted to... But gods forbid we 
send a "retry" command.)
 
So I'm wondering how we could go about adding a command to do a disconnect 
followed by a delayed reconnect. Hopefully something as simple as having the 
client send commands to his own console - and hopefully not something so hacky 
as grabbing the process ID and sending keyboard commands to it.
 
Thanks in advance for any advice you can provide,
- Thothie

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Fullbright or similar in render target pass

[James Marchant]

Well, I moved my code around a little and got it vaguely working. Fullbright is 
rendered properly in the camcorder's screen (the small inset screen on the 
v_model in the picture) but I noticed that phonged materials and only materials 
with phong are rendered in the incorrect view. They will be drawn as black in 
the camera view and as fullbright in the player's view. I have a picture link 
here to illustrate the problem if it lets me add links: 
http://tinypic.com/r/33clwsj/5
Anyone know why this behaviour happens? For reference, I render the camera view 
in the same way as monitors are rendered in normal Source 
(CViewRender::RenderView, Orange Box, just after #ifdef USE_MONITORS)
Thanks!James


From: james.march...@live.com
To: amck...@yahoo.com; hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Fullbright or similar in render target pass
Date: Sun, 28 Jul 2013 18:37:47 +0100




Hey guys. That's vaguely what I was looking for. I did experiment with setting 
mat_fullbright to 1, but the problem is that having it on only during the 
render pass when it's drawing the camera's render target doesn't work. It 
either turns on for both view passes (so you see it on screen and on your 
camera v_ model's viewfinder) or isn't on at all.
Any other ideas? Thanks for the help so far :)

Date: Sat, 27 Jul 2013 18:19:02 -0700
From: amck...@yahoo.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Fullbright or similar in render target pass

Keep in mind that code was designed for single player. If this is coop or 
online, then please test it out :) 

 Sincerely Adam McKernKAP Candidate for Mitchel (Castle Hill)
From: Nick 
 To: Discussion of Half-Life Programming  
 Sent: Saturday, 27 July 2013 7:48 AM
 Subject: Re: [hlcoders] Fullbright or similar in render target pass
   
looks good!

all 
//nightfall - amckern - amck...@yahoo.com
//NightVision did was set 
cvar->FindVar("mat_fullbright")->SetValue(1);


on clientside



On Wed, Jul 24, 2013 at 6:00 PM, Daniel Glenn  wrote:

Hey James,
Have you taken a look at the Night Vision article on the VDC? It's 
implementation was made for Source 2006 if I'm not mistaken but it may be of 
some help since the effect itself is just a screen overlay and shaders (With 
full source in the article).


https://developer.valvesoftware.com/wiki/Vision_Nocturna




On Wed, Jul 24, 2013 at 5:41 PM, James Marchant  wrote:





Nobody got any ideas on this? Pretty stumped here...

From: james.march...@live.com
To: hlcoders@list.valvesoftware.com


Date: Sat, 20 Jul 2013 15:30:01 +0100
Subject: [hlcoders] Fullbright or similar in render target pass




Hello there. I'm looking at making a camcorder type effect on a v_model where 
I'm using render targets much like the func_monitors do in HL2 to project the 
screen onto the camera's LCD screen. However, because the camera needs a night 
vision effect on its screen, I was wondering how to render a light specifically 
and only during the camera's render target pass. Considering the level is 
pretty much pitch black, I was thinking of using a large dynamic light that's 
killed on the normal render pass after, but it produces very strange results. 
It can also bleed into the normal render pass so the level gets illuminated 
when not looking at the camera screen.


Hope I've explained myself well. Anyone got any ideas? Much appreciated!
James 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  

___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders






___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders



  
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Fullbright or similar in render target pass

[James Marchant]

Nobody got any ideas on this? Pretty stumped here...

From: james.march...@live.com
To: hlcoders@list.valvesoftware.com
Date: Sat, 20 Jul 2013 15:30:01 +0100
Subject: [hlcoders] Fullbright or similar in render target pass




Hello there. I'm looking at making a camcorder type effect on a v_model where 
I'm using render targets much like the func_monitors do in HL2 to project the 
screen onto the camera's LCD screen. However, because the camera needs a night 
vision effect on its screen, I was wondering how to render a light specifically 
and only during the camera's render target pass. Considering the level is 
pretty much pitch black, I was thinking of using a large dynamic light that's 
killed on the normal render pass after, but it produces very strange results. 
It can also bleed into the normal render pass so the level gets illuminated 
when not looking at the camera screen.
Hope I've explained myself well. Anyone got any ideas? Much appreciated!
James 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Fullbright or similar in render target pass

[James Marchant]

Hello there. I'm looking at making a camcorder type effect on a v_model where 
I'm using render targets much like the func_monitors do in HL2 to project the 
screen onto the camera's LCD screen. However, because the camera needs a night 
vision effect on its screen, I was wondering how to render a light specifically 
and only during the camera's render target pass. Considering the level is 
pretty much pitch black, I was thinking of using a large dynamic light that's 
killed on the normal render pass after, but it produces very strange results. 
It can also bleed into the normal render pass so the level gets illuminated 
when not looking at the camera screen.
Hope I've explained myself well. Anyone got any ideas? Much appreciated!
James ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] Blending view angles to entity attachment angles?

[James Marchant]

Hello. I'm doing some camera stuff in Source, where an entity will temporarily 
take control of the player's view for opening a door. We have a 
point_viewcontrol hooked up to a prop_dynamic which animates the camera from 
the prop's attachment point. This works perfectly fine.
However, I wish to blend the current player view angles to the entity 
attachment's angles before the animation starts so it smoothly transitions from 
player view to point_viewcontrol view. The blend happens, but it blends to the 
wrong angles (0, 180, 0)
My code is almost 100% identical to the blending code for the vehicle code 
which does perfectly blend the player view to the vehicle's attachment. It's 
placed in C_BasePlayer::CreateMove just above the vehicle blending code. My 
code:
if (m_hViewEntityTest)  {   if (m_bBlendView == false)  
{   m_bBlendView = true;
m_flViewAngleDeltaTime = gpGlobals->curtime + 0.75; }
C_BaseAnimating *pAttacher = 
m_hViewEntityTest->GetBaseAnimating();
if ( pAttacher ){   if ( 
m_flViewAngleDeltaTime > gpGlobals->curtime )  {
   // Blend the view angles.   int 
eyeAttachmentIndex = pAttacher->LookupAttachment( "vehicle_driver_eyes" );  
Vector vehicleEyeOrigin;
QAngle vehicleEyeAngles;
pAttacher->GetAttachmentLocal( eyeAttachmentIndex, vehicleEyeOrigin, 
vehicleEyeAngles );QAngle 
outAngles;   InterpolateAngles( pCmd->viewangles, 
vehicleEyeAngles, outAngles, 0.03 );   
pCmd->viewangles = outAngles;   engine->SetViewAngles( 
pCmd->viewangles);   }   }   }
Does anyone have any ideas why it is not blending to the prop's attachment 
angles?
Thanks!James

  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Working Around the Latest Goldsrc (Half-Life) Changes

[James Marchant]

If you're getting the VGUI camera lock after exiting a fullscreen VGUI panel, 
you can do various things such as type "centerview" in the console. I guess if 
your mod is VGUI heavy you'll have to record the user's view angles on the 
client and set them back after closing the VGUI as a hacky workaround. -nofbo 
as a launch option will fix a lot of the graphical errors that pop up, and 
gl_vsync 0 may fix performance issues.

From: st_th...@hotmail.com
To: hlcoders@list.valvesoftware.com
Date: Mon, 18 Feb 2013 14:26:35 -0800
Subject: [hlcoders] Working Around the Latest Goldsrc (Half-Life) Changes








Seems that Valve thought it might be fun to move 
the Half-Life installation folder from /half-life to 
common/half-life, thus breaking every self installer ever.
 
In addition, something about the new DLL's or 
folder priorities seems to break mouse functionality for most 
users.
 
Was wondering if any mod developers or coders out 
there may have found work arounds for this latest insanity yet?
 
- Thothie

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Compiling in VS 2012

[James Marchant]

Are you not able to check it out in Express 2012, which is free?

From: kra...@siosphere.com
Date: Mon, 26 Nov 2012 11:14:09 -0700
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Compiling in VS 2012

Has anyone been able to compile the SDK in Visual Studio 2012? I need to 
purchase Visual Studio Professional, and the newest (2012) is the cheapest at 
$500, but isn't worth it if I can't get the SDK to compile with it.


Thanks,


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] GoldSrc Client -> Server communication?

[James Marchant]

I would also very much like to know this, as all of Cry of Fear's development 
relied on client commands for client->server communication. However, as far as 
I can tell from briefly looking through projects like TFC, it seems to use the 
same method of faking client commands. I'm 80% sure it's not possible to use 
any method, but would love to be proved wrong.
From: r2d2r...@gmail.com
Date: Sat, 25 Aug 2012 19:38:06 +0200
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] GoldSrc Client -> Server communication?

Hello,
I'm resuming development in a long-abandoned singleplayer mod for HL1. Since we 
heavily rely in VGUI menus, the server must know when they are closed by the 
client so the appropiate flag is unset in CBasePlayer's savedata and we don't 
have weird bugs when loading a game that was saved while a menu was open. Until 
now I have been using Client_Commands for this, but is there a more elegant 
approach?


Cheers.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Bug with BloomScale

[James Pizzurro]

You are forgiven.
On Mar 29, 2012 2:05 PM, "Tony "omega" Sergi"  wrote:

> Minh discovered a *really silly* copy and paste mistake that I made in
> 2008:
>
> inside *viewpostprocess.cpp* --
> static float GetCurrentBloomScale( void )
> {
> *--snip--*
> //Tony; in multiplayer, get the local player etc.
> if ( (pLocalPlayer != NULL && pLocalPlayer->m_Local.m_
> TonemapParams.m_flAutoExposureMin > 0.0f) )
> {
> flCurrentBloomScale =
> pLocalPlayer->m_Local.m_TonemapParams.m_flAutoExposureMin;
> }
> *--snip--*
> }
>
> that should be using *m_TonemapParams.m_flBloomScale* not autoexposure ;(
>
> Sorry guys.
>
>
> --
> -Tony
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] GoldSrc - How does the map list work in "Create Server"?

[James Marchant]

Great, thanks!

From: r2d2r...@gmail.com
Date: Fri, 9 Dec 2011 20:51:43 +0100
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] GoldSrc - How does the map list work in "Create Server"?

https://developer.valvesoftware.com/wiki/The_liblist.gam_File_Structure#mpentity
 - WON 
onlyhttps://developer.valvesoftware.com/wiki/The_liblist.gam_File_Structure#mpfilter
 - Steam only



2011/12/9 James Marchant 







Hi. I'm wondering how you control which maps do/don't show in the map list in 
"Create Server" in GoldSrc. In my mod, all maps show, including singleplayer 
maps. In normal Half-Life, only the MP maps show. Any ideas?


  

___

To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders







___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

[hlcoders] GoldSrc - How does the map list work in "Create Server"?

[James Marchant]

Hi. I'm wondering how you control which maps do/don't show in the map list in 
"Create Server" in GoldSrc. In my mod, all maps show, including singleplayer 
maps. In normal Half-Life, only the MP maps show. Any ideas?
  ___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders

Re: [hlcoders] Where to find update news?

[James Pizzurro]

When pigs fly.

On Tue, Oct 18, 2011 at 7:31 PM, Stephen Swires wrote:

> Though I wonder if Valve are ever going to release a proper update for the
> SDK like Gabe promised. Expecting too much?
>
>
> On Wed, Oct 19, 2011 at 12:28 AM, Tobias Kammersgaard <
> tobias.kammersga...@gmail.com> wrote:
>
>> That's the only change. Oh, and they broke the tools, but that's not
>> really new.
>>
>> - ScarT
>>
>>
>> On 19 October 2011 01:11, Nathan Voge  wrote:
>>
>>>  Hey all, I keep seeing the Source SDK is updating. Great! but what? I
>>> know they did some stuff with TF2 but other than that I can't find what has
>>> changed. The "product update" 
>>> newson 
>>> Steam is very out of date. The last update on there is from Sep 14, 2006!
>>> And the Dev Wiki page for Source SDK Release 
>>> Noteswas 
>>> last updated 6/23/2010. Is there somewhere else I should be checking?
>>>
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>>
>
>
> --
> - Stephen Swires
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Community manager ?

[James Deeman]

FYI, i have had replies from Valve but also didn't get any response from
mdur...@valvesoftware.com, who was my first point of call due to my
understanding he was mod community manager. Anyone have a clue if he is
still in the role?

James Deeman.

On 5 October 2011 09:40, Saul Rennison  wrote:

> You're emailing the wrong people. Check the list of Valve employee's on
> their site and email the programmer's at a suitable time in Seattle.
> *Several* engine programmers replied to one of my emails when the initial
> person I sent it to forwarded it to the appropriate people.
>
> On Wednesday, 5 October 2011, Jed  wrote:
> > 3 Months?
> >
> > Lucky you - I haven't got a single reply from anyone with a Valve
> > address in over 3 years!
> >
> >
> > On 5 October 2011 02:39, Psy_Commando  wrote:
> >> Hi I was wondering is mdur...@valvesoftware.com still the address of
> the mod
> >> community manager ? I have never received any responses from that
> address in
> >> more than 3 months. I have a few questions to ask him before settling
> for
> >> good on the Alien swarm sdk.
> >>
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >>
> >>
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
> --
>
>
> Kind regards,
> *Saul Rennison*
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
James Deeman
Nottingham, UK
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Font size cap?

[James Deeman]

Ah ofc, 128 would make sense. Thanks for that, and good call on the texture
thing, will make a note of that. Cheers,

James.

On 31 August 2011 22:57, Ben K.  wrote:

> I figured a 128x128 bitmap is all you're gonna get. I've run into this
> limit myself. Considered using a texture, maybe with $distancealpha (
> http://developer.**valvesoftware.com/wiki/$**distancealpha<http://developer.valvesoftware.com/wiki/$distancealpha>)
>  yet?
>
> Cheers,
>
> Ben
>
>
> James Deeman wrote:
>
>> Is there a cap to how large your font can go? I am finding that after a
>> certain point the size of the glyphs just don't change, around 120 'tall'
>> value in the Scheme file. Is this right? Anyone know what the actual figure
>> is?
>>
>> Any replies appreciated.
>>
>> --
>> James Deeman
>> Nottingham, UK
>>
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>
>


-- 
James Deeman
Nottingham, UK
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Font size cap?

[James Deeman]

Is there a cap to how large your font can go? I am finding that after a
certain point the size of the glyphs just don't change, around 120 'tall'
value in the Scheme file. Is this right? Anyone know what the actual figure
is?

Any replies appreciated.

-- 
James Deeman
Nottingham, UK
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] hlcoders Digest, Vol 5, Issue 27

[James Pizzurro]

It was sent from his iPhone.
On Aug 19, 2011 6:47 PM, "Aaron Johnson"  wrote:
> What is this the h4x0r from vegas. Or another cs_siege. I'd APC suicide
myself to n0thing. I still goat more fury for zit pharms.
>
> i miss talent. rip n0thing
>
>
> Sent from my iPhone
>
> On 2011-08-19, at 5:03 PM, hlcoders-requ...@list.valvesoftware.com wrote:
>
>> Send hlcoders mailing list submissions to
>> hlcoders@list.valvesoftware.com
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> or, via email, send a message with subject or body 'help' to
>> hlcoders-requ...@list.valvesoftware.com
>>
>> You can reach the person managing the list at
>> hlcoders-ow...@list.valvesoftware.com
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of hlcoders digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Getting an attachment position on client side view model
>> (Michael Kramer)
>> 2. Re: Getting an attachment position on client side view model
>> (Asher Baker)
>>
>>
>> --
>>
>> Message: 1
>> Date: Fri, 19 Aug 2011 13:49:04 -0600
>> From: Michael Kramer 
>> To: Discussion of Half-Life Programming
>> 
>> Subject: Re: [hlcoders] Getting an attachment position on client side
>> view model
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> is pEntity of type CBaseViewModel?
>>
>> if not, try casting pEntity to CBaseViewModel
>>
>> On Fri, Aug 19, 2011 at 12:55 PM, Ryan Sheffer 
wrote:
>>
>>> Thanks for the code, but unfortunately I need a way to get the
attachment
>>> without using the beams attachment point stuff.
>>>
>>>
>>> On Thu, Aug 18, 2011 at 11:13 PM, Michael Kramer <
>>> gameexpertmas...@gmail.com> wrote:
>>>
 When I drew a beam for one of my weapons I used the following:

 pBeam->PointEntInit( endPos, this );
 pBeam->SetEndAttachment( 1 );
 pBeam->SetWidth( width / 4.0f );
 pBeam->SetEndWidth( width );

 However this was serverside code, But I did then have it also spark on
the
 muzzle, so I did:
 CBaseViewModel *pViewModel = pOwner->GetViewModel();
 pViewModel->GetAttachment(LookupAttachment("muzzle"),origin,angles);
 g_pEffects->Sparks(origin);


 Below is the entire drawBeam function I used:

 CBasePlayer *pOwner = ToBasePlayer( GetOwner() );
 CBaseViewModel *pViewModel = pOwner->GetViewModel();

 if ( pOwner == NULL )
 return;

 //Check to store off our view model index
 if ( pViewModel == NULL )
 {
 CBaseViewModel *vm = pOwner->GetViewModel();
 if ( vm )
 {
 m_hViewModel.Set( vm );
 }
 }
 #ifndef CLIENT_DLL
 //Draw a tracer down the middle
 UTIL_Tracer( startPos, endPos, 0, TRACER_DONT_USE_ATTACHMENT, 6500,
 true, "GaussTracer" );

 //Draw the main beam shaft
 CBeam *pBeam = CBeam::BeamCreate( GAUSS_BEAM_SPRITE, width );

 if ( useMuzzle )
 {
 pBeam->PointEntInit( endPos, this );
 pBeam->SetEndAttachment( 1 );
 pBeam->SetWidth( width / 4.0f );
 pBeam->SetEndWidth( width );
 }

 else
 {
 pBeam->SetStartPos( startPos );
 pBeam->SetEndPos( endPos );
 pBeam->SetWidth( width );
 pBeam->SetEndWidth( width / 4.0f );
 }

 pBeam->SetBrightness( 255 );
 pBeam->SetColor( 255, 145+random->RandomInt( -16, 16 ), 0 );
 pBeam->RelinkBeam();
 pBeam->LiveForTime( 5.1f );


 On Thu, Aug 18, 2011 at 11:11 PM, Ryan Sheffer wrote:

> Hey coders!
>
> I came across a nasty little issue and I thought maybe somebody has
come
> across this before.
> I am trying to create a client side beam from the muzzle of the
players
> view model to where the bullet impacts, but I cannot get the
attachment
> position for the muzzle on the view model.
>
> Here is the code I am using for getting the attachment:
>
> int attachment = pEntity->LookupAttachment( "muzzle" );
> pEntity->GetAttachment( attachment, vecAttachment, angAttachment );
>
> pEntity is the view model.
> This is the same way I saw it done on the physcannons client side
code.
> The position it gets appears to be somewhere close to the origin of
the
> map but the coordinates are not exactly 0, 0, 0. One way to fix the
position
> is to give myself a weapon_physcannon and then when I switch back to
my gun
> the attachment position is where it should be, from the muzzle. I
don't see
> anything special in the weapon_physcannon's code so I am baffled.
>
> Some things to note:
> - This is a client side entity, client side code
> - The attachment on the model looks fine in the model viewer
>
> So any help would be wonderful, I am just digging away at the
debugging
> trying to find the issue but nothing sticks out, only the fact that
having a
>>>

Re: [hlcoders] Swap_Buffers spiking to >10-15 ms every few seconds

[James Pizzurro]

Is this a custom map we're talking about here?

Regardless, I'm sure you've already looked at this, but just in case:
http://developer.valvesoftware.com/wiki/Showbudget#Showbudget_categories

Scroll on down to the "Swap buffers" section and have a look.

*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com


On Fri, Aug 12, 2011 at 12:06 AM, Joel R.  wrote:

> Hi Valve,
>
> There is a very noticeable drop in FPS every so often due to Swap_Buffers.
> I see it on my mod and on a vanilla scratch mod when I use +showbudget.  Is
> it possible this could be looked at?  It's causing a slight hiccup in my
> smoothness.
>
> Thank You,
>
> Joel
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Overriding scheme setting for vguiscreen.

[James Deeman]

Sorry i should have pointed out the mod is 2007 based. I can't seem to find
that console command.

On 3 August 2011 21:48, Adam "amckern" McKern  wrote:

> conconmand vgui_refrsh (i think) used when you change screen res on 2003,
> and 2005, will also repaint the vgui.
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
> --
> *From:* James Deeman 
> *To:* hlcoders@list.valvesoftware.com
> *Sent:* Thursday, 4 August 2011 6:17 AM
> *Subject:* [hlcoders] Overriding scheme setting for vguiscreen.
>
> I am trying to customise a vguiscreen using its .res file and a scheme
> file. My scheme is being applied to the panel just fine and the default
> label color is being applied, but when I come to change the color of an
> individual label on the panel 'fgcolor_override' has no effect.
> I am however able to change the fgcolor of the label if I get a pointer to
> it in the vguiscreen class' code, and call SetFgColor() inside the
> overridden ApplySchemeSettings() function. Is there anyway to configure this
> individual label's color in the .res file of the panel or the Scheme itself,
> rather than in code? I thought 'fgcolor_override' was exactly the thing i
> needed.
>
> Thanks.
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
James Deeman
Nottingham, UK
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Overriding scheme setting for vguiscreen.

[James Deeman]

I am trying to customise a vguiscreen using its .res file and a scheme file.
My scheme is being applied to the panel just fine and the default label
color is being applied, but when I come to change the color of an individual
label on the panel 'fgcolor_override' has no effect.
I am however able to change the fgcolor of the label if I get a pointer to
it in the vguiscreen class' code, and call SetFgColor() inside the
overridden ApplySchemeSettings() function. Is there anyway to configure this
individual label's color in the .res file of the panel or the Scheme itself,
rather than in code? I thought 'fgcolor_override' was exactly the thing i
needed.

Thanks.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Should I switch ASW SDK or stay with Source 2007

[James Pizzurro]

Garry's Mod is certainly an excellent environment to test ideas in, though
I've never quite completed anything for it. You raise an interesting
proposition though. Support Python and we'll see? (I joke) :p

On Mon, Aug 1, 2011 at 12:36 PM, Stephen Swires wrote:

> Do you have navigation mesh bindings yet?
>
>
> On Mon, Aug 1, 2011 at 5:35 PM, Garry Newman wrote:
>
>> That's true - it does have its disadvantages.. but it has its advantages.
>> It's easier. The engine will get updated around your Lua code. There's an
>> existing playerbase - playing your mod is as easy as joining a different
>> server. If your mod is half decent I'd ship it with GMod.. allowing people
>> to play with your content in GMod's sandbox, then join a different server
>> and play the game itself.
>>
>> garry
>>
>>
>>
>> On Mon, Aug 1, 2011 at 5:28 PM, Saul Rennison wrote:
>>
>>> Slightly restricts your fanbase to Gmod owners, then, and you have enough
>>> money, thanks.
>>>
>>>
>>> Kind regards,
>>> *Saul Rennison*
>>>
>>>
>>>
>>> On 1 August 2011 17:22, Garry Newman  wrote:
>>>
>>>> The solution is simple - code your mod in GMod :D
>>>>
>>>> garry
>>>>
>>>>
>>>>
>>>> On Mon, Aug 1, 2011 at 5:05 PM, Stephen Swires <
>>>> stephen.swi...@gmail.com> wrote:
>>>>
>>>>> It's not actually the codebase that matters, it's the benefits of the
>>>>> later Source versions including Mac support, better multi-threaded
>>>>> rendering, etc. But I suppose for most of you, if you were to start a new
>>>>> project now, Source wouldn't even be considered. You have UDK, Unity, and
>>>>> later this month CryEngine 3 to play with.
>>>>>
>>>>>
>>>>> On Mon, Aug 1, 2011 at 3:54 PM, James Pizzurro <
>>>>> ja...@agentredproductions.com> wrote:
>>>>>
>>>>>> In my opinion, 2007 is an excellent codebase. I realize Valve has
>>>>>> added/changed/removed some things since its initial release to the 
>>>>>> public,
>>>>>> but generally speaking, things work quite well with very few "required"
>>>>>> changes. What I do think stands to be improved is Hammer, but it sounds 
>>>>>> like
>>>>>> they're working on that, so to be honest, there's not much to complain
>>>>>> about. Just my two cents...and this conversation should probably stop 
>>>>>> here
>>>>>> or be taken elsewhere seeing as it's a bit off-topic, no?
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 1, 2011 at 1:30 AM, Nathan Voge  wrote:
>>>>>>
>>>>>>>  2007!!! You guys/gals realize its more than half way through 2011 -
>>>>>>> right? We should have a freakin updated sdk by now Valve!
>>>>>>>
>>>>>>> Releasing Alien Swarm for free was a nice start but it was not
>>>>>>> developed to be a base of anything but Alien Swarm. It was released 
>>>>>>> over a
>>>>>>> year ago - Last update is just days away from 1 year - and its basically
>>>>>>> dead. We need tools that work and eliminate the bs of creating, 
>>>>>>> importing,
>>>>>>> and modifying content. We need code where everything works (without 
>>>>>>> having
>>>>>>> to use community patches) and provides us a great base but doesn't 
>>>>>>> overwhelm
>>>>>>> us with its size. We need better documentation as well. You can't 
>>>>>>> expect the
>>>>>>> community to write all the help files.
>>>>>>>
>>>>>>> I've seen the words "masochist" and "Source" used near each other too
>>>>>>> many times to not say this stuff. Ever notice how dead the mailing list 
>>>>>>> is
>>>>>>> in recent years?
>>>>>>>
>>>>>>> As it stands I can probably count the number of for profit, released,
>>>>>>> Source Engine games not produced by Valve on one hand. Build a better 
>>>>>>> Source
>>>>&g

Re: [hlcoders] Should I switch ASW SDK or stay with Source 2007

[James Pizzurro]

In my opinion, 2007 is an excellent codebase. I realize Valve has
added/changed/removed some things since its initial release to the public,
but generally speaking, things work quite well with very few "required"
changes. What I do think stands to be improved is Hammer, but it sounds like
they're working on that, so to be honest, there's not much to complain
about. Just my two cents...and this conversation should probably stop here
or be taken elsewhere seeing as it's a bit off-topic, no?

On Mon, Aug 1, 2011 at 1:30 AM, Nathan Voge  wrote:

>  2007!!! You guys/gals realize its more than half way through 2011 - right?
> We should have a freakin updated sdk by now Valve!
>
> Releasing Alien Swarm for free was a nice start but it was not developed to
> be a base of anything but Alien Swarm. It was released over a year ago -
> Last update is just days away from 1 year - and its basically dead. We need
> tools that work and eliminate the bs of creating, importing, and modifying
> content. We need code where everything works (without having to use
> community patches) and provides us a great base but doesn't overwhelm us
> with its size. We need better documentation as well. You can't expect the
> community to write all the help files.
>
> I've seen the words "masochist" and "Source" used near each other too many
> times to not say this stuff. Ever notice how dead the mailing list is in
> recent years?
>
> As it stands I can probably count the number of for profit, released,
> Source Engine games not produced by Valve on one hand. Build a better Source
> SDK and you will get more interest in Source licensing. Hell, I'd probably
> even call it something else so people aren't scared off by its previous rep.
>
>
>
> --
> Date: Sun, 31 Jul 2011 01:44:25 +0100
> From: stephen.swi...@gmail.com
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] Should I switch ASW SDK or stay with Source 2007
>
>
> In addition to that Marek, I can see people taking advantage of Mac OS X
> and replay support
>
> On Sun, Jul 31, 2011 at 12:34 AM, Marek Sieradzki <
> marek.sierad...@gmail.com> wrote:
>
> No significant changes at all, just that it has multithreaded leaf
> system, shadows and rendering which change 20-50 FPS into 150.
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
>
> --
> - Stephen Swires
>
> ___ To unsubscribe, edit your
> list preferences, or view the list archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] hlcoders Digest, Vol 4, Issue 16

[James Pizzurro]

More or less full sentences this time around though, so I'm satisfied.

On Sat, Jul 16, 2011 at 5:28 AM, Tony "omega" Sergi wrote:

> I swear this guy is a bot.
>
>
>
> On Sat, Jul 16, 2011 at 5:13 PM, Sam  wrote:
>
>> How about making a game or toolkit around the SDK that's easier to learn
>> or use?
>>
>> Maybe something that's useful for the people here, why are you all
>> here now, and not working for a games company?
>>
>> How about something like an MMO made inside the game, except instead
>> of leveling up by killing monsters, you level up by learning and
>> writing and using code?
>> Maybe with grouping and guilding options too...
>>
>> Are you all here to learn, or perhaps to make money, but not at a
>> normal programming job?
>>
>> Are you companies?
>>
>>
>>
>> ANyways i'm good at coordination and am a general (ist too), I bet the
>> easiest way for us all to win really fast now? Tell me what you have,
>> and what you want, and if you all go I can link all you into a team
>> and build what is already quickly? :) Right here on this list. How
>> many are there, and who wants what?
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> --
> -Tony
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Choppy motion using the 2007 sdk mp template

[James Pizzurro]

Oh, sorry, that wasn't meant to be interpreted as sarcasm (I blame the
Interwebs).

But alas, I think I can redeem myself with a wiki page I created some years
ago that fixes at least some of those water animation issues, although I
thought it only pertained to non-template SDK 2007:
http://developer.valvesoftware.com/wiki/Fix_Missing_Player_Animations

On Thu, Jul 14, 2011 at 4:07 PM, Eek Glur  wrote:

> Thanks for that sarcasm, but it could also imply that the issue with laggy
> movement was (assumed to be) only present when sprinting was disabled, thus
> was fixed for that situation. Either way -> pointless issue. I will take a
> look into it, but even then - I've already noticed more issues that I'm
> probably just fighting a loosing battle -> movement issues persist when
> crouching and walking in water, and sometimes just completely randomly when
> walking. The hl2dm branch seems not to have all the issues, but even that
> works the same in water. *pulls hair out*
>
>
> On Thu, Jul 14, 2011 at 8:02 PM, James Pizzurro <
> ja...@agentredproductions.com> wrote:
>
>> The title of that fix on the VDC is actually quite clever, being "Fix
>> laggy movement when Sprinting is disabled," which seems to imply it's only
>> for mods that want sprinting disabled entirely, so I'm not too surprised to
>> hear it doesn't work for mods that want sprinting enabled but the "laggy
>> movement" fixed.
>>
>> That said and while I don't have the source code in front of me to pull
>> up, I'd probably start by searching for all instances of "m_flRunSpeed" and
>> look for anything pertaining to updating movement (which I imagine will be
>> the majority of the results). I'd be surprised if that search didn't give
>> you at least one lead to go off of.
>>
>>
>> On Thu, Jul 14, 2011 at 2:23 PM, Eek Glur  wrote:
>>
>>> Up-on reverting to a completely clean SDK, I can see that this does
>>> somewhat work, sorry for that! However there are still some big problems:
>>> the patch (as far as I can tell) for sprinting just sets the players speed
>>> to their defined sprint speed instead of  run speed, not much of a problem
>>> if you don't use sprinting since the movements are smooth (YAY). But if you
>>> do, then running is the same as sprinting, and there are lots of
>>> inconsitencies with moving - By default movement is choppy, when sprinting
>>> movement is choppy (yet sometimes not choppy?), when reverting to normal
>>> movement after sprinting movement is smooth again. So, it does seem workable
>>> to use without sprinting/stamina, although, it's not a complete fix -
>>> which'd be nice! (also it seems kind of overcomplicated to modify movement
>>> code without coming up with this problem over and over again, currently).
>>>
>>> Thanks all.
>>>
>>>
>>> On Thu, Jul 14, 2011 at 5:38 PM, Eek Glur  wrote:
>>>
>>>> I don't know how this worked for you, because I applied both patches
>>>> with and without sprinting enabled, and nothing changes, but you are right 
>>>> -
>>>> host_timescale 0.1 is a great way of demonstrating the problem. Any more
>>>> ideas? What could I have done wrong :/
>>>>
>>>>
>>>> On Thu, Jul 14, 2011 at 6:56 AM, Ryan Liptak wrote:
>>>>
>>>>> You're right, ignore what I replied with earlier, it does nothing to
>>>>> solve the issue. I just tested the sprinting fix on its own with a fresh
>>>>> 2007 SDK template and it fixes the jittery movement (by the way, if anyone
>>>>> wants to see the issue clearly, use host_timescale 0.1 on a fresh 2007 SDK
>>>>> template mod).
>>>>>
>>>>>  -Original Message- From: Ryan Kistner
>>>>>> Sent: Wednesday, July 13, 2011 8:56 PM
>>>>>>
>>>>>> To: Discussion of Half-Life Programming
>>>>>> Subject: Re: [hlcoders] Choppy motion using the 2007 sdk mp template
>>>>>>
>>>>>> If you're using the 2007 template SDK you might want to see if you
>>>>>> have SDK_USE_SPRINTING set. If it isn't then flMaxSpeed is set
>>>>>> incorrectly. I don't remember specifically what was going on but I
>>>>>> helped a user fix two issues in the template SDK:
>>>>>>
>>>>>> http://developer.**valvesoftware.com/wiki/Source_**
>>>>>> 2007_Template_Fixes<

Re: [hlcoders] Choppy motion using the 2007 sdk mp template

[James Pizzurro]

gt;>>>> experiencing
>>>>>>>> this in a clean base - 2007 multiplayer template, only fixes are
>>>>>>>> compile
>>>>>>>> fixes, release build, default game directory (appid 218), etc. One
>>>>>>>> strange
>>>>>>>> thing I noticed is that while playing is choppy, if I record a demo,
>>>>>>>> on
>>>>>>>> playback it will be super smooth as if there wasn't a problem at
>>>>>>>> all. It's
>>>>>>>> as if the client isn't properly syncronized with the server, while
>>>>>>>> playing.
>>>>>>>> I don't know, but I've had some other people try it out, and they
>>>>>>>> have the
>>>>>>>> same problem, too.
>>>>>>>>
>>>>>>>> Also, sorry for breaking format, I assumed receiving digests would
>>>>>>>> still
>>>>>>>> send my threads back individually - not the case :P
>>>>>>>>
>>>>>>>>   How much and exactly where have you been "toying" with your source
>>>>>>>>   code? I
>>>>>>>>   assume you're not experiencing these issues with a clean,
>>>>>>>>   unmodified 2007
>>>>>>>>   scratch or template build?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> __**_
>>>>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>>>>> archives,
>>>>>>>> please visit:
>>>>>>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>>>>>>
>>>>>>>>
>>>>>>> __**_
>>>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>>>> archives,
>>>>>>> please visit:
>>>>>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> __**__
>>>>> __**_
>>>>> To unsubscribe, edit your list preferences, or view the list archives,
>>>>> please visit:
>>>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>>>
>>>>>
>>>>> __**_
>>>>> To unsubscribe, edit your list preferences, or view the list archives,
>>>>> please visit:
>>>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> __**_
>>>> To unsubscribe, edit your list preferences, or view the list archives,
>>>> please visit:
>>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>>
>>>>
>>>
>>> __**_
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/**mailman/listinfo/hlcoders<http://list.valvesoftware.com/mailman/listinfo/hlcoders>
>>>
>>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] hlcoders Digest, Vol 4, Issue 4

[James Pizzurro]

 entity rather than the weapon. Are you using
> predicted_viewmodel?
> >>
> >> On 12/07/2011 9:05, Priyadarshi Sharma wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am having the issue of a weapon being fired multiple times on client
> >>> side when there is a lag between client and server (net_fakelag 100).
> >>> This is similar to the issue mentioned here :
> >>>
> http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg19271.html
> >>>
> >>> I've tried the suggested fix but it doesn't seem to help in my case.
> >>> It only happens in the burst fire mode though, not otherwise.
> >>>
> >>> Below are the relevant functions. As you can see, even checking for
> >>> IsFirstTimePredicted() doesn't solve the issue and the function is
> >>> still called multiple times on client side as evident from the
> >>> DevMsg() below. How do I go on about solving this issue?
> >>>
> >>> PS - I've also tried the fix mentioned here -
> >>>
> http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg19344.html,
> >>> which indicates a bug with the SDK itself, but no help here too.
> >>>
> >>> Code :
> >>>
> >>> void MyWeapon::ItemPostFrame()
> >>> {
> >>>
> >>> ? ? ? ?// Burstfire continues for 3 shots after we press fire
> >>> ? ? ? ?if(cBurstShots)
> >>> ? ? ? ? ? ? ? ?BurstFire();
> >>> ? ? ? ?else
> >>> ? ? ? ? ? ? ? ?BaseClass::ItemPostFrame();
> >>> }
> >>>
> >>> void MyWeapon::BurstFire()
> >>> {
> >>> ? ? ? ?if (!m_iClip1)
> >>> ? ? ? ?{
> >>> ? ? ? ? ? ? ? ?cBurstShots = 0;
> >>> ? ? ? ? ? ? ? ?return;
> >>> ? ? ? ?}
> >>>
> >>> ? ? ? ?if (tNextBurst> ?gpGlobals->curtime)
> >>> ? ? ? ? ? ? ? ?return;
> >>>
> >>> #ifdef CLIENT_DLL
> >>> ? ? ? ? if ( prediction->InPrediction()&&
> >>> ?!prediction->IsFirstTimePredicted() )
> >>> ? ? ? ? ? ? ? ? return;
> >>> #endif
> >>>
> >>> #ifdef CLIENT_DLL
> >>> ? ? ? ?DevMsg("Time : %f cBurstShots : %d tNextBurst : %f\n",
> >>> gpGlobals->curtime, cBurstShots, tNextBurst);
> >>> #endif
> >>>
> >>> ? ? ? ?// making this NOT relative to curtime means it won't be totally
> >>> cpu/tickrate dependent
> >>> ? ? ? ?tNextBurst += info.m_tReloadChamber;
> >>>
> >>> ? ? ? ?--cBurstShots;
> >>>
> >>> ? ? ? ?Fire();
> >>>
> >>> ? ? ? ?m_flNextPrimaryAttack = m_flNextSecondaryAttack =
> >>> gpGlobals->curtime + 0.1;
> >>>
> >>> ? ? ? ?WeaponSound( SINGLE );
> >>> ? ? ? ?DoMuzzleFlash();
> >>> }
> >>>
> >>>
> >>> void MyWeapon::PrimaryAttack()
> >>> {
> >>> ? ? ? ?if (!fBurstMode)
> >>> ? ? ? ? {
> >>> ? ? ? ? ? ? ? ?Fire();
> >>> ? ? ? ? ? ? ? ?return;
> >>> ? ? ? ?}
> >>>
> >>> ? ? ? ?cBurstShots = 3;
> >>> ? ? ? ?tNextBurst = gpGlobals->curtime;
> >>> ? ? ? ?SendWeaponAnim( ACT_VM_PRIMARYATTACK );
> >>> }
> >>>
> >>> ___
> >>> To unsubscribe, edit your list preferences, or view the list archives,
> >>> please visit:
> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>
> >>>
> >>
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >>
> >
> >
> >
> > --
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> >
> > End of hlcoders Digest, Vol 4, Issue 4
> > **
> >
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


-- 
*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Choppy motion using the 2007 sdk mp template

[James Pizzurro]

How much and exactly where have you been "toying" with your source code? I
assume you're not experiencing these issues with a clean, unmodified 2007
scratch or template build?

On Tue, Jul 12, 2011 at 11:29 PM, iiyo cc  wrote:

> Hello folks,
>
> I've been toying with the mod from scratch/multiplayer template from the
> 2007 SDK and have a big issue that I can't figure out how to fix (nor find
> any information about - which is odd, because I'm sure it can't only be
> me!). Anyway, the issue is when moving around there is a really choppy
> motion - the world doesn't transition nicely from view - it pans very
> choppily. To describe it, it's like playing Minecraft on a bad computer
> while the world is generating, except it's not an FPS issue since that's
> constantly at fps_max!
>
> I hope someone knows what the problem could be.
>
> Thanks~
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>


-- 
*James Pizzurro*
Co-founder, Programmer
Agent Red Productions
646-341- direct
ja...@agentredproductions.com | www.agentredproductions.com
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Faceposer 2009

[James Warner]

Try installing Windows into a Virtual Machine (Vmware Player, Workstation).

> From: hlcoders-requ...@list.valvesoftware.com
> Subject: hlcoders Digest, Vol 34, Issue 10
> To: hlcoders@list.valvesoftware.com
> Date: Tue, 14 Dec 2010 06:31:44 -0800
> 
> Send hlcoders mailing list submissions to
>   hlcoders@list.valvesoftware.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://list.valvesoftware.com/mailman/listinfo/hlcoders
> or, via email, send a message with subject or body 'help' to
>   hlcoders-requ...@list.valvesoftware.com
> 
> You can reach the person managing the list at
>   hlcoders-ow...@list.valvesoftware.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hlcoders digest..."
> 
> 
> Today's Topics:
> 
>1. Faceposer 2009 (Cory de La Torre)
>2. Re: Faceposer 2009 (Tom Edwards)
>3. Re: Faceposer 2009 (Cory de La Torre)
>4. Re: Faceposer 2009 (Cory de La Torre)
>5. Re: Faceposer 2009 (Tom Edwards)
>6. Re: Faceposer 2009 (Cory de La Torre)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 14 Dec 2010 03:50:21 -0800
> From: Cory de La Torre 
> Subject: [hlcoders] Faceposer 2009
> To: Discussion of Half-Life Programming
>   
> Message-ID:
>   
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Not really sure if this falls under mapping or not, so I threw it in the
> coders list. My current problem is extracting phenom extraction. I'm
> currently using Tom Edwards "fixed" phonemeextractor.dll. For reasons I
> can't seem to understand is during the extraction (after putting in the
> sentence for the audio file and clicking ok) faceposer just plain crashes.
> I've found it works for other people and sometimes it doesn't, though I seem
> to be the in the rare group of people that faceposer just plain crashes on
> during the extraction.
> 
> I was following a tutorial earlier that dates back to around 2008.The
> tutorial has directed me to go and download the SpeechSDK and install that.
> Upon further investigation I've found that under Windows 7 you don't even
> need that, and just the fixed dll. After reading some more I've come to
> another fork in the road. It seems the only way to get this shit all fixed
> up again is to reinstall windows, something I am totally not going to do if
> this still doesn't end working. Honestly I shouldn't have to reinstall my
> operating system anyways. Thats a severe punishment for this going south. My
> question is whether or not installing the SpeechSDk is the reason Faceposer
> is crashing at extraction.
> 
> To clarify I've went and uninstalled the SpeechSDK before putting in the
> fixed phonemeextractor.dll.
> 
> 
> Aside all of this madness; whats going on anyways!? I wouldn't have expected
> getting faceposer to work would be all this trouble under 2009 on future
> operating systems that almost everyone has entirely migrated too. I'm
> assuming Valve is at least using some Windows 7 and Vista machines up there,
> unless they are seriously using XP to use a "working" faceposer. The fact we
> need to use a custom modified dll to get all this working again is pretty
> bad. Faceposer should "just work" out of the box, and not require any users
> to go searching around for things. Yeah, yeah I know, not in valves current
> needs to do (too busy, yadda yadda) but that shit is starting to get real
> tiring. I'd like for once to actually be able to use a single Source Engine
> tool that isn't made by someone outside of Valve and works/does not require
> workarounds.
> 
> -- 
> Gear Dev
> 
> 
> --
> 
> Message: 2
> Date: Tue, 14 Dec 2010 12:44:42 +
> From: Tom Edwards 
> Subject: Re: [hlcoders] Faceposer 2009
> To: Discussion of Half-Life Programming
>   
> Message-ID: <4d0766ba.4020...@steamreview.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Someone once said they fixed the problem by copying some SAPI-related 
> DLLs off their Windows install CD. They disappeared without telling 
> anyone what those files were, unfortunately.
> 
> The SAPI extractor is crumbling away because Valve don't use it. They 
> have a different extractor built with phoneme middleware that they don't 
> - I assume - have a distribution license for.
> 
> I went back to the extractor just now to make sure it still works and 
> found a bug in the error message that appears when extraction totally 
> fails. Somehow I'd cocked up the process of launching the control panel 
> app. Fix here: 
> http://steamreview.org/external/vdc/phonemeextractor_sapi5.4.zip
> 
> On 14/12/2010 11:50, Cory de La Torre wrote:
> > Not really sure if this falls under mapping or not, so I threw it in the
> > coders list. My current problem is extracting phenom extraction. I'm
> > currently using Tom Edwards "fixed" phonemeextractor.dll. For reasons I
> > can't seem to understand is d

[hlcoders] Rain Splash Effect

[James Warner]

Hi all again.Continuing from my previous message, I got it working in the end, 
but the rain splash is always spawning at 0 0 0. 
http://i52.tinypic.com/10mogma.png is whats happening.if( trace.fraction < 
1 || trace.DidHit() )   {if ( RandomInt( 0, 100 ) <= 
r_RainSplashPercentage.GetInt() )   DispatchParticleEffect( 
"Rain_01_impact_sphere", trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );
   // Tell the framework it's time to remove the particle from the list 
  return false;   }is the code to spawn the rain.
Any ideas?Thanks, FiX 
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Tony's Rain Splash tutorial on VDC

[James Warner]

Hi all on the mailing list.First post on here, hope it works :)Was following 
the tutorial on the VDC (rain splashes).I have come to a problem, when I run 
the mod, I get "Client: Missing precache for particle system "Rain_01"!"Rain_01 
being the particle effect in Hl2:Ep2. I was trying to use the Rain_01_impact as 
the particle for water splashes.Full code here: http://pastebin.com/PsqqByA1I 
have tried:void CClient_Precipitation::ClientThink(){   Simulate( 
gpGlobals->frametime );PrecacheParticleSystem("Rain_01");}andvoid 
CClient_Precipitation::ClientThink(){   Simulate( gpGlobals->frametime );
PrecacheParticleSystem("Rain_01_impact");}along with 
tryingDispatchParticleEffect( "Rain_01", 
trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );andDispatchParticleEffect( 
"Rain_01_impact", trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );None of 
which seems to work.Any ideas?
Many thanks, FiX  
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Logaddress and rcon

[James McDonnell]

I've been working on an rcon application in c#, kind of as a learning tool.
And I've got it to send and receive packets, it all works relatively well,
cept a few bugs, as previously mentioned about 2 years ago on here the
cvarlist command returns about 3 sets of responses, and what I mean by that,
is It has about 42 packets or something, and is split up into three
delimited responses by having two bytes of 0x00 at the end of each response.
Now I understand the cvarlist returns a huge response, but does anyone know
why it behaves like this?

 

My other issue I'm having right now is I'm trying to get the application to
receive an additional udp connection from the server from the logaddress_add
command, so that it will asynchronously continue to collect and read packets
to my application. But I don't have a very good idea of how to do it. Anyone
have and tips or pointers? I'm writing it in Visual Studio with c#.

 

Thanks

James.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Prevent pause during open dev console?

[James Pizzurro]

If I remember correctly, when the game is paused, at least one of the things
that happens is host_timescale is set to 0. I'm not sure what could be done
about this though because it is all probably handled in
the inaccessible parts of the engine.

On Thu, Sep 30, 2010 at 5:04 PM, Martin Smith  wrote:

> Still no luck, but thank you also for the feedback.
>
> On Thu, Sep 30, 2010 at 4:39 PM, Tom Edwards  >wrote:
>
> >  You can run unpause (or perhaps it's pause again, as a toggle) while
> > inside the console. It's probably possible to bind a key that does both
> > things at once.
> >
> >
> > On 30/09/2010 7:18, Martin Smith wrote:
> >
> >> Hey list,
> >>
> >> By default, when the engine receives a toggleconsole command in a
> >> single-player game, the game is paused until the console is closed. I'd
> >> like
> >> to allow use of the dev console while a simulation continues running.
> Can
> >> anyone think of a way to prevent this from happening?
> >>
> >> I guess the alternative is intercepting the command, and trying to run
> the
> >> console dialog from the Client DLL.
> >>
> >> Thanks!
> >>
> >> Martin
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >>
> >>
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Melee weapon "lag" in the hl2dm SDK

[James Pizzurro]

If it is indeed an issue with the lag compensation system itself, one rather
simple workaround would be to decrease the maximum range of all your melee
weapons. I've done this before in one of my own modifications with moderate
success. Of course, a more direct solution would be optimal.

On Sep 20, 2010 12:53 PM, "Tom Edwards"  wrote:
> On whose end are hits achieved at a distance? The attacker or the target?
>
> On 20/09/2010 5:48, Richard Paterson wrote:
>> This is sort of a vague question but I hope to perhaps benefit from
>> the experience of others if anyone has managed to overcome this issue.
>>
>> My mod relies quite heavily on melee combat and I've noticed that lag
>> compensation is relatively bad in the case of melee weapon use. Hits
>> can be achieved at substantial distances at times(multiple player
>> lengths). I've also noticed that this isn't the case in other valve
>> games such as tf2.
>> Being a noob on the net side of things, I can see that lag
>> compensation is indeed used during collision detections for bludgeon
>> weapons but I lack the knowledge to determine what needs tweaking.
>> Perhaps it's more a question of player movement updates as melee
>> weapon hit detection success is more dependent on the player's
>> positions relative to one another than in the case of normal
>> projectile weapons.
>>
>> I'd also like to know if other people have at least noticed this
>> problem, otherwise I'll have to assume I introduced the problem myself
>> via prior modifications.
>>
>> I would greatly appreciate any help or advice.
>>
>> Richard.
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2009?

[James Pizzurro]

The answer is no, not yet.

On Sep 11, 2010 7:24 PM, "Matheus Lima Faiotto"  wrote:
> Alright guys,
>
> I'm sorry I'm kind of late here, however, Is it possible to Create a Mod
with the Source Engine 2009?
>
> because while attempting to, I get an error about being able to open
\CreateAMod\something\gameinfo_mp.txt
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2009

[James Murray]

Valve has not released the new SDK yet so you will have to wait Sorry...

On Tue, Jun 15, 2010 at 2:04 AM, Adrian  wrote:

> Hello,
>
>
> I have a question. I have tried starting a source mod yesterday evening,
> and
> I have failed.
> The problem is that I want to start the mod on newest engine (2009 in the
> source_sdk)
> but the application tells me that mods are not yet supported for this
> version of source.
>
> Does any of You have an idea, when will Valve let us work on this engine?
>
>
> A little offtopic now, but related to my plans.
> I'd like to create my mod on newest engine because I noticed that HL2 works
> on EP2 engine now ( or sort of ) and the maps work totally fine.
> When I tried playing my mod (episode 2 engine ( 2007 if I remember
> correctly)) on those stock HL2 maps the game was unplayable
> due to massive ammounts of bugs like missing sequences, sounds and
> animations ( like lack Alyx beating metrocops near the Kleiner's elevator
> so
> I couldn't advance in the campaign.)
> I have tried decompiling those maps of course, but re-compiling haven't
> fixed anything, plus it caused even more bugs.
>
> Now again I have tried making a mod on the EP2 engine, due to old files
> being lost.
> This is impossible due to C++ errors, the same stuff happens when I'm
> trying
> to compile a mod on the earliest engine - errors.
>
> Is the SDK some sort of patch-broken or is it just me?
>
>
>
> Thanks,
>
> Adrian
>
>
> __ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur
> wirusow 5196 (20100614) __
>
> Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.
> http://www.eset.pl lub http://www.eset.com
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Particle rain like L4D(2)?

[James K]

Adding rain splashes (after we found out how to do it with a very long
discussion) makes the standard func_precipitation look pretty good. If
you mess with cl_winddir, cl_windspeed, and (i think it's called)
r_rainlength you can replicate the L4D2 rain pretty well.

Although, I will admit, having particles instead of textured tracers
for the rain drops would look a lot better.

-James

On Sat, May 22, 2010 at 9:21 AM, Tobias Kammersgaard
 wrote:
> That's not rally what I want to do. The episode two entity doesn't have the
> l4d options (particle rain).
>
> Den 22/05/2010 14.32 skrev "Adam "amckern" McKern" :
>
> http://forums.l4dmaps.net/thread-1139.html
>
> If you want to know more, ask at interlopers, or on those forums.
>
> Adam
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
> --- On Sat, 22/5/10, Tobias Kammersgaard 
> wrote:
>
> From: Tobias Kammersgaard 
> Subject: [hlcoders] Particle rain like L4D(2)?
> To: "Discussion of Half-Life Programming" 
> Received: Saturday, 22 May, 2010, 10:10 PM
>
>
> Hey!
>
> I'm trying to make a rain effect using particles like Valve's done in
> L4D(2). Obviously its a...
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James Keith]

It seems to impact it a little bit but I have such a good video card  
that I can't see a difference.



On May 21, 2010, at 6:04 PM, Dexter  wrote:

> Glad you got it working! I'm looking for something similiar in  
> effect, but
> isn't doing so many tracelines performance impacting?
>
> On Fri, May 21, 2010 at 12:23 PM, James K  wrote:
>
>> I didn't comment enough stuff out. Whoops. Thanks for putting up with
>> my stupidity, Tony.
>>
>> -James
>>
>> On Fri, May 21, 2010 at 9:57 AM, Tony "omega" Sergi > >
>> wrote:
>>> I dropped the code into a a blank sdk and it works.
>>> I made one minor alteration though, here's the whole thing. if it  
>>> still
>>> doesn't work for you then i have no idea, as i was just sitting in  
>>> a box
>> map
>>> with a displacement ground seeing slime splashes randomly, WITH rain
>> coming
>>> down.
>>> http://pastebin.com/0KfbHkii
>>> -Tony
>>>
>>>
>>> On Fri, May 21, 2010 at 9:50 AM, James K   
>>> wrote:
>>>
>>>> Removing the IsInAir conditional broke the rain completely. No  
>>>> rain or
>>>> splashes at all now.
>>>>
>>>> On Thu, May 20, 2010 at 8:13 AM, Tony "omega" Sergi <
>> omegal...@gmail.com>
>>>> wrote:
>>>>> and remove all of the other randoms other than what that i  
>>>>> changed the
>>>> code
>>>>> to.
>>>>> So for the final output:
>>>>>
>>>>>   /*Tony; the traceline replaces the IsInAir check.
>>>>>   you also don't want the random's to be around the traceline  
>>>>> either,
>> or
>>>>> it will only check SOMETIMES. it needs to check _all_ the time.
>>>>>   you also probably want to do some radius checking of the  
>>>>> particles
>>>>> position (ignoring z) for if it's in range of the local player  
>>>>> to run
>>>> this
>>>>> code or not
>>>>>   otherwise you will have traces for every particle all over the
>> place
>>>>> even if there's no way that the player can see it
>>>>>   so when the player is out of that radius, you would only use  
>>>>> if (
>>>>> !IsInAir( pParticle->m_Pos ) { return false; }
>>>>>  */
>>>>>   trace_t trace;
>>>>>   UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_SOLID, NULL,
>>>>> COLLISION_GROUP_NONE, &trace);
>>>>>   if( trace.fraction < 1 || trace.DidHit() )
>>>>>   {
>>>>>   if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt 
>>>>> () )
>>>>>   DispatchParticleEffect( "rain_splash",
>>>>> trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );
>>>>>
>>>>>   // Tell the framework it's time to remove the particle  
>>>>> from the
>>>> list
>>>>>   return false;
>>>>>   }
>>>>>   // We still want this particle
>>>>>   return true;
>>>>>
>>>>> -Tony
>>>>>
>>>>> On Thu, May 20, 2010 at 7:16 PM, Saul Rennison <
>> saul.renni...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Remove the IsInAir conditional, that's your issue.
>>>>>>
>>>>>> On Thursday, May 20, 2010, James K  wrote:
>>>>>>> I don't want to post the whole file because I really haven't
>> changed
>>>>>>> anything else and that would be massive, so here's the tidbit  
>>>>>>> i'm
>>>>>>> working with. The whole file is c_effects.cpp if you need to see
>> the
>>>>>>> rest.
>>>>>>>
>>>>>>>// No longer in the air? punt.
>>>>>>>if ( !IsInAir( pParticle->m_Pos ) )
>>>>>>>{
>>>>>>>// Possibly make a splash if we hit a water  
>>>>>>> surface
>>>> and
>>>>>> it's in
>>>>>>> front of the view.
>>>>>>>if ( m_Splashes.Count() < 99 )
>>>>>>>{
>>>>>>>if ( RandomInt( 0

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

I didn't comment enough stuff out. Whoops. Thanks for putting up with
my stupidity, Tony.

-James

On Fri, May 21, 2010 at 9:57 AM, Tony "omega" Sergi  wrote:
> I dropped the code into a a blank sdk and it works.
> I made one minor alteration though, here's the whole thing. if it still
> doesn't work for you then i have no idea, as i was just sitting in a box map
> with a displacement ground seeing slime splashes randomly, WITH rain coming
> down.
> http://pastebin.com/0KfbHkii
> -Tony
>
>
> On Fri, May 21, 2010 at 9:50 AM, James K  wrote:
>
>> Removing the IsInAir conditional broke the rain completely. No rain or
>> splashes at all now.
>>
>> On Thu, May 20, 2010 at 8:13 AM, Tony "omega" Sergi 
>> wrote:
>> > and remove all of the other randoms other than what that i changed the
>> code
>> > to.
>> > So for the final output:
>> >
>> >    /*Tony; the traceline replaces the IsInAir check.
>> >    you also don't want the random's to be around the traceline either, or
>> > it will only check SOMETIMES. it needs to check _all_ the time.
>> >    you also probably want to do some radius checking of the particles
>> > position (ignoring z) for if it's in range of the local player to run
>> this
>> > code or not
>> >    otherwise you will have traces for every particle all over the place
>> > even if there's no way that the player can see it
>> >    so when the player is out of that radius, you would only use if (
>> > !IsInAir( pParticle->m_Pos ) { return false; }
>> >   */
>> >    trace_t trace;
>> >    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_SOLID, NULL,
>> > COLLISION_GROUP_NONE, &trace);
>> >    if( trace.fraction < 1 || trace.DidHit() )
>> >    {
>> >        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>> >            DispatchParticleEffect( "rain_splash",
>> > trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );
>> >
>> >        // Tell the framework it's time to remove the particle from the
>> list
>> >        return false;
>> >    }
>> >    // We still want this particle
>> >    return true;
>> >
>> > -Tony
>> >
>> > On Thu, May 20, 2010 at 7:16 PM, Saul Rennison > >wrote:
>> >
>> >> Remove the IsInAir conditional, that's your issue.
>> >>
>> >> On Thursday, May 20, 2010, James K  wrote:
>> >> > I don't want to post the whole file because I really haven't changed
>> >> > anything else and that would be massive, so here's the tidbit i'm
>> >> > working with. The whole file is c_effects.cpp if you need to see the
>> >> > rest.
>> >> >
>> >> >         // No longer in the air? punt.
>> >> >         if ( !IsInAir( pParticle->m_Pos ) )
>> >> >         {
>> >> >                 // Possibly make a splash if we hit a water surface
>> and
>> >> it's in
>> >> > front of the view.
>> >> >                 if ( m_Splashes.Count() < 99 )
>> >> >                 {
>> >> >                         if ( RandomInt( 0, 100 ) <
>> >> r_RainSplashPercentage.GetInt() )
>> >> >                         {
>> >> >    trace_t trace;
>> >> >    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
>> >> > COLLISION_GROUP_NONE, &trace);
>> >> >    if( trace.fraction < 1 || trace.DidHit() )
>> >> >    {
>> >> >        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>> >> >            DispatchParticleEffect( "rain_splash", trace.endpos,
>> >> > trace.m_pEnt->GetAbsAngles() , NULL );
>> >> >    }
>> >> >                         }
>> >> >                 }
>> >> >
>> >> >                 // Tell the framework it's time to remove the particle
>> >> from the list
>> >> >                 return false;
>> >> >         }
>> >> >
>> >> >         // We still want this particle
>> >> >         return true;
>> >> > }
>> >> >
>> >>
>> > ___
>> > To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >
>> >
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> --
> -Tony
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

Removing the IsInAir conditional broke the rain completely. No rain or
splashes at all now.

On Thu, May 20, 2010 at 8:13 AM, Tony "omega" Sergi  wrote:
> and remove all of the other randoms other than what that i changed the code
> to.
> So for the final output:
>
>    /*Tony; the traceline replaces the IsInAir check.
>    you also don't want the random's to be around the traceline either, or
> it will only check SOMETIMES. it needs to check _all_ the time.
>    you also probably want to do some radius checking of the particles
> position (ignoring z) for if it's in range of the local player to run this
> code or not
>    otherwise you will have traces for every particle all over the place
> even if there's no way that the player can see it
>    so when the player is out of that radius, you would only use if (
> !IsInAir( pParticle->m_Pos ) { return false; }
>   */
>    trace_t trace;
>    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_SOLID, NULL,
> COLLISION_GROUP_NONE, &trace);
>    if( trace.fraction < 1 || trace.DidHit() )
>    {
>        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>            DispatchParticleEffect( "rain_splash",
> trace.endpos,trace.m_pEnt->GetAbsAngles() , NULL );
>
>        // Tell the framework it's time to remove the particle from the list
>        return false;
>    }
>    // We still want this particle
>    return true;
>
> -Tony
>
> On Thu, May 20, 2010 at 7:16 PM, Saul Rennison wrote:
>
>> Remove the IsInAir conditional, that's your issue.
>>
>> On Thursday, May 20, 2010, James K  wrote:
>> > I don't want to post the whole file because I really haven't changed
>> > anything else and that would be massive, so here's the tidbit i'm
>> > working with. The whole file is c_effects.cpp if you need to see the
>> > rest.
>> >
>> >         // No longer in the air? punt.
>> >         if ( !IsInAir( pParticle->m_Pos ) )
>> >         {
>> >                 // Possibly make a splash if we hit a water surface and
>> it's in
>> > front of the view.
>> >                 if ( m_Splashes.Count() < 99 )
>> >                 {
>> >                         if ( RandomInt( 0, 100 ) <
>> r_RainSplashPercentage.GetInt() )
>> >                         {
>> >    trace_t trace;
>> >    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
>> > COLLISION_GROUP_NONE, &trace);
>> >    if( trace.fraction < 1 || trace.DidHit() )
>> >    {
>> >        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>> >            DispatchParticleEffect( "rain_splash", trace.endpos,
>> > trace.m_pEnt->GetAbsAngles() , NULL );
>> >    }
>> >                         }
>> >                 }
>> >
>> >                 // Tell the framework it's time to remove the particle
>> from the list
>> >                 return false;
>> >         }
>> >
>> >         // We still want this particle
>> >         return true;
>> > }
>> >
>>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

I don't want to post the whole file because I really haven't changed
anything else and that would be massive, so here's the tidbit i'm
working with. The whole file is c_effects.cpp if you need to see the
rest.

inline bool CClient_Precipitation::SimulateRain(
CPrecipitationParticle* pParticle, float dt )
{
if (GetRemainingLifetime( pParticle ) < 0.0f)
return false;

Vector vOldPos = pParticle->m_Pos;

// Update position
VectorMA( pParticle->m_Pos, dt, pParticle->m_Velocity,
pParticle->m_Pos );

// wind blows rain around
for ( int i = 0 ; i < 2 ; i++ )
{
if ( pParticle->m_Velocity[i] < s_WindVector[i] )
{
pParticle->m_Velocity[i] += ( 5 / pParticle->m_Mass );

// clamp
if ( pParticle->m_Velocity[i] > s_WindVector[i] )
pParticle->m_Velocity[i] = s_WindVector[i];
}
else if (pParticle->m_Velocity[i] > s_WindVector[i] )
{
pParticle->m_Velocity[i] -= ( 5 / pParticle->m_Mass );

// clamp.
if ( pParticle->m_Velocity[i] < s_WindVector[i] )
pParticle->m_Velocity[i] = s_WindVector[i];
}
}

// No longer in the air? punt.
if ( !IsInAir( pParticle->m_Pos ) )
{
// Possibly make a splash if we hit a water surface and it's in
front of the view.
if ( m_Splashes.Count() < 99 )
{
if ( RandomInt( 0, 100 ) < 
r_RainSplashPercentage.GetInt() )
{
   trace_t trace;
   UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
COLLISION_GROUP_NONE, &trace);
   if( trace.fraction < 1 || trace.DidHit() )
   {
   if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
   DispatchParticleEffect( "rain_splash", trace.endpos,
trace.m_pEnt->GetAbsAngles() , NULL );
   }
}
}

// Tell the framework it's time to remove the particle from the 
list
return false;
}

// We still want this particle
return true;
}


On Wed, May 19, 2010 at 11:08 PM, Nick  wrote:
> post all of your code, that way we can help easier.
>
> On Wed, May 19, 2010 at 6:05 PM, James K  wrote:
>> Yup.
>>
>> On Wed, May 19, 2010 at 6:22 PM, Saul Rennison  
>> wrote:
>>> Just to make sure: the displacements DO have hull, ray and physics
>>> collisions enabled in Hammer, don't they?
>>>
>>> Thanks,
>>> - Saul.
>>>
>>>
>>> On 19 May 2010 21:41, James K  wrote:
>>>
>>>> It's still not working, even with this new code. This is really really
>>>> stupid.
>>>>
>>>> James
>>>>
>>>> On Wed, May 19, 2010 at 2:57 AM, Tony "omega" Sergi 
>>>> wrote:
>>>> > It also doesn't help that you're only doing the trace when the random
>>>> value
>>>> > is within the current limit.
>>>> > You need to do the check ALL the time, regardless of if it will actually
>>>> > spawn it or not.
>>>> > Displacements are a single plane, chances are you're repeatedly skipping
>>>> the
>>>> > actual check 99% of the time.
>>>> > Your original code was correct except for the order. ie: new code:
>>>> >
>>>> >    trace_t trace;
>>>> >    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
>>>> > COLLISION_GROUP_NPC, &trace);
>>>> >    if( trace.fraction < 1 || trace.DidHit() )
>>>> >    {
>>>> >        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>>>> >            DispatchParticleEffect( "spash", trace.endpos,
>>>> > trace.m_pEnt->GetAbsAngles() , NULL );
>>>> >    }
>>>> >
>>>> > Also, you can verify it if you set r_RainSplashPercentage to 101 (because
>>>> > even if you set it to 100, it would never trace as it would HAVE to be
>>>> below
>>>> > the value.)
>>>> > -Tony
>>>> >
>>>> > On Wed, May 19, 2010 at 2:59 PM, Ryan Sheffer 
>>>> wrote:
>>>> >
>>>> >> Try shooting a trace right to the ground from the starting point and see
>>&g

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

Yup.

On Wed, May 19, 2010 at 6:22 PM, Saul Rennison  wrote:
> Just to make sure: the displacements DO have hull, ray and physics
> collisions enabled in Hammer, don't they?
>
> Thanks,
> - Saul.
>
>
> On 19 May 2010 21:41, James K  wrote:
>
>> It's still not working, even with this new code. This is really really
>> stupid.
>>
>> James
>>
>> On Wed, May 19, 2010 at 2:57 AM, Tony "omega" Sergi 
>> wrote:
>> > It also doesn't help that you're only doing the trace when the random
>> value
>> > is within the current limit.
>> > You need to do the check ALL the time, regardless of if it will actually
>> > spawn it or not.
>> > Displacements are a single plane, chances are you're repeatedly skipping
>> the
>> > actual check 99% of the time.
>> > Your original code was correct except for the order. ie: new code:
>> >
>> >    trace_t trace;
>> >    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
>> > COLLISION_GROUP_NPC, &trace);
>> >    if( trace.fraction < 1 || trace.DidHit() )
>> >    {
>> >        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>> >            DispatchParticleEffect( "spash", trace.endpos,
>> > trace.m_pEnt->GetAbsAngles() , NULL );
>> >    }
>> >
>> > Also, you can verify it if you set r_RainSplashPercentage to 101 (because
>> > even if you set it to 100, it would never trace as it would HAVE to be
>> below
>> > the value.)
>> > -Tony
>> >
>> > On Wed, May 19, 2010 at 2:59 PM, Ryan Sheffer 
>> wrote:
>> >
>> >> Try shooting a trace right to the ground from the starting point and see
>> if
>> >> you can hit the displacment. You might be passing right through it on
>> your
>> >> checks.
>> >> I don't remember having problems tracing to displacements myself, so I
>> find
>> >> this sort of odd. Another thing to consider are the collision options
>> for
>> >> displacements.
>> >>
>> >> On Tue, May 18, 2010 at 4:08 PM, James K  wrote:
>> >>
>> >> > With the new code it will collide only with thick brushes. With the
>> >> > old code it collided with both.
>> >> >
>> >> > On Tue, May 18, 2010 at 6:54 PM, Tobias Kammersgaard
>> >> >  wrote:
>> >> > > Does it collide with thin brushes?
>> >> > >
>> >> > > Den 19/05/2010 00.38 skrev "James K" :
>> >> > >
>> >> > > Still a no go with your code. Tried MASK_SOLID and
>> >> > > COLLISION_GROUP_NONE too, still not working.
>> >> > >
>> >> > > Blargh.
>> >> > >
>> >> > >
>> >> > > On Tue, May 18, 2010 at 12:33 AM, Ryan Sheffer > >
>> >> > wrote:
>> >> > >> Hmm, you could check ...
>> >> > > ___
>> >> > > To unsubscribe, edit your list preferences, or view the list
>> archives,
>> >> > please visit:
>> >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >> > >
>> >> > >
>> >> >
>> >> > ___
>> >> > To unsubscribe, edit your list preferences, or view the list archives,
>> >> > please visit:
>> >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> ~Ryan ( skidz )
>> >> ___
>> >> To unsubscribe, edit your list preferences, or view the list archives,
>> >> please visit:
>> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >>
>> >>
>> >
>> >
>> > --
>> > -Tony
>> > ___
>> > To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >
>> >
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

It's still not working, even with this new code. This is really really stupid.

James

On Wed, May 19, 2010 at 2:57 AM, Tony "omega" Sergi  wrote:
> It also doesn't help that you're only doing the trace when the random value
> is within the current limit.
> You need to do the check ALL the time, regardless of if it will actually
> spawn it or not.
> Displacements are a single plane, chances are you're repeatedly skipping the
> actual check 99% of the time.
> Your original code was correct except for the order. ie: new code:
>
>    trace_t trace;
>    UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
> COLLISION_GROUP_NPC, &trace);
>    if( trace.fraction < 1 || trace.DidHit() )
>    {
>        if ( RandomInt( 0, 100 ) <= r_RainSplashPercentage.GetInt() )
>            DispatchParticleEffect( "spash", trace.endpos,
> trace.m_pEnt->GetAbsAngles() , NULL );
>    }
>
> Also, you can verify it if you set r_RainSplashPercentage to 101 (because
> even if you set it to 100, it would never trace as it would HAVE to be below
> the value.)
> -Tony
>
> On Wed, May 19, 2010 at 2:59 PM, Ryan Sheffer  wrote:
>
>> Try shooting a trace right to the ground from the starting point and see if
>> you can hit the displacment. You might be passing right through it on your
>> checks.
>> I don't remember having problems tracing to displacements myself, so I find
>> this sort of odd. Another thing to consider are the collision options for
>> displacements.
>>
>> On Tue, May 18, 2010 at 4:08 PM, James K  wrote:
>>
>> > With the new code it will collide only with thick brushes. With the
>> > old code it collided with both.
>> >
>> > On Tue, May 18, 2010 at 6:54 PM, Tobias Kammersgaard
>> >  wrote:
>> > > Does it collide with thin brushes?
>> > >
>> > > Den 19/05/2010 00.38 skrev "James K" :
>> > >
>> > > Still a no go with your code. Tried MASK_SOLID and
>> > > COLLISION_GROUP_NONE too, still not working.
>> > >
>> > > Blargh.
>> > >
>> > >
>> > > On Tue, May 18, 2010 at 12:33 AM, Ryan Sheffer 
>> > wrote:
>> > >> Hmm, you could check ...
>> > > ___
>> > > To unsubscribe, edit your list preferences, or view the list archives,
>> > please visit:
>> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> > >
>> > >
>> >
>> > ___
>> > To unsubscribe, edit your list preferences, or view the list archives,
>> > please visit:
>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >
>> >
>>
>>
>> --
>> ~Ryan ( skidz )
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> --
> -Tony
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

With the new code it will collide only with thick brushes. With the
old code it collided with both.

On Tue, May 18, 2010 at 6:54 PM, Tobias Kammersgaard
 wrote:
> Does it collide with thin brushes?
>
> Den 19/05/2010 00.38 skrev "James K" :
>
> Still a no go with your code. Tried MASK_SOLID and
> COLLISION_GROUP_NONE too, still not working.
>
> Blargh.
>
>
> On Tue, May 18, 2010 at 12:33 AM, Ryan Sheffer  wrote:
>> Hmm, you could check ...
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

Still a no go with your code. Tried MASK_SOLID and
COLLISION_GROUP_NONE too, still not working.

Blargh.

On Tue, May 18, 2010 at 12:33 AM, Ryan Sheffer  wrote:
> Hmm, you could check if its in a solid.
>
> int contents = enginetrace->GetPointContents( position );
> if ( contents & CONTENTS_SOLID )
> return false;
>
> Also try other masks like MASK_SOLID and use COLLISION_GROUP_NONE.
>
> I imagine you are doing that trace per particle movement and that seems very
> expensive to me. I would probably do a trace to the ground on creation and
> get a z value and just have each particle have its own finishing z value.
> Checking against a vector per check instead of tracing, hull checking, etc
> is way better imo. I guess you want to make sure it can hit physical props
> as well, and there are ways of optimizing for that specifically. Anyway,
> good luck. :)
>
>
> On Mon, May 17, 2010 at 7:03 PM, James K  wrote:
>
>> It's still not creating splashes on displacements.
>>
>> The code for creating splashes is found around line 331 in
>> c_effects.cpp. Here's my modded code for it:
>> ---
>> // Possibly make a splash if we hit a water surface and it's in front
>> of the view.
>>     if ( m_Splashes.Count() < 99 )
>>      {
>>        if ( RandomInt( 0, 100 ) < r_RainSplashPercentage.GetInt() )
>>        {
>>           trace_t trace;
>>            UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_SOLID, NULL,
>> COLLISION_GROUP_PLAYER, &trace);
>>           if( trace.fraction < 1 )
>>           {
>>              DispatchParticleEffect( "rain_splash", trace.endpos,
>> trace.m_pEnt->GetAbsAngles() , NULL );
>>           }
>>        }
>>     }
>>
>>                 // Tell the framework it's time to remove the particle from
>> the list
>>                return false;
>>        }
>>
>>        // We still want this particle
>>        return true;
>> }
>> --
>>
>> It's completely ignoring displacements, however. If you visualize the
>> tracers you can see them going right through the displacements and
>> hitting the surface below them.
>>
>> I'm so frustrated!
>>
>> On Mon, May 17, 2010 at 10:46 AM, Ryan Sheffer 
>> wrote:
>> > Ignore Util_remove, it's specific to his code. The mask and collision
>> > group should work fine. If not, you need to post all your code.
>> >
>> > ~Ryan
>> >
>> > On May 16, 2010, at 12:58 PM, James K  wrote:
>> >
>> >> UTIL_Remove is a server thing, isn't it? The code doesn't work because
>> >> it says it's undefined.
>> >>
>> >> I'm more concerned with making the tracer collide with displacements
>> >> and other dynamic entities, because no matter what I do it won't
>> >> recognize they're there. The skybox collision isn't a major issue yet.
>> >>
>> >> James
>> >> On Sun, May 16, 2010 at 7:51 AM, Jonathan White
>> >>  wrote:
>> >>> Hi James,
>> >>>
>> >>> I am going to offer this solution since I don't think you have
>> >>> nailed down
>> >>> your problem to exactly what is going on. My guess is that the
>> >>> trace is
>> >>> hitting the rain entity itself. I say this because you have not
>> >>> added the
>> >>> rain entity a the "ignored entity" and have allowed the trace to hit
>> >>> ANYTHING.
>> >>>
>> >>> Try this code:
>> >>>
>> >>> UTIL_TraceLine( vOldPos, pParticle->m_Pos, MASK_SOLID, this,
>> >>> COLLISION_GROUP_PLAYER, &tr );
>> >>>
>> >>> if( tr.surface.flags & SURF_SKY )
>> >>> {
>> >>>        // Game Over, we hit the sky box, remove the mine from the
>> >>> world
>> >>>        UTIL_Remove(this);
>> >>>        return false;
>> >>> }
>> >>>
>> >>> Right before the collision group is "this" which if function call
>> >>> is called
>> >>> in the rain entity class will produce the desired results.
>> >>> Otherwise you
>> >>> might have to explicitly call on the rain particle entity
>> >>> (pParticle)? I am
>> >>> not sure of your setup at the moment or if you are even using
>> &

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

It's still not creating splashes on displacements.

The code for creating splashes is found around line 331 in
c_effects.cpp. Here's my modded code for it:
---
// Possibly make a splash if we hit a water surface and it's in front
of the view.
 if ( m_Splashes.Count() < 99 )
 {
if ( RandomInt( 0, 100 ) < r_RainSplashPercentage.GetInt() )
{
   trace_t trace;
   UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_SOLID, NULL,
COLLISION_GROUP_PLAYER, &trace);
   if( trace.fraction < 1 )
   {
  DispatchParticleEffect( "rain_splash", trace.endpos,
trace.m_pEnt->GetAbsAngles() , NULL );
   }
}
 }

// Tell the framework it's time to remove the particle from the 
list
return false;
}

// We still want this particle
return true;
}
--

It's completely ignoring displacements, however. If you visualize the
tracers you can see them going right through the displacements and
hitting the surface below them.

I'm so frustrated!

On Mon, May 17, 2010 at 10:46 AM, Ryan Sheffer  wrote:
> Ignore Util_remove, it's specific to his code. The mask and collision
> group should work fine. If not, you need to post all your code.
>
> ~Ryan
>
> On May 16, 2010, at 12:58 PM, James K  wrote:
>
>> UTIL_Remove is a server thing, isn't it? The code doesn't work because
>> it says it's undefined.
>>
>> I'm more concerned with making the tracer collide with displacements
>> and other dynamic entities, because no matter what I do it won't
>> recognize they're there. The skybox collision isn't a major issue yet.
>>
>> James
>> On Sun, May 16, 2010 at 7:51 AM, Jonathan White
>>  wrote:
>>> Hi James,
>>>
>>> I am going to offer this solution since I don't think you have
>>> nailed down
>>> your problem to exactly what is going on. My guess is that the
>>> trace is
>>> hitting the rain entity itself. I say this because you have not
>>> added the
>>> rain entity a the "ignored entity" and have allowed the trace to hit
>>> ANYTHING.
>>>
>>> Try this code:
>>>
>>> UTIL_TraceLine( vOldPos, pParticle->m_Pos, MASK_SOLID, this,
>>> COLLISION_GROUP_PLAYER, &tr );
>>>
>>> if( tr.surface.flags & SURF_SKY )
>>> {
>>>        // Game Over, we hit the sky box, remove the mine from the
>>> world
>>>        UTIL_Remove(this);
>>>        return false;
>>> }
>>>
>>> Right before the collision group is "this" which if function call
>>> is called
>>> in the rain entity class will produce the desired results.
>>> Otherwise you
>>> might have to explicitly call on the rain particle entity
>>> (pParticle)? I am
>>> not sure of your setup at the moment or if you are even using
>>> entities, just
>>> wanted to throw it out there.
>>>
>>> Thanks
>>> Killermonkey
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list
>>> archives, please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

UTIL_Remove is a server thing, isn't it? The code doesn't work because
it says it's undefined.

I'm more concerned with making the tracer collide with displacements
and other dynamic entities, because no matter what I do it won't
recognize they're there. The skybox collision isn't a major issue yet.

James
On Sun, May 16, 2010 at 7:51 AM, Jonathan White
 wrote:
> Hi James,
>
> I am going to offer this solution since I don't think you have nailed down
> your problem to exactly what is going on. My guess is that the trace is
> hitting the rain entity itself. I say this because you have not added the
> rain entity a the "ignored entity" and have allowed the trace to hit
> ANYTHING.
>
> Try this code:
>
> UTIL_TraceLine( vOldPos, pParticle->m_Pos, MASK_SOLID, this,
> COLLISION_GROUP_PLAYER, &tr );
>
> if( tr.surface.flags & SURF_SKY )
> {
>        // Game Over, we hit the sky box, remove the mine from the world
>        UTIL_Remove(this);
>        return false;
> }
>
> Right before the collision group is "this" which if function call is called
> in the rain entity class will produce the desired results. Otherwise you
> might have to explicitly call on the rain particle entity (pParticle)? I am
> not sure of your setup at the moment or if you are even using entities, just
> wanted to throw it out there.
>
> Thanks
> Killermonkey
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

Do you know by chance what the !picker traceline uses?

On Sat, May 15, 2010 at 8:44 PM, Tom Edwards  wrote:
> You can stop them from hitting the skybox by checking the surface you
> hit...look at the HL2 rocket for how to do that. It disappears if it
> hits the skybox.
>
> As for displacements, phys objects, etc. your choice of collision group
> is almost certainly to blame. I'd use whatever the !picker traceline uses.
>
> On 15/05/2010 11:10, James K wrote:
>> I'm trying to get rain splashes to show up when they collide with the
>> ground. In a way, I've succeed. I can get splashes. The problem is
>> they're almost everywhere but where I want them. They show up even on
>> the skybox, which I don't want. They won't show up on displacements,
>> glass, or physics props, however, which isn't good.
>> Here's the code for the tracer:
>> ---
>>          if ( RandomInt( 0, 100 )<  r_RainSplashPercentage.GetInt() )
>>          {
>>             trace_t trace;
>>             UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
>> COLLISION_GROUP_NPC,&trace);
>>             if( trace.fraction<  1 )
>>             {
>>                DispatchParticleEffect( "spash", trace.endpos,
>> trace.m_pEnt->GetAbsAngles() , NULL );
>>             }
>>          }
>>       }
>> --
>> I've tried making a new mask and collision group, both of which didn't
>> help at all.
>>
>> Anyone better at this than I am?
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives, 
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Getting a tracer to collide with displacements and glass - and not the skybox?

[James K]

I'm trying to get rain splashes to show up when they collide with the
ground. In a way, I've succeed. I can get splashes. The problem is
they're almost everywhere but where I want them. They show up even on
the skybox, which I don't want. They won't show up on displacements,
glass, or physics props, however, which isn't good.
Here's the code for the tracer:
---
if ( RandomInt( 0, 100 ) < r_RainSplashPercentage.GetInt() )
{
   trace_t trace;
   UTIL_TraceLine(vOldPos, pParticle->m_Pos, MASK_ALL, NULL,
COLLISION_GROUP_NPC, &trace);
   if( trace.fraction < 1 )
   {
  DispatchParticleEffect( "spash", trace.endpos,
trace.m_pEnt->GetAbsAngles() , NULL );
   }
}
 }
--
I've tried making a new mask and collision group, both of which didn't
help at all.

Anyone better at this than I am?

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Of hats, bonemerged models and things.

[James Gray]

Make it client side, and just parent it to an attachment. You can offset it
as needed for different hats by moving the origin for the hat models.

On Tue, Feb 2, 2010 at 1:30 PM, Joel R.  wrote:

> Create the hat clientside. Server only needs to send the hat id.
>
> On Tue, Feb 2, 2010 at 1:04 PM, Jed  wrote:
>
> > I've been pondering for a while how to better streamline the headgear
> > aspect of our player models and I've been considering something
> > similar to TF2 and the bone merge method.
> >
> > Currently all the helmets are compiled into the player model as a body
> > group and are set based on code logic in the DLLs. When the helmet has
> > to come off it sets the body group to the "null" helmet  and spawns a
> > client side helmet "gib" which falls to the ground and then vanishes
> > after a while. I think this is what Day of Defeat does but it's
> > getting a little cumbersome for us as we have a dozen (and more to
> > come) helmets and compiling them all into the player models AND making
> > "gib" versions takes ages. That and the code logic to select/spawn the
> > right one based on the map, year, theatre, etc. it's going to get
> > unmanageable soon.
> >
> > Logically the smartest thing I thought to do would be to make a helmet
> > entity that has a world model and bone merges to the head bone of the
> > player mode in the same way weapon w_model is bone merged with the
> > hand. However, I'm worried that adding an entity for the helmet is
> > going to add yet more stuff for the server to track and add more
> > network traffic.
> >
> > I understand the process - spawn a helmet entity, pre-cache and set
> > its model, parent it to the player entity, set it to follow it, set
> > bone merge and turn of the vphysics. When it needs to come off do the
> > reverse basically.
> >
> > Couple of things I wonder though
> >
> > - As this is purely cosmetic, couldn't this just be a client side
> > entity to relieve load on the server?
> > - Is it even possible to have a client side model entity that can be
> > bone merged with a player model?
> > - If I have to go with a server side entity what's the best way to
> > make it behave like a prop physics when it becomes detached without
> > adding network overhead for position and velocity updates?
> >
> > Searching the code I've not found any specific client side only model
> > entities apart from the gibs which use the temporary entity method.
> > Certainly nothing with bone merges or following.
> >
> > Any tips, insights, opinions, examples?
> >
> > - Jed
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


-- 
James Gray
Lead Programmer
InterWave Studios
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Hitbox Specific Actions

[James Martin]

Thank you so much Matt! That seemed to be the problem...

I was overlooking the fact that the melee was using MASK_SHOT_HULL for the
trace, which excludes CONTENTS_HITBOX.

I knew it was something stupid I was overlooking (as this has to have been a
very easy concept.)
Anyway, all is working perfectly fine now.

Sorry for my stupidity :p

On Sun, Feb 21, 2010 at 4:45 PM, Matt Hoffman
wrote:

> Is the trace hitting the hitgroups? Could it be colliding with a player
> bounding box or some other thing? Check the parameters of your trace?
>
> On Sun, Feb 21, 2010 at 1:43 PM, James Martin  wrote:
>
> > I'm just using the player models (dod) that came with the sdk. I've not
> > messed with modeling at all :-/
> >
> > In the model viewer, it shows each of the hitboxes in proper groups.
> > Hitbox 13 and 14 are neck and head, respectively. They are both in group
> 1.
> > (HITGROUP_HEAD)
> >
> > So, everything seems to be just fine outside of the code.
> >
> > Let me know if you have any more ideas, maybe there's something I
> > overlooked...
> >
> > On Sun, Feb 21, 2010 at 4:33 PM, Rodrigo 'r2d2rigo' Diaz <
> > r2d2r...@gmail.com
> > > wrote:
> >
> > > If you are using a custom model, maybe it has autogenerated hitboxes or
> > all
> > > of them are set as group 0. Check the VDC for more info:
> > > http://developer.valvesoftware.com/wiki/$hbox
> > >
> > > 2010/2/21 James Martin 
> > >
> > > > Yes, I've fully compiled both DLLs.
> > > >
> > > > As for the models, they show the different hitboxes, also I can grab
> > the
> > > > entity's CBaseAnimating and iterate through the hitboxes. So I know
> > they
> > > > are
> > > > there.
> > > >
> > > > The problem is that the enginetrace, is done via the engine (hence
> the
> > > > name.) So I have no way of knowing how it's checking for the
> hitboxes,
> > or
> > > > altering the code in question.
> > > > It really makes no sense to me why it returns the hitbox/hitgroup as
> 0.
> > > >
> > > > Anyway, thanks for the input.
> > > >
> > > > On Sun, Feb 21, 2010 at 4:18 PM, Rodrigo 'r2d2rigo' Diaz <
> > > > r2d2r...@gmail.com
> > > > > wrote:
> > > >
> > > > > Did you recompile both DLLs? Are you sure the model contains
> > > > > hitgroup-specific info, so they are properly identified?
> > > > >
> > > > > 2010/2/21 James Martin 
> > > > >
> > > > > > A friend asked me to help start a mod, and I ran into a problem
> > quite
> > > > > early
> > > > > > on.
> > > > > > The request was for specific damage amount on a headshot.
> > > > > >
> > > > > > This seemed like an easy goal, but has me stumped. What would be
> > the
> > > > > proper
> > > > > > way to detect a headshot? My first assumption was to check the
> > > "hitbox"
> > > > > or
> > > > > > "hitgroup" members from the CGameTrace. After searching the SDK,
> > this
> > > > > > seemed
> > > > > > to be the right method. CBasePlayer::TraceAttack checks the
> > hitgroup
> > > > > there
> > > > > > for scaling damage.
> > > > > > The problem is, this just simply does not work for me. I added a
> > > simple
> > > > > > console message to print the hitbox and hitgroup specified, and
> > they
> > > > > ALWAYS
> > > > > > show as 0. (Which explains why the different damage doesn't
> work.)
> > > > > >
> > > > > > I've not messed with modeling any however, loading the model in
> the
> > > > model
> > > > > > viewer, I can see the hitboxes are there...
> > > > > >
> > > > > > I'm starting to think there is something painfully obvious that
> I'm
> > > > > > overlooking here. If someone could please give me a hint as to
> what
> > > I'm
> > > > > > doing wrong, I'd greatly appreciate it.
> > > > > > ___
> > > > > > To unsubscribe, edit your list preferences, or view the list
> > > archives,
> > > > > > please visit:
> >

Re: [hlcoders] Hitbox Specific Actions

[James Martin]

I'm just using the player models (dod) that came with the sdk. I've not
messed with modeling at all :-/

In the model viewer, it shows each of the hitboxes in proper groups.
Hitbox 13 and 14 are neck and head, respectively. They are both in group 1.
(HITGROUP_HEAD)

So, everything seems to be just fine outside of the code.

Let me know if you have any more ideas, maybe there's something I
overlooked...

On Sun, Feb 21, 2010 at 4:33 PM, Rodrigo 'r2d2rigo' Diaz  wrote:

> If you are using a custom model, maybe it has autogenerated hitboxes or all
> of them are set as group 0. Check the VDC for more info:
> http://developer.valvesoftware.com/wiki/$hbox
>
> 2010/2/21 James Martin 
>
> > Yes, I've fully compiled both DLLs.
> >
> > As for the models, they show the different hitboxes, also I can grab the
> > entity's CBaseAnimating and iterate through the hitboxes. So I know they
> > are
> > there.
> >
> > The problem is that the enginetrace, is done via the engine (hence the
> > name.) So I have no way of knowing how it's checking for the hitboxes, or
> > altering the code in question.
> > It really makes no sense to me why it returns the hitbox/hitgroup as 0.
> >
> > Anyway, thanks for the input.
> >
> > On Sun, Feb 21, 2010 at 4:18 PM, Rodrigo 'r2d2rigo' Diaz <
> > r2d2r...@gmail.com
> > > wrote:
> >
> > > Did you recompile both DLLs? Are you sure the model contains
> > > hitgroup-specific info, so they are properly identified?
> > >
> > > 2010/2/21 James Martin 
> > >
> > > > A friend asked me to help start a mod, and I ran into a problem quite
> > > early
> > > > on.
> > > > The request was for specific damage amount on a headshot.
> > > >
> > > > This seemed like an easy goal, but has me stumped. What would be the
> > > proper
> > > > way to detect a headshot? My first assumption was to check the
> "hitbox"
> > > or
> > > > "hitgroup" members from the CGameTrace. After searching the SDK, this
> > > > seemed
> > > > to be the right method. CBasePlayer::TraceAttack checks the hitgroup
> > > there
> > > > for scaling damage.
> > > > The problem is, this just simply does not work for me. I added a
> simple
> > > > console message to print the hitbox and hitgroup specified, and they
> > > ALWAYS
> > > > show as 0. (Which explains why the different damage doesn't work.)
> > > >
> > > > I've not messed with modeling any however, loading the model in the
> > model
> > > > viewer, I can see the hitboxes are there...
> > > >
> > > > I'm starting to think there is something painfully obvious that I'm
> > > > overlooking here. If someone could please give me a hint as to what
> I'm
> > > > doing wrong, I'd greatly appreciate it.
> > > > ___
> > > > To unsubscribe, edit your list preferences, or view the list
> archives,
> > > > please visit:
> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >
> > > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Hitbox Specific Actions

[James Martin]

Yes, I've fully compiled both DLLs.

As for the models, they show the different hitboxes, also I can grab the
entity's CBaseAnimating and iterate through the hitboxes. So I know they are
there.

The problem is that the enginetrace, is done via the engine (hence the
name.) So I have no way of knowing how it's checking for the hitboxes, or
altering the code in question.
It really makes no sense to me why it returns the hitbox/hitgroup as 0.

Anyway, thanks for the input.

On Sun, Feb 21, 2010 at 4:18 PM, Rodrigo 'r2d2rigo' Diaz  wrote:

> Did you recompile both DLLs? Are you sure the model contains
> hitgroup-specific info, so they are properly identified?
>
> 2010/2/21 James Martin 
>
> > A friend asked me to help start a mod, and I ran into a problem quite
> early
> > on.
> > The request was for specific damage amount on a headshot.
> >
> > This seemed like an easy goal, but has me stumped. What would be the
> proper
> > way to detect a headshot? My first assumption was to check the "hitbox"
> or
> > "hitgroup" members from the CGameTrace. After searching the SDK, this
> > seemed
> > to be the right method. CBasePlayer::TraceAttack checks the hitgroup
> there
> > for scaling damage.
> > The problem is, this just simply does not work for me. I added a simple
> > console message to print the hitbox and hitgroup specified, and they
> ALWAYS
> > show as 0. (Which explains why the different damage doesn't work.)
> >
> > I've not messed with modeling any however, loading the model in the model
> > viewer, I can see the hitboxes are there...
> >
> > I'm starting to think there is something painfully obvious that I'm
> > overlooking here. If someone could please give me a hint as to what I'm
> > doing wrong, I'd greatly appreciate it.
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Hitbox Specific Actions

[James Martin]

A friend asked me to help start a mod, and I ran into a problem quite early
on.
The request was for specific damage amount on a headshot.

This seemed like an easy goal, but has me stumped. What would be the proper
way to detect a headshot? My first assumption was to check the "hitbox" or
"hitgroup" members from the CGameTrace. After searching the SDK, this seemed
to be the right method. CBasePlayer::TraceAttack checks the hitgroup there
for scaling damage.
The problem is, this just simply does not work for me. I added a simple
console message to print the hitbox and hitgroup specified, and they ALWAYS
show as 0. (Which explains why the different damage doesn't work.)

I've not messed with modeling any however, loading the model in the model
viewer, I can see the hitboxes are there...

I'm starting to think there is something painfully obvious that I'm
overlooking here. If someone could please give me a hint as to what I'm
doing wrong, I'd greatly appreciate it.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Replacing rain "particles" with updated real particles?

[James K]

All I really need to do is create a particle system with each tracer the
rain makes and parent it to that tracer, i just can't figure out how to do
that...

On Sun, Nov 22, 2009 at 5:40 PM, Michael Corsaro  wrote:

> Also, keep in mind that L4D2 uses a newer version of the particle systems.
> I'm not sure if Valve even plans on updating the old systems for Tf2 or for
> the SDK.
>
> On Sun, Nov 22, 2009 at 3:34 PM, Matt Hoffman
> wrote:
>
> > Tom: Wouldn't particle systems overflow the edges of the brush?
> >
> > On Sun, Nov 22, 2009 at 12:04 PM, Jorge Rodriguez 
> > wrote:
> >
> > > I haven't seen how they actually do it but I doubt they would use
> > anything
> > > but particles. Either way it would be very easy for you to do it with
> > > particles.
> > >
> > > --
> > > Jorge "Vino" Rodriguez
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Replacing rain "particles" with updated real particles?

[James K]

I wrote that. That just adds the splashes, the raindrops are still just
textured tracers, which I want to be particles.

On Sun, Nov 22, 2009 at 1:02 PM, Tobias Kammersgaard <
tobias.kammersga...@gmail.com> wrote:

> Someone posted some code for this on the VDC, but the effects are far from
> L4D(2)'s.
>
> http://developer.valvesoftware.com/wiki/Rain_splashes
>
> <http://developer.valvesoftware.com/wiki/Rain_splashes>It also gives
> rather
> bad performance in my experience.
>
> /ScarT
>
>
> 2009/11/22 James K 
>
> > func_precipitation rain seems to create a tracer with a texture slapped
> on
> > it and tells it to go downward. This would've been okay about 7 years
> ago,
> > but it looks really bad today compared to L4D/L4D2's rain. Is there any
> way
> > I can create a particle effect like L4D and L4D2 use and attach it to
> that
> > tracer and use that instead of a material? I'm unsure of how to do that.
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Replacing rain "particles" with updated real particles?

[James K]

func_precipitation rain seems to create a tracer with a texture slapped on
it and tells it to go downward. This would've been okay about 7 years ago,
but it looks really bad today compared to L4D/L4D2's rain. Is there any way
I can create a particle effect like L4D and L4D2 use and attach it to that
tracer and use that instead of a material? I'm unsure of how to do that.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Physcannon drops objects weird in new SDK

[James Murray]

No No No here is the fix for the Physcannon physics issues!

http://forums.steampowered.com/forums/showpost.php?p=10788350&postcount=47

On Sun, Aug 30, 2009 at 9:41 PM, Ryan Sheffer  wrote:

> So I did a bit of looking through the code and I found out it screws up in
> TransformAnglesToPlayerSpace. Not sure exactly why this isn't working, but
> setting SetIgnorePitch to true deals with the issue, but you loose that
> somewhat neat rotation the object is given when you move the object above
> your head. Since the team I am working in prefers this since it makes it
> easier to stack objects, I probably wont get around to actually tracking
> down the problem.
>
> If anyone is interested, all you need to do is:
>
> In function CWeaponPhysCannon::AttachObject( CBaseEntity *pObject, const
> Vector &vPosition )
> change this to true like so
> m_grabController.SetIgnorePitch( true );
>
> and in function CWeaponPhysCannon::ManagePredictedObject( void )
> change this to true like so
> m_grabController.SetIgnorePitch( true );
>
> Its a great quick fix until somebody hunts down the problem, and I
> personally prefer it this way.
>
> Cheers.
>
> On Sun, Aug 30, 2009 at 6:39 PM, Ryan Sheffer  wrote:
>
> > I just noticed my physgun is also causing this problem, but my normal
> > pickup isn't. The only difference between the two is the normal pickup
> > doesnt alter the rotation of the object depending on how you have it in
> the
> > air. What it looks like to me is the changes in rotation of the object
> while
> > being held by the physcannon are only being made on the client, and not
> the
> > server. So the fix would be to ensure the server object is making these
> > updates to the objects rotation as well, or better yet, remove the
> rotation
> > crap from the client all together so there is no confliction.
> >
> >
> > On Sun, Aug 30, 2009 at 3:57 PM, Bob Somers 
> wrote:
> >
> >> Cool. Your fellow list mates would be very thankful if you kept them
> >> updated. :)
> >>
> >> --Bob
> >>
> >>
> >>
> >> On Sun, Aug 30, 2009 at 6:36 AM, Denis Craig
> >> wrote:
> >> >
> >> > When you move the prop with the physcannon, it updates the angles on
> the
> >> clientside as normal but takes a very long time to update on the server,
> so
> >> obviously when you drop the prop it'll snap to the server's angles
> instead.
> >> >
> >> > Working on a fix at the moment, I think it's happening somewhere in
> the
> >> UpdateEntity() in the CGrabController class (in the
> weapon_physcannon.cpp
> >> file).
> >> >
> >> >> From: magicbob...@gmail.com
> >> >> Date: Sun, 30 Aug 2009 02:48:19 -0700
> >> >> To: hlcoders@list.valvesoftware.com
> >> >> Subject: Re: [hlcoders] Physcannon drops objects weird in new SDK
> >> >>
> >> >> Did this ever get resolved? If so I'd love to know the solution, I'm
> >> >> working through this bug myself.
> >> >>
> >> >> --Bob
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Jul 29, 2009 at 2:49 PM, James Murray
> >> wrote:
> >> >> > What file should I look in?
> >> >> >
> >> >> > On Mon, Jul 27, 2009 at 2:43 PM, Ryan Sheffer  >
> >> wrote:
> >> >> >
> >> >> >> The movement prediction is screwed up, but I don't remember how I
> >> fixed it.
> >> >> >> Check that the client side movement is updating correctly and that
> >> it isn't
> >> >> >> failing. It looks like the server isn't updating the objects
> >> rotation, so
> >> >> >> when you drop the object it notices the deviance with the server
> and
> >> snaps
> >> >> >> it back.
> >> >> >>
> >> >> >> On Mon, Jul 27, 2009 at 6:45 AM, James Murray <
> james1...@gmail.com>
> >> wrote:
> >> >> >>
> >> >> >> > This is kinda hard to explain but here it goes, In the new
> Orange
> >> Box SDK
> >> >> >> > if
> >> >> >> > you pick up any object with the physcannon and drop it the
> object
> >> will
> >> >> >> not
> >> >> >> > stay th

Re: [hlcoders] Interpolation of projectiles

[James Gray]

One possibility is to override ShouldDraw() and enforce the  
appropriate conditions.



On Aug 30, 2009, at 9:05 AM, Tom Edwards   
wrote:

> I want to bring up the issue of projectiles hanging in the air for a
> moment after spawning again. The last time it was discussed the  
> solution
> given was to predict:
>
> http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg21121.html
>
> This is a bad idea though, because it causes the projectile to
> materialise several feet in front of the firer on observers' computers
> (contrary to what Tony said at the time, TF2 does NOT predict
> rockets/grenades).
>
> The problem is that the projectile is spawned as soon as the client
> receives it, irrespective of interpolation, and then (correctly) does
> not start to move until interp catches up. You can change the length  
> of
> the delay by increasing the interp period; decreasing host_timescale
> makes spotting the difference easier.
>
> I've run tests and discovered that /all/ of Valve's games are affected
> by this issue, including TF2. I've not compiled the SDK template game
> but I expect it also suffers.
>
> The solution is clear: prevent the projectile's clientside
> representation from spawning until the interpolated world is ready.
> Anyone know how to do that?
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Velocity Clamp

[James Murray]

Yeah just use WinMerge with the copy you already have and the copy I gave
you.

On Thu, Jul 30, 2009 at 7:29 AM, Harry Pidcock  wrote:

> WinMerge?? SVN Diff?
>
> --
> From: "Harry Jeffery" 
> Sent: Thursday, July 30, 2009 9:47 PM
> To: ; "Discussion of Half-Life Programming"
> 
> Subject: Re: [hlcoders] Velocity Clamp
>
> > Actually do you know which bits are modified? I'm using scratch SDK
> > and I dont really want to go through the whole of both files looking
> > for a subtle difference.
> >
> > 2009/7/29 Harry Jeffery :
> >> Cheers, I'm sure they'll end up on the VDC wiki too.
> >>
> >> 2009/7/29  :
> >>>
> >>> Here are the Modified Files.
> >>>
> >>> http://www.mediafire.com/file/0j55azewemm/hl2_player.cpp
> >>>
> >>> http://www.mediafire.com/file/nm3ynwiwin1/gamemovement.cpp
> >>>
> >>>
> >>>
> >>> -- Saul Rennison wrote :
> >>> You don't mind sending me the files too, do you? I'll add it to VDC :)
> >>> Even
> >>> better, upload them somewhere and paste the links on the mailing list
> >>> itself.
> >>>
> >>> Thanks,
> >>> - Saul.
> >>>
> >>>
> >>> 2009/7/29 James Murray 
> >>>
> >>>> I have fixed that in my mod and I will email you the fix when I get
> off
> >>>> of
> >>>> work :) only two files to edit
> >>>>
> >>>> On Wed, Jul 29, 2009 at 6:55 AM, Harry Jeffery <
> >>>> harry101jeff...@goog...> wrote:
> >>>>
> >>>> > I'm modifying the orangebox engine from the MP template.
> >>>> >
> >>>> > I am trying to re-implement bunnyhopping as a viable way of moving.
> I
> >>>> > believe I have tracked the problem down to
> CGameMovement::WalkMove(),
> >>>> > when ever the player touches the ground the players velocity is
> >>>> > instantly clamped to normal movement speed thus making bunnyhopping
> >>>> > impossible. After looking through the function I am having some
> >>>> > difficulty finding where the velocity gets clamped.
> >>>> >
> >>>> > Note: I have tried tweaking sv_maxspeed and sv_maxvelocity to no
> >>>> > effect.
> >>>> >
> >>>> > ___
> >>>> > To unsubscribe, edit your list preferences, or view the list
> >>>> > archives,
> >>>> > please visit:
> >>>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>> >
> >>>> >
> >>>> ___
> >>>> To unsubscribe, edit your list preferences, or view the list archives,
> >>>> please visit:
> >>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>>
> >>>>
> >>> ___
> >>> To unsubscribe, edit your list preferences, or view the list archives,
> >>> please visit:
> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>
> >>>
> >>> --
> >>> This message was sent on behalf of james1...@gmail.com at
> >>> openSubscriber.com
> >>>
> http://www.opensubscriber.com/message/hlcoders@list.valvesoftware.com/12621219.html
> >>>
> >>> ___
> >>> To unsubscribe, edit your list preferences, or view the list archives,
> >>> please visit:
> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>
> >>>
> >>
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
>
>
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.392 / Virus Database: 270.13.35/2271 - Release Date:
> 07/29/09
> > 18:07:00
> >
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Physcannon drops objects weird in new SDK

[James Murray]

What file should I look in?

On Mon, Jul 27, 2009 at 2:43 PM, Ryan Sheffer  wrote:

> The movement prediction is screwed up, but I don't remember how I fixed it.
> Check that the client side movement is updating correctly and that it isn't
> failing. It looks like the server isn't updating the objects rotation, so
> when you drop the object it notices the deviance with the server and snaps
> it back.
>
> On Mon, Jul 27, 2009 at 6:45 AM, James Murray  wrote:
>
> > This is kinda hard to explain but here it goes, In the new Orange Box SDK
> > if
> > you pick up any object with the physcannon and drop it the object will
> not
> > stay the way it was when you were holding it instead it will almost
> rotate
> > to the position it was when you picked it up, Here is a video showing the
> > problem
> >
> > http://www.youtube.com/watch?v=jTvTWNR-DuU
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
>
> --
> ~Ryan ( skidz )
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Velocity Clamp

[James Murray]

I have fixed that in my mod and I will email you the fix when I get off of
work :) only two files to edit

On Wed, Jul 29, 2009 at 6:55 AM, Harry Jeffery <
harry101jeff...@googlemail.com> wrote:

> I'm modifying the orangebox engine from the MP template.
>
> I am trying to re-implement bunnyhopping as a viable way of moving. I
> believe I have tracked the problem down to CGameMovement::WalkMove(),
> when ever the player touches the ground the players velocity is
> instantly clamped to normal movement speed thus making bunnyhopping
> impossible. After looking through the function I am having some
> difficulty finding where the velocity gets clamped.
>
> Note: I have tried tweaking sv_maxspeed and sv_maxvelocity to no effect.
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Error with movement animations in new SDK (A FIX)

[James Murray]

Can you please find out? I have been trying to fix this for a long time now

On Sun, Jul 26, 2009 at 9:56 AM, Daniel Rapp  wrote:

> Did you mean in hl2mp_player_shared.cpp for this?  And what function was
> it?
>
> I noticed this issue as well and also upper body movement looking up makes
> the player look down.  I also noticed a problem with crouch walk with a
> weapon where the root node is pulling the player back making the right leg
> ik rule stick but not the left.  Looks really funny.  I don't quite
> understand how the animstate works, so I had no idea what to do to fix it.
> I was looking at the blends in the qc's thinking the issue was there, never
> even occured to me it was code related... Thanks for narrowing it down, I
> would have never found it!
>
>
> - Original Message -
> From: "Jonathan White" 
> To: 
> Sent: Saturday, July 25, 2009 11:15 AM
> Subject: [hlcoders] Error with movement animations in new SDK (A FIX)
>
>
> > When we merged our code to the new Orangebox code in the sdk update a
> > couple
> > of months ago we immediately noticed that the leg movements of the
> players
> > looked as if they were skating on ice. I instantly trolled through the
> new
> > hl2mp_playeranimstate code that came with the SDK and came up empty.
> >
> > Today I had renewed interest to fix this problem and opened up HLMV and
> > noticed that the leg movements looked very different then what is seen
> > ingame. A closer examination revealed that the legs were moving in the
> > OPPOSITE direction then the body in game!
> >
> > So, if you are experiencing these problems as well, the very simple fix
> is
> > to edit this one line in hl2mp_playeranimstate.cpp
> >
> > Line 573, change it to be: GetBasePlayer()->SetPoseParameter( pStudioHdr,
> > m_PoseParameterData.m_iMoveY, flYaw );
> >
> > Tony had inverted the yaw as referenced in his comment right above, but
> > that
> > doesn't work with the sdk animations, apparently.
> >
> > Jonathan White
> > GoldenEye: Source
> >
> >
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Physcannon drops objects weird in new SDK

[James Murray]

This is kinda hard to explain but here it goes, In the new Orange Box SDK if
you pick up any object with the physcannon and drop it the object will not
stay the way it was when you were holding it instead it will almost rotate
to the position it was when you picked it up, Here is a video showing the
problem

http://www.youtube.com/watch?v=jTvTWNR-DuU
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Physcannon drops objects weird in new SDK

[James Murray]

This is kinda hard to explain but here it goes, In the new SDK if you pick
up any object with the physcannon and drop it the object will not stay the
way it was when you were holding it instead it will almost rotate to the
position it was when you picked it up, Here is a video showing the problem

http://www.youtube.com/watch?v=jTvTWNR-DuU
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Funky 3D view angles in Hammer, Model Viewer, and Model Browser.

[James K]

I'm sure a lot of people have noticed this. Whenever I first start hammer
and load a map the 3D view is all screwed up and has a very odd camera angle
that doesn't go away without hitting CTRL+Z about 6 times. This happens
in pretty much anything with a 3D view in the SDK. What's the deal? Is
anybody working on a fix?
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK Beta Concluded

[James K]

I don't think he hates non-official maps, i think he hates the shitty
5-second remakes idiots make.

James

On Sat, Jun 27, 2009 at 5:16 PM, Nick  wrote:

> On Mon, Jun 15, 2009 at 4:09 PM, botman wrote:
> > On 6/15/2009 4:02 PM, Matt Hoffman wrote:
> >> I for one am hating the official map release.
> >>
> >> While I have a project that I would have needed the map sources for (and
> not
> >> recompiles), I think we are going to see alot of 2FORT_PRO_FIXED and
> >> CP_GRAVELPIT_PRO_FIXED_FIXED_V2. I for one, do not want these.
> >>
> >> However, I guess there is hope as I haven't seen too many of those, and
> >> decompiling was already possible.
> >>
> >> When you say the "model sources' are coming soon, how soon is soon?
> Because
> >> I'm currently fixing all of the models so that they can recompile
> (Fixing
> >> flexes and the such), and I'm wondering if your going to: A. Include
> these
> >> with your model sources, and B: Do it in a timely manner?
> >
> > Am I the only one that finds it ironic that you hate that the map
> > sources are being released because people will "fix" them, but in the
> > same email ask when the model sources will get releases so you can "fix"
> > them?  :)
> >
> > --
> > Jeffrey "botman" Broome
> >
>
>
> I agree 110% with "botman".
>
> Matt Hoffman, you hate on mappers, because you don't like non-official
> maps FORGET YOU, GO PLAY OFFICIAL MAPS. Then you in the very same
> post say you want to fix models. You just hate freedom, as long as it
> isn't your freedom.
>
> All maps, models and tools should be open and free.
>
>
>
>
>
>
>
>
>
>
>
>
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Sharing a depot in perforce

[James Gray]

Git? If you go that route, I would say Mercurial is much better.


On Jun 25, 2009, at 11:23 AM, Heimo Stieg   
wrote:

> for coding projects i prefer git. ( okay the first checkout takes a
> while but after that  )
>
> Tony Sergi schrieb:
>> Perforce actually is a lot better, but because I don't wanna pay  
>> for it, I wouldn't use it for my personal team projects.
>> It's also got a much higher learning curve.
>>
>> So tbh, svn is best for small projects, p4 is way better for  
>> huge ones, especially ones with multiple sub projects.
>>
>>
>>
>> -Tony
>>
>> -Original Message-
>> From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders- 
>> boun...@list.valvesoftware.com] On Behalf Of Garry Newman
>> Sent: June-26-09 12:38 AM
>> To: Discussion of Half-Life Programming
>> Subject: Re: [hlcoders] Sharing a depot in perforce
>>
>> Slightly off topic, but why do people use Perforce over SVN  
>> (besides 'cuz Valve does')?
>> garry
>>
>> On Thu, Jun 25, 2009 at 4:25 PM, botman   
>> wrote:
>>
>>
>>> Ben Tucker wrote:
>>>
 im having some perforce troubles I have two computers on the
 same

>>> network, and both have perforce installed. I also have them  
>>> sharing a
>>> netfolder ( a hard drive shared on the network ). I cant install
>>> perforce server on the netfolder because it isnt actually a  
>>> server. Id
>>> like to store a perforce depot on there that both the computers  
>>> can access and use.
>>>
 I have attempted this by defining a depot on both of the comps. I
 did

>>> this with MSDOS:
>>>
 p4 depot lido
 and then changed the map: field to the netfolder's path and where I
 had

>>> the depot folder. This half worked, as they both could put files up
>>> there and do things with them. however, they could not detect the
>>> other computers files, so they could not collaborate.
>>>
 anyone know how to fix this so they can collaborate on the same  
 files?


>>> You shouldn't be "sharing" files anywhere.  You install Perforce on
>>> one machine and run it as the server...
>>>
>>>
>>> http://www.perforce.com/perforce/doc.082/manuals/p4sag/01_install.html
>>> #1049719
>>>
>>> You install Perforce on the other machine (the client) and run it  
>>> as a
>>> client.
>>>
>>> The server creates a depot using "p4 depot SomeDepotName"...
>>>
>>>
>>> http://www.perforce.com/perforce/doc.082/manuals/p4sag/03_superuser.ht
>>> ml#1044923
>>>
>>> ...and the client(s) access those files by creating a ClientSpec (or
>>> Workspace) that contains that depot.
>>>
>>> The client can then add new files to the depot or sync to  
>>> revisions of
>>> files in the depot.  The P4 server keeps track of which version of
>>> each file a client has.  At no point should you "share" a file  
>>> between
>>> the server and client by putting on a shared network resource where
>>> either machine can modify that file.
>>>
>>> --
>>> Jeffrey "botman" Broome
>>>
>>>
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list  
>>> archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK Beta Concluded

[James Keith]

That's valve sdk tools for ya ;)

James



On Jun 17, 2009, at 12:21 AM, Matt Hoffman  
 wrote:

> Well the VGUI is fixed, but it has problems. :(
>
> Sometimes when I open it I can't click on anything. I can  
> occasionally drag
> the model or something around (Becomes a thumbnailed box with  
> nothing in
> it), but no results. The only thing I can do is close the model  
> browser. If
> I open/close it several times (5/6) it occasionally will 'respond'  
> again,
> but usually the only fix is to restart hammer.
>
> On Tue, Jun 16, 2009 at 4:47 PM, Matt Hoffman
> wrote:
>
>> Thanks Mike!
>>
>>
>> On Tue, Jun 16, 2009 at 4:25 PM, Mike Durand > >wrote:
>>
>>> Hi All-
>>>
>>> The Hammer crash fix is now out. The root cause of the crash was a  
>>> missing
>>> resource file that Hammer relies on and that is included in the  
>>> same game
>>> cache file as the TF2 binaries. So you'll need to run TF2 once in  
>>> order to
>>> pick up the updated game cache. After that you should be able to  
>>> use the
>>> VGUI model browser again.
>>>
>>> Please note that this only fixes people mapping for TF. People who  
>>> are
>>> mapping Portal and Ep2 will need a similar update that will be  
>>> coming in the
>>> next couple of days.
>>>
>>> Again, sorry for the inconvenience and please let me know if you  
>>> see more
>>> issues.
>>>
>>> -Mike
>>>
>>>
>>> -Original Message-
>>> From: hlcoders-boun...@list.valvesoftware.com [mailto:
>>> hlcoders-boun...@list.valvesoftware.com] On Behalf Of Mike Durand
>>> Sent: Tuesday, June 16, 2009 11:04 AM
>>> To: Discussion of Half-Life Programming
>>> Subject: Re: [hlcoders] Source SDK Beta Concluded
>>>
>>> I'm working on a fix right now. In the mean time please uncheck  
>>> the "Use
>>> VGUI Model Browser" checkbox in the Hammer General options.
>>>
>>> Sorry for the inconvenience.
>>>
>>> -Mike
>>>
>>> -Original Message-
>>> From: hlcoders-boun...@list.valvesoftware.com [mailto:
>>> hlcoders-boun...@list.valvesoftware.com] On Behalf Of Matt Hoffman
>>> Sent: Tuesday, June 16, 2009 8:25 AM
>>> To: Discussion of Half-Life Programming
>>> Subject: Re: [hlcoders] Source SDK Beta Concluded
>>>
>>> Will our VGUI model browser be fixed?
>>>
>>> On Mon, Jun 15, 2009 at 11:59 PM, Tony Sergi  
>>> >>> wrote:
>>>
>>>> When it comes to the source code.. No, I haven't submitted any of  
>>>> my
>>> fixes
>>>> yet. I haven't had time to finish that off.
>>>>
>>>>
>>>> -Tony
>>>>
>>>> -Original Message-
>>>> From: hlcoders-boun...@list.valvesoftware.com [mailto:
>>>> hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joel R.
>>>> Sent: June-16-09 6:41 AM
>>>> To: Discussion of Half-Life Programming
>>>> Subject: Re: [hlcoders] Source SDK Beta Concluded
>>>>
>>>> Is there a changelog of changes to the SDK? I'm sure something was
>>> changed?
>>>>
>>>> On Mon, Jun 15, 2009 at 4:31 PM, Matt Hoffman
>>>> wrote:
>>>>
>>>>>>> Am I the only one that finds it ironic that you hate that the  
>>>>>>> map
>>>>>>> sources are being released because people will "fix" them, but  
>>>>>>> in
>>>>>>> the same email ask when the model sources will get releases so  
>>>>>>> you
>>> can
>>>> "fix"
>>>>>>> them?  :)
>>>>>
>>>>> There is a difference between "fixing" the maps
>>>>> (arena_2fort_night_fixed_pro_b3) and my fixing of the  
>>>>> characters. As
>>>>> it stands, the scout has been fixed. This fixing is not editing  
>>>>> the
>>>>> model reference, It's re-compiling the characters with facial  
>>>>> flexes
>>>>> so that I can do custom animations, *cough* machinima *cough* etc.
>>>>>
>>>>> The price I pay to not make 2bit machinima.
>>>>>
>>>>> On Mon, Jun 15, 2009 at 2:09 PM, Mike Durand <
>>> mik...@valvesoft

Re: [hlcoders] Hint to new feature?

[James Gray]

Steam itself has been considered Steam3 for quite some time now, a  
year or maybe two, but the distinction here is with the user  
authentication protocol, which has been slowly evolving in use. It was  
first noticeable when SteamCommunity came out, where you can see the  
64 bit representation of your Steam ID, and the advent of community  
groups, which also have Steam IDs. This is my understanding, anyways.

As was mentioned before, the Linux binaries are most likely just for  
the dedicated server.

On Jun 13, 2009, at 11:07 AM, Harry Jeffery  wrote:

> Well I still live in hope for people like myself who prefer ubuntu to
> windows getting an official steam client port.
>
> 2009/6/13 Saul Rennison :
>> Steam API .so's are required for Steam authentication on players, not
>> necassarily an actual Steam Client GUI.
>>
>> --
>> Thanks,
>> - Saul
>>
>> On 13 Jun 2009, at 12:49, Harry Jeffery
>>  wrote:
>>
>>> Steam3 is in development afaik. Considering some .so files that were
>>> in the l4d demo for a short period of time it's safe to assume  
>>> that it
>>> will support linux. <3
>>>
>>> 2009/6/13 Saul Rennison :
 Steam3 doesn't that already exist? I swear I've seen Steam3
 referenced
 in L4D debug messages :/

 --
 Thanks,
 - Saul

 On 13 Jun 2009, at 11:39, Harry Jeffery
  wrote:

> Probably for steamworks mods only (insurgency, zp:s, etc.)
>
> I look forward to steam3 and whatever new features and
> compatibilities
> it has to offer.
>
> 2009/6/13 Yaakov Smith :
>> From SDK Beta Gameinfo.txt (Scratch mod):
>>
>>
>>
>> "GameInfo"
>>
>> {
>>
>>// This is what shows up in the 'Third Party  
>> Games'
>> area of
>> the Steam games list.
>>
>>
>>
>> Is this a hint to new organisational features for steam?
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

 ___
 To unsubscribe, edit your list preferences, or view the list
 archives, please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders


>>>
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list
>>> archives, please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Why did VALVe remove almost everything we got in thenew SDK beta update?

[James K]

Aww, another update and still no normal2ssbump :(

James

On Fri, Jun 12, 2009 at 7:08 PM, Jonas 'Sortie' Termansen  wrote:

> Indeed, and all Europeans have to pay the same price in EUR too.
>
> - Original Message -
> From: "Yatin Vadhia" 
> To: "Discussion of Half-Life Programming"  >
> Sent: Saturday, June 13, 2009 1:03 AM
> Subject: Re: [hlcoders] Why did VALVe remove almost everything we got in
> thenew SDK beta update?
>
>
> > Or  '99.99 in the UK due to the new rate of VAT applicable for non
> > physical products from 1st June.
> >
> > On 12 Jun 2009, at 23:56, "Adam \"amckern\" McKern"
> >  wrote:
> >
> >> :) I agree Jed - WTF's with 3x the price for us here?
> >>
> >> 
> >> Owner Nigredo Studios http://www.nigredostudios.com
> >>
> >> --- On Sat, 13/6/09, Jed  wrote:
> >>
> >> From: Jed 
> >> Subject: Re: [hlcoders] Why did VALVe remove almost everything we
> >> got in the new SDK beta update?
> >> To: "Discussion of Half-Life Programming"
> >>  >> >
> >> Received: Saturday, 13 June, 2009, 8:25 AM
> >>
> >>> What's the deal VALVe? Don't want us to have tools that should be
> >>> publicly available?
> >>
> >> No. Now you have to buy them as DLC via Steam for the low low price of
> >> $59.99 (or $129.99 if you live in Australia).
> >>
> >> :D
> >>
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list
> >> archives, please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >>
> >>
> >>
> >>  Need a Holiday? Win a $10,000 Holiday of your choice. Enter
> >> now.http://us.lrd.yahoo.com/
> >> _ylc=
> >>
> X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg-
> >> -/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/
> >> creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other
> >> %26p2=au%26p3=mailtagline
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list
> >> archives, please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Why did VALVe remove almost everything we got in the new SDK beta update?

[James K]

Thanks so much, i was afraid you guys were getting all sneaky :)

James

On Fri, Jun 12, 2009 at 6:54 PM, Mike Durand wrote:

> The removal of these tools was not intentional and I'm looking into it now.
>
> Thanks for your patience.
>
> -Mike Durand,
>  Valve
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com [mailto:
> hlcoders-boun...@list.valvesoftware.com] On Behalf Of James K
> Sent: Friday, June 12, 2009 2:02 PM
> To: Discussion of Half-Life Programming
> Subject: [hlcoders] Why did VALVe remove almost everything we got in the
> new SDK beta update?
>
> About 2 hours ago we got an update to the SDK beta that included new
> programs like normal2ssbump.exe and a few others, but then a patch released
> minutes after removed that and almost 90% of the stuff in my orangebox bin
> folder. What's the deal VALVe? Don't want us to have tools that should be
> publicly available?
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Why did VALVe remove almost everything we got in the new SDK beta update?

[James K]

About 2 hours ago we got an update to the SDK beta that included new
programs like normal2ssbump.exe and a few others, but then a patch released
minutes after removed that and almost 90% of the stuff in my orangebox bin
folder. What's the deal VALVe? Don't want us to have tools that should be
publicly available?
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source SDK Update?

[James K]

- removed almost everything

James Keith

On Fri, Jun 12, 2009 at 3:32 PM, Jonas 'Sortie' Termansen  wrote:

> My Steam Client has just downloaded a small Source SDK Update, but I cannot
> find any mentions about such an update anywhere. I'd like a changelist :D
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Depth buffer problem

[James Gray]

Yeah, I have no problems with running studiocompile. Out of curiosity, what
version of Windows are you all running this on?

On Tue, May 26, 2009 at 2:13 PM, BEaST  wrote:

> Really? I have everything works fine! Maybe problem in erroneous bat-files?
> The solution, which helped me:
>
> 1) Copy from your ...\sourcesdk\bin\orangebox\bin\ directory into
> ...\src\materialsystem\stdshaders\ next files - shadercompile.exe and
> shadercompile_dll.dll
>
> 2) Change buildshaders.bat : following lines
>
> echo %SDKBINDIR%\shadercompile.exe >> filestocopy.txt
> echo %SDKBINDIR%\shadercompile_dll.dll >> filestocopy.txt
> echo %SDKBINDIR%\vstdlib.dll >> filestocopy.txt
> echo %SDKBINDIR%\tier0.dll >> filestocopy.txt
>
> modify to
>
> echo shadercompile.exe >> filestocopy.txt
> echo shadercompile_dll.dll >> filestocopy.txt
> rem echo %SDKBINDIR%\vstdlib.dll >> filestocopy.txt
> rem echo %SDKBINDIR%\tier0.dll >> filestocopy.txt
>
> > Sorry I don't have anything to contribute, but how were you able to
> > get the shader SDK working? Using the beta SDK and DXSDK Nov2008,
> > the .fxc files do not seem to build successfully.
> >
> >
> >
> >
> >
> > On May 23, 2009, at 9:29 PM, "walter"  wrote:
> >
> > > I tried to make CShadowDepthView draw into a custom render target
> > > which
> > > would then be passed to shader, but I cant find the right way how to
> > > do
> > > it. Being inexperienced in programming, I really could use some
> > > advice.
> > > > only way - additional render pass with depth write only. Simplest way
> > > > (IMHO) to use CClientShadowMgr. It uses CShadowDepthView::Draw() for
> > > > writing full range depth. I think it should look like "always
> > > > turned on
> > > > flashlight" with FOV`s (horizontal and vertical) and resolution
> > > > equal to
> > > > viewport FOV and resolution accordingly. Something like that...
> > > >
> > > > Pardon for poorly english ))
> > > > > Is there any other way how to get depth (distance) into shader?
> > > > >
> > > > > It is for Orange Box-based mod.
> > > > > > On PC platform _rt_FullFrameDepth is a compressed depth buffer.
> > > > > > This
> > > > > means
> > > > > > that presented not full depth range, but only part, not to exceed
> > > > > > OO_DESTALPHA_DEPTH_RANGE (as defined in the file
> common_ps_fxc.h).
> > > > > That is
> > > > > > why we have fake soft particles. Sadly :(
> > > > > > > Is this for ep1?
> > > > > > >
> > > > > > > On Fri, May 22, 2009 at 12:52 PM, walter
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > I wrote a custom shader which accesses depth buffer through
> > > > > > > > "_rt_FullFrameDepth" render target. It works, but alpha
> channel
> > > > > > > becomes
> > > > > > > > maxed out to white just few meters from camera, preventing
> > > > > intended
> > > > > > > > function. Any idea what could I be doing wrong?
> > > > > > > > Jan "Walter" Sluka
> > > > > > > >
> > > > > > > > ___
> > > > > > > > To unsubscribe, edit your list preferences, or view the list
> > > > > archives,
> > > > > > > > please visit:
> > > > > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > > > > ___
> > > > > > > To unsubscribe, edit your list preferences, or view the list
> > > > > archives,
> > > > > > > please visit:
> > > > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > > > ___
> > > > > > To unsubscribe, edit your list preferences, or view the list
> > > > > > archives,
> > > > > > please visit:
> > > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > > ___
> > > > > To unsubscribe, edit your list preferences, or view the list
> > > > > archives,
> > > > > please visit:
> > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > ___
> > > > To unsubscribe, edit your list preferences, or view the list
> > > > archives,
> > > > please visit:
> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list
> > > archives, please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Depth buffer problem

[James Gray]

Sorry I don't have anything to contribute, but how were you able to  
get the shader SDK working? Using the beta SDK and DXSDK Nov2008,  
the .fxc files do not seem to build successfully.





On May 23, 2009, at 9:29 PM, "walter"  wrote:

> I tried to make CShadowDepthView draw into a custom render target  
> which
> would then be passed to shader, but I cant find the right way how to  
> do
> it. Being inexperienced in programming, I really could use some  
> advice.
>
>> only way - additional render pass with depth write only. Simplest way
>> (IMHO) to use CClientShadowMgr. It uses CShadowDepthView::Draw() for
>> writing full range depth. I think it should look like "always  
>> turned on
>> flashlight" with FOV`s (horizontal and vertical) and resolution  
>> equal to
>> viewport FOV and resolution accordingly. Something like that...
>>
>> Pardon for poorly english ))
>>
>>> Is there any other way how to get depth (distance) into shader?
>>>
>>> It is for Orange Box-based mod.
>>>
 On PC platform _rt_FullFrameDepth is a compressed depth buffer.  
 This
>>> means
 that presented not full depth range, but only part, not to exceed
 OO_DESTALPHA_DEPTH_RANGE (as defined in the file common_ps_fxc.h).
>>> That is
 why we have fake soft particles. Sadly :(
> Is this for ep1?
>
> On Fri, May 22, 2009 at 12:52 PM, walter  
> 
> wrote:
>> I wrote a custom shader which accesses depth buffer through
>> "_rt_FullFrameDepth" render target. It works, but alpha channel
> becomes
>> maxed out to white just few meters from camera, preventing
>>> intended
>> function. Any idea what could I be doing wrong?
>> Jan "Walter" Sluka
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list
>>> archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> ___
> To unsubscribe, edit your list preferences, or view the list
>>> archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
 ___
 To unsubscribe, edit your list preferences, or view the list  
 archives,
 please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list  
>>> archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Depth buffer problem

[James Gray]

Is this for ep1?

On Fri, May 22, 2009 at 12:52 PM, walter  wrote:

> I wrote a custom shader which accesses depth buffer through
> "_rt_FullFrameDepth" render target. It works, but alpha channel becomes
> maxed out to white just few meters from camera, preventing intended
> function. Any idea what could I be doing wrong?
> Jan "Walter" Sluka
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Finding the bound key for a specific command

[James Gray]

vgui::input or ::input should have functions for what you are looking  
for iirc.



On May 15, 2009, at 4:51 PM, Saul Rennison   
wrote:

> Take a look at the *KeyHintText* usermessage. This will display a  
> panel on
> the HUD with the key and a short message of your choice.
>
> 2009/5/15 Richard Slaughter 
>
>> Hi List,
>>
>> I'd like to be able to display the key for a current command, e.g.
>> "phys_swap", on the HUD.
>>
>> Is it possible to find out what key is currently bound to a command  
>> on
>> the client?
>> Thanks!
>>
>> Rich
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> -- 
> Thanks,
> - Saul.
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Setting a weapon to play the "draw" sequence when itisselected/picked up?

[James Keith]

The physgun is so broken it's not included in the project by default. I 
don't mean the "Gravity Gun". I don't see a function that gets called when 
it's picked up.

I didn't mess anything up as far as i know, the code is broken to hell and 
back. It doesn't even have a viewmodel by default, i had to code one in. The 
secondary fire (which makes a weld-ball) is tracing correctly, so i dunno 
why primary isn't.

Thanks,
James

- Original Message - 
From: "Jonas 'Sortie' Termansen" 
To: "Discussion of Half-Life Programming" 
Sent: Sunday, May 10, 2009 5:16 PM
Subject: Re: [hlcoders] Setting a weapon to play the "draw" sequence when 
itisselected/picked up?


> Uhm, I didn't know the physgun was broken in the first place. For playing
> such a sequence, find the function that is called when the physgun is 
> picked
> up, and start the animation there? Or check some baseclass.
>
> The last one sounds like you messed something up related to model
> attachments on view models, maybe screwed up a few vectors or whatever, 
> but
> I am not sure what you mean.
>
> - Original Message - 
> From: "James Keith" 
> To: 
> Sent: Sunday, May 10, 2009 10:59 PM
> Subject: [hlcoders] Setting a weapon to play the "draw" sequence when it
> isselected/picked up?
>
>
>> I'm working on getting the Physics Gun (physgun) to work again, and one
>> step of that is getting it to play the model's "draw" sequence when the
>> player picks it up or switches to it in inventory. How can i do this?
>>
>> Unrelated to the topic title, i can't seem to get the beam that comes out
>> of the gun to follow the tracer the gun emits. It comes out of the gun,
>> but it goes to the origin. Any ideas on that?
>>
>> Thanks,
>> James
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, 
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> 


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Setting a weapon to play the "draw" sequence when it is selected/picked up?

[James Keith]

I'm working on getting the Physics Gun (physgun) to work again, and one step of 
that is getting it to play the model's "draw" sequence when the player picks it 
up or switches to it in inventory. How can i do this?

Unrelated to the topic title, i can't seem to get the beam that comes out of 
the gun to follow the tracer the gun emits. It comes out of the gun, but it 
goes to the origin. Any ideas on that?

Thanks,
James
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Making the sentry turret fire other types of ammo?

[James Keith]

I looked there, the only thing i found was

  info.m_iAmmoType = m_iAmmoType;

Which isn't exactly helpful.

Thanks,
James
- Original Message - 
From: "Alexander Hirsch" <1ze...@googlemail.com>
To: "Discussion of Half-Life Programming" 
Sent: Thursday, May 07, 2009 6:07 PM
Subject: Re: [hlcoders] Making the sentry turret fire other types of ammo?


> You probably have to change CNPC_FloorTurret::Shoot (it's in
> npc_turret_floor.cpp).
>
> On Thu, May 7, 2009 at 11:54 PM, James Keith  wrote:
>
>> I can't find where the sentry defines the type of bullet it shoots out in
>> it's source code. If i wanted to say, change the thing it shoots out to
>> crossbow ammo or shotgun ammo, how would i go about doing that? I know 
>> SMOD
>> has turrets that fire crossbow bolts, lasers, and a bunch of other stuff, 
>> so
>> it's got to be possible.
>>
>> Thanks,
>> James
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, 
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> 


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Making the sentry turret fire other types of ammo?

[James Keith]

I can't find where the sentry defines the type of bullet it shoots out in it's 
source code. If i wanted to say, change the thing it shoots out to crossbow 
ammo or shotgun ammo, how would i go about doing that? I know SMOD has turrets 
that fire crossbow bolts, lasers, and a bunch of other stuff, so it's got to be 
possible.

Thanks,
James
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Sending Data from Client to Server

[James Gray]

You could use an impulse command, or indeed use a client command  
handled by the server. Look at CBasePlayer::ClientCommand and  
CBasePlayer::ImpulseCommands



On May 4, 2009, at 1:44 AM, Steve Henderson  wrote:

> This may be considered slightly hackish but here goes:
>
> Make a server side console command by adding this at the bottom of
> your server class:
>
> static ConCommand
> armar_set_model_transparency("armar_set_model_transparency" ,
> setModelTransparency, "Set the transparency for a model", 0);
>
> Then add a corresponding method in the same class:
>
> void setModelTransparency(void) {
>
>if(engine->Cmd_Argc() == 3){
>
>char* model_name = engine->Cmd_Argv(1);
>byte alpha = (byte) atoi(engine->Cmd_Argv(2));
>
>if(strlen(model_name) > 0) {
>//Msg("Trying to set the transparency on model %s to %d\n",
> model_name, alpha);
>CBaseEntity* aModel =
> dynamic_cast(gEntList.FindEntityByName( NULL,
> model_name));
>if(!aModel) {
>Warning("Didn't find entity %s..can't set transparency 
> \n", model_name);
>} else {
>//Msg("Got the base entity\n");
>aModel->SetRenderMode(kRenderTransColor);
>aModel->SetRenderColorA(alpha);
>
>}
>
>
>} else {
>Warning("Tried to set the transparency on a model with a  
> null string\n");
>}
>}
> }
>
>
> Then, from the client call the server console command like this:
>
>char command[64];
>sprintf(command, "armar_set_model_transparency mymodel 255");
>engine->ClientCmd(command);
>
> Good Luck!
>
> Steve
>
>
> On Mon, May 4, 2009 at 2:34 AM, Walter Gray   
> wrote:
>> Hey list,
>>I'm trying to create a hammer output field for one of my entities,
>> but I've run into a bit of a roadblock.
>>The entity is used to control the playback of full screen movies,
>> and networked so that the server side and thus hammer can be used to
>> start or stop the movie while the client side is responsible for
>> actually playing the video files.  I want to have an output fire when
>> the movie ends, but that would require that when the movie ends on  
>> the
>> client side either because it finishes normally or the player stops  
>> it,
>> data be transmitted from the client to the server.
>>As I understand it, CNetworkVars only transmit from server to
>> client, so the only way I can think of right now would be to encode  
>> the
>> information in the key press info (create an unbound IN_MOVIEENDED
>> button).  Is there a better, non-hacky way to go about this?
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] What's the offset for on SendPropInt in making send tables?

[James Gray]

The SENDINFO macro fills in the first three parameters based on the  
variable.



On May 3, 2009, at 2:30 AM, Brent Lewis  wrote:

>
> Wait a minute... the SendPropInt function has a nBits parameter...  
> and no default values for parameters...
>
> SendProp SendPropInt(
>char *pVarName,
>int offset,
>int sizeofVar,
>int nBits,
>int flags,
>SendVarProxyFn varProxy
>)
>
> There's a #define or overload I'm missing somewhere, isn't there?
>
>> Date: Tue, 2 Jun 2009 14:51:45 +0900
>> From: minh...@telus.net
>> To: hlcoders@list.valvesoftware.com
>> Subject: Re: [hlcoders] What's the offset for on SendPropInt in  
>> making send tables?
>>
>> Are you referring to the number that goes after the initial comma?
>> That value refers to the number of bits it will use to transfer the
>> data. Always try to use the fewest bits possible as it optimizes  
>> network
>> communication.
>> So for example.. if your variable "m_iMental"  rangers between 0  
>> and 100.
>> You should use a bit size of 7 (as that will allow you to use values
>> from 0 - 127 )
>> Also, you need to use the flag  SPROP_UNSIGNED.
>> So your declaration will look like this
>>
>>SendPropInt(SENDINFO(m_iMental), 7, SPROP_UNSIGNED ),
>>
>>
>>
>> Brent Lewis wrote:
>>> I want to add an int network variable and figured this was  
>>> probably the place to do it. The problem is, I'm not quite sure  
>>> what the "offset" parameter of SendPropInt is, and what value I  
>>> should use. I know what offset means traditionally, but by this  
>>> example it seems that may not be the meaning.
>>>
>>>IMPLEMENT_SERVERCLASS_ST( CBasePlayer, DT_BasePlayer )
>>>
>>>SendPropDataTable(SENDINFO_DT(pl),  
>>> &REFERENCE_SEND_TABLE(DT_PlayerState),  
>>> SendProxy_DataTableToDataTable),
>>>
>>>SendPropEHandle(SENDINFO(m_hVehicle)),
>>>SendPropEHandle(SENDINFO(m_hUseEntity)),
>>>SendPropInt(SENDINFO(m_iHealth), 10 ),
>>>SendPropInt(SENDINFO(m_iMental), ???)
>>>SendPropInt(SENDINFO(m_lifeState), 3,  
>>> SPROP_UNSIGNED ),
>>>SendPropInt(SENDINFO(m_iBonusProgress), 15 ),
>>>SendPropInt(SENDINFO(m_iBonusChallenge), 4 ),
>>>SendPropFloat(SENDINFO(m_flMaxspeed), 12,  
>>> SPROP_ROUNDDOWN, 0.0f, 2048.0f ),  // CL
>>>SendPropInt(SENDINFO(m_fFlags), PLAYER_FLAG_BITS,  
>>> SPROP_UNSIGNED|SPROP_CHANGES_OFTEN,  
>>> SendProxy_CropFlagsToPlayerFlagBitsLength ),
>>>SendPropInt(SENDINFO(m_iObserverMode), 3,  
>>> SPROP_UNSIGNED ),
>>>SendPropEHandle(SENDINFO(m_hObserverTarget) ),
>>>SendPropInt(SENDINFO(m_iFOV), 8, SPROP_UNSIGNED ),
>>>SendPropInt(SENDINFO(m_iFOVStart), 8,  
>>> SPROP_UNSIGNED ),
>>>SendPropFloat(SENDINFO(m_flFOVTime) ),
>>>SendPropInt(SENDINFO(m_iDefaultFOV), 8,  
>>> SPROP_UNSIGNED ),
>>>SendPropEHandle(SENDINFO(m_hZoomOwner) ),
>>>SendPropArray 
>>> ( SendPropEHandle( SENDINFO_ARRAY( m_hViewModel ) ), m_hViewModel ),
>>>SendPropString(SENDINFO(m_szLastPlaceName) ),
>>>SendPropInt( SENDINFO( m_ubEFNoInterpParity ),  
>>> NOINTERP_PARITY_MAX_BITS, SPROP_UNSIGNED ),
>>>
>>>// Data that only gets sent to the local player.
>>>SendPropDataTable( "localdata", 0,  
>>> &REFERENCE_SEND_TABLE(DT_LocalPlayerExclusive),  
>>> SendProxy_SendLocalDataTable ),
>>>
>>>END_SEND_TABLE()
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list  
>>> archives, please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>>
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list  
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
> ___
> To unsubscribe, edit your list preferences, or view the list  
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders