Re: [hlcoders] Working on multiple devices

[Joel R.]

The project files are like this:

The .sln and .vcproj files contain the project folder structure,
dependencies, references, etc.  These you should be committing.  However,
make sure to edit property stuff like the Debug Command Line paths to use
Environment Variables.  You can easily call env vars by doing $(ENV_NAME).
Create a readme.txt/setup.txt that lists these env vars and commit it, so
you/others know what to setup.

The ones that are more user specific, with things like color schemes,
syntax highlighting, etc. would be in the .suo file.  These are usually
hidden files, but might not be, and you can have git/svn ignore these.  You
can also ignore all the build stuff like obj/property folders.  .pdb files
are usually quite large, so you can ignore them too, unless you have a
stable build and you need it for debugging purposes.


On Mon, Apr 14, 2014 at 1:25 PM, Krzysztof Lesiak wrote:

>  Ok, this question is more management-related: I’m keeping my modified
> SDK code in a Github repo, but I’d like to be able to work on multiple
> devices. By default, project files are not synced, so the problem is, that
> while I sync all my source files and have them e.g. on my laptop, they are
> not in their respective places in the project and I’d have to add them
> manually on the other device, which is tedious and not really possible when
> I’m away from my PC, since I don't remember the exact place where I’ve put
> them.
> This brings me to my question: should I just sync project/solution/filters
> files OR should I add some lines to the .vpc file every time I add a new
> file/filter? The latter seems to be a good solution when attempting to
> compile on Linux at a later point, but I’d probably have to write a tool
> for that, since adding filenames manually is tedious and error prone.
>
> What’s your opinion on that?
>
> Krzysztof
>
> ___
> 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 2013 Release

[Joel R.]

Wow, very nice.  I'm still crossing my fingers for a new engine though, the
amount of Source Developers has dwindled to near non-existent.   UDK and
Unity are just too good at the moment.


On Thu, Jun 27, 2013 at 12:29 PM, T X4  wrote:

>  For anyone who's curious about what *exactly* has changed since Source
> SDK 2007, I've managed to generate a diff between the last released version
> of the 2007 SDK against the new 2013 SDK (*MP code only*). There was
> initially plenty of extra 'noise' since virtually every single file was
> detected as changed - this was due to Valve replacing the header comments
> in all files. So after spending close to six hours filtering out changes of
> that nature, I finally managed to get some useful output.
>
> *Summaries (filenames only)*:
> Changed Files (binaries) 
> Changed Files (text)  - Use this to quickly
> index the diffs for changes specific to a given file, since scrolling
> through it might be fairly laggy at times.
> File Removals 
> File Additions 
> Unchanged* Files 
>
> *Detailed git diff output (packaged with the above summaries in text form)
> *:
> Here 
>
> *Statistics (post noise reduction)*:
> Changed files (binaries): 17
> Changed files (text): 1465
> Files removed: 423
> Files added: 851
> Unchanged* files: 1349
>
> **Unchanged* *includes* the files whose header comments were modified to
> reduce the amount of noise output.
>
> Hope you guys will find these to be of use.
> (also, to those longing for custom main menus, look near the bottom of
> /mp/src/common/GameUI/IGameUI.h for a pleasant surprise [image: Emoji] )
>
> Regards,
> TESLA-X4
>
>
> ___
> 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] Prediction Jerkiness with aircraft ?

[Joel R.]

I'd start from scratch again.

Quick question though...  Are the ships in Eternal Silence updating the
client entity position and angles as you are?  Or is it server side only...?

On the flip side... I would create my own custom clientside entity.  This
way YOU control everything that happens to it, and not the server, because
it appears like you are battling with the prediction system.  If the
origin/angles are off by a small tolerance (defined in c_baseentity.cpp),
the client will teleport immediately to the server values.

Also, for the smoothing, I'd override the GetRenderOrigin and
GetRenderAngles functions.  This way you can display a smoothed
origin/angles, but the simulation origin and angles are still simulated
perfectly.  This may be another reason why you are getting jitter, because
of the battle between smoothing and simulation.


On Sun, Apr 29, 2012 at 2:39 PM, Psy_Commando  wrote:

> Finally got the dedicated server to work with my local network ip. It does
> the same thing as with net_fakelag on the listen server, it doesn't look
> broken to me...
>
> Still can't find what part of the code is causing the stuttering...
>
>
> On Sun, Apr 29, 2012 at 10:43 AM, Ben Pye  wrote:
>
>> With the dedicated server run with the argument "-ip 127.0.0.1" and then
>> it should listen on localhost.
>>
>>
>> On Sun, Apr 29, 2012 at 12:36 AM, Psy_Commando wrote:
>>
>>> You're sure about that ? you're the first person to tell me that.
>>> Besides, I can't connect to a dedicated server on the same machine for
>>> some reasons, it just timeouts, whether I use 127.0.0.1 or my local network
>>> IP.
>>>
>>>
>>> On Sat, Apr 28, 2012 at 5:09 PM, Stephen Swires <
>>> stephen.swi...@gmail.com> wrote:
>>>
>>>> Like I said. Fake lag does not work properly on listen servers in ASW.
>>>> You can check for any lag prediction issues by creating a local dedicated
>>>> server and connecting to it, then fake lag works as intended.
>>>>  On Apr 28, 2012 8:32 PM, "Psy_Commando"  wrote:
>>>>
>>>>> I made some progress changing the base class's base class to
>>>>> CBaseAnimating instead of CPhysicsPropMultiplayer, it fixed some of the
>>>>> stuttering, but once you add lag with net_fakelag it does it again. I 
>>>>> can't
>>>>> find the reason why the origin differs between client and server though, 
>>>>> at
>>>>> a glance it looks like the client is slightly ahead in time compared to 
>>>>> the
>>>>> server.
>>>>> If it can help, here's the base class :
>>>>>
>>>>> Client :
>>>>> c_prop_sfr_vehicle.h - http://pastebin.com/tqUFNGQZ
>>>>> c_prop_sfr_vehicle.cpp -http://pastebin.com/eCKcE3VX
>>>>>
>>>>> Server :
>>>>> prop_sfr_vehicle.h - h <http://goog_156218657>
>>>>> http://pastebin.com/zPb3HbEh
>>>>> prop_sfr_vehicle.cpp - http://pastebin.com/5y1m0S89
>>>>>
>>>>> On Fri, Apr 27, 2012 at 11:18 AM, Joel R.  wrote:
>>>>>
>>>>>> Nick, if you knew anything about coding, you'd be able to make it
>>>>>> work fairly quickly.  He is not going to give you all the SDK code 
>>>>>> prepped
>>>>>> and ready.
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 26, 2012 at 11:17 PM, Nick  wrote:
>>>>>>
>>>>>>> The code you posted certainly is impressive. I just can't find an
>>>>>>> easy
>>>>>>> way to put it in a sdk and run it? How to spawn the vech?
>>>>>>>
>>>>>>> Make an sdk with the files included that works, (with a working copy
>>>>>>> of the mod) and all of the code and send a link to valve.. I am sure
>>>>>>> they will help out.
>>>>>>>
>>>>>>> A single file isn't at all helpful compared to a working source code
>>>>>>> copy, and actual files and a 10 step list to "test" the exact problem
>>>>>>> you are experiencing. WE HAVE TO BE ABLE TO RUN THE EXACT CODE IF U
>>>>>>> WANT ANY HELP ON SUCH A MASSIVE "PROBLEM"..
>>>>>>>
>>>>>>> On Thu, Apr 26, 2012 at 12:18 AM, Psy_Commando <
>>>>>>> psycomma...@gmail.com> wrote:
>>>>>>> &g

Re: [hlcoders] Prediction Jerkiness with aircraft ?

[Joel R.]

Nick, if you knew anything about coding, you'd be able to make it work
fairly quickly.  He is not going to give you all the SDK code prepped and
ready.

On Thu, Apr 26, 2012 at 11:17 PM, Nick  wrote:

> The code you posted certainly is impressive. I just can't find an easy
> way to put it in a sdk and run it? How to spawn the vech?
>
> Make an sdk with the files included that works, (with a working copy
> of the mod) and all of the code and send a link to valve.. I am sure
> they will help out.
>
> A single file isn't at all helpful compared to a working source code
> copy, and actual files and a 10 step list to "test" the exact problem
> you are experiencing. WE HAVE TO BE ABLE TO RUN THE EXACT CODE IF U
> WANT ANY HELP ON SUCH A MASSIVE "PROBLEM"..
>
> On Thu, Apr 26, 2012 at 12:18 AM, Psy_Commando 
> wrote:
> > I already posted a link to the pastebin with the whole code earlier (
> > http://pastebin.com/eMcKh1YL ). And who at valve would help ? Most of
> the
> > time I don't get answers when I mail devs. And what do you mean share
> what
> > the problem is with you, isn't it what I've been foing?
> >
> > Is there any examples of simple moving predicted entities, besides the
> > player ? I could really use an example...
> >
> > By the way, is what Stephen says accurate ? Is the net_fakelag command
> not
> > working on listen servers ?
> >
> >
> > On Thu, Apr 26, 2012 at 12:34 AM, Nick  wrote:
> >>
> >> i think you should give us a basic code, and send it to valve... only
> >> valve can help you. Usually valve is quite nice, and I am sure they
> >> wouldn't mind helping you out, as long as you can share what the
> >> problem is with the rest of us.
> >>
> >>
> >>
> >> On Sun, Apr 22, 2012 at 3:04 PM, Psy_Commando 
> >> wrote:
> >> > Alright, what else could be causing jittering ? There is so little
> going
> >> > on
> >> > in that entity.
> >> >
> >> >
> >> > On Sat, Apr 21, 2012 at 8:40 PM, Tony "omega" Sergi
> >> > 
> >> > wrote:
> >> >>
> >> >> As I said. looking at your prediction dump, it's not actually
> >> >> predicting
> >> >> properly.
> >> >> Either they're not updating at the same rate, or they're not running
> >> >> the
> >> >> same code producing the same results.
> >> >> see your screenshot: http://dl.dropbox.com/u/13343993/abox0003.jpg
> >> >> notice in red, velocity is 0 0 0 that means
> >> >> disabling VPhysicsUpdate is not the solution, as that means you break
> >> >> every vphysics object. Look at what it's doing, it's getting it's
> >> >> position
> >> >> after vphysics simulates and updating the entity.
> >> >> so unless you're trying to make a purely client-authoritive ship, you
> >> >> can't disable that without adding code to update the position from
> the
> >> >> client.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Apr 22, 2012 at 7:40 AM, Stephen Swires
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> It maybe worth mentioning that net_fakelag is broken on listen
> servers
> >> >>> in
> >> >>> Alien Swarm. It works on dedicated, however
> >> >>>
> >> >>>
> >> >>> On Sat, Apr 21, 2012 at 10:05 PM, Psy_Commando <
> psycomma...@gmail.com>
> >> >>> wrote:
> >> 
> >>  I found what was causing the stuttering with 0 ping and in
> >>  singleplayer.
> >>  I disabled this code in cbaseentity_shared :
> >> 
> >> >
> >> >
> >> >
> >> >
> //-
> >> > // Purpose: My physics object has been updated, react or extract
> >> > data
> >> >
> >> >
> >> >
> //-
> >> > void CBaseEntity::VPhysicsUpdate( IPhysicsObject *pPhysics )
> >> > {
> >> > switch( GetMoveType() )
> >> > {
> >> > case MOVETYPE_VPHYSICS:
> >> > {
> >> > if ( GetMoveParent() )
> >> > {
> >> > Log_Warning( LOG_DEVELOPER_VERBOSE, "Updating
> >> > physics
> >> > on object in hierarchy %s!\n", GetClassname());
> >> > return;
> >> > }
> >> > Vector origin;
> >> > QAngle angles;
> >> >
> >> > pPhysics->GetPosition( &origin, &angles );
> >> >
> >> > if ( !IsFinite( angles.x ) || !IsFinite( angles.y ) ||
> >> > !IsFinite( angles.x ) )
> >> > {
> >> > Msg( "Infinite angles from vphysics! (entity
> %s)\n",
> >> > GetDebugName() );
> >> > angles = vec3_angle;
> >> > }
> >> > #ifndef CLIENT_DLL
> >> > Vector prevOrigin = GetAbsOrigin();
> >> > #endif
> >> >
> >> > for ( int i = 0; i < 3; ++i )
> >> > {
> >> > angles[ i ] = AngleNormalize( angles[ i ] );
> >> > }
> >> >
> >> > #ifndef CLIENT_DLL
> >> > NetworkQuantize( origin, angles );
> 

Re: [hlcoders] Prediction Jerkiness with aircraft ?

[Joel R.]

Well, you have to make sure prediction is turned on.  If prediction is off,
the NetworkOrigin and NetworkAngles and NetworkVelocity will be updating
the Origin/Angles/Velocity, and you end up having this struggle between
server updating your position and you updating it on the clientside.

On Thu, Apr 19, 2012 at 7:39 PM, Psy_Commando  wrote:

> Well its an entity that exist on both client and server. I'll use it in mp
> so making it clientside isn't an option.
>
> On Thu, Apr 19, 2012 at 8:28 PM, Joel R.  wrote:
>
>> Did you create this entity on the server?
>>
>> There is a lot of code the client player class does to make prediction
>> work.  I'd recommend just creating a clientside entity and manipulate that,
>> not the one from server.
>>
>>
>> On Thu, Apr 19, 2012 at 7:22 PM, Psy_Commando wrote:
>>
>>> Found out why, the server ent returned false for IsPredicted() .
>>>
>>> The plane is still jittery though, but here is the dump i get while
>>> moving : http://dl.dropbox.com/u/13343993/abox0003.jpg
>>> It would seem velocity differs, along with a few others.
>>>
>>>
>>> On Thu, Apr 19, 2012 at 5:47 PM, Psy_Commando wrote:
>>>
>>>> Wait, it worked with "weapon_smg1" but it doesn't work with my entity..
>>>>
>>>>
>>>> On Thu, Apr 19, 2012 at 4:55 PM, Christopher Harris <
>>>> char...@resrchnet.com> wrote:
>>>>
>>>>> It should be like for instance
>>>>>
>>>>> ** **
>>>>>
>>>>> **-  **cl_pclass prop_physics or cl_pclass weapon_crossbow
>>>>>
>>>>> ** **
>>>>>
>>>>> Also make sure that developer convar is set to at least 1. 
>>>>>
>>>>> ** **
>>>>>
>>>>> *From:* hlcoders-boun...@list.valvesoftware.com [mailto:
>>>>> hlcoders-boun...@list.valvesoftware.com] *On Behalf Of *Psy_Commando
>>>>> *Sent:* Thursday, April 19, 2012 4:15 PM
>>>>>
>>>>> *To:* Discussion of Half-Life Programming
>>>>> *Subject:* Re: [hlcoders] Prediction Jerkiness with aircraft ?
>>>>>
>>>>> ** **
>>>>>
>>>>> I tried cl_pclass with the class name, but nothing happens.
>>>>>
>>>>> Also, after a few minutes of messing around I get this assert :
>>>>> src\game\server\baseentity.cpp (460) : Assertion Failed: fabs(
>>>>> CoordFromCell( cellwidth, cell[0], pOut->m_Vector[ 0 ] ) - v->x ) <
>>>>> cellEpsilon
>>>>> swarm.exe has triggered a breakpoint
>>>>>
>>>>> On Thu, Apr 19, 2012 at 3:12 PM, Christopher Harris <
>>>>> char...@resrchnet.com> wrote:
>>>>>
>>>>> cl_pclass classname
>>>>>
>>>>>  
>>>>>
>>>>> run that with your ship classname and you get a nice easy to read
>>>>> debug gui to see what predicted variables are off for all predicted parts
>>>>> of that entitytype. I only used it on an entity type I have 1 instance of
>>>>> so not sure what behavior occurs if you have many of em.
>>>>>
>>>>>  
>>>>>
>>>>> *From:* hlcoders-boun...@list.valvesoftware.com [mailto:
>>>>> hlcoders-boun...@list.valvesoftware.com] *On Behalf Of *Psy_Commando
>>>>> *Sent:* Thursday, April 19, 2012 12:37 PM
>>>>> *To:* Discussion of Half-Life Programming
>>>>> *Subject:* Re: [hlcoders] Prediction Jerkiness with aircraft ?
>>>>>
>>>>>  
>>>>>
>>>>> Well, it would seem this is a Alien Swarm related issue.. Even the hl2
>>>>> jeep is having the same problem.
>>>>>
>>>>> On Tue, Apr 17, 2012 at 10:11 PM, Psy_Commando 
>>>>> wrote:
>>>>>
>>>>> Its called in the shared ProcessMovement method.I assume that method
>>>>> is called at the same time on client and server..
>>>>>
>>>>>  
>>>>>
>>>>> On Tue, Apr 17, 2012 at 5:40 PM, Joel R.  wrote:*
>>>>> ***
>>>>>
>>>>> Where are you running this simulation code?  You need to make sure
>>>>> it's in a location that is sync'd with the server.
>>>>>
>>>>> A

Re: [hlcoders] Prediction Jerkiness with aircraft ?

[Joel R.]

Did you create this entity on the server?

There is a lot of code the client player class does to make prediction
work.  I'd recommend just creating a clientside entity and manipulate that,
not the one from server.

On Thu, Apr 19, 2012 at 7:22 PM, Psy_Commando  wrote:

> Found out why, the server ent returned false for IsPredicted() .
>
> The plane is still jittery though, but here is the dump i get while moving
> : http://dl.dropbox.com/u/13343993/abox0003.jpg
> It would seem velocity differs, along with a few others.
>
>
> On Thu, Apr 19, 2012 at 5:47 PM, Psy_Commando wrote:
>
>> Wait, it worked with "weapon_smg1" but it doesn't work with my entity..
>>
>>
>> On Thu, Apr 19, 2012 at 4:55 PM, Christopher Harris <
>> char...@resrchnet.com> wrote:
>>
>>> It should be like for instance
>>>
>>> ** **
>>>
>>> **-  **cl_pclass prop_physics or cl_pclass weapon_crossbow
>>>
>>> ** **
>>>
>>> Also make sure that developer convar is set to at least 1. 
>>>
>>> ** **
>>>
>>> *From:* hlcoders-boun...@list.valvesoftware.com [mailto:
>>> hlcoders-boun...@list.valvesoftware.com] *On Behalf Of *Psy_Commando
>>> *Sent:* Thursday, April 19, 2012 4:15 PM
>>>
>>> *To:* Discussion of Half-Life Programming
>>> *Subject:* Re: [hlcoders] Prediction Jerkiness with aircraft ?
>>>
>>> ** **
>>>
>>> I tried cl_pclass with the class name, but nothing happens.
>>>
>>> Also, after a few minutes of messing around I get this assert :
>>> src\game\server\baseentity.cpp (460) : Assertion Failed: fabs(
>>> CoordFromCell( cellwidth, cell[0], pOut->m_Vector[ 0 ] ) - v->x ) <
>>> cellEpsilon
>>> swarm.exe has triggered a breakpoint
>>>
>>> On Thu, Apr 19, 2012 at 3:12 PM, Christopher Harris <
>>> char...@resrchnet.com> wrote:
>>>
>>> cl_pclass classname
>>>
>>>  
>>>
>>> run that with your ship classname and you get a nice easy to read debug
>>> gui to see what predicted variables are off for all predicted parts of that
>>> entitytype. I only used it on an entity type I have 1 instance of so not
>>> sure what behavior occurs if you have many of em.
>>>
>>>  
>>>
>>> *From:* hlcoders-boun...@list.valvesoftware.com [mailto:
>>> hlcoders-boun...@list.valvesoftware.com] *On Behalf Of *Psy_Commando
>>> *Sent:* Thursday, April 19, 2012 12:37 PM
>>> *To:* Discussion of Half-Life Programming
>>> *Subject:* Re: [hlcoders] Prediction Jerkiness with aircraft ?
>>>
>>>  
>>>
>>> Well, it would seem this is a Alien Swarm related issue.. Even the hl2
>>> jeep is having the same problem.
>>>
>>> On Tue, Apr 17, 2012 at 10:11 PM, Psy_Commando 
>>> wrote:
>>>
>>> Its called in the shared ProcessMovement method.I assume that method is
>>> called at the same time on client and server..
>>>
>>>  
>>>
>>> On Tue, Apr 17, 2012 at 5:40 PM, Joel R.  wrote:***
>>> *
>>>
>>> Where are you running this simulation code?  You need to make sure it's
>>> in a location that is sync'd with the server.
>>>
>>> Also, I would not use GetNetworkOrigin, as I have seen it can become too
>>> jittery, use GetLocalOrigin instead.  
>>>
>>> ** **
>>>
>>> On Tue, Apr 17, 2012 at 4:25 PM, Psy_Commando 
>>> wrote:
>>>
>>> Doesn't the client interpolate automatically ? I thought that was what
>>> the Network origin was for.
>>> Anyways, I'm not really sure what they did but here's the handling code
>>> I'm using, its mostly code made by the Eternal Silence guys modified to fit.
>>> http://pastebin.com/6kVZJxiD
>>>
>>> I think they basically just use vphysics for collisions, they rotate the
>>> angles and velocity directly to steer the craft.
>>>
>>> And also FakeJitter should be 0, I never changed it.
>>>
>>>  ****
>>>
>>> On Tue, Apr 17, 2012 at 4:58 PM, Joel R.  wrote:***
>>> *
>>>
>>> Also, when you added fakelag to reach about 300 ping, the red and green
>>> crosshairs were still sync'd perfectly.  This should not be possible unless
>>> you are extrapolating on the server, but even then it would go way off on
>>> turn

Re: [hlcoders] Prediction Jerkiness with aircraft ?

[Joel R.]

Where are you running this simulation code?  You need to make sure it's in
a location that is sync'd with the server.

Also, I would not use GetNetworkOrigin, as I have seen it can become too
jittery, use GetLocalOrigin instead.



On Tue, Apr 17, 2012 at 4:25 PM, Psy_Commando  wrote:

> Doesn't the client interpolate automatically ? I thought that was what the
> Network origin was for.
> Anyways, I'm not really sure what they did but here's the handling code
> I'm using, its mostly code made by the Eternal Silence guys modified to fit.
> http://pastebin.com/6kVZJxiD
>
> I think they basically just use vphysics for collisions, they rotate the
> angles and velocity directly to steer the craft.
>
> And also FakeJitter should be 0, I never changed it.
>
>
> On Tue, Apr 17, 2012 at 4:58 PM, Joel R.  wrote:
>
>> Also, when you added fakelag to reach about 300 ping, the red and green
>> crosshairs were still sync'd perfectly.  This should not be possible unless
>> you are extrapolating on the server, but even then it would go way off on
>> turns.
>>
>>
>> On Tue, Apr 17, 2012 at 3:55 PM, Joel R.  wrote:
>>
>>> You will need to smooth out the origin and angles.  I'm not sure why but
>>> the physics simulation cannot be followed without doing some sort of
>>> smoothing to the origin/angles.  What I did was interpolate them by a small
>>> amount to smooth out the kinks.  I created a "fakeOrigin" and "fakeAngles"
>>> that are smoothed to the real values.
>>>
>>>
>>> On Tue, Apr 17, 2012 at 3:51 PM, Psy_Commando wrote:
>>>
>>>> using vphysics
>>>>
>>>>
>>>> On Tue, Apr 17, 2012 at 4:48 PM, Joel R.  wrote:
>>>>
>>>>> Is the entity simulated using the physics object or bbox and
>>>>> gamemovement?
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 17, 2012 at 3:44 PM, Psy_Commando 
>>>>> wrote:
>>>>>
>>>>>> I'm having a problem with an aircraft vehicle I've made. I asked the
>>>>>> Eternal Silence team for some pointers and they've shared their flight 
>>>>>> code
>>>>>> with me, but I'm still getting this weird jerkiness, even at 0ms of ping.
>>>>>> I'm using the Alien Swarm SDK for this.
>>>>>>
>>>>>> Here's a video to show the problem :
>>>>>> http://www.youtube.com/watch?v=zs64WcoD_IQ
>>>>>>
>>>>>> I'm really not sure what's the problem, I can post parts of the code
>>>>>> here if that would help.
>>>>>> Any suggestion would be greatly appreciated.
>>>>>>
>>>>>> ___
>>>>>> 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] Prediction Jerkiness with aircraft ?

[Joel R.]

Also, when you added fakelag to reach about 300 ping, the red and green
crosshairs were still sync'd perfectly.  This should not be possible unless
you are extrapolating on the server, but even then it would go way off on
turns.

On Tue, Apr 17, 2012 at 3:55 PM, Joel R.  wrote:

> You will need to smooth out the origin and angles.  I'm not sure why but
> the physics simulation cannot be followed without doing some sort of
> smoothing to the origin/angles.  What I did was interpolate them by a small
> amount to smooth out the kinks.  I created a "fakeOrigin" and "fakeAngles"
> that are smoothed to the real values.
>
>
> On Tue, Apr 17, 2012 at 3:51 PM, Psy_Commando wrote:
>
>> using vphysics
>>
>>
>> On Tue, Apr 17, 2012 at 4:48 PM, Joel R.  wrote:
>>
>>> Is the entity simulated using the physics object or bbox and
>>> gamemovement?
>>>
>>>
>>>
>>> On Tue, Apr 17, 2012 at 3:44 PM, Psy_Commando wrote:
>>>
>>>> I'm having a problem with an aircraft vehicle I've made. I asked the
>>>> Eternal Silence team for some pointers and they've shared their flight code
>>>> with me, but I'm still getting this weird jerkiness, even at 0ms of ping.
>>>> I'm using the Alien Swarm SDK for this.
>>>>
>>>> Here's a video to show the problem :
>>>> http://www.youtube.com/watch?v=zs64WcoD_IQ
>>>>
>>>> I'm really not sure what's the problem, I can post parts of the code
>>>> here if that would help.
>>>> Any suggestion would be greatly appreciated.
>>>>
>>>> ___
>>>> 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] Prediction Jerkiness with aircraft ?

[Joel R.]

You will need to smooth out the origin and angles.  I'm not sure why but
the physics simulation cannot be followed without doing some sort of
smoothing to the origin/angles.  What I did was interpolate them by a small
amount to smooth out the kinks.  I created a "fakeOrigin" and "fakeAngles"
that are smoothed to the real values.

On Tue, Apr 17, 2012 at 3:51 PM, Psy_Commando  wrote:

> using vphysics
>
>
> On Tue, Apr 17, 2012 at 4:48 PM, Joel R.  wrote:
>
>> Is the entity simulated using the physics object or bbox and gamemovement?
>>
>>
>>
>> On Tue, Apr 17, 2012 at 3:44 PM, Psy_Commando wrote:
>>
>>> I'm having a problem with an aircraft vehicle I've made. I asked the
>>> Eternal Silence team for some pointers and they've shared their flight code
>>> with me, but I'm still getting this weird jerkiness, even at 0ms of ping.
>>> I'm using the Alien Swarm SDK for this.
>>>
>>> Here's a video to show the problem :
>>> http://www.youtube.com/watch?v=zs64WcoD_IQ
>>>
>>> I'm really not sure what's the problem, I can post parts of the code
>>> here if that would help.
>>> Any suggestion would be greatly appreciated.
>>>
>>> ___
>>> 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] Prediction Jerkiness with aircraft ?

[Joel R.]

Is the entity simulated using the physics object or bbox and gamemovement?



On Tue, Apr 17, 2012 at 3:44 PM, Psy_Commando  wrote:

> I'm having a problem with an aircraft vehicle I've made. I asked the
> Eternal Silence team for some pointers and they've shared their flight code
> with me, but I'm still getting this weird jerkiness, even at 0ms of ping.
> I'm using the Alien Swarm SDK for this.
>
> Here's a video to show the problem :
> http://www.youtube.com/watch?v=zs64WcoD_IQ
>
> I'm really not sure what's the problem, I can post parts of the code here
> if that would help.
> Any suggestion would be greatly appreciated.
>
> ___
> 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] Rotation on the player's local axes

[Joel R.]

Try using my Quat class, it does the calculations differently, and is
perfectly tuned for engine->SetViewAngles


On Sun, Mar 4, 2012 at 8:48 PM, Craig Louie  wrote:

> Considering my old log file further, it looks like the hitch is definitely
> caused by the sudden switch from (yaw=0, roll=0) to (yaw=+/-180,
> roll=+/-180).
>
>
> 89.787949 0.00 0.00
> 89.796173 0.00 0.00
> 89.950935 -0.00 0.00
> 89.989258 -0.00 0.00
> 89.796158 180.00 180.00
> 89.639793 -180.00 -180.00
> 89.543274 180.00 180.00
> 89.290382 -180.00 -180.00
>
> The QuaternionAngles() function will always produce QAngles with pitch
> clamped between +/-90, therefore the yaw/roll values of +/-180 will always
> occur as shown in the log above.
> Example:
> Pitch = 91; Yaw = 0; Roll = 0;
> is equal to
> Pitch = 89; Yaw = 180; Roll = 180;
> These angles represent the point just past pitching straight down, when
> the player is starting to flip upside down.
>
> It would then seem that to fix the hitch, I would have to either move the
> entire engine away from using Euler Angles, or I would have to change the
> motion blur system. These changes aren't really in the scope of my humble
> mod. For now I will settle with turning off motion blur.
>
> Unfortunately, I have a more important gameplay bug that has been lurking
> from the beginning. I haven't mentioned it until now. When I pitch
> downwards towards the ground very, very slowly, the player stops pitching
> right around pitch = 89, straight down. So just as the player is about to
> look straight down, the slow downward pitch gets stuck (the bug also occurs
> when looking straight up). This is what it looks like in the log:
>
> Pitch YawRoll look_angle (this is the amount of
> pitch being applied in a given frame)
> 89.964256 0.00 0.00 -0.049802
> 89.981636 0.00 0.00 -0.017369
> 89.985939 0.00 0.00 -0.032433
> 89.964264 0.00 0.00 -0.049802
> 89.969955 0.00 0.00 -0.005686
> 89.975136 0.00 0.00 -0.054909
> 89.981659 0.00 0.00 -0.043205
> 89.999550 0.00 0.00 -0.018781
>
> So for very small pitch increments, the player's rotation gets stuck when
> the pitch nears 90 degrees (straight down). You can see the pitch values
> fluctuating up and down over these several frames. Note, the pitch doesn't
> get stuck with larger pitch increments, so it definitely has to do with the
> small look_angle values.
>
> My initial theory was that there was some lingering pitch clamping
> somewhere in the code, but I believe I have removed all instances of
> clamping (Tony's article made a point of removing pitch clamping from
> various places in the code).
>
> If anyone has any advice, I'd love to hear it.
>
> I also wanted to thank Saul, Minh, Joel and Tony for getting me this far.
> You guys are awesome and I am really humbled by your generous advice.
>
> Thanks!
>
>
>
> On Sat, Mar 3, 2012 at 11:23 PM, Joel R.  wrote:
>
>> I think I ran into a similar problem building the orientation state using
>> AxisAngles.  I believe you have to first build the "default" state before
>> you can multiply the (yaw/pitch/roll) quaternions.
>>
>>
>> On Sun, Mar 4, 2012 at 12:31 AM, Craig Louie wrote:
>>
>>> I've tried both Joel and Tony's methods, but I'm still unsure of how I
>>> can escape the inherent aliasing problem of Euler Angles.
>>>
>>> With Joel's method, for instance, after I have used Slerp to get a
>>> rotation quaternion, I still need to convert the resulting quaternion back
>>> into Euler Angles (with QuaternionAngles()) because the Source engine
>>> ultimately needs orientation in QAngle form when I call
>>> engine->SetViewAngles(viewangles). Any thoughts on this?
>>>
>>> Also, I've learned more about the nature of the twisting hitch
>>> experienced when looking straight up/down (this was my original problem).
>>> When I turn off motion blur, the hitch isn't visible. My theory is that the
>>> twisting hitch I am seeing is a result of the player's orientation twisting
>>> at the instant the player looks straight up/down.
>>>
>>> Below is a part of a log showing the changes in viewangle as I pitch
>>> down through pitch=90 (as shown in my youtube video).
>>>
>>> 88.025864 0.00 0.00
>>> 88.136208 0.00 0.00
>>> 88.278770 0.00 0.00
>>> 88.421890 0.00 0.00
>>> 88.531670 0.00 0.00
>>> 88.68376

Re: [hlcoders] Rotation on the player's local axes

[Joel R.]

gles_out[ROLL] += 360;
> }
>
> //###
>
>
> Thanks!
>
>
>
> On Fri, Mar 2, 2012 at 12:40 AM, Craig Louie  wrote:
>
>> Thanks Tony and Joel for more awesome help. I didn't get as much time as
>> I would have liked to work on it tonight. I will have to continue tomorrow
>> night (and probably into the weekend). I'll keep the thread posted. Thanks!
>>
>> P.S. cool flight sim vid, Joel. Are you a fellow X-Wing/Tie Fighter fan?
>> Freespace perhaps?
>>
>>
>>
>> On Thu, Mar 1, 2012 at 10:29 PM, Joel R.  wrote:
>>
>>> http://www.youtube.com/watch?v=5y6a_oFtNiI
>>>
>>>
>>> On Thu, Mar 1, 2012 at 10:35 PM, Tony "omega" Sergi >> > wrote:
>>>
>>>> This actually will work in Source, as the input/view stuff is basically
>>>> identical:
>>>> http://articles.thewavelength.net/269/
>>>> -Tony
>>>>
>>>>
>>>>
>>>> On Fri, Mar 2, 2012 at 5:09 AM, Craig Louie wrote:
>>>>
>>>>> Thanks Joel! I'll also try out your method when I get home. I'll keep
>>>>> everyone posted on my results.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 1, 2012 at 11:12 AM, Joel R.  wrote:
>>>>>
>>>>>> Quaternion.h
>>>>>> http://pastebin.com/hxTBab3T
>>>>>>
>>>>>> Quaternion.cpp
>>>>>> http://pastebin.com/2WizAewD
>>>>>>
>>>>>> Quaternion Rotation Formulas (Yaw/Pitch/Roll)
>>>>>> http://pastebin.com/BHRvcbCG
>>>>>>
>>>>>> I got most of the quaternion stuff from Ogre engine and converted to
>>>>>> work on Source Engine.  The functions you will be interested in using are
>>>>>> FromRotationMatrix, ToRotationMatrix, AxisAngle, ToAxisAngle,
>>>>>> GetRotationTo, ToAxes, Slerp, GetAngles, GetMatrix
>>>>>>
>>>>>> So basically you'll do what's below: (this is psuedocode, function
>>>>>> names are not exact!)
>>>>>>
>>>>>>
>>>>>> Quat current, target;
>>>>>> current.FromRotationMatrix( ent->EntityWorldTransform() );
>>>>>>
>>>>>> target = current;
>>>>>> target = yaw( target, 10 ); //10 degrees to the right, this function
>>>>>> is not part of Quat class for some reason
>>>>>>
>>>>>> current = Slerp( current, target, 0.2 ); //This is only 20%, you'll
>>>>>> need to calculate the angle difference between current/target, and then
>>>>>> move based on your angles per second speed.
>>>>>>
>>>>>> matrix3x4_t newRot;
>>>>>> current.ToRotationMatrix( newRot );
>>>>>> ent->SetWorldTransform( newRot );
>>>>>>
>>>>>>
>>>>>>
>>>>>> Enjoy!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 12:46 PM, Joel R.  wrote:
>>>>>>
>>>>>>> The quaternion calculations you're doing are similar to just
>>>>>>> manipulating the Euler Angles, which cause Gimbal Lock.
>>>>>>>
>>>>>>> The way I did it in my flight simulation is to create a Current
>>>>>>> Quaternion (from the starting Matrix Transformation when user spawns) 
>>>>>>> and
>>>>>>> Target Quaternion (where they want to rotate to).  I also used some
>>>>>>> formulas to rotate the quaternion in the individual yaw/pitch/roll
>>>>>>> orientations, I recommend googling for these formulas.  I then used the
>>>>>>> Slerp formula to animate from the Current quaternion to the Target
>>>>>>> quaternion. Slerp will avoid Gimbal-Lock entirely, which is very neat.
>>>>>>>
>>>>>>> After you do those calculations, just convert the new Current
>>>>>>> Quaternion into a Matrix Transformation and set the Entity to take that
>>>>>>> transform.
>>>>>>>
>>>>>>> I'

Re: [hlcoders] Rotation on the player's local axes

[Joel R.]

http://www.youtube.com/watch?v=5y6a_oFtNiI

On Thu, Mar 1, 2012 at 10:35 PM, Tony "omega" Sergi wrote:

> This actually will work in Source, as the input/view stuff is basically
> identical:
> http://articles.thewavelength.net/269/
> -Tony
>
>
>
> On Fri, Mar 2, 2012 at 5:09 AM, Craig Louie  wrote:
>
>> Thanks Joel! I'll also try out your method when I get home. I'll keep
>> everyone posted on my results.
>>
>> Thanks!
>>
>>
>>
>> On Thu, Mar 1, 2012 at 11:12 AM, Joel R.  wrote:
>>
>>> Quaternion.h
>>> http://pastebin.com/hxTBab3T
>>>
>>> Quaternion.cpp
>>> http://pastebin.com/2WizAewD
>>>
>>> Quaternion Rotation Formulas (Yaw/Pitch/Roll)
>>> http://pastebin.com/BHRvcbCG
>>>
>>> I got most of the quaternion stuff from Ogre engine and converted to
>>> work on Source Engine.  The functions you will be interested in using are
>>> FromRotationMatrix, ToRotationMatrix, AxisAngle, ToAxisAngle,
>>> GetRotationTo, ToAxes, Slerp, GetAngles, GetMatrix
>>>
>>> So basically you'll do what's below: (this is psuedocode, function names
>>> are not exact!)
>>>
>>>
>>> Quat current, target;
>>> current.FromRotationMatrix( ent->EntityWorldTransform() );
>>>
>>> target = current;
>>> target = yaw( target, 10 ); //10 degrees to the right, this function is
>>> not part of Quat class for some reason
>>>
>>> current = Slerp( current, target, 0.2 ); //This is only 20%, you'll need
>>> to calculate the angle difference between current/target, and then move
>>> based on your angles per second speed.
>>>
>>> matrix3x4_t newRot;
>>> current.ToRotationMatrix( newRot );
>>> ent->SetWorldTransform( newRot );
>>>
>>>
>>>
>>> Enjoy!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 1, 2012 at 12:46 PM, Joel R.  wrote:
>>>
>>>> The quaternion calculations you're doing are similar to just
>>>> manipulating the Euler Angles, which cause Gimbal Lock.
>>>>
>>>> The way I did it in my flight simulation is to create a Current
>>>> Quaternion (from the starting Matrix Transformation when user spawns) and
>>>> Target Quaternion (where they want to rotate to).  I also used some
>>>> formulas to rotate the quaternion in the individual yaw/pitch/roll
>>>> orientations, I recommend googling for these formulas.  I then used the
>>>> Slerp formula to animate from the Current quaternion to the Target
>>>> quaternion. Slerp will avoid Gimbal-Lock entirely, which is very neat.
>>>>
>>>> After you do those calculations, just convert the new Current
>>>> Quaternion into a Matrix Transformation and set the Entity to take that
>>>> transform.
>>>>
>>>> I've used this to control the entity rotation as well as the camera, it
>>>> allows you to do some pretty nifty tricks.
>>>>
>>>> I'll look for the code, if I still have it, and I'll post it here for
>>>> you.  Or if you figure out, please post a video =D
>>>>
>>>> Regards,
>>>>
>>>> Joel
>>>>
>>>>
>>>>
>>>> On Thu, Mar 1, 2012 at 11:55 AM, Minh  wrote:
>>>>
>>>>>  You can try spitting out the results to a file so you can observe the
>>>>> hitch more closely.
>>>>> Look for a function called COM_Log
>>>>>
>>>>> COM_Log ( "viewangle_hitch.txt", "%.2f  %.2f  %.2f  \n",
>>>>> viewangles.x, viewangles.y, viewangles.z );
>>>>>
>>>>> On 3/1/2012 3:55 AM, Craig Louie wrote:
>>>>>
>>>>> Thanks for the reply Saul. I hadn't thought of disabling prediction. I
>>>>> just gave it a shot. I changed to "engine->ClientCmd( "cl_predict 0" );" 
>>>>> in
>>>>> cdll_client_int.cpp. With another test, the unsmooth rotation when looking
>>>>> straight up/down still occurs.
>>>>>
>>>>> My main theories at this point:
>>>>> 1) Something is occurring in VectorAngles(vec_for_out, vec_up_out,
>>>>> viewangles) to cause this. VectorAngles() might not produce straight
>>>>> up/down Euler angles properly - choking because of aliasing perhaps? This
>

Re: [hlcoders] Rotation on the player's local axes

[Joel R.]

Quaternion.h
http://pastebin.com/hxTBab3T

Quaternion.cpp
http://pastebin.com/2WizAewD

Quaternion Rotation Formulas (Yaw/Pitch/Roll)
http://pastebin.com/BHRvcbCG

I got most of the quaternion stuff from Ogre engine and converted to work
on Source Engine.  The functions you will be interested in using are
FromRotationMatrix, ToRotationMatrix, AxisAngle, ToAxisAngle,
GetRotationTo, ToAxes, Slerp, GetAngles, GetMatrix

So basically you'll do what's below: (this is psuedocode, function names
are not exact!)


Quat current, target;
current.FromRotationMatrix( ent->EntityWorldTransform() );

target = current;
target = yaw( target, 10 ); //10 degrees to the right, this function is not
part of Quat class for some reason

current = Slerp( current, target, 0.2 ); //This is only 20%, you'll need to
calculate the angle difference between current/target, and then move based
on your angles per second speed.

matrix3x4_t newRot;
current.ToRotationMatrix( newRot );
ent->SetWorldTransform( newRot );



Enjoy!





On Thu, Mar 1, 2012 at 12:46 PM, Joel R.  wrote:

> The quaternion calculations you're doing are similar to just manipulating
> the Euler Angles, which cause Gimbal Lock.
>
> The way I did it in my flight simulation is to create a Current Quaternion
> (from the starting Matrix Transformation when user spawns) and Target
> Quaternion (where they want to rotate to).  I also used some formulas to
> rotate the quaternion in the individual yaw/pitch/roll orientations, I
> recommend googling for these formulas.  I then used the Slerp formula to
> animate from the Current quaternion to the Target quaternion. Slerp will
> avoid Gimbal-Lock entirely, which is very neat.
>
> After you do those calculations, just convert the new Current Quaternion
> into a Matrix Transformation and set the Entity to take that transform.
>
> I've used this to control the entity rotation as well as the camera, it
> allows you to do some pretty nifty tricks.
>
> I'll look for the code, if I still have it, and I'll post it here for
> you.  Or if you figure out, please post a video =D
>
> Regards,
>
> Joel
>
>
>
> On Thu, Mar 1, 2012 at 11:55 AM, Minh  wrote:
>
>>  You can try spitting out the results to a file so you can observe the
>> hitch more closely.
>> Look for a function called COM_Log
>>
>> COM_Log ( "viewangle_hitch.txt", "%.2f  %.2f  %.2f  \n",   viewangles.x,
>> viewangles.y, viewangles.z );
>>
>> On 3/1/2012 3:55 AM, Craig Louie wrote:
>>
>> Thanks for the reply Saul. I hadn't thought of disabling prediction. I
>> just gave it a shot. I changed to "engine->ClientCmd( "cl_predict 0" );" in
>> cdll_client_int.cpp. With another test, the unsmooth rotation when looking
>> straight up/down still occurs.
>>
>> My main theories at this point:
>> 1) Something is occurring in VectorAngles(vec_for_out, vec_up_out,
>> viewangles) to cause this. VectorAngles() might not produce straight
>> up/down Euler angles properly - choking because of aliasing perhaps? This
>> is a big guess because I don't know the inner workings of VectorAngles().
>> 2) There is some code somewhere else that is conflicting with the full,
>> unclamped rotation I've implemented. I've tried to remove all instances of
>> pitch clamping, for example. But I may have missed something. Also, it's
>> possible mouse rotation is somehow conflicting with my changes to joystick
>> rotation.
>>
>> Here's a video of the issue I'm seeing. It happens a few times in the
>> video. You'll see it happen the first time at about 11 seconds in when the
>> text on the floor twists/shakes.
>> http://www.youtube.com/watch?v=PLN641Qsn08
>>
>> Thanks!
>>
>>
>>
>> On Wed, Feb 29, 2012 at 11:34 PM, Saul Rennison 
>> wrote:
>>
>>> The hitching is most likely something trying to revert your angle
>>> changes (I.e. in prediction). Have you tried disabling prediction?
>>>
>>>
>>> On Thursday, March 1, 2012, Craig Louie wrote:
>>>
>>>> Hello Coders,
>>>>
>>>> I'm trying to create a space flight combat game with the Source SDK.
>>>> Currently, I am trying to achieve rotation around the player's local axes
>>>> for airplane-like pitch, yaw and roll. Below is the code I'm using to try
>>>> to implement full 3D rotation. I'm running into a problem where the
>>>> player's view twists and hitches unsmoothly when the player looks straight
>>>> up or straight down. I think this may be because of the inherent problem of

Re: [hlcoders] Rotation on the player's local axes

[Joel R.]

The quaternion calculations you're doing are similar to just manipulating
the Euler Angles, which cause Gimbal Lock.

The way I did it in my flight simulation is to create a Current Quaternion
(from the starting Matrix Transformation when user spawns) and Target
Quaternion (where they want to rotate to).  I also used some formulas to
rotate the quaternion in the individual yaw/pitch/roll orientations, I
recommend googling for these formulas.  I then used the Slerp formula to
animate from the Current quaternion to the Target quaternion. Slerp will
avoid Gimbal-Lock entirely, which is very neat.

After you do those calculations, just convert the new Current Quaternion
into a Matrix Transformation and set the Entity to take that transform.

I've used this to control the entity rotation as well as the camera, it
allows you to do some pretty nifty tricks.

I'll look for the code, if I still have it, and I'll post it here for you.
Or if you figure out, please post a video =D

Regards,

Joel


On Thu, Mar 1, 2012 at 11:55 AM, Minh  wrote:

>  You can try spitting out the results to a file so you can observe the
> hitch more closely.
> Look for a function called COM_Log
>
> COM_Log ( "viewangle_hitch.txt", "%.2f  %.2f  %.2f  \n",   viewangles.x,
> viewangles.y, viewangles.z );
>
> On 3/1/2012 3:55 AM, Craig Louie wrote:
>
> Thanks for the reply Saul. I hadn't thought of disabling prediction. I
> just gave it a shot. I changed to "engine->ClientCmd( "cl_predict 0" );" in
> cdll_client_int.cpp. With another test, the unsmooth rotation when looking
> straight up/down still occurs.
>
> My main theories at this point:
> 1) Something is occurring in VectorAngles(vec_for_out, vec_up_out,
> viewangles) to cause this. VectorAngles() might not produce straight
> up/down Euler angles properly - choking because of aliasing perhaps? This
> is a big guess because I don't know the inner workings of VectorAngles().
> 2) There is some code somewhere else that is conflicting with the full,
> unclamped rotation I've implemented. I've tried to remove all instances of
> pitch clamping, for example. But I may have missed something. Also, it's
> possible mouse rotation is somehow conflicting with my changes to joystick
> rotation.
>
> Here's a video of the issue I'm seeing. It happens a few times in the
> video. You'll see it happen the first time at about 11 seconds in when the
> text on the floor twists/shakes.
> http://www.youtube.com/watch?v=PLN641Qsn08
>
> Thanks!
>
>
>
> On Wed, Feb 29, 2012 at 11:34 PM, Saul Rennison 
> wrote:
>
>> The hitching is most likely something trying to revert your angle changes
>> (I.e. in prediction). Have you tried disabling prediction?
>>
>>
>> On Thursday, March 1, 2012, Craig Louie wrote:
>>
>>> Hello Coders,
>>>
>>> I'm trying to create a space flight combat game with the Source SDK.
>>> Currently, I am trying to achieve rotation around the player's local axes
>>> for airplane-like pitch, yaw and roll. Below is the code I'm using to try
>>> to implement full 3D rotation. I'm running into a problem where the
>>> player's view twists and hitches unsmoothly when the player looks straight
>>> up or straight down. I think this may be because of the inherent problem of
>>> aliasing/Gimbal-lock when using Euler angles. Any advise?
>>>
>>> //#
>>> //Take the Euler angles for the player's orientation (viewangles) and
>>> convert them to vectors.
>>> Vector vec_for, vec_rt, vec_up, vec_for_out, vec_rt_out, vec_up_out;
>>> AngleVectors(viewangles, &vec_for, &vec_rt, &vec_up);
>>>
>>> //Take the resulting vectors and the desired rotation amounts and
>>> convert them to Quaternions.
>>> Quaternion turn_q, look_q, roll_q;
>>> // NOTE: Assumes axis is a unit vector, non-unit vectors will bias the
>>> resulting rotation angle (but not the axis)
>>> VectorNormalize(vec_up);
>>> AxisAngleQuaternion(vec_up, turn_angle, turn_q);
>>>
>>> VectorNormalize(vec_rt);
>>> AxisAngleQuaternion(vec_rt, look_angle, look_q);
>>>
>>> VectorNormalize(vec_for);
>>> AxisAngleQuaternion(vec_for, roll_angle, roll_q);
>>>
>>> //Convert the quaternions to matrices.
>>> matrix3x4_t xform0, xform1, xform2;
>>> QuaternionMatrix(turn_q, xform0);
>>> QuaternionMatrix(look_q, xform1);
>>> QuaternionMatrix(roll_q, xform2);
>>>
>>> //Combine matrices.
>>> matrix3x4_t xformA, xformB;
>>> MatrixMultiply(xform0, xform1, xformA);
>>> MatrixMultiply(xformA, xform2, xformB);
>>>
>>> //Rotate the vectors with our combined rotation matrix.
>>> VectorRotate(vec_for, xformB, vec_for_out);
>>> VectorRotate(vec_rt, xformB, vec_rt_out);
>>> VectorRotate(vec_up, xformB, vec_up_out);
>>>
>>> //Determine the new viewangles based on our rotated vectors.
>>> VectorAngles(vec_for_out, vec_up_out, viewangles);
>>> //#
>>>
>>> I put this code into in_joystick.cpp in the JoyStickMove( float
>>> frametime, CUserCmd *cmd ) function.
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>
>>  --
>>
>>
>>  Kind 

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

[Joel R.]

It's actually on the map scratch mod map sdk_teams_hdr.bsp, and on my mod a
simple custom map with only 2 textures and absolutely no
shaders/particles/effects.

It could be that i'm in window mode, but i doubt it, its a low reso.

On Thu, Aug 11, 2011 at 11:14 PM, James Pizzurro <
ja...@agentredproductions.com> wrote:

> 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
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

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

[Joel R.]

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

Re: [hlcoders] Physics props 90° angle snap issue - (linux?)

[Joel R.]

Have you tested it on a windows dedicated server?  Listenservers don't act
entirely the same as dedicated servers.  It appears like the angle of the
physics object is updating a bad networked angle value.

On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer wrote:

>  As great as Noir Desir's song is, obviously it's not what I wanted to show
> :D
> Here's the real vid with the issue:
>
> *http://www.youtube.com/watch?v=QhmrP6eSAek*
>
> sorry for that.
>
>
> On 19/02/2011 9:15, Maarten De Meyer wrote:
>
> Hi list,
>
> we're facing an issue I don't immediately know where to start to debug.
> Basically, in all of our maps, some physics props have an issue where the
> orientation of their model snaps at 90° angles instantaneously. This is not
> only with props, but also eg with our vehicles, so I'm looking suspicously
> at vphysics :). In addition, this only seems to happen on our linux server.
> Not 100% sure, since it does not happen consistently on all props, but we've
> tried reproducing it a lot on a windows listenserver without success, and on
> our linux dedicated server it happens frequently. Here's a video of the
> issue:
>
> *http://www.youtube.com/watch?v=NrgcRvBJYBE*
>
> At one point we had a vehicle that stood still with a driver in it, and it
> did a 'snap' at nearly fixed intervals of several seconds. Player got out,
> it went away, player stepped in, it was back ( another reason for me to look
> at vphysics with the evil eye ).
>
> I'm hoping someone has hit this issue before, or can at least point me in
> the right direction, or, a method for debugging this. Since I'm not sure if
> it's related to vphysics linux internals, the linux build machine/settings,
> networking tolerances, ... I'm not sure where to start looking.
>
> Thanks for any feedback ( or sympathy :D ),
>
> Maarten
>
>
> ___
> 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] Learning how to program for the development of a Source mod

[Joel R.]

First thing, is making sure you understand C++.  Second, it helps if you
understand how the game engine is designed and what is readily available at
the top level.

The Source Engine is designed to give you quick and easy access to building
different weapons (server), changing movement code (shared), adding
networked variables from Server to Client (shared/separated), updating the
Player class for gameplay (shared/separated), managing spawns (server), and
creating custom entities (server/shared).

The more intermediate areas, are working with the User Interfaces (client),
VGUI and HUD, usually you use HUD for information that's always on your
screen and VGUI for inputs from the player, Input Controls (client),
Particle Effects (client), creating scripts for custom settings outside of
hard coding (server/client), and Client To Server networking.

The advanced areas of interest are, Rendering (client), Shaders (client),
Prediction (client/server), and Custom Animation (client).

There are of course more things you can do that I did not state, but to get
a grasp of the different things and their level of difficulty helps a bit.
The hardest thing to grasp as a beginner will probably be how the Client and
Server communicate, there are several ways they can communicate, and I
suggest you read about it on Valve's Wiki.


On Sat, Feb 12, 2011 at 12:54 PM, Marcus Posey
wrote:

> Great place to start looking is the Valve Developer Community.
> http://developer.valvesoftware.com/wiki/Main_Page
>
>
> On Sat, Feb 12, 2011 at 12:28 PM, Richard O'Brien wrote:
>
>>  I'm looking to try and learn how to program for a Source mod, but
>> struggling to find resources. I'm a Computer Science graduate and the
>> language I've mostly used is Java, but I just don't know really where to
>> start when it comes to games programming. I've never touched it before and I
>> don't know quite what's involved. Any help/pointers will be greatly
>> appreciated.
>>
>> Thanks
>>
>> --
>> Date: Sat, 12 Feb 2011 11:32:58 -0600
>> From: witsalldonebe...@gmail.com
>> To: hlcoders@list.valvesoftware.com
>> Subject: Re: [hlcoders] GoldSrc questions.
>>
>> Thanks Tom Edwards.
>>
>> On Sat, Feb 12, 2011 at 6:25 AM, Tom Edwards wrote:
>>
>>
>> http://web.archive.org/web/20070301012630/http://collective.valve-erc.com/index.php?go=q1_or_q2
>>
>>
>> On 12/02/2011 1:47, Marcus Posey wrote:
>>
>> Can you link to the source?
>>
>> On Fri, Feb 11, 2011 at 6:50 PM, Tom Schumann > schumann@gmail.com>> wrote:
>>
>>Actually, I just found it.
>>From the article titled "Half-Life's Code Basis" by Chris Bokitch,
>>originially posted on the VERC:
>>
>>What came first, the chicken or the egg? What is Half-Life built
>>on, Quake 1 or Quake 2? These questions pop up pretty frequently,
>>and neither seems to have an accepted answer. In an effort to
>>extinguish the argument, I've asked the people who know best.
>>About Half-Life, that is. We're not touching the question about
>>the chicken.
>>
>>Ken Birdwell explains it like this:
>>
>>"It is fundamentally just a heavily modified Quake 1 engine. There
>>are about 50 lines of code from the Quake 2 engine, mostly bugs
>>fixes to hard problems that Carmack found and fixed before we ran
>>into them."
>>
>>At its core, it's a Quake 1 engine. You can tell this by comparing
>>Half-life's map compiling tools with those shipped with Quake1.
>>You'll find very minor differences -- none of them are
>>fundamental. The core rendering is architecturally identical to
>>Quake1, the only "significant" change is removing the fixed
>>palette, making map lighting RGB instead of 8 bit, and converting
>>software rendering to be 16 bit color instead of 8 bit color,
>>which was pretty easy and only required minor code changes. Our
>>skeletal animation system is new, though it was heavily influenced
>>by the existing model rendering code, as were a lot of our updated
>>particle effects, though less so with our beam system. Decals are
>>totally new, our audio system has some major additions to what
>>already existed, and at ship time our networking was almost
>>totally Quake1 / QuakeWorld networking but about a year later Yahn
>>rewrote most of all of it to be very different in design. The most
>>highly changed sections are the game logic; ours being written in
>>C++ and Quake's being in written interpreted "Quake C". Our AI
>>system is very /very/ different from anything in Quake, and
>>there's a lot of other significant architectural changes in the
>>whole server and client implementations, though if you look hard
>>enough you can find a few remnants of some nearly unmodified
>>Quake1 era entities buried in places.
>>
>>Jay Stelly adds, "We also took PAS from QW and/or Q2 and a couple
>>of other minor routines I can remember (no more than 100-200 lines
>>of cod

Re: [hlcoders] Anaglyph Shaders

[Joel R.]

You could go cheap and just add a frame around the edges to hide the ugly
parts.

On Tue, Nov 9, 2010 at 11:17 AM, AndreaZzZ  wrote:

> Coding will solve this problem...
>
> 2010/11/9 Joel R. 
>
> > If you go outside of the 0.0 -> 1.0 range it will be capped to 0.0 or
> 1.0.
> > I can't think of a way to fix that problem, since it would require
> > rendering
> > a bigger view than the users resolution.
> >
> > On Tue, Nov 9, 2010 at 10:21 AM, AndreaZzZ  wrote:
> >
> > > Thanks, I did it. But there is a problem -
> > > http://img130.imageshack.us/img130/6206/testhardware0017.jpg (look at
> > the
> > > rocks)
> > >
> > > 2010/11/9 Joel R. 
> > >
> > > > HALF2 has the .x and .y properties.  So just do something like HALF2
> > > > leftCoord = ZeroTexCoord; leftCoord.x += left_pos; Then sample the
> > color
> > > at
> > > > the new coordinate.  However you should note, that the color you will
> > be
> > > > returning in that function will be for the original pixel location.
> > > >  Shaders
> > > > go from Top left corner to Top Right Corner and repeats until it
> > reaches
> > > > the
> > > > bottom most row.
> > > >
> > > > This means you'll have to work in reverse by sampling left or right
> > > towards
> > > > the "original" pixel, instead of working from the original pixel
> > outward.
> > > > It
> > > > would also be best to use different shader passes for each blue and
> red
> > > of
> > > > the anaglyph.
> > > >
> > > > On Tue, Nov 9, 2010 at 8:34 AM, AndreaZzZ 
> wrote:
> > > >
> > > > > I'm currently doing anaglyph. How to move left and right along the
> x
> > > > axis,
> > > > > my shader moves along the axes xy as correct?
> > > > > Code:
> > > > >
> > > > > sampler BaseTextureSampler : register( s0 );
> > > > >
> > > > > HALF4 main( HALF2 ZeroTexCoord : TEXCOORD0 ) : COLOR
> > > > > {
> > > > > float left_pos = 0.008;
> > > > > float right_pos = -0.008;
> > > > >
> > > > > float4 left = tex2D(BaseTextureSampler, ZeroTexCoord + left_pos);
> > > > > float4 right = tex2D(BaseTextureSampler, ZeroTexCoord + right_pos);
> > > > >
> > > > > float r = 0.7*left.g + 0.3*left.b;
> > > > > float g = 1*right.g;
> > > > > float b = 1*right.b;
> > > > >
> > > > > return float4(r, g, b, 1);
> > > > > }
> > > > >
> > > > >
> > > > > Sorry for my English because English isn't my native language.
> > > > > ___
> > > > > 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] Anaglyph Shaders

[Joel R.]

If you go outside of the 0.0 -> 1.0 range it will be capped to 0.0 or 1.0.
I can't think of a way to fix that problem, since it would require rendering
a bigger view than the users resolution.

On Tue, Nov 9, 2010 at 10:21 AM, AndreaZzZ  wrote:

> Thanks, I did it. But there is a problem -
> http://img130.imageshack.us/img130/6206/testhardware0017.jpg (look at the
> rocks)
>
> 2010/11/9 Joel R. 
>
> > HALF2 has the .x and .y properties.  So just do something like HALF2
> > leftCoord = ZeroTexCoord; leftCoord.x += left_pos; Then sample the color
> at
> > the new coordinate.  However you should note, that the color you will be
> > returning in that function will be for the original pixel location.
> >  Shaders
> > go from Top left corner to Top Right Corner and repeats until it reaches
> > the
> > bottom most row.
> >
> > This means you'll have to work in reverse by sampling left or right
> towards
> > the "original" pixel, instead of working from the original pixel outward.
> > It
> > would also be best to use different shader passes for each blue and red
> of
> > the anaglyph.
> >
> > On Tue, Nov 9, 2010 at 8:34 AM, AndreaZzZ  wrote:
> >
> > > I'm currently doing anaglyph. How to move left and right along the x
> > axis,
> > > my shader moves along the axes xy as correct?
> > > Code:
> > >
> > > sampler BaseTextureSampler : register( s0 );
> > >
> > > HALF4 main( HALF2 ZeroTexCoord : TEXCOORD0 ) : COLOR
> > > {
> > > float left_pos = 0.008;
> > > float right_pos = -0.008;
> > >
> > > float4 left = tex2D(BaseTextureSampler, ZeroTexCoord + left_pos);
> > > float4 right = tex2D(BaseTextureSampler, ZeroTexCoord + right_pos);
> > >
> > > float r = 0.7*left.g + 0.3*left.b;
> > > float g = 1*right.g;
> > > float b = 1*right.b;
> > >
> > > return float4(r, g, b, 1);
> > > }
> > >
> > >
> > > Sorry for my English because English isn't my native language.
> > > ___
> > > 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] Anaglyph Shaders

[Joel R.]

HALF2 has the .x and .y properties.  So just do something like HALF2
leftCoord = ZeroTexCoord; leftCoord.x += left_pos; Then sample the color at
the new coordinate.  However you should note, that the color you will be
returning in that function will be for the original pixel location.  Shaders
go from Top left corner to Top Right Corner and repeats until it reaches the
bottom most row.

This means you'll have to work in reverse by sampling left or right towards
the "original" pixel, instead of working from the original pixel outward. It
would also be best to use different shader passes for each blue and red of
the anaglyph.

On Tue, Nov 9, 2010 at 8:34 AM, AndreaZzZ  wrote:

> I'm currently doing anaglyph. How to move left and right along the x axis,
> my shader moves along the axes xy as correct?
> Code:
>
> sampler BaseTextureSampler : register( s0 );
>
> HALF4 main( HALF2 ZeroTexCoord : TEXCOORD0 ) : COLOR
> {
> float left_pos = 0.008;
> float right_pos = -0.008;
>
> float4 left = tex2D(BaseTextureSampler, ZeroTexCoord + left_pos);
> float4 right = tex2D(BaseTextureSampler, ZeroTexCoord + right_pos);
>
> float r = 0.7*left.g + 0.3*left.b;
> float g = 1*right.g;
> float b = 1*right.b;
>
> return float4(r, g, b, 1);
> }
>
>
> Sorry for my English because English isn't my native language.
> ___
> 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] TFC conc grenade effects - how to?

[Joel R.]

you can find the conc code in GoldSrc

On Fri, Oct 29, 2010 at 6:10 PM, Jeffrey "botman" Broome <
botman.hlcod...@gmail.com> wrote:

> I thought Valve never released the source to TFC or CS.
>
> GoldSrc downloads can be found here...
>
> http://www.fileplanet.com/32334/0/0/0/1/section/SDKs_/_Source_Code
>
>
> On 10/29/2010 6:01 PM, Andreas Grimm wrote:
>
>> where can i find the hl1 source? :-O
>>
>> -Original Message-
>> From: hlcoders-boun...@list.valvesoftware.com [mailto:
>> hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joel R.
>> Sent: Saturday, October 30, 2010 12:49 AM
>> To: Discussion of Half-Life Programming
>> Subject: Re: [hlcoders] TFC conc grenade effects - how to?
>>
>> The source code is in the hl1 source
>>
>> On Fri, Oct 29, 2010 at 5:23 PM, Andreas Grimm  wrote:
>>
>>  Hello,
>>>
>>> I have a question about the TFC conc grenade effect:
>>> http://www.youtube.com/watch?v=cMQAo9i0jGw
>>>
>>> After grenade detonation the viewangle circles around and the weapon
>>> seems
>>> to move around, too ...
>>>
>>> My firdst question: Is the same effect in Source games possible?
>>>
>>> And: Does anyone know which values I have to change there?
>>> For the player: Is it the viewangle vector only or something else, too?
>>> For the weapon: I have no idea how to move the viewmodel of the weapon
>>> like
>>> this :D
>>>
>>> A few tips would be great :)
>>>
>>> Andreas
>>>
>>>
>>> ___
>>> 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] TFC conc grenade effects - how to?

[Joel R.]

The source code is in the hl1 source

On Fri, Oct 29, 2010 at 5:23 PM, Andreas Grimm  wrote:

> Hello,
>
> I have a question about the TFC conc grenade effect:
> http://www.youtube.com/watch?v=cMQAo9i0jGw
>
> After grenade detonation the viewangle circles around and the weapon seems
> to move around, too ...
>
> My firdst question: Is the same effect in Source games possible?
>
> And: Does anyone know which values I have to change there?
> For the player: Is it the viewangle vector only or something else, too?
> For the weapon: I have no idea how to move the viewmodel of the weapon like
> this :D
>
> A few tips would be great :)
>
> Andreas
>
>
> ___
> 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] Duke Nukem Forever Whiteboard in Source?

[Joel R.]

You'd first have to know the size of the board.  Then just use a ray trace
to capture where on the board you are clicking and convert to 2D
coordinates.  Then using a RenderTarget for the board texture, you should be
able to edit the image directly pixel by pixel.  I don't remember the exact
functions anymore, but it is possible.


On Sun, Oct 3, 2010 at 2:23 PM, Trevor 'Drak'  wrote:

> I'm sure most of you have seen the DNF game play videos. If not, you're
> crazy and need to watch this: http://www.youtube.com/watch?v=SDjJRRbOvzU
> Skip to about 4 minutes for the gameplay. As you can see there is a
> whiteboard that you can draw/erase (change colors?) and it's pretty darn
> realistic.
>
> Soon as I saw this awhile back from a different video, I attempted to
> replicate it with in Source.
> All I managed todo was create a 3D VGUI Screen (assuming this is the best
> way) with a whiteboard background. And then looked within the Alien Swarm
> SDK
> to see how the radar, where you can draw on it, was done. Pretty
> unsuccessful. Got nowhere close. I skipped and tried figuring out how I
> could change my mouse cursor on the screen to a pen, or eraser and such.
> Unable to figure it out.
>
> Would anybody know how to even get something close to this, or just point
> in any direction that could possibly lead me into figuring it out?
> 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

Re: [hlcoders] gameinfo.txt doesn't exist

[Joel R.]

I had this too, I can't remember what fixed it, but try:

- Add your mod to the GameConfig.txt.
- Run the Source SDK Base 200X from Tools at least once.


On Fri, Jul 16, 2010 at 3:59 PM, adam chance
wrote:

> When I Debug my Mod, I get this error
>
> Setup file 'gameindo.txt' doesn't exist in subdirectory 'hl2'.
> Check your -game parameter or VCONFIG setting.
>
> What do I do?
> ___
> 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 2!!!

[Joel R.]

Please enlighten me then, Marek.  Voxels can be better the smaller they are,
and in a few years will be better suited when we have more powerful
computers.  Many are still struggling to even play TF2 with their current
machines.  So yes, I'm retarded because I thought ahead of your small mind.

On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland wrote:

> That's the plan. He's hoping to do something similar to id tech 5's
> megatexture technology for geometry. It's called sparse voxel octree
> technology
>
> Basically(from what I understand), the idea is to make the voxels very
> very small to allow for high fidelity, but to only load the depth of
> the octree that could be seen at the current resolution, therefore
> allowing for incredibly detailed models, that only stream the small
> details if they could be seen at the current resolution. This is a big
> step up from LOD where the programmer basically has to guess where to
> swap the models out (and they need to be separate models)
>
> On 18 June 2010 18:42, Harry Jeffery 
> wrote:
> > I believe John Carmack is hoping to use voxels in id Tech 6. That
> > engine's only 10 years away so who knows, this could be the future but
> > we wont find out until we get there.
> >
> > On 18 June 2010 17:26, Harry Pidcock  wrote:
> >> Ray traced polygon rendering is quite an expensive task on a CPU.
> >>
> >> But real time point cloud rendering can be done on it quite well.
> >>
> >> http://www.youtube.com/watch?v=Q-ATtrImCx4
> >>
> >> Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
> marketing
> >> budget.
> >>
> >>
> >> This video is rendered in real time on a single core CPU, although it is
> >> only rendering at like 800x600,
> >> if the algorithm had some parallelism, maybe even have it developed for
> >> GPUs/hardware specialization. Then it would certainly be
> >> able to render large amounts of detail at a higher resolution.
> >>
> >> Although it doesn't have any advanced shading, it is still quite
> interesting
> >> to see such a complex static environment drawn with a single CPU thread.
> >>
> >> Of course there are huge computational and memory issues with bone
> >> animation, shading, transparency etc. So don't think you will see this
> in
> >> the next 5 - 10years.
> >>
> >> --
> >> From: "Jonathan Murphy" 
> >> Sent: Saturday, June 19, 2010 12:31 AM
> >> To: "Discussion of Half-Life Programming" <
> hlcoders@list.valvesoftware.com>
> >> Subject: Re: [hlcoders] Source Engine 2!!!
> >>
> >>> Katrina, you might be interested in reading up on Real Time
> >>> Raytracing, which is an alternative to rasterisation (GPU) based
> >>> rendering and is/has been extensively researched and even implemented.
> >>>
> >>> http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
> >>> http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
> >>>
> >>> At the moment though it seems GPUs are going to stay very mainstream.
> >>>
> >>> On Saturday, June 19, 2010, joshua simmons 
> wrote:
>  Oh yeah I understand. There is only very rudmentry 3d support, in no
> way
>  capable of supporting any game. My point was more on the radical rate
> at
>  which they are evolving in comparison. Even the purely reverse
> engineered
>  open source NVIDIA driver is out doing the proprietary one in terms of
>  2d.
>  Now I of course realise there is a big jump from that to capable 3d,
> but
>  considering (iirc) amd have developers working on the open source
> driver,
>  I
>  see it as mainly a matter of time before it becomes a viable
> alternative.
> 
>  On 18 Jun 2010 22:01, "Bob Somers"  wrote:
> 
>  Katrina, I'm not giving lectures on computer graphics here. Google has
>  all the information you asked for. If you'd like, I can also recommend
>  some graphics textbooks which would clear things up. Also, saying a
>  Linux system running on a 100 MHz machine is comparable to Windows
>  running on a 2 GHz machine is a ridiculous overstatement. They are not
>  that radically different. If you're so convinced you can make the
>  words best software renderer, by all means go do it. I'm sure at the
>  very least you can wave your SIGGRAPH paper in our faces when you're
>  done.
> 
>  Josh, I'm not sure you can call it better Linux support if their 3D
>  support is... well... really bad. They may have opened up their
>  hardware spec so that the free drivers can get rolling (I have tried
>  the new drivers in Fedora 13 and they are quite good so far), but the
>  free drivers are at least a year behind their Windows counterpart in
>  terms of supporting the full features of the cards. There is virtually
>  zero shader support in the free drivers at this point. nVidia's
>  drivers, on the other hand, may be proprietary, but at least you can
>  get decent 3D perf

Re: [hlcoders] Source Engine 2!!!

[Joel R.]

Voxels were the first thing used in 3d graphics, they are pretty horrible
compared to today's standards.

On Fri, Jun 18, 2010 at 12:42 PM, Harry Jeffery <
harry101jeff...@googlemail.com> wrote:

> I believe John Carmack is hoping to use voxels in id Tech 6. That
> engine's only 10 years away so who knows, this could be the future but
> we wont find out until we get there.
>
> On 18 June 2010 17:26, Harry Pidcock  wrote:
> > Ray traced polygon rendering is quite an expensive task on a CPU.
> >
> > But real time point cloud rendering can be done on it quite well.
> >
> > http://www.youtube.com/watch?v=Q-ATtrImCx4
> >
> > Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
> marketing
> > budget.
> >
> >
> > This video is rendered in real time on a single core CPU, although it is
> > only rendering at like 800x600,
> > if the algorithm had some parallelism, maybe even have it developed for
> > GPUs/hardware specialization. Then it would certainly be
> > able to render large amounts of detail at a higher resolution.
> >
> > Although it doesn't have any advanced shading, it is still quite
> interesting
> > to see such a complex static environment drawn with a single CPU thread.
> >
> > Of course there are huge computational and memory issues with bone
> > animation, shading, transparency etc. So don't think you will see this in
> > the next 5 - 10years.
> >
> > --
> > From: "Jonathan Murphy" 
> > Sent: Saturday, June 19, 2010 12:31 AM
> > To: "Discussion of Half-Life Programming" <
> hlcoders@list.valvesoftware.com>
> > Subject: Re: [hlcoders] Source Engine 2!!!
> >
> >> Katrina, you might be interested in reading up on Real Time
> >> Raytracing, which is an alternative to rasterisation (GPU) based
> >> rendering and is/has been extensively researched and even implemented.
> >>
> >> http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
> >> http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
> >>
> >> At the moment though it seems GPUs are going to stay very mainstream.
> >>
> >> On Saturday, June 19, 2010, joshua simmons 
> wrote:
> >>> Oh yeah I understand. There is only very rudmentry 3d support, in no
> way
> >>> capable of supporting any game. My point was more on the radical rate
> at
> >>> which they are evolving in comparison. Even the purely reverse
> engineered
> >>> open source NVIDIA driver is out doing the proprietary one in terms of
> >>> 2d.
> >>> Now I of course realise there is a big jump from that to capable 3d,
> but
> >>> considering (iirc) amd have developers working on the open source
> driver,
> >>> I
> >>> see it as mainly a matter of time before it becomes a viable
> alternative.
> >>>
> >>> On 18 Jun 2010 22:01, "Bob Somers"  wrote:
> >>>
> >>> Katrina, I'm not giving lectures on computer graphics here. Google has
> >>> all the information you asked for. If you'd like, I can also recommend
> >>> some graphics textbooks which would clear things up. Also, saying a
> >>> Linux system running on a 100 MHz machine is comparable to Windows
> >>> running on a 2 GHz machine is a ridiculous overstatement. They are not
> >>> that radically different. If you're so convinced you can make the
> >>> words best software renderer, by all means go do it. I'm sure at the
> >>> very least you can wave your SIGGRAPH paper in our faces when you're
> >>> done.
> >>>
> >>> Josh, I'm not sure you can call it better Linux support if their 3D
> >>> support is... well... really bad. They may have opened up their
> >>> hardware spec so that the free drivers can get rolling (I have tried
> >>> the new drivers in Fedora 13 and they are quite good so far), but the
> >>> free drivers are at least a year behind their Windows counterpart in
> >>> terms of supporting the full features of the cards. There is virtually
> >>> zero shader support in the free drivers at this point. nVidia's
> >>> drivers, on the other hand, may be proprietary, but at least you can
> >>> get decent 3D performance out of the machine on a current distro. The
> >>> proprietary ATI driver has decent support and performance, but it
> >>> won't run on anything newer than Fedora 11. (Sorry if I keep
> >>> referencing things in terms of Fedora versions, it's my distro of
> >>> choice.)
> >>>
> >>> I'm all for free software, don't get me wrong. I would love for
> >>> nothing more than to have free alternative drivers for ATI and nVidia
> >>> cards, but if gaming is really going to be commercially viable on the
> >>> Linux desktop it's the performance that matters. No publisher is going
> >>> to bother trying to ship a game for Linux where the poor driver
> >>> support is going to cause them support headaches all day long.
> >>>
> >>> --Bob
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons 
> >>> wrote:
>  Actually to be h...
> >>>
>  To unsubscribe, edit your list preferences, or view th

[hlcoders] Source Engine 2!!!

[Joel R.]

Is this the big surprise for E3?!  I hope it is, that would so rock!
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

[Joel R.]

Portal 2 isn't due to be released until 2011.  There are 2 reasons this
could be.  First reason, this is one of the first mods their testing on
Source Engine 2.  Second reason, they lost their code and have to redo
everything.

On Thu, Jun 10, 2010 at 2:20 PM, Shawn P. Zipay wrote:

> They already said the surprise is Portal 2 related.  They made that very
> painfully clear in the last press release sent out about the Portal 2
> delay.
>
> Shawn P. Zipay
> Community Manager
>
> MyInternetServices -- http://www.myinternetservices.com
> CS-Nation -- http://www.csnation.net
> Total Gaming Network -- http://www.totalgamingnetwork.com
>
>
> On Thu, Jun 10, 2010 at 3:16 PM, Tom Edwards  >wrote:
>
> > We're on Source 15 already, keep up!
> >
> > On 10/06/2010 8:07, Joel R. wrote:
> > > Is this the big surprise for E3?!  I hope it is, that would so rock!
> > > ___
> > > 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] Happy St.Patricks Day

[Joel R.]

Cheers lad!



On Wed, Mar 17, 2010 at 12:09 PM, cathal mc nally wrote:

> Just thought Id lighten the Mood a wee bit
> So Happy Paddys day from a friendly Irish Coder
> :)
> have a few on me
>
> regards
> FooFighter
>
> Send instant messages to your online friends http://uk.messenger.yahoo.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] Of hats, bonemerged models and things.

[Joel R.]

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

Re: [hlcoders] Discussion, Joel R. has invited you to open a Google mail account

[Joel R.]

shit, wrong person, ignore.

On Fri, Dec 11, 2009 at 10:06 AM, Didrole  wrote:

> SPAM
>
> 2009/12/11 Joel R. 
>
> > I've been using Gmail and thought you might like to try it out. Here's
> > an invitation to create an account.
> >
> > -------
> >
> > Joel R. has invited you to open a free Gmail account.
> >
> > To accept this invitation and register for your account, visit
> > http://mail.google.com/mail/a-7ab4886b1-4403d80fb7-81761ab28c15aa81
> >
> > Once you create your account, Joel R. will be notified with
> > your new email address so you can stay in touch with Gmail!
> >
> > If you haven't already heard about Gmail, it's a new search-based webmail
> > service that offers:
> >
> > - Over 2,700 megabytes (two gigabytes) of free storage
> > - Built-in Google search that instantly finds any message you want
> > - Automatic arrangement of messages and related replies into
> >  "conversations"
> > - Powerful spam protection using innovative Google technology
> > - No large, annoying ads--just small text ads and related pages that are
> >  relevant to the content of your messages
> >
> > To learn more about Gmail before registering, visit:
> > http://mail.google.com/mail/help/benefits.html
> >
> > And, to see how easy it can be to switch to a new email service, check
> > out our new switch guide: http://mail.google.com/mail/help/switch/
> >
> > We're still working every day to improve Gmail, so we might ask for your
> > comments and suggestions periodically.  We hope you'll like Gmail.  We
> > do.  And, it's only going to get better.
> >
> > Thanks,
> >
> > The Gmail Team
> >
> > (If clicking the URLs in this message does not work, copy and paste them
> > into the address bar of your browser).
> >
> > ___
> > 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] Discussion, Joel R. has invited you to open a Google mail account

[Joel R.]

I've been using Gmail and thought you might like to try it out. Here's
an invitation to create an account.

-------

Joel R. has invited you to open a free Gmail account.

To accept this invitation and register for your account, visit
http://mail.google.com/mail/a-7ab4886b1-4403d80fb7-81761ab28c15aa81

Once you create your account, Joel R. will be notified with
your new email address so you can stay in touch with Gmail!

If you haven't already heard about Gmail, it's a new search-based webmail
service that offers:

- Over 2,700 megabytes (two gigabytes) of free storage
- Built-in Google search that instantly finds any message you want
- Automatic arrangement of messages and related replies into
  "conversations"
- Powerful spam protection using innovative Google technology
- No large, annoying ads--just small text ads and related pages that are
  relevant to the content of your messages

To learn more about Gmail before registering, visit:
http://mail.google.com/mail/help/benefits.html

And, to see how easy it can be to switch to a new email service, check
out our new switch guide: http://mail.google.com/mail/help/switch/

We're still working every day to improve Gmail, so we might ask for your
comments and suggestions periodically.  We hope you'll like Gmail.  We
do.  And, it's only going to get better.

Thanks,

The Gmail Team

(If clicking the URLs in this message does not work, copy and paste them
into the address bar of your browser).

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

Re: [hlcoders] client-side game events

[Joel R.]

Protection service for cheat server plugins?  Sounds like a scam.


On Fri, Dec 11, 2009 at 9:25 AM, Ronny Schedel wrote:

> No one said a server plugin cannot be used for cheating, the fact, it is
> used frequently for cheating and this is a problem. Some game server
> companies offers you a protection service about cheat server plugins.
>
>
> > wow.. i really tought that client side events detection were
> > factible (bad inglish mode ON)
> >
> > if that was true about VAC banned.. why a client-side plugin can
> > be
> > a cheating plugin, and a server-side plugin not?..
> >
> > i just wanted to make a client-side plugin to make easier record
> > demos.
> > and when a player dies. stop it. and record with other name
> > automatically. so, it's impossible? ):
> >
> >
> > 2009/12/11 Jacob Heidt 
> >
> >> True indeed. The way that those dirty cheaters tend to get their hands
> on
> >> the internals, events etc, is through vfunc hooks - take a look at the
> >> SourceHook library in MetaMod:Source.
> >> However, I would like to advise against client side mods/hooks on
> >> mods/games
> >> that are not yours. You may be VAC banned for detection of client side
> >> hooks, since 99.% of 3rd party client side hooks are from dirty
> >> rotten
> >> cheaters.
> >>
> >> .jheidt
> >>
> >> -Original Message-
> >> From: hlcoders-boun...@list.valvesoftware.com
> >> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Ronny
> >> Schedel
> >> Sent: Friday, December 11, 2009 10:02 AM
> >> To: Discussion of Half-Life Programming
> >> Subject: Re: [hlcoders] client-side game events
> >>
> >>
> >> I don't think it's possible with the provided interface system by Valve,
> >> two
> >>
> >> reasons:
> >>
> >> 1. Valve don't want to have their mods altered again.
> >> 2. No one likes cheats.
> >>
> >>
> >> > too bad!, i liked so much bananas! ):
> >> >
> >> > this is how i defined CEmptyServerPlugin:
> >> >
> >> >
> >> > class CEmptyServerPlugin: public IServerPluginCallbacks, public
> >> > IGameEventListener2
> >> > {
> >> > [...]
> >> > }
> >> >
> >> > but there's not any "IClientPluginCallbacks" maybe i need an include
> >> > that
> >> > is
> >> > not come with the example?
> >> >
> >> > what should i do to capture CLIENT events?
> >> >
> >> > PD: please. i'm not an experienced programmer. dont laught of
> >> > me ):
> >> >
> >> >
> >> > 2009/12/11 Ronny Schedel 
> >> >
> >> >> One million dollar question: what is the CEmptyServerPlugin for?
> >> >>
> >> >> 1) servers
> >> >> 2) clients
> >> >> 3) bananas
> >> >>
> >> >> If it is too difficult for you, here is a hint: it's not number 3.
> >> >>
> >> >>
> >> >> > hello again!
> >> >> >
> >> >> > i'm a bit confused about how events are managed in game (team
> >> >> > fortress
> >> >> > 2)
> >> >> >
> >> >> > actually, i'm coding a CLIENT SIDE plugin, in wich i need to detect
> >> the
> >> >> > "player_death" event...
> >> >> >
> >> >> > this is what i got...
> >> >> >
> >> >> > void CEmptyServerPlugin::FireGameEvent( IGameEvent * event )
> >> >> > {
> >> >> >const char* eventName = event->GetName();
> >> >> >int _short;
> >> >> >
> >> >> >if( FStrEq( eventName, "player_death"))
> >> >> >{
> >> >> >_short = event->GetInt( "userid");
> >> >> >
> >> >> >player_info_t pinfo;
> >> >> >engineclient->GetPlayerInfo(engineclient->GetLocalPlayer(),
> >> >> > &pinfo);
> >> >> >
> >> >> >//verifify that client dies
> >> >> >if( _short == pinfo.userID)
> >> >> >{
> >> >> >//code here
> >> >> >}
> >> >> >}
> >> >> > }
> >> >> >
> >> >> >
> >> >> > this work well, when i create a server in the game. but when i
> >> play
> >> >> in
> >> >> > public servers. it doesn't work
> >> >> >
> >> >> > and this is what confuse me:
> >> >> > to make this code work in public servers. first i have to
> create
> >> my
> >> >> > own
> >> >> > server, and then connect to other i want
> >> >> >
> >> >> > why this happen?, what should i do?. i'm really confused
> >> >> > here
> >> >> >
> >> >> >
> >> >> > my own investigations in google, told me that using
> >> >> > "CEmptyServerPlugin"
> >> >> > is
> >> >> > the problem,. i don't know
> >> >> >
> >> >> >
> >> >> > nice to met you all!, and greetings from Chile! :D
> >> >> >
> >> >> > PD: sorry for my bad english
> >> >> > ___
> >> >> > 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
> >> >>
> >> >>
> >> > ___
> >> > T

Re: [hlcoders] Garry's Mod - gamemode contest

[Joel R.]

Definately a good place to post this, I would have never have seen it.
Looks like I may have to win 10 grand.

On Wed, Dec 2, 2009 at 11:16 AM, Lech  wrote:

> Whoever remakes Build Bridge/To The Top automatically wins 1st place!
>
>
> On Wed, Dec 2, 2009 at 9:29 AM, Garry Newman 
> wrote:
> > I don't know whether this will be considered spam, but I thought I'd let
> the
> > list know about this contest incase anyone's interested (to my mind it's
> > probably the 2nd most logical place to post this)
> >
> > The basic facts are this. Coding a gamemode for GMod, using Lua. Best 5
> > gamemodes win a prize. Top prize is $5,000.
> >
> > I'm sure a lot of people here know C++, and the Source engine, but don't
> > really know Lua.. To be totally honest if you could code a mod you will
> find
> > it insanely easy to code one in Lua. Many of the functions are named the
> > same, you don't have to code common things like class or round based
> systems
> > because they're already done.
> >
> > You can read more about it here:
> http://frettacontest.facepunchstudios.com/
> >
> > garry
> > ___
> > 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] Arbitrary Gravity Direction

[Joel R.]

This is very very possible.

Objectives and problems you have to overcome to meet this goal:


   - Use Quaternions to break Gimbal Locking (happens with Matrix and Euler
   Angles). You can download a nice set of Quaternion functions from Ogre
   Engine (free download) and with some slight tweaks they will work on
   Source.  Quaternions are basically an Up Direction (vector), and an Angle
   (float).  There is a function called "Slerp" that will let you smoothly
   orient between 2 quaternions.  There are multiple ways to create Quaternions
   using Matrices or Vectors.


   - You'll have to keep a new vector that saves your "gravity direction".
   If you want to orient automatically you'll need to constantly trace
   downwards along your gravity direction and based on the new Ground Normal,
   allow orientation or not.


   - Source uses AABB which means your player box will never rotate, ever.
   This causes a problem with your origin.  When you rotate onto a wall, your
   origin will be much closer to the ground than before. Simply hack around
   this by adjusting your RenderOrigin up X units off the ground (when you are
   on it of course).


   - Jumping was one of the bigger problems I first encountered. This is
   better suited for orientations based on events, if you want automatic
   orientation based on the ground the player is on, you'll need to have
   multiple traces of different lengths to make sure you maintain the correct
   orientation.  You can also trigger going to a default gravity if you are in
   the air too long or the ground your over is to complicated or is orienting
   too fast.


   - You'll have to orient your models correctly.  Models use Euler Angles
   for orientation, so if you use Quaternions, you'll have to convert to Matrix
   and then to Euler Angles.  Not such a biggy, but Euler angles were never
   meant for 6 degrees of freedom usage. If you want to use them, only use them
   in the local world space where everything is oriented at (0,0,1).  Then
   convert to world space.


   - Wall collision is another big problem you will encounter.  Since you
   won't have the luxury of using the players bounding box for tracing, you'll
   have to be accurate with line traces.  I constantly found myself getting
   knocked off the ground because of odd terrain.  Stairs is another wall
   collision problem you have to face.  This requires more line traces going in
   your movement direction starting from the top of your player model to the
   middle and so on. You have to make sure you can actually move forward if not
   you'll get yourself stuck in the terrain.


   - Other Entities is the last problem.  So far you've only managed the
   players.  Now you have to manage all other entity objects.  You'll have to
   follow the same basic principles as the player orientation depending on what
   your entities do. Physics entities have to all orient based on the same
   gravity direction, if you want each one to have it's own orientation, you'll
   need to work with the physics interface.  This requires managing the angular
   velocity and linear velocity.   This is more complicated, and if you can
   pull off the player orientation, you should be able to figure a way to do
   this.




On Wed, Oct 14, 2009 at 3:21 PM, Adam "amckern" McKern wrote:

> Its possible, but very hard to get going - though i did not change the
> view, i did make it so that your movement is dependent on shooting weapons
> in a ZeroG environment
>
> http://www.nigredostudios.com/prime/screenshots/zerog0002.jpg
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
> --- On Thu, 15/10/09, Tony Paloma  wrote:
>
> From: Tony Paloma 
> Subject: Re: [hlcoders] Arbitrary Gravity Direction
> To: "'Discussion of Half-Life Programming'" <
> hlcoders@list.valvesoftware.com>
> Received: Thursday, 15 October, 2009, 4:08 AM
>
> IPhysicsEnvironment has a function called SetGravity that takes a Vector.
> You can use it to set an arbitrary direction for gravity, but it will work
> for VPhysics objects only. I didn't check if this information was in that
> thread you posted. Sorry if it was.
>
> If you have an instance of VPHYSICS_INTERFACE_VERSION, you can get the
> environment by:
> pPhysics->GetActiveEnvironmentByIndex(0);
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of
> a...@watkins.to
> Sent: Wednesday, October 14, 2009 6:39 AM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] Arbitrary Gravity Direction
>
> See this thread for a discussion and partial implementation of arbitrary
> gravity direction.
> http://forums.steampowered.com/forums/showthread.php?t=778484
>
> I never got it working entirely right, and gave up on it anyway :)
> And it never did props.
>
> --
> This message was sent on behalf of a...@watkins.to at openSubscriber.com
>
> http://www.opensubscriber.com/message/hlcoders@list.valv

Re: [hlcoders] Do high ping players cause extra lag?

[Joel R.]

The ones who say, "high pingers lag everyone else", play too much starcraft.


On Tue, Oct 13, 2009 at 1:03 PM, Ryan Sheffer  wrote:

> The only thing I would consider with a high pinging player would be spikes
> severe enough to cause a full client update to that player, which might
> fail
> and call another full client update. It is unreasonable to think this would
> happen though, but its the only thing I can think of. Other than that, I
> would go with the fact that a player with 250 ping looks laggy to players
> with 50 ping.
>
> On Tue, Oct 13, 2009 at 7:46 AM, Andrew Ritchie 
> wrote:
>
> > "Extra" load on servers would imply a 100 ping player and a 500 ping
> player
> > require different amounts of processing.  The 2 obvious places this could
> > potentially occur in Source are the think/movement calculations on each
> > packet and rewinding players in prediction for the shot calculations.
>  The
> > former *might* be an issue if Source calculates and runs every individual
> > command packet and accumulates them between tick frames.  However that'd
> > not
> > be any more or less packets to calculate for someone with a higher ping,
> it
> > would just mean their commands arrive later.  If there's a lot of choke
> or
> > backup in deliveries then it might be a case of they all arrive and are
> > processed at one time.  That all boils down to the individual engines'
> > handling of packets, worst case would also be if an engine waited on and
> > demanded synchronized packet order which could throw a spanner in the
> works
> > on a dodgey connection, and that is really dependent on the networking
> > model
> > the developers chose.
> >
> > I'm sure you already know all that, so just confirming that there's a lot
> > of
> > different things that could potentially cause high pings to upset a game
> > server.  However if it's a consistent connection most people will just be
> > complaining because prediction isn't perfect and extrapolation on high
> > latency players will be more prone cause noticeable divergences from
> actual
> > data from time to time.
> >
> > On Tue, Oct 13, 2009 at 1:23 PM, Marek Sieradzki
> > wrote:
> >
> > > HL1 is ancient.
> > >
> > > ___
> > > 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
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] getting animation velocity and applying it to player

[Joel R.]

You have to convert it to World Coordinates:

VectorTransform( vecLocalOrigin, EntityToWorldTransform(), vecResultOrigin);




On Fri, Sep 25, 2009 at 7:35 PM, Ryan Sheffer  wrote:

> I guess all I can say is if the GetBonePosition function is returning the
> local origin instead of the offset from the global origin.
>
> And I was thinking something like,
>
> vector v_direction = NewBoneOrigin - PreviousBoneOrigin;
> float length_moved = v_direction.Length2D(); // I dont remember the
> magnitude function, its something like Length2D.
>
> Then you have a distance traveled plus a direction of movement which you
> could clamp how you see fit.
> length_moved could be used to determine a velocity for that frame.
>
> On Fri, Sep 25, 2009 at 1:07 AM, Michael Chang  >wrote:
>
> > >
> > > Micheal, as you know I'm doing something rather similar. I've gotten it
> > > working reasonably well, but in truth I don't like the way I have it
> > > working. It's laggy and a bit jumpy, and plays terribly for players
> with
> > > latency more than 50. But I can basically show you how it works, here's
> > the
> > > abridged version:
> > >
> >
> > Jorge:
> > Dude thanks again for sharing the code. Much appreciated.
> >
> > I've spent a good deal of time trying to get this to work the way I want.
> > There seems to be some oddities with GetIntervalMovement. When I print
> out
> > the deltas for newPosition - GetLocaPosition(), what appears to be
> > happening
> > is that
> >
> > 1. When I'm not moving, the deltas are incorrect and extremely small.
> > 2. When I'm pressing +forward the deltas are correct and the player
> > animates
> > correctly.
> >
> > What's the relationship with GetIntervalMovement and user commands? I've
> > traced all the lines of code with Studio_Seq stuff and nothing seems to
> > care
> > about current speed or input. I'm at a total loss as to why
> > GetIntervalMovement would return different things based on whether or not
> > I'm trying to move!!
> >
> >
> >
> > You could get a bone position (spine bone perhaps) and save that, and
> frame
> > > by frame compare the distance the bone traveled to get a velocity from
> > that
> > > and apply it to the player. Maybe this isn't what you want thought. ;)
> > >
> > >
> > Ryan:
> >
> > I spent about a minute sketching this out not expecting it to work and
> not
> > surprisingly it didn't.
> >
> >int boneNum = player->LookupBone("ValveBiped.Bip01_Pelvis");
> >if(boneNum==-1)
> >return;
> >
> >Vector bonePos;
> >QAngle boneAngle;
> >player->GetBonePosition(boneNum, bonePos, boneAngle);
> >
> >if(lastBonePos == vec3_origin){
> >lastBonePos = bonePos;
> >return;
> >}
> >
> >Vector delta = bonePos-lastBonePos;
> >mv->m_vecVelocity = delta/gpGlobals->frametime;
> >lastBonePos = bonePos;
> >
> > What would be the right approach to this? This doesn't seem right at all.
> >
> >
> > Thanks for your patience guys. I guess I'm trying to do something that's
> > not
> > very common in Source so there's not much documentation on this at all :|
> >
> > ~M
> > ___
> > 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] Optimising projectile bandwidth

[Joel R.]

cl_entityreport 1

This shows you a list of all entities and bars to show how much networking
their doing.

On Thu, Sep 17, 2009 at 1:54 AM, Andrew Armstrong wrote:

> I forget the command (check this lists archives or the wiki?) but you can
> turn on a cvar to make network packet info appear above the head of each
> entity, so you can immediately see who is responsible for sending how much
> data per packet, pretty neat.
>
> - Andrew
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Adam
> "amckern"
> McKern
> Sent: Thursday, 17 September 2009 12:07 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Optimising projectile bandwidth
>
> Coders,
>
> Just wondering, how do you find the bandwidth, and the packet size of your
> code?
>
> I have always messed around with sp code, and had NO Need to worry about
> this before, but SvenCoop is having heaps of new features tossed in at the
> moment, and i want to check that we are not going to flood, or starve the
> client with net data.
>
> Adam
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
> --- On Wed, 16/9/09, Andrew Armstrong  wrote:
>
> From: Andrew Armstrong 
> Subject: Re: [hlcoders] Optimising projectile bandwidth
> To: "'Discussion of Half-Life Programming'"
> 
> Received: Wednesday, 16 September, 2009, 7:48 AM
>
> Yeah of course, I was just thinking though you may be able to alter how
> often updates are sent since the rocket won't be making a right angle turn
> :) after its been shot and given a constant velocity the client should be
> pretty accurate as to where the rocket is (so more updates, and bandwidth
> usage, should not be necessary).
>
> - Andrew
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joel R.
> Sent: Tuesday, 15 September 2009 11:37 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Optimising projectile bandwidth
>
> Prediction doesn't stop the server from sending you updates, because if
> your
> clientside values go out of range you have set, it snaps to the server's
> values.
>
> On Tue, Sep 15, 2009 at 8:02 AM, Andrew Armstrong
> wrote:
>
> > I have not played with the game SDK before (just for server plugins), but
> > surely client side prediction can step in here and you can relax how
> often
> > you send updates?
> >
> > If the client received the origin, direction and velocity of the rocket,
> > client side prediction would take care of movnig the projectile fine
> (like
> > player movements).
> >
> > Can you maybe make it client side predicted (is there a flag? how do
> > players
> > and other entities auto predict?) and just relax how often you send
> > updates,
> > given that the rocket won't be changing direction/velocity?
> >
> > - Andrew
> >
> > -Original Message-
> > From: hlcoders-boun...@list.valvesoftware.com
> > [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom
> Edwards
> > Sent: Tuesday, 15 September 2009 8:28 PM
> > To: Discussion of Half-Life Programming
> > Subject: Re: [hlcoders] Optimising projectile bandwidth
> >
> > Thanks Joel, that sounds like it would work. I realised earlier today
> > however that what I'm trying to do is a bad idea no matter how I handle
> > it, because if either the client or the server ever started to choke on
> > some frames the rockets risk going out of sync.
> >
> > It might be possible to overcome that issue, but only by writing a lot
> > of fairly low-level code: I can only assume that Valve's existing code
> > all assumes that the origin is being transmitted if the position of an
> > entity is in any way important.
> >
> > Oh well. It was worth thinking about. :-)
> >
> > Joel R. wrote:
> > > It's kind of tricky to do something like this.
> > >
> > > I recommend using a server-side only rocket entity that has
> TransmitState
> > > disabled.  Then use a *reliable* UserMessage with the Origin and
> Velocity
> > > attached and sent to all players.  When a player receives this
> > information,
> > > create a clientside only entity of this rocket and duplicate the way
> the
> > > server moves the rocket in a straight line.  Use PhysicsSimulate to
> move
> > > your rocket through the world, think functions are time based and not
> > very
> > &g

Re: [hlcoders] Optimising projectile bandwidth

[Joel R.]

Tom Edwards Wrote: "I realised earlier today
however that what I'm trying to do is a bad idea no matter how I handle
it, because if either the client or the server ever started to choke on
some frames the rockets risk going out of sync."


Your going to be out-of-sync regardless unless you forward predict the
rocket based on the latency.



On Tue, Sep 15, 2009 at 8:36 AM, Joel R.  wrote:

> Prediction doesn't stop the server from sending you updates, because if
> your clientside values go out of range you have set, it snaps to the
> server's values.
>
>
> On Tue, Sep 15, 2009 at 8:02 AM, Andrew Armstrong 
> wrote:
>
>> I have not played with the game SDK before (just for server plugins), but
>> surely client side prediction can step in here and you can relax how often
>> you send updates?
>>
>> If the client received the origin, direction and velocity of the rocket,
>> client side prediction would take care of movnig the projectile fine (like
>> player movements).
>>
>> Can you maybe make it client side predicted (is there a flag? how do
>> players
>> and other entities auto predict?) and just relax how often you send
>> updates,
>> given that the rocket won't be changing direction/velocity?
>>
>> - Andrew
>>
>> -Original Message-
>> From: hlcoders-boun...@list.valvesoftware.com
>> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Edwards
>> Sent: Tuesday, 15 September 2009 8:28 PM
>> To: Discussion of Half-Life Programming
>> Subject: Re: [hlcoders] Optimising projectile bandwidth
>>
>> Thanks Joel, that sounds like it would work. I realised earlier today
>> however that what I'm trying to do is a bad idea no matter how I handle
>> it, because if either the client or the server ever started to choke on
>> some frames the rockets risk going out of sync.
>>
>> It might be possible to overcome that issue, but only by writing a lot
>> of fairly low-level code: I can only assume that Valve's existing code
>> all assumes that the origin is being transmitted if the position of an
>> entity is in any way important.
>>
>> Oh well. It was worth thinking about. :-)
>>
>> Joel R. wrote:
>> > It's kind of tricky to do something like this.
>> >
>> > I recommend using a server-side only rocket entity that has
>> TransmitState
>> > disabled.  Then use a *reliable* UserMessage with the Origin and
>> Velocity
>> > attached and sent to all players.  When a player receives this
>> information,
>> > create a clientside only entity of this rocket and duplicate the way the
>> > server moves the rocket in a straight line.  Use PhysicsSimulate to move
>> > your rocket through the world, think functions are time based and not
>> very
>> > efficient for this.
>> >
>> > There is a way to do it using the network tables of a client/server
>> entity
>> > but you still have to deal with entity creation which is a lot of
>> useless
>> > data in itself.  It gets really hacky though since you have to manage
>> > stopping the transmitting and letting the client take over, but it still
>> > uses the origin that the server has for PVS culling, so yea it gets ugly
>> > really fast.
>> >
>> >
>> >
>> > On Mon, Sep 14, 2009 at 6:15 AM, Tom Edwards
>> wrote:
>> >
>> >
>> >> I have a simple rocket entity that travels in a straight line until it
>> >> hits something and explodes. Since the rocket travels in straight lines
>> >> at a constant speed all that the client needs to know is its starting
>> >> position and angles, but I'm having trouble getting the engine to only
>> >> network that particular data. Nothing I've tried works:
>> >>
>> >>* Standard CBaseAnimating entity
>> >>  o Sends m_flSimulationTime and m_vecOrigin in every update,
>> >>which together create 11 bytes of useless data per rocket.
>> >>If 16 players at cl_updaterate 30 each have one rocket in
>> >>the air, that's 844.8Kb/s leaving the server*, none of it
>> >>useful in any way. Standard entities also run into the
>> >>interp problem I was talking about the other week.
>> >>* CBaseAnimating with SendPropExclude on m_flSimulationTime and
>> >>  m_vecOrigin
>> >>  o Rocket never appears on the client, even though I set the
>> >>  

Re: [hlcoders] Optimising projectile bandwidth

[Joel R.]

Prediction doesn't stop the server from sending you updates, because if your
clientside values go out of range you have set, it snaps to the server's
values.

On Tue, Sep 15, 2009 at 8:02 AM, Andrew Armstrong wrote:

> I have not played with the game SDK before (just for server plugins), but
> surely client side prediction can step in here and you can relax how often
> you send updates?
>
> If the client received the origin, direction and velocity of the rocket,
> client side prediction would take care of movnig the projectile fine (like
> player movements).
>
> Can you maybe make it client side predicted (is there a flag? how do
> players
> and other entities auto predict?) and just relax how often you send
> updates,
> given that the rocket won't be changing direction/velocity?
>
> - Andrew
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Edwards
> Sent: Tuesday, 15 September 2009 8:28 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Optimising projectile bandwidth
>
> Thanks Joel, that sounds like it would work. I realised earlier today
> however that what I'm trying to do is a bad idea no matter how I handle
> it, because if either the client or the server ever started to choke on
> some frames the rockets risk going out of sync.
>
> It might be possible to overcome that issue, but only by writing a lot
> of fairly low-level code: I can only assume that Valve's existing code
> all assumes that the origin is being transmitted if the position of an
> entity is in any way important.
>
> Oh well. It was worth thinking about. :-)
>
> Joel R. wrote:
> > It's kind of tricky to do something like this.
> >
> > I recommend using a server-side only rocket entity that has TransmitState
> > disabled.  Then use a *reliable* UserMessage with the Origin and Velocity
> > attached and sent to all players.  When a player receives this
> information,
> > create a clientside only entity of this rocket and duplicate the way the
> > server moves the rocket in a straight line.  Use PhysicsSimulate to move
> > your rocket through the world, think functions are time based and not
> very
> > efficient for this.
> >
> > There is a way to do it using the network tables of a client/server
> entity
> > but you still have to deal with entity creation which is a lot of useless
> > data in itself.  It gets really hacky though since you have to manage
> > stopping the transmitting and letting the client take over, but it still
> > uses the origin that the server has for PVS culling, so yea it gets ugly
> > really fast.
> >
> >
> >
> > On Mon, Sep 14, 2009 at 6:15 AM, Tom Edwards
> wrote:
> >
> >
> >> I have a simple rocket entity that travels in a straight line until it
> >> hits something and explodes. Since the rocket travels in straight lines
> >> at a constant speed all that the client needs to know is its starting
> >> position and angles, but I'm having trouble getting the engine to only
> >> network that particular data. Nothing I've tried works:
> >>
> >>* Standard CBaseAnimating entity
> >>  o Sends m_flSimulationTime and m_vecOrigin in every update,
> >>which together create 11 bytes of useless data per rocket.
> >>If 16 players at cl_updaterate 30 each have one rocket in
> >>the air, that's 844.8Kb/s leaving the server*, none of it
> >>useful in any way. Standard entities also run into the
> >>interp problem I was talking about the other week.
> >>* CBaseAnimating with SendPropExclude on m_flSimulationTime and
> >>  m_vecOrigin
> >>  o Rocket never appears on the client, even though I set the
> >>AbsOrigin there with a backdoor variable.
> >>* CBaseAnimating with UpdateTransmitState() logic
> >>  o Rocket disappears from client when transmission stops. Grr!
> >>* Temporary entity
> >>  o Unreliable, start to be dropped if more than 32 are in a
> >>single update. Clearly a bad idea.
> >>
> >> The only method I've not tried yet is a networked dummy entity that
> >> spawns non-networked rockets at both ends (which would pretty much be a
> >> reliable temp ent). Since the client isn't supposed to spawn its own
> >> entities I don't hold much hope for this approach either.
> >>
&g

Re: [hlcoders] Optimising projectile bandwidth

[Joel R.]

It's kind of tricky to do something like this.

I recommend using a server-side only rocket entity that has TransmitState
disabled.  Then use a *reliable* UserMessage with the Origin and Velocity
attached and sent to all players.  When a player receives this information,
create a clientside only entity of this rocket and duplicate the way the
server moves the rocket in a straight line.  Use PhysicsSimulate to move
your rocket through the world, think functions are time based and not very
efficient for this.

There is a way to do it using the network tables of a client/server entity
but you still have to deal with entity creation which is a lot of useless
data in itself.  It gets really hacky though since you have to manage
stopping the transmitting and letting the client take over, but it still
uses the origin that the server has for PVS culling, so yea it gets ugly
really fast.



On Mon, Sep 14, 2009 at 6:15 AM, Tom Edwards wrote:

> I have a simple rocket entity that travels in a straight line until it
> hits something and explodes. Since the rocket travels in straight lines
> at a constant speed all that the client needs to know is its starting
> position and angles, but I'm having trouble getting the engine to only
> network that particular data. Nothing I've tried works:
>
>* Standard CBaseAnimating entity
>  o Sends m_flSimulationTime and m_vecOrigin in every update,
>which together create 11 bytes of useless data per rocket.
>If 16 players at cl_updaterate 30 each have one rocket in
>the air, that's 844.8Kb/s leaving the server*, none of it
>useful in any way. Standard entities also run into the
>interp problem I was talking about the other week.
>* CBaseAnimating with SendPropExclude on m_flSimulationTime and
>  m_vecOrigin
>  o Rocket never appears on the client, even though I set the
>AbsOrigin there with a backdoor variable.
>* CBaseAnimating with UpdateTransmitState() logic
>  o Rocket disappears from client when transmission stops. Grr!
>* Temporary entity
>  o Unreliable, start to be dropped if more than 32 are in a
>single update. Clearly a bad idea.
>
> The only method I've not tried yet is a networked dummy entity that
> spawns non-networked rockets at both ends (which would pretty much be a
> reliable temp ent). Since the client isn't supposed to spawn its own
> entities I don't hold much hope for this approach either.
>
> What on earth can I do here? Give up would be one option I suppose...
>
> * Okay, PVS culling would help. But still...
>
>
> ___
> 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] Fragments memory corruption in the Source Engine (exploit; arbitary memory access)

[Joel R.]

Public disclosure is the only way to get something fixed.

On Thu, Aug 20, 2009 at 11:09 PM, Adam "amckern" McKern
wrote:

> Dont you just love public disclosure by black hats?
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
> --- On Fri, 21/8/09, 1nsane <1nsane...@gmail.com> wrote:
>
> From: 1nsane <1nsane...@gmail.com>
> Subject: Re: [hlcoders] Fragments memory corruption in the Source Engine
> (exploit; arbitary memory access)
> To: "Discussion of Half-Life Programming"  >
> Received: Friday, 21 August, 2009, 12:55 PM
>
> And there's still some left.
>
> But hey, now this is super public!
>
> On Thu, Aug 20, 2009 at 10:49 PM, AzuiSleet  wrote:
>
> > These exploits are already public, and have been floating around for
> years
> > before anyway.
> >
> > On Thu, Aug 20, 2009 at 8:43 PM, Matt Hoffman
> > wrote:
> >
> > > Is it really a good idea to post the link? Not everyone on this list
> has
> > > the
> > > best intentions, nor do I think anyone can do anything about it?
> (Correct
> > > me
> > > if I'm wrong)
> > >
> > > Wouldn't it work better directly mailed to Valve?
> > >
> > > On Thu, Aug 20, 2009 at 7:37 PM, Saul Rennison <
> saul.renni...@gmail.com
> > > >wrote:
> > >
> > > > Luigi has found yet another exploit in Valve's up-to-date,
> > > > unexploitable engine :D
> > > >
> > > >
> > > >
> > > > 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
> > >
> > >
> > ___
> > 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
>
>
>
>
>
>  
> __
> Find local businesses and services in your area with Yahoo!7 Local.
> Get started: http://local.yahoo.com.au
> ___
> 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] Prediction table questions

[Joel R.]

If it's on the table, it will take the clients value.  If the client's value
goes beyond the threshold set in the prediction table, it snaps to whatever
the server has.

On Wed, Aug 12, 2009 at 4:07 PM, Tom Edwards wrote:

> I'm unclear on what the prediction table actually achieves. Here is what
> I think might be happening:
>
> *In table:*
>
>* Prediction error if too far out when next update arrives
>* Memorised when the prediction system rewinds, and restored afterwards
>
> *Not in table: *
>
>* Not checked for prediction accuracy
>* Can be operated on multiple times as the prediction system rewinds
>  o Test prediction->IsFirstTimePredicted() to avoid this
>
> Is this at all accurate? Is there anything else? And:
>
>* What does it mean to have a var that is the network table but not
>  the prediction table?
>* What decides which functions get rewound?
>
>
>
> ___
> 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] Cryptic crash in engine.dll

[Joel R.]

Any custom shaders on props?


On Thu, Aug 6, 2009 at 10:05 AM, Minh  wrote:

> Has anyone encountered the following crash in the engine.dll ?
>
> CColorMeshData *CModelRender::FindOrCreateStaticPropColorData(
> ModelInstanceHandle_t handle )
> {
> ..
> ..
>Assert( modelloader->IsLoaded( instance.m_pModel ) && (
> instance.m_pModel->type == mod_studio ) );
>studiohwdata_t *pStudioHWData = g_pMDLCache->GetHardwareData(
> instance.m_pModel->studio );
>
>
>
> It is happening to me constantly whenever i change resolutions on a
> certain level. It only happens on some of my levels and I can't seem to
> find the cause of it. I thought it had something to do with the number
> of static props but I ended up removing all static props from my level
> and it still gives me the same crash. Anyone have any experience with
> this crash?
>
> ___
> 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] Terrain LOD: Runtime Regular-Grid Algorithms

[Joel R.]

Yes, you'd have to use a physics system like bullet physics or similar.  HL2
uses both Havok and their BSP collision system. This loads the level into
memory 2 times and has 2 side by side frames doing collision checks.

If you attach your own physics system (which is easy) to the world and any
collidable objects, you'll have to redo some of the lighting effects,
shadows mostly.  The visual is alot more complicated than collision system
because there is no set way of doing shaders and shadows.


On Wed, Jul 29, 2009 at 5:18 PM, Ryan Sheffer  wrote:

> Am I right to believe that even if you used the mesh builder to make a
> terrain, it would never be considered in collision detection?
>
> On Wed, Jul 29, 2009 at 1:43 PM, Jed  wrote:
>
> > Waldo (ex Valve/DoD Team) wrote something like this for another engine
> > not so long ago. Did a nice job of auto texturing terrain with
> > grass/scree/rock based on the steepness of the slop. Another nice
> > trick is to apply snow over time based on the normal angle of the face
> > relative to the vertical (sky).
> >
> > - Jed
> >
> > 2009/7/29 Saul Rennison :
> > > All displacement handling is done in the engine. By simply having the
> mod
> > > code, you would be FORCED to use an entity and use the mesh builder to
> > > manually build the terrain menu. Make your own Hammer and customize
> VBSP
> > to
> > > add custom terrain data into an unused BSP lump.
> > >
> > > Thanks,
> > > - Saul.
> > >
> > >
> > > 2009/7/29 Adam Donovan 
> > >
> > >> Given the code base we have in the SDK and considering there is
> someone
> > to
> > >> actually spend the time programming it, would it be possible to create
> a
> > >> terrain system that would outperform the current displacement system?
> > >> Perhaps it might be possible to use the current blend texture
> technique
> > but
> > >> ad a little additional control over the blending based on slope and
> > height,
> > >> just like cannon fodder did in DispGen.
> > >> Any ideas anyone?
> > >> http://www.vterrain.org/LOD/Papers/
> > >> ___
> > >> 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
> >
> >
>
>
> --
> ~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] whats happening with this engine

[Joel R.]

Not to mention this engine took many years to build, if they take just as
much time on the next engine they would have to start now.  Source Engine
will only last so long as a modern engine.  Maybe we're in for some of that
knock your heads off excitement.  From a business perspective it must be
done.


On Fri, Jul 24, 2009 at 4:46 PM, Minh  wrote:

>I don't think addressing these concerns would hurt their profits at all.
> I imagine many of the folks at Valve are aware and in fact, would like to
> fix these issues but they choose to prioritize their time on other things.
> We don't even know what they're working on these days so it's hard for us
> to
> say that they're not addressing these problems internally.
>Rest assured, they are reading these forums and they are aware of the
> concerns. Their decision to address them is strictly their prerogative. I'm
> sure many of us would do things differently if we had our foot in Valve's
> offices but that's what seperates us from Valve.
>As an amateur developer, I've learned to just work with the tools that
> have been given to me.. I'm aware of the engine's deficiencies but I choose
> to work with it because it offers me what i need. If I chose to work with
> the Unreal engine, I'm sure I can come up with a list of things I'd like to
> change in that engine as well.
>I think it's easier to adapt my workflow to the engine, than to wait on
> the engine developer to adapt the engine to my workflow... especially when
> we all know that Valve are more focused on making great games than making
> easy to use engine + tools. You guys might be waiting for awhile...
>
>
> - Original Message -
> From: "Bob Somers" 
> To: "Discussion of Half-Life Programming"  >
> Sent: Friday, July 24, 2009 12:11 PM
> Subject: Re: [hlcoders] whats happening with this engine
>
>
> > No kidding. Nothing like asking a company who's in business to make
> > money to throw their profit making tools into the public domain...
> >
> > --Bob
> >
> >
> >
> > On Fri, Jul 24, 2009 at 11:21 AM, Ryan Sheffer
> wrote:
> >> In a nutshell, asking far too much.
> >>
> >> On Fri, Jul 24, 2009 at 10:58 AM, Nick  wrote:
> >>
> >>> I basically summed up the entire thread for everyone.
> >>>
> >>>
> >>> Give modders better tools:
> >>> Open source hammer.
> >>> Open source all tools.
> >>> Release specs on proprietary formats
> >>> Enable a lua added version of sdk
> >>> allow some sort of documentation of the non-released parts of sdk
> >>> (release entire sdk, but have only clientside code available)
> >>>
> >>> Make it easier to create content, and modify the engine.
> >>>
> >>> ___
> >>> 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
> >
>
>
> ___
> 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] whats happening with this engine

[Joel R.]

Ahh Saul, I guess I'm a bit outdated.  From what I remember, they had kept
some content formats and were slowly converting them to their own formats.

On Fri, Jul 24, 2009 at 2:47 PM, Saul Rennison wrote:

> "And it will all have derived from the Source Engine."
> If you've read their blog you'll know they started from scratch.
>
> "gutted them out and rewrote them."
> Again, no. They decided to make their own engine to fit their own needs as
> they weren't very experianced with Source.
>
> Thanks,
> - Saul.
>
>
> 2009/7/24 Joel R. 
>
> > Profit making? The only games that made profit on the source engine are
> the
> > ones by valve and the one by garry.
> >
> > I believe the NS2 engine will be everything you guys here wanted.  They
> > took
> > all the best aspects of the source engine, gutted them out and rewrote
> > them.  They will have better tools, better everything, all written by 2
> > guys
> > (probably just 1 guy).  And it will all have derived from the Source
> > Engine.  From what little we have seen it seems to be shaping up quite
> > nicely.
> >
> >
> >
> >
> > On Fri, Jul 24, 2009 at 2:11 PM, Bob Somers 
> wrote:
> >
> > > No kidding. Nothing like asking a company who's in business to make
> > > money to throw their profit making tools into the public domain...
> > >
> > > --Bob
> > >
> > >
> > >
> > > On Fri, Jul 24, 2009 at 11:21 AM, Ryan Sheffer
> > wrote:
> > > > In a nutshell, asking far too much.
> > > >
> > > > On Fri, Jul 24, 2009 at 10:58 AM, Nick  wrote:
> > > >
> > > >> I basically summed up the entire thread for everyone.
> > > >>
> > > >>
> > > >> Give modders better tools:
> > > >> Open source hammer.
> > > >> Open source all tools.
> > > >> Release specs on proprietary formats
> > > >> Enable a lua added version of sdk
> > > >> allow some sort of documentation of the non-released parts of sdk
> > > >> (release entire sdk, but have only clientside code available)
> > > >>
> > > >> Make it easier to create content, and modify the engine.
> > > >>
> > > >> ___
> > > >> 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
> > >
> > >
> > ___
> > 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] whats happening with this engine

[Joel R.]

Profit making? The only games that made profit on the source engine are the
ones by valve and the one by garry.

I believe the NS2 engine will be everything you guys here wanted.  They took
all the best aspects of the source engine, gutted them out and rewrote
them.  They will have better tools, better everything, all written by 2 guys
(probably just 1 guy).  And it will all have derived from the Source
Engine.  From what little we have seen it seems to be shaping up quite
nicely.




On Fri, Jul 24, 2009 at 2:11 PM, Bob Somers  wrote:

> No kidding. Nothing like asking a company who's in business to make
> money to throw their profit making tools into the public domain...
>
> --Bob
>
>
>
> On Fri, Jul 24, 2009 at 11:21 AM, Ryan Sheffer wrote:
> > In a nutshell, asking far too much.
> >
> > On Fri, Jul 24, 2009 at 10:58 AM, Nick  wrote:
> >
> >> I basically summed up the entire thread for everyone.
> >>
> >>
> >> Give modders better tools:
> >> Open source hammer.
> >> Open source all tools.
> >> Release specs on proprietary formats
> >> Enable a lua added version of sdk
> >> allow some sort of documentation of the non-released parts of sdk
> >> (release entire sdk, but have only clientside code available)
> >>
> >> Make it easier to create content, and modify the engine.
> >>
> >> ___
> >> 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
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] whats happening with this engine

[Joel R.]

This type of argument always leads to this, one side says it should be
better, one side says be happy for what you've got.

We are definitely happy, but what is wrong with improvement?  Improvement =
awesome = more money.  The source engine just turned 5 years old, it is not
getting any younger, churning out games is getting slower, and other engines
make game building much quicker.  Anyway you look at it, there is only
something positive that comes out of improvement.



On Thu, Jul 23, 2009 at 7:49 PM, Paul Peloski  wrote:

> Maybe they do remember that, and think, "if Counter-Strike and Team
> Fortress
> were made with our SDK, we must be doing a pretty good job."
>
> Paul
>
> On Thu, Jul 23, 2009 at 6:39 PM, Saul Rennison  >wrote:
>
> > Maybe Valve should then remember they wouldn't have Team Fortress and
> > Counter-Strike without mods.
> >
> > Thanks,
> > -Saul.
> >
> > On 24 Jul 2009, at 01:28, Bob Somers  wrote:
> >
> > > With all due respect to you guys, I think you're forgetting that
> > > ultimately Valve is not in the mod-support business. They're in the
> > > business of making their own games, and the success of their titles
> > > shows how well they do it.
> > >
> > > Their tools are designed for the way the workflow happens at Valve,
> > > not at your house. They're providing their tools to you as a courtesy.
> > > Now, if they want to take suggestions from the community that's great,
> > > but ultimately you're getting all their tools for free so it's really
> > > "too bad" if they don't work they way you want them to.
> > >
> > > I'm not well versed in the model compilation process for Source, but
> > > there's one thing a command line interface has over a GUI...
> > > scriptability. In a big software company, the rule of thumb is that
> > > anything that can be automated should be automated. You can't script a
> > > GUI (at least, not very easily at all).
> > >
> > > --Bob
> > >
> > >
> > >
> > >
> > > On Thu, Jul 23, 2009 at 5:08 PM, Saul
> > > Rennison wrote:
> > >> Hell I'm on Summer Holidays, I'll give this a go, although it does
> > >> mean I'd have to do texture support which I'm not so great at. But
> > >> GCF
> > >> support is possible via Nemesis' HLlib.
> > >>
> > >> All replies in this topic bring up good points in the Source Engine,
> > >> heres my 2 pence:
> > >> I don't agree with the fact Source doesn't have good physics.
> > >> Source should move to DAE.
> > >> StudioMDL and HLMV should be open-source, leave P4 integration in, we
> > >> only need the code / snippets from it.
> > >>
> > >> There's probably more but I can't be bothered replying.
> > >>
> > >> Thanks,
> > >> -Saul.
> > >>
> > >> On 24 Jul 2009, at 00:17, Harry Jeffery
> > >>  wrote:
> > >>
> > >>> If it's all made nice and modular and supports either dll or python
> > >>> plugins I think it would work great.
> > >>>
> > >>> Nothing there that should be too hard to re-implement.
> > >>>
> > >>> 2009/7/24 Matt Hoffman :
> >  Because...
> > 
> >  Hell that's a good point. The VMF document format isn't exactly
> >  hard to
> >  understand. The compile tools are all plugged-in.
> > 
> >  Only thing you would have issues with (I'd Imagine): Loading from
> >  the GCFS
> >  quickly, and efficiently. Though I imagine Jed would have a
> >  solution there.
> >  Displacements could also be an issue.
> > 
> >  I'd imagine it's possible.
> > 
> > 
> > 
> >  On Thu, Jul 23, 2009 at 4:06 PM, Harry Jeffery <
> >  harry101jeff...@googlemail.com> wrote:
> > 
> > > 1. Update SDK and make it uber leet as per suggestions.
> > > 2. Distribute SDK (not on valvetime please)
> > > 3. Studios pay for license
> > > 4. More mods become commercially viable (e.g. GMod)
> > > 5. ?
> > > 6. Profit!
> > >
> > > But seriously, it can be done.
> > >
> > > And if hammer is so bad why has the community not started work
> > > on an
> > > opensource version with python support for plugins.
> > >
> > > 2009/7/23 Jorge Rodriguez :
> > >> Source engine works just fine for outdoors areas. Did you people
> > >> forget
> > > that
> > >> half of HL2 and the episodes take place outdoors? Obviously it
> > >> doesn't
> > > scale
> > >> up to GTA-size large areas, but it can handle some pretty large
> > >> areas.
> > >>
> > >> --
> > >> 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
> > >
> > 

Re: [hlcoders] whats happening with this engine

[Joel R.]

Hes an old schooler it does not matter

back on topic

Yes, there is much room for improvement in many areas.  Source Engine is the
only modern engine to still be using BSP.  However, i think the tools like
hammer should be open source so people like us can improve them since valve
lacks the manpower to do so.


On Thu, Jul 23, 2009 at 4:09 PM, Kohan Venets  wrote:

>
> I'm not claiming to agree or disagree, but I'd like to mention that using
> proper spelling and grammar would help people take you seriously.  "Iam"
> "disapointed" "beleive" "displacment" "isnt" "alogothim" "differnt"
> "fundemenal" "woulod" "jsut" "Id" "dont".
>
> It's just difficult to believe that you have a job as a game developer when
> you type that way.
>
> -Kohan
>
>
>
> > Date: Thu, 23 Jul 2009 22:51:26 +0200
> > From: adamjjdono...@gmail.com
> > To: hlcoders@list.valvesoftware.com
> > Subject: [hlcoders] whats happening with this engine
> >
> > After being on this list for years Iam slightly disapointed that it has
> not
> > been taken further..mainly Iam talking about the tools artists get to use
> to
> > create the worlds and actually cant beleive that a modern computer game
> > developer still works with it as its rather limited in environment
> > design..take for example the displacment system..there isnt even lod
> > alogothim for it which makes it so limited..seeing as I work for a game
> > developer and know that its not easy to manage differnt projects and
> > content..I still think some rethinking of fundemenal aspects of the
> engine
> > woulod be a great idea about now..perhaps even jsut to give people like
> me
> > some hope that the engine will slowly migrate into something more
> modern..Id
> > expect some flaming and spam to follow this post like how their are other
> > engines to use and that i dont have to use source engine..that being
> said..i
> > kinda care about seeing progress.
> > greetz
> > nava
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
>
> _
> NEW mobile Hotmail. Optimized for YOUR phone.  Click here.
> http://windowslive.com/Mobile?ocid=TXT_TAGLM_WL_CS_MB_new_hotmail_072009
> ___
> 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] Mod crashes on loading map with custom entity inside, how to debug?

[Joel R.]

You can see the values the variables are holding on that line.  Use that to
figure out which is bonkers.

On Sun, Jul 19, 2009 at 3:01 PM, botman  wrote:

> Maybe this will help...
>
> http://msdn.microsoft.com/en-us/library/k0k771bt%28VS.71%29.aspx
>
>  From your questions, it sounds like you really don't know C++.  Is that
> the case?
>
> On 7/19/2009 1:50 PM, Matt Hoffman wrote:
> > I mean, I know which line the code is breaking on. How do I find out
> which
> > part of the line (m_pVehicles, or the Update, or gpGlobals, or Frametime
> or
> > m_Controls, etc) is causing the problem? Or is it caused by the entire
> line?
> > Or is there not enough information provided by the engine/crash to help
> me
> > here?
> >
> >
> >
> > On Sun, Jul 19, 2009 at 11:44 AM, Yorg Kuijs  wrote:
> >
> >> Ehm the pointer itself would be the null pointer?
> >> So m_pVehicle is a NULL pointer, not enough to know when or how the
> >> pointer should get something to point to though.
> >>
> >> Matt Hoffman wrote:
> >>> How do I find which part of that line points to a NULL-pointer?
> >>>
> >>> On Sun, Jul 19, 2009 at 11:23 AM, Alexander Hirsch<
> >> 1ze...@googlemail.com>wrote:
> >>>
>  Whatever line it is pointing at, that line contains an access to a
>  NULL-pointer ("Access violation reading location 0x").I have
> too
>  little information to find out how to fix that.
> 
>  That CXX0030-error could just be because of insufficient
> >> debug-information
>  and code-optimazations.
> 
>  On Sun, Jul 19, 2009 at 8:08 PM, Matt Hoffman
>  wrote:
> 
> 
> > It crashes at
> >
> > m_pVehicle->Update( gpGlobals->frametime, m_controls);
> >
> > in fourwheelvehiclephysics.cpp, with the error: "Unhandled exception
> at
> > 0x0e60f730 in hl2.exe: 0xC005: Access violation reading location
> > 0x."
> >
> > However, I'm not sure/can't find what is actually crashing. If I look
> >
>  under
> 
> > gpGlobals>CGlobalVarBase>pSaveData, I find several red X's  saying
> > "CXX0030:
> > Error: expression cannot be evaluated". I'd say this would be my
> >> problem,
> > but I haven't touched anything to do with save data and normal maps
> >> don't
> > crash, just ones with my Jetski in them... So now I'm throughly
> >> confused.
> > :D
> >
> > On Sun, Jul 19, 2009 at 10:54 AM, Alexander Hirsch<
> >
>  1ze...@googlemail.com
> 
> >> wrote:
> >>
> >> Yes, just wait for the crash and analyze it in the debugger.
> >>
> >> On Sun, Jul 19, 2009 at 7:46 PM, Matt Hoffman
> >> wrote:
> >>
> >>
> >>> I guess maybe the question was of how to debug it. Build it in
> Debug
> >>> Config,
> >>> and then put a breakpoint...where? Or just wait until it crashes
> and
> >>>
> > then
> >
> >>> step through?
> >>>
> >>> /me is new to debugging something this big.
> >>>
> >>> On Sun, Jul 19, 2009 at 10:04 AM, Alexander Hirsch<
> >>>
> >> 1ze...@googlemail.com
> >>
>  wrote:
> 
>  Not having it client-side produces an error, not a crash
> 
> > though.What's
> >
>  wrong
>  with crashing while it loads? Debugging should work regardless of
> 
>  the
> 
>  game-state :S
> 
>  On Sun, Jul 19, 2009 at 6:59 PM, Matt Hoffman
>  wrote:
> 
> 
> > I'm trying to resurrect the Jetski from the HL2 Beta. I found the
> > serverside
> > file still shipping with Ep2's Mod code so I figured I'd give it
> >
>  a
> 
> >>> shot.
> >>>
>  I
> 
> > got the code to compile, but now it crashes the map if I start
> >
>  with
> 
> > a
> >
> > prop_vehicle_jetski in it. (Added a FGD entry based off the
> >
> > Airboat,
> >
> >>> uses
> >>>
> > the Airboat's model). So now my question is, how do I debug this
> >
> >> crash
> >>
> > (Memory could not be read) when it happens on load time? Or
> >
>  should
> 
> > I
> >
> >> go
> >>
> > about spawning the entity a different way that might be more
> >
>  prone
> 
> > to
> >
> > letting me debug?
> >
> > Also I assume not having a client-side file is going to be bad?
> >
> > (And
> >
> >>> may
> >>>
>  be
> 
> > the source of my crashes even?)
> > ___
> > To unsubscribe, edit your list preferences, or view the list
> >
> >> archives,
> >>
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> >
>  ___
>  To

Re: [hlcoders] Access reception to hlcoders forum

[Joel R.]

I think he is trying to learn how to remove speed hackers by using recorded
demos.  In any case, he definately needs some work on that engrish.


On Fri, Jul 3, 2009 at 7:38 AM, botman  wrote:

> Jonas 'Sortie' Termansen wrote:
> > Engrish anyone?
> >
> > Trinitron, I have no idea what you are talking about. This isn't a
> 'forum',
> > it's a mailing list. But if you want to see the previous mails, there
> should
> > be some website where you can browse them.
> >
> > But what I understood was, you want the current .dem format?
> >
> >
> There is a searchable archive of the hlcoders email list here...
>
> http://www.mail-archive.com/hlcoders%40list.valvesoftware.com/
>
> ...but the history doesn't go back as far as the archives here...
>
> http://list.valvesoftware.com/mailman/private/hlcoders/
>
> --
> 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

Re: [hlcoders] generating a map overview image

[Joel R.]

It's possible to generate the image entirely with a single command.  Source
can read/write pixel data and save to a file, you generate the pixels by
capturing the view, which to get a 4000px wide screen, would require several
view captures, then just add the views into the pixel buffer accordingly.

To get the positions, you start with the World min/max , use a bit of
Pythagorean Theorem to get a height distance and divide the space
accordingly to reach 4000 or so pixels.


On Wed, Jun 24, 2009 at 1:03 PM, 1nsane <1nsane...@gmail.com> wrote:

> What about starting the game in windowed mode with a custom resolution?
> Perhaps that would allow going over the max supported by the monitor and as
> such the screenshot could be made bigger.
>
> On Wed, Jun 24, 2009 at 12:53 PM, Joel R.  wrote:
>
> > You can create a 4000px sized image using the same code created to create
> a
> > screenshot.  However it will require taking several shots because of the
> > natural screen FOV.
> >
> > On Wed, Jun 24, 2009 at 11:41 AM, Jeffrey Wong <
> mindstormmas...@gmail.com
> > >wrote:
> >
> > > Does anyone know of a tool that can produce a very high resolution
> image
> > of
> > > a map overview?  The process we currently use and that is outlined on
> the
> > > developer wiki is essentially a screenshot, thus being limited in size.
> > >  For
> > > example, I'd like to make a 4000px version of the map overview seen
> here:
> > > http://www.dystopia-stats.com/img/overviews/dys_vaccine2.png
> > >
> > > Thanks in advance.
> > > ___
> > > 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] generating a map overview image

[Joel R.]

You can create a 4000px sized image using the same code created to create a
screenshot.  However it will require taking several shots because of the
natural screen FOV.

On Wed, Jun 24, 2009 at 11:41 AM, Jeffrey Wong wrote:

> Does anyone know of a tool that can produce a very high resolution image of
> a map overview?  The process we currently use and that is outlined on the
> developer wiki is essentially a screenshot, thus being limited in size.
>  For
> example, I'd like to make a 4000px version of the map overview seen here:
> http://www.dystopia-stats.com/img/overviews/dys_vaccine2.png
>
> Thanks in advance.
> ___
> 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

[Joel R.]

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  >wrote:
>
> > Don't forget to do a 'Refresh SDK Content' from the SDK launcher. Once
> you
> > do that they should show up for you.
> >
> > -Mike
> >
> > -Original Message-
> > From: hlcoders-boun...@list.valvesoftware.com [mailto:
> > hlcoders-boun...@list.valvesoftware.com] On Behalf Of Harry Jeffery
> > Sent: Monday, June 15, 2009 1:53 PM
> > To: Discussion of Half-Life Programming
> > Subject: Re: [hlcoders] Source SDK Beta Concluded
> >
> > Yeah, I'm loving the idea of releasing official map sources. =]
> >
> > Just cant find them. They're not in the mapsrc folder and the search
> > for .vmf returns nothing but prefabs.
> >
> > 2009/6/15 Saul Rennison :
> > > *shock horror*
> > >
> > > That's going to be absolutely amazing for all the TF2 mappers out
> there!
> > > Grats to the Valve team :)
> > >
> > > 2009/6/15 Mike Durand 
> > >
> > >> Hi All-
> > >>
> > >> Just wanted to give you a heads-up that the SDK Beta is over and has
> > been
> > >> rolled into the Source SDK. Here are the release notes:
> > >>
> > >>-Added source files for ten shipping TF2 maps:
> > >>arena_lumberyard
> > >>arena_ravine
> > >>cp_badlands
> > >>cp_dustbowl
> > >>cp_granary
> > >>cp_gravelpit
> > >>ctf_2fort
> > >>pl_badwater
> > >>pl_goldrush
> > >>tc_hydro
> > >>
> > >>-Updated shadercompile binaries and added missing DLL
> > needed
> > >> for shader compilation.
> > >>
> > >> -Mike
> > >> ___
> > >> 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
> >
> >
> > ___
> > 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] (no subject)

[Joel R.]

And I write this from my bosses computer. I win.



On Fri, Mar 6, 2009 at 10:53 AM, Saul Rennison wrote:

> I'm now writing from my PC :3
>
> 2009/3/6 Rodrigo 'r2d2rigo' Diaz 
>
> > Hah, I beat you all. Writing from my laptop!
> >
> > 2009/3/6 Saul Rennison 
> >
> > > FROM MY IPHONE!!!
> > >
> > > Sent from my iPhone
> > >
> > > 2009/3/6 Tobias Kammersgaard 
> > >
> > > > Sending more messages from my Nokia 5310 XpressMusic while I'm
> sitting
> > > > in front of my computer laugh out loud!
> > > >
> > > > 2009/3/5, homi :
> > > > > please dont send mi this mesges. thanks
> > > > > ___
> > > > > To unsubscribe, edit your list preferences, or view the list
> > archives,
> > > > > please visit:
> > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sendt fra min mobile enhed
> > > >
> > > > /ScarT
> > > >
> > > > ___
> > > > 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
> >
> >
>
>
> --
> 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] Technical Design Document or Quick Reference Guide?

[Joel R.]

So, I guess the question is:

Valve, can we have permission to post SDK code on the internet, strictly for
documentation purposes?

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

Re: [hlcoders] OB material system, when?

[Joel R.]

I wish Shaders would get me !
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Which are the other 3 mods that get access to thesteamworks sdk?

[Joel R.]

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

Re: [hlcoders] Getting rid of pitch in mouse movements

[Joel R.]

Override the function
virtual boolCreateMove( float flInputSampleTime, CUserCmd *pCmd );
in your player class, whether it be c_sdk_player or c_hl2mp_player

In that function you first call the BaseClass::CreateMove then change pCmd
to whatever value you want. Since you want angles you'll change the
pCmd->viewangles and also engine->SetViewAngles( QAngle ) so the
gamemovement on client and server both have the exact same angle values.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Console commands returns "command unknown" on a Linux OB build

[Joel R.]

I have compiled on 3.4.6 and 4.2.3 and it works.  However most servers are
currently using the glibc for 3.4.6 and it is incompatible for 4.2.3 so it's
recommended you just use 3.4.6.  You must use omega's updated files, however
you may want to edit the makefile so it doesn't use the optimization flags
for 4.2.2
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SDK Updated and No Longer A Beta

[Joel R.]

Nevermind, I understand the process now.  Shaders are for next beta.

On Wed, Jul 9, 2008 at 3:40 PM, Joel R. <[EMAIL PROTECTED]> wrote:

> Thanks Mike, does this mean it has Shaders too?
>
> On Wed, Jul 9, 2008 at 3:00 PM, Mike Durand <[EMAIL PROTECTED]>
> wrote:
>
>> Hi All-
>>
>>
>>
>> Just a heads-up: we are updating the SDK with a fix for DoD:Source not
>> showing up in the Orange Box games list and we are changing it from a
>> beta to a release. So you'll likely need to restart Steam if you have
>> joined the beta.
>>
>>
>>
>> -Mike
>>
>> ___
>> 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] SDK Updated and No Longer A Beta

[Joel R.]

Thanks Mike, does this mean it has Shaders too?

On Wed, Jul 9, 2008 at 3:00 PM, Mike Durand <[EMAIL PROTECTED]>
wrote:

> Hi All-
>
>
>
> Just a heads-up: we are updating the SDK with a fix for DoD:Source not
> showing up in the Orange Box games list and we are changing it from a
> beta to a release. So you'll likely need to restart Steam if you have
> joined the beta.
>
>
>
> -Mike
>
> ___
> 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] OrangeBox Shaders

[Joel R.]

Hi Valve,

I really appreciate the recent update's we've been given, it really
blossomed the Orange Box SDK as of yet.  The only thing we really need now
are shader's.  I used shaders in Ep1 for several effects that I'd like to
have again in my mod for Orange Box.  Is there any work being done with
them?  I'm progressing on my mod a lot and I'm sure others are too, so it
would be a great and final addition to completing the Orange Box SDK set we
so deeply love =D.

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

Re: [hlcoders] Linux & Orange Box

[Joel R.]

If valve doesn't want new mods to come out, that's perfectly fine. =D

On Sat, Jun 21, 2008 at 9:24 AM, Garry Newman <[EMAIL PROTECTED]> wrote:

> No, THEY haven't cleaned my bathroom since 2001! I don't see why I
> should have to do it when I bought their game!
>
> garry
>
> On Sat, Jun 21, 2008 at 3:13 PM, Jeffrey botman Broome
> <[EMAIL PROTECTED]> wrote:
> > Garry Newman wrote:
> >> Valve need to come and clean my bathroom. I bought Half-Life 1 in
> >> 2001, I pay their wages, they owe me this.
> >
> > You haven't cleaned your bathroom since 2001?
> >
> > Ew, you're disgusting!
> >
> > --
> > 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

Re: [hlcoders] Post your code!

[Joel R.]

I posted a link to my Source Towers mod that I made Open Source about 2
weeks ago.

http://developer.valvesoftware.com/wiki/SourceTowers

On Sun, Jun 15, 2008 at 4:46 PM, Ben Everett <[EMAIL PROTECTED]> wrote:

> Copyright isn't an issue at all, distribution is. I'll contact FilePlanet
> and FileShack to have them host it. You can already nab all art assets and
> code from:
> http://www.obike.net/forsaken/Forsaken%20Release.rar
>
> I'll upload a installation file for the mod itself shortly.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Edwards
> Sent: Sunday, June 15, 2008 2:33 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Post your code!
>
> Watch out for copyright. It doesn't matter if you can get in touch with
> them any more: it's still not your work.
>
> Otherwise, bring it on! :-)
>
> Ben Everett wrote:
> > Hmm, since Forsaken is now officially dead (can't get in touch w/ anyone
> > anymore) I've thought about releasing the source code, art assets, and
> map
> > assets for free as well as the last playable build of the game. What
> would
> > you guys think of that?
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Tom
> Edwards
> > Sent: Saturday, June 14, 2008 4:30 AM
> > To: hlcoders
> > Subject: [hlcoders] Post your code!
> >
> > Do you have any code lying around that might be useful to others? Why
> > not share it?
> >
> > http://developer.valvesoftware.com/wiki/Category:Free_source_code
> >
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> > __ NOD32 3186 (20080613) Information __
> >
> > This message was checked by NOD32 antivirus system.
> > 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
>
>
> __ NOD32 3187 (20080615) Information __
>
> This message was checked by NOD32 antivirus system.
> 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] Sideways fall damage

[Joel R.]

The player movement code in gamemovement.cpp has a function called
TryPlayerMove.  In this function is where it detects walls and slides you
across them instead of stopping abruptly.  Find the section that it
determines is walls and use your own code to calculate if its a hard
collision.

On Mon, Jun 2, 2008 at 9:54 PM, Garrett <[EMAIL PROTECTED]> wrote:

> I did, but it looks like it really only works when you actually make
> contact with the ground such that you now have a ground entity.
>  Unfortunately, I don't think a ground entity would get set if you collide
> with a wall in mid air.  But I may be wrong about that, so feel free to
> correct me if I am.
>
>
> - Original Message 
> From: Ryan Sheffer <[EMAIL PROTECTED]>
> To: Discussion of Half-Life Programming 
> Sent: Monday, June 2, 2008 4:01:06 PM
> Subject: Re: [hlcoders] Sideways fall damage
>
> Take a look at that player fall damage command.
>
> On Mon, Jun 2, 2008 at 11:17 AM, Garrett <[EMAIL PROTECTED]> wrote:
>
> > So I looked at CPhysicsProp, and it seemed to use VPhysicsCollision.  I
> > tried overriding that in
> > my player class and put a bunch of DevMsg's in there, but it never seemed
> > to get called.
> >
> > --- Tom Edwards <[EMAIL PROTECTED]> wrote:
> >
> > > Physprops take sideways damage, so I'd start there.
> > >
> > > Garrett wrote:
> > > > Hi,
> > > > So I was wondering how I would go about causing players to take "fall
> > damage" if they get
> > > slammed into a wall in midair.  I did notice a void
> > > CGameMovement::PerformFlyCollisionResolution( trace_t &pm, Vector &move
> > ).  Would it be possible
> > > to modify that, or is that completely wrong or is there more to it?
> > > >
> > > > Garrett
> > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > 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
> >
> >
>
>
> --
> ~Ryan
> ___
> 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] Orange Box SDK Code Update???

[Joel R.]

It's not about being owed something.

It's that we've been given a broken SDK and it's been that way for over 5
months with no update in sight.  This is unheard of at the commercial
level.




2008/5/18 Daniel Glenn <[EMAIL PROTECTED]>:

> Heh. Is it too early to make this thread into a fanboy rant about how every
> other engine pales in comparison to Source? If not, I want to start it. But
> yes, I agree. I'm just not a big fan of people who think they're "owed"
> something.
>
> 2008/5/18 Ben Mears <[EMAIL PROTECTED]>:
>
> > Here's my opinion.
> >
> > Valve doesn't owe us anything but it is in their best interest to keep us
> > happy as we are the ones who promote and further the Source Engine. After
> > all, where did Counter Strike, Team Fortress, and Portal originate from?
> I
> > think Valve has done a pretty good job of supporting us modders but it's
> > true that there is always more they could do for us. Maybe the people who
> > are unhappy with Valve should move on to other engines, Unreal 3 or
> > CryEngine 2 for example, see how those engines compare to Source and then
> > re-evaluate their opinons.
> >
> > Again, that's just my two cents.
> >
> >
> > On Sun, May 18, 2008 at 3:42 AM, Ondřej Hošek <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Which would obviously reduce the longevity of their games.
> > >
> > > ~~ Ondra
> > >
> > > On 18.05.08 10:16 Uhr, Daniel Glenn wrote:
> > > > We don't deserve a damned thing. Valve could have simply not released
> > the
> > > > source code at all.
> > > >
> > > >
> > > > On Sat, May 17, 2008 at 11:25 AM, John<[EMAIL PROTECTED]>  wrote:
> > > >
> > > >
> > > >> Come on Valve :D All us modders deserve that fixed code in good time
> > :\
> > > Its
> > > >> been a few months
> > > >>
> > > >> On Sat, May 17, 2008 at 2:25 PM, Tom Leighton<
> > > [EMAIL PROTECTED]
> > > >>
> > > >> wrote:
> > > >>
> > > >>
> > > >>> That was a fix from Tony Sergi (VALVE)
> > > >>>
> > > >>> Tom Edwards wrote:
> > > >>>
> > > >>>> That /was/ a fix from Valve.
> > > >>>>
> > > >>>> Janek wrote:
> > > >>>>
> > > >>>>
> > > >>>>> @Benjamin and Tom>  I saw this post as it was an answer to a
> > question
> > > >>>>>
> > > >>> from
> > > >>>
> > > >>>>> me. But this fix is for sratch sdk (different in hl2mp) and also
> I
> > > >>>>>
> > > >>> prefer a
> > > >>>
> > > >>>>> fix frm Valva as there could have other less noticeable
> prediction
> > > >>>>>
> > > >>> issue.
> > > >>>
> > > >>>>> 2008/5/17 Mikie<[EMAIL PROTECTED]>:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> For the last four years, Valve has needed to hire more people.
> > > >>>>>> They have the budget considering the success they've had,
> > > >>>>>>
> > > >>>>>> I never understood why Valve management is so reluctant to do
> so.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> -Original Message-
> > > >>>>>> From: [EMAIL PROTECTED]
> > > >>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Daniel
> > > >>>>>> Glenn
> > > >>>>>> Sent: Saturday, May 17, 2008 12:14 AM
> > > >>>>>> To: Discussion of Half-Life Programming
> > > >>>>>> Subject: Re: [hlcoders] Orange Box SDK Code Update???
> > > >>>>>>
> > > >>>>>> Obviously, they're not working on at least two retail games
> right
> > > now
> > > >>>>>>
> > > >>> or
> > > >>>
> > > >>>>>> anything. Be patient is my advice.
> > 

[hlcoders] Orange Box SDK Code Update???

[Joel R.]

We've been patiently waiting for about 5 months now waiting on an update to
the Source SDK Code.

Major Things Needed:
- Updated Source SDK (Scratch Mod/HL2MP) (This should be finished).
- Source Shaders
- Particle Editor

Making effects is crucial to any game.  Currently if you switch to Orange
Box, you cannot use Shaders or optimized particles (Particle Editor
system).  The current SDK is riddled with bugs that have been fixed but are
casually awaiting to be updated in.

TF2 has received 26 updates since the release of Orange Box SDK.
We have received 1 update to Hammer and Engine.
We have received 0 updates to the code-base.

In it's current state, Orange Box SDK is broken.

I and many others would greatly appreciate an immediate update as soon as
possible. Thanks for your time.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SDK Update - No More Beta

[Joel R.]

Not to sound rude, but this update is uncalled for.  This is practically the
same stuff we got from our last update a couple MONTHS ago.  I was expecting
shader code, updated sdk code bugs, at the very least... more things.  I
know omega has fixed alot of bugs with the sdk code.  So why are we getting
an update that's relatively the same as last update?  Now that it's out of
beta does this mean we will get more updates at a faster pace? Or does this
mean nothing, and that we should expect most of Orange Box's most
anticipated features until the 4th quarter of this year?

On Mon, Mar 24, 2008 at 2:24 PM, Cory de La Torre <[EMAIL PROTECTED]>
wrote:

> Yeah I have the same , and it's very annoying, but not much of a problem.
>
> On Mon, Mar 24, 2008 at 1:19 PM, Jake Breen <[EMAIL PROTECTED]
> >
> wrote:
>
> > Also when are you folks gonna fix the low quality texture bug in the
> > source sdk? It's quite annoying to work with.
> >
> > Jake Breen wrote:
> > > Aw no particle editor, but glad to see the sdk isn't beta anymore.
> > Congrats.
> > >
> > > Mike Durand wrote:
> > >
> > >> Hi All-
> > >>
> > >>
> > >>
> > >>  The Source SDK has been updated to address some crashes and is no
> > >> longer in beta. Here are the release notes:
> > >>
> > >>
> > >>
> > >> =Enhancements=
> > >>
> > >> * There is now a drop list in the SDK Launcher that allows the user
> to
> > >> switch between engine versions.
> > >>
> > >> * Modders can now create single player and multi-player mods based in
> > >> the HL2:Episode Two source code when the engine version is set to The
> > >> Orange Box. It is still possible to create mods based on HL2:Episode
> > >> One.
> > >>
> > >> * Two new lighting preview modes are available in Hammer.
> > >>
> > >> * Models are automatically centered when loaded in Faceposer.
> > >>
> > >>
> > >>
> > >> =Bug Fixes=
> > >>
> > >> * Fixed crash and corrupt configurations for users that don't own any
> > >> Orange Box games.
> > >>
> > >> * Resolved issues with building models for any games that that use
> the
> > >> Half-Life 2:Episode 1 engine.
> > >>
> > >> * Fixed crashes in Hammer and Model Viewer when HL2 is set to the
> > active
> > >> game.
> > >>
> > >>
> > >>
> > >> =Known Issues=
> > >>
> > >> * Cannot create shortcuts to Hammer, Faceposer, and Model Viewer.
> > >>
> > >> * Linux makefiles for the Orange Box source code are incomplete and
> > will
> > >> be updated in the next release.
> > >>
> > >> * The Particle Editor is not presently included in the Source SDK.
> > >>
> > >> * SDK shader code only included with mods built to use Half-Life
> > >> 2:Episode 1.
> > >>
> > >> * Particle Editor is not included in this release.
> > >>
> > >>
> > >>
> > >> Please overcome your typical shyness and report any problems you have
> > to
> > >> me. J
> > >>
> > >>
> > >>
> > >> -Best,
> > >>
> > >>  Mike
> > >>
> > >> ___
> > >> 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
> >
> >
>
>
> --
> Gear Dev
> ___
> 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] OrangeBox SDK m_vecNetworkOrigin prediction bug

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Is there a fix to this bug yet?  I have confirmed this on 2 different
computers.
The only things I did to the SDK was remove the DT_WaterBullet /
DT_WeaponCycler classes entirely, by commenting and removing files.

Bug Description:
  Client and Server are not in-sync for the m_vecNetworkOrigin variable.
This causes stutterring of player movement since prediction will attempt to
fix the position.  Motion Blur has no effect on this issue.

How to Know if you Have it?
  1) sv_cheats 1
  2) cl_pdump 1
  3) Run/Jump and watch m_vecNetworkOrigin, will turn red if not in-sync.
  or
  1) The world stutters as you move around.
--

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

Re: [hlcoders] OB Scratch Mod (Movement Stutter)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
When I turn motion blur off it still jitters and m_vecNetworkOrigin still
shows all red in cl_pdump

On Feb 10, 2008 3:08 PM, Akz <[EMAIL PROTECTED]> wrote:

> Any news on this issue? I'm getting this too and it is in fact related
> to motion blur. As soon as motion blur is disabled the problem goes
> away... I don't think the prediction errors with m_vecNetworkOrigin have
> anything to do with this. Also tested this in TF2 but it doesn't seem to
> happen there.
>
> Garry Newman wrote:
>
> >I think the stuttering only happens in listen servers when you're the
> >host and is just the motion blur stuttering. I'm pretty sure it
> >happens in TF2 too.
> >
> >garry
> >
> >On Tue, Feb 5, 2008 at 7:18 PM, Joel R. <[EMAIL PROTECTED]> wrote:
> >
> >
> >>--
> >>[ Picked text/plain from multipart/alternative ]
> >>I still haven't figured this out, it seems to happen on Scratch Mod and
> >>Multiplayer Mod.  When I use cl_pdump 1 to show my data it says that
> >>m_vecNetworkOrigin is always out of sync with the server (shows in red)
> when
> >>I move.  I tried upping the prediction tolerance to 100.0f and it still
> was
> >>incorrect.
> >>
> >>I'm able to debug fine so it is loading the correct DLLs, but I don't
> >>understand how no one else has this problem or notices 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

Re: [hlcoders] OB Scratch Mod (Movement Stutter)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Yea my problem is isolated to Episode 2 with scratch/mp mods.
m_vecNetworkOrigin is getting messed up somewhere.

On Feb 5, 2008 4:50 PM, Ross Bearman <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Jay, do you want to post the code, or could you get in contact with us at
> [EMAIL PROTECTED] Would be a great help, a soon as we can merge it
> in
> an test it I'll get back to the list about how it performs in MP.
>
> On Feb 5, 2008 10:22 PM, Jay Stelly <[EMAIL PROTECTED]> wrote:
>
> > It sounds like you guys are all talking about different problems.  The
> > original post said:
> >
> > > Also the default movement for players stutters as you walk, jump or
> > fall.
> >
> > That doesn't sound like it's related to motion blur, or physics objects
> > and it certainly doesn't happen in tf2 (at least not on my machine).
> > That sounds more like a prediction or interpolation problem.  It should
> > be easy enough to isolate by disabling prediction or running on a listen
> > server in single player mode.
> >
> > As far as problems with physics objects and movement - I did fix a
> > couple of things on that between ep1 and TOB.  There are still
> > prediction errors in that case because the simulation is still server
> > only, but the player command scheduling code changed to fix a problem
> > with jitter/batching in the usercmds arriving at the server.  You
> > wouldn't notice any of these problems in single player except on the low
> > end where sv_alternateticks 1 creates a similar situation.  I haven't
> > tested that code against HL2MP but I imagine it would help with the
> > player movement over physics props if integrated.
> >
> > Jay
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Ross Bearman
> > > Sent: Tuesday, February 05, 2008 12:51 PM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: Re: [hlcoders] OB Scratch Mod (Movement Stutter)
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ] It's also
> > > definitely not motion blur as the SourceForts build that has
> > > the bug is in an older SDK. The problem most commonly occurs
> > > in SourceForts when people push a physics object up against
> > > another one, unfortunately even after extensive testing we
> > > couldn't replicate it to any degree of success.
> > > It would just happen, seemingly randomly. I've only ever got
> > > it once or twice, some people get it to an unbearable level.
> > >
> > > Our proposed fix was "Make player jump 0 units (stop looking
> > > at me funny) every few seconds or every time a movement key
> > > is pressed to minimise the noticeable effect of jitter bug."
> > >
> > > I'm not sure whether this has been tested yet our end, so you
> > > may want to try this as a fix.
> > >
> > > On Feb 5, 2008 8:32 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ] The problem he's
> > > > reporting can't possibly have anything to do with motion
> > > blur. Motion
> > > > blur is a post processing effect done purely after
> > > everything has been
> > > > rendered. He said he's printing cl_pdump 1 (1 being his player's
> > > > entity) and it's showing that m_vecNetworkOrigin is
> > > constantly out of
> > > > sync.
> > > >
> > > > This definitely leads me to believe there is a prediction
> > > problem, but
> > > > I don't really know what it is either. I've had this happen after I
> > > > slam into a wall while walking, and then having it fix itself by
> > > > jumping. It actually all started after a steam update a while back,
> > > > and nothing that I can see in the game code itself has changed.
> > > >
> > > >
> > > > On Feb 5, 2008 2:30 PM, Garry Newman <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > I think the stuttering only happens in listen servers
> > > when you're the
> > > > > host and is just the motion blur stuttering. I'm pretty sure it
> > > > > happens in TF2 too.
> > > > >
> > > > > garry
> > 

Re: [hlcoders] OB Scratch Mod (Movement Stutter)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I still haven't figured this out, it seems to happen on Scratch Mod and
Multiplayer Mod.  When I use cl_pdump 1 to show my data it says that
m_vecNetworkOrigin is always out of sync with the server (shows in red) when
I move.  I tried upping the prediction tolerance to 100.0f and it still was
incorrect.

I'm able to debug fine so it is loading the correct DLLs, but I don't
understand how no one else has this problem or notices it.
--

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

[hlcoders] OB Scratch Mod (Movement Stutter)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Mike,

The "Start a mod from scratch" is set to use AppID 420 when that doesn't
work, only 440 does.  Also the default movement for players stutters as you
walk, jump or fall.  Looking around with mouse is very smooth, so it's
something with the movement code.  I updated and reinstalled the sdk 5
minutes ago so it's happened on 2 stock installs.
--

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

Re: [hlcoders] SDK Orange Box Crash (vstdlib.dll)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I am using AppId 420 and I've tested using the hl2.exe from all folders,
only one that loads is Source SDK Base but it still crashes when I try
creating a server.

On Jan 28, 2008 6:08 PM, Tim Baker <[EMAIL PROTECTED]> wrote:

> Mike Durand said:
> "
> 1) We have made it so that anyone who has the rights to the old Source
> SDK Base (215) will get the new one (218). This means that users who do
> not own any Orange Box games will be able to play your mod using the
> Orange Box engine. Of course, if your mod utilizes content from an
> Orange Box game then your customer will need to own that game. Right now
> there is a problem with the new SDK Base so you should use 420 if your
> mod is single player or 440 if your mod is multi-player.
> "
>
> I've been using the Episode 2 hl2.exe.
>
> -- Tim Baker
>
>
> > It seems everyone is able to get their game to run except me.  When I
> run
> > the game it loads up the mod, then when I create a server it crashes
> right
> > away and the call stack shows it's last instruction in the vstdlib.dll.
>  I
> > deleted everything regarding SDK Base/Tools and when I re-downloaded and
> > recreated my mod, the same exact error happens.
> >
> > For debug I'm using the HL2.exe in Source SDK Base folder to start up
> the
> > game.  As far as I know thats correct.  It is using the updated AppID,
> so
> > I'm not sure how you guys are getting it to run.
>
>
> ___
> 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] SDK Orange Box Crash (vstdlib.dll)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
It seems everyone is able to get their game to run except me.  When I run
the game it loads up the mod, then when I create a server it crashes right
away and the call stack shows it's last instruction in the vstdlib.dll.  I
deleted everything regarding SDK Base/Tools and when I re-downloaded and
recreated my mod, the same exact error happens.

For debug I'm using the HL2.exe in Source SDK Base folder to start up the
game.  As far as I know thats correct.  It is using the updated AppID, so
I'm not sure how you guys are getting it to run.
--

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

Re: [hlcoders] New update.

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I've gotten it to compile, but I can't get it to run.

I've tried using AppId 440 and the fixes posted by Mike by omega, but they
don't work either.  The call stack shows it to be vstdlib.dll where it
crashes.  I'm waiting for the official fixes though.  Hopefully particle
editor gets thrown in =)

On Jan 25, 2008 3:19 PM, Jake Breen <[EMAIL PROTECTED]> wrote:

> Has anyone got the episodic code to compile with vs 2005?
> Or is that just me >.>
>
> -Jake
>
> Garry Newman wrote:
> > If you haven't restarted Steam since you changed it, you should..
> >
> > garry
> >
> > On Jan 25, 2008 7:29 PM, Adam Buckland <[EMAIL PROTECTED]> wrote:
> >
> >> --
> >> [ Picked text/plain from multipart/alternative ]
> >> That's the problem. I am using AppID 440...
> >>
> >> Any ideas? :)
> >>
> >> --
> >>
> >> ___
> >> 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] New update.

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Usually a couple minutes past midnight =)

On Jan 23, 2008 10:42 AM, Tobias Kammersgaard <[EMAIL PROTECTED]>
wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Either that, or to avoid the refence to Valve time ;)
> http://developer.valvesoftware.com/wiki/Valve_time
>
> /ProZak
>
>
> On 23/01/2008, Paul Peloski <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Don't get your hopes up. Notice how he left off the year on 1/23. He
> > really
> > means 1/23/2009. Why else would he specify the date in that format when
> he
> > could have just said "later today."
> >
> > Regards,
> >
> > Paul
> >
> > On Jan 23, 2008 4:54 AM, Tom Leighton <[EMAIL PROTECTED]>
> wrote:
> >
> > > Cheers Mike.
> > >
> > > :O TODAYS THE 23RD
> > >
> > > Awesome, cheers Mike
> > >
> > > Matt Stafford wrote:
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Cheers for the update Mike.
> > > >
> > > > On Jan 23, 2008 4:58 PM, Mike Durand <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > >
> > > >> Hi All-
> > > >>
> > > >> I'm just testing a release candidate now. If there aren't any
> > > showstoppers
> > > >> then we will have a public beta starting on 1/23. I'll keep you
> > posted.
> > > >>
> > > >> Thanks for your patience.
> > > >>
> > > >> -Mike
> > > >>
> > > >> -Original Message-
> > > >> From: [EMAIL PROTECTED] [mailto:
> > > >> [EMAIL PROTECTED] On Behalf Of Tom Leighton
> > > >>  Sent: Tuesday, January 22, 2008 6:59 PM
> > > >> To: hlcoders@list.valvesoftware.com
> > > >> Subject: Re: [hlcoders] New update.
> > > >>
> > > >> über ditto
> > > >>
> > > >> Matt Stafford wrote:
> > > >>
> > > >>> --
> > > >>> [ Picked text/plain from multipart/alternative ]
> > > >>> Ditto.
> > > >>>
> > > >>> On 1/23/08, Joel R. <[EMAIL PROTECTED]> wrote:
> > > >>>
> > > >>>
> > > >>>> --
> > > >>>> [ Picked text/plain from multipart/alternative ]
> > > >>>> Is the Steam update nearing completion?  I've got a lot of coding
> > > ahead
> > > >>>>
> > > >> of
> > > >>
> > > >>>> me and I'd love to get started soon.
> > > >>>>
> > > >>>> On Jan 15, 2008 6:58 PM, Brandon Dunham <[EMAIL PROTECTED]>
> > wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> --
> > > >>>>> [ Picked text/plain from multipart/alternative ]
> > > >>>>> I agree with this, even something like this:
> > > >>>>> -EP1 Engine
> > > >>>>> =HL2
> > > >>>>> =HL2: DM
> > > >>>>> =HL2: EP1
> > > >>>>> -Orange Box Engine
> > > >>>>> =Portal
> > > >>>>> =Team Fortress 2
> > > >>>>>
> > > >>>>> But then again, I guess it might have something to do with the
> > game
> > > >>>>> config.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> From: [EMAIL PROTECTED]
> > > >>>>>> To: hlcoders@list.valvesoftware.com
> > > >>>>>> Subject: Re: [hlcoders] New update.
> > > >>>>>> Date: Tue, 15 Jan 2008 15:26:26 -0700
> > > >>>>>>
> > > >>>>>> I apologize if I'm overstepping my bounds, but may I make a
> > > >>>>>>
> > > >> suggestion
> > > >>
> > > >>>>>> to change your change slightly? I know everyone on this list
> will
> > > >>>>>> understand the purpose of the engine selector list box and why
> > the
> > > >>>>>

Re: [hlcoders] New update.

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Is the Steam update nearing completion?  I've got a lot of coding ahead of
me and I'd love to get started soon.

On Jan 15, 2008 6:58 PM, Brandon Dunham <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> I agree with this, even something like this:
> -EP1 Engine
> =HL2
> =HL2: DM
> =HL2: EP1
> -Orange Box Engine
> =Portal
> =Team Fortress 2
>
> But then again, I guess it might have something to do with the game
> config.
>
>
> > From: [EMAIL PROTECTED]
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] New update.
> > Date: Tue, 15 Jan 2008 15:26:26 -0700
> >
> > I apologize if I'm overstepping my bounds, but may I make a suggestion
> > to change your change slightly? I know everyone on this list will
> > understand the purpose of the engine selector list box and why the games
> > are separated, but if you're already integrating the Orange Box and
> > Episode 1 SDK Launchers, why not simply combine the games in one single
> > list box? I suggest this from a user experience and end user simplicity
> > standpoint... having one list with all the games, just like it used to
> > be, will cause less questions to be asked by people who are new to the
> SDK.
> >
> > //   Adam Maras (memzero)
> >
> > Mike Durand wrote:
> > > That change comment shouldn't have gone out when it did so there is no
> > > change in the SDK Launcher yet. When it does get updated then you will
> > > have a drop-list of engine versions that removed the need to add the
> > > "-engine" start option.
> > >
> > > -Mike
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Tom
> Leighton
> > > Sent: Tuesday, January 15, 2008 12:42 AM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: Re: [hlcoders] New update.
> > >
> > > Same, i cant see any changes to the source sdk launcher... The same
> old
> > > dropdown box for games, and -engine ep1 still has effect.
> > >
> > >
> > > Jake Breen wrote:
> > >
> > >> Anyone know what this changes?
> > >> "
> > >>
> > >>* SDK Launcher now has a drop list of engine versions in addition
> > >>
> > > to
> > >
> > >>  a drop list of games/mods. This eliminates the need to specify
> > >>  engine version as a launch option"
> > >>
> > >>
> > >> From the latest steam update...no changes to source sdk on my side...
> > >>
> > >> ___
> > >> 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
> >
>
> _
> Make distant family not so distant with Windows Vista(R) + Windows Live™.
>
> http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
> --
>
> ___
> 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] Re: Shader - Multi-Pass and Light Direction

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I figured out how to blend the colors together.  We can't use the values of
the first pass but we can blend 2 passes using:

EnableAlphaBlending( SHADER_BLEND_ONE, SHADER_BLEND_ONE_MINUS_DST_ALPHA );

The first param is the source , and second param is destination, there are
different blend types listed in the enum ShaderBlendFactor_t.

I'm still not sure about Light Direction and Color though.  I'm only able to
get the light at my current origin and not at the pixel in the map.

Also another question popped up recently, will we have access to all of the
TF2/portal shaders?
--

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

[hlcoders] Shader - Multi-Pass and Light Direction

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Hey guys,

I'm having trouble figuring out how Multi-Pass shaders in Source work.  I'm
looking at the dx9 shader dll files.  core_dx9.cpp offers the best example
of a multi-pass shader.  However, there are a few things I don't
understand.

1) How can I use the end result colors of the first pass and manipulate it
in the second pass.  The core_dx9 just shows it running the exact same thing
2 times, do the colors get combined automatically?

2) Do I have to redo all the calculations again for Light Direction and
Color?
---a) Light Direction:
---1) How can I get the light direction and color in the pixel shader?
---2) Is there a way I can reuse the values from first pass?

Any help would be appreciated thanks.
--

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

Re: [hlcoders] Creating a Sphere Trace

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I just noticed that HL1 has a TraceSphere function available.  Did this
function become flawed once the Physics system was entered in the the scene
equation?  Just wondering why it was removed from HL2.

On Sep 29, 2007 4:50 PM, Daniel Menard <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Not having a method of tracing a VCollide to the world really limits what
> we
> can do with prediction, especially when talking about vehicles. Since
> VPhysics is essentially unpredictable in the networking sense, we can't
> run
> the collision code client-side (unless we limit ourselves to an AABB,
> which
> really won't work for proned players, cars, trucks, planes etc..). The
> ability to sweep a collidable and implement our own physics in game code
> would fix this... There is a SweepCollideable function in the physics
> interface, but it is stubbed.
>
> We've found a happy medium, which is to have predictable simulation code
> much like the players and having a Physics Shadow follow the object server
> side. This works for flying vehicles (since most of the time they don't
> hit
> stuff). Any mod working with ground vehicles has a huge problem though,
> since they're always colliding. Not predicting vehicles is an option, but
> expect your player base to complain about laggy controls...
>
> On 9/29/07, John Sheu <[EMAIL PROTECTED]> wrote:
> >
> > Jay Stelly wrote:
> > > But it's not a framework that lets you sweep a
> > > vcollide against the entire scene - which is probably what you want
> (and
> > > what John wanted as I recall).  In fact it's pretty straightforward to
> > > extend vphysics to do this, but the current implementation would be
> > > incredibly slow if you used any displacements at all because it would
> > > have to consider each triangle separately.
> > >
> >
> > That would be really nice.  Or actually, would have been really nice.
> > And kinda overdue, since the SDK-side framework is there
> > > d) "physics tests only happen once per frame in static positions" -
> not
> > > exactly sure what you are trying to say here but it sounds incorrect
> to
> > > me.  The movement in vphysics though not described as sweeps/traces is
> > > still computed as continuous motion.  It's not like all of the objects
> > > move and then do a static test to see if they are inside another
> object
> > > or have passed through another object.  The collisions are computed
> > > continuously along the path of translation/rotation.  It may still be
> a
> > > pain for your player movement strategy, but it certainly isn't
> evaluated
> > > in "static positions" if that helps to understand it better.
> > >
> >
> > I realize that VPhysics fundamentally does continuous collisions.  I've
> > played around some with the Bullet physics library some, and an idea of
> > how things work.  (Whether this is a correct "idea" or not is another
> > question.)  What I mean was that from game code, you cannot evaluate
> > collisions on a collideable from more than one position in a given
> > frame, or move/sweep them during the frame for movement tests.
> >
> > -John Sheu
> >
> > ___
> > 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] Any Source 2007 code update?

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
The psycological effect has already been enacted.  I am doomed.

On Jan 14, 2008 1:01 AM, Adam amckern McKern <[EMAIL PROTECTED]> wrote:

> Knowing valve it would be something along the lines
> of;
>
> - Fixed everything
> - Added a hole heap of stuff
>
> Then a week latter;
> - Updated steam so mods would be broken if they
> migrated to the new code base.
> - Ported CSS to the new engine so hammer wont work
> either
>
> :P
>
> Adam
>
>
> --- Matt Stafford <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Still doesn't answer the questions about tool
> > updates and bug fixes :)
> >
> > On 1/14/08, Ryan Sheffer <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > If you remember the huge code update with episode
> > 1, expect that but more.
> > > D:
> > >
> > > On Jan 13, 2008 2:48 PM, Matt Stafford
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Thanks Mike. Can we get any indication on whats
> > included with this
> > > update?
> > > > Which tools (particle editor, material editor
> > etc) and any major bug
> > > fixes
> > > > or code changes? Shader updates etc? Or are we
> > just gonna wait it out
> > > and
> > > > get a surprise :)
> > > >
> > > > On 1/11/08, andy no <[EMAIL PROTECTED]>
> > wrote:
> > > > >
> > > > > Hope fully it will come fast.
> > > > >
> > > > >
> > ___
> > > > > To unsubscribe, edit your list preferences, or
> > view the list archives,
> > > > > please visit:
> > > > >
> >
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matt Stafford (Wraiyth)
> > > > http://www.wraiyth.com
> > > > --
> > > >
> > > > ___
> > > > To unsubscribe, edit your list preferences, or
> > view the list archives,
> > > > please visit:
> > > >
> >
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >
> > > >
> > >
> > >
> > > --
> > > ~skidz
> > > --
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or
> > view the list archives,
> > > please visit:
> > >
> >
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> >
> >
> > --
> > Matt Stafford (Wraiyth)
> > http://www.wraiyth.com
> > --
> >
> > ___
> > To unsubscribe, edit your list preferences, or view
> > the list archives, please visit:
> >
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
>
> 
> Owner Nigredo Studios http://www.nigredostudios.com
>
>
>
>  
> 
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ___
> 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] Sleep

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I don't think you want to freeze the computer for any amount of time.  I
think what you need is just a float var that saves gpGlobals->curtime and
uses that to determine if 3 seconds passed.

On Dec 9, 2007 5:14 PM, Christopher <[EMAIL PROTECTED]> wrote:

> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> What is the best way to do a Sleep(.) command within the server version of
> the player, and what would I have to #include?
>
>
>
> I want to change the velocity of the player 3 times over 3 seconds.
>
>
>
> 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

[hlcoders] Any Source 2007 code update?

[Joel R.]

Is there any news regarding the delays for the Source 2007 sdk code to
be released?  I've put the entire mod on hold until it gets released
as I expected it to be rather soon.  There has been complete silence
lately regarding what's happening or what's needed to happen to roll
it out to us folks that are waiting.  I'd rather get a rough draft now
to begin the implementation than blindly wait months for it to be
released and be taken by suprise to begin the long merging process.

Any news would be appreciated, thanks!

-Joel

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

Re: [hlcoders] NPC hull vs. NPC size

[Joel R.]

Havoc should have a function that does an OBB trace that could be exposed to us.

On Nov 26, 2007 1:30 PM, Paul Peloski <[EMAIL PROTECTED]> wrote:
> --
> [ Picked text/plain from multipart/alternative ]
> Well, there is UTIL_TraceEntity/AI_TraceEntity, which seems to be able to
> sweep an OBB. But I don't think the path finding code is set up to use it.
> Though of course I haven't read every file in the SDK and I was hoping there
> was some NPC/code path that overrides the TraceHull CAI_MoveProbe with a
> TraceEntity one. What I want seems possible but with no working example or
> advice I'm reluctant to start coding it in case it becomes too
> difficult/impossible.
>
> Regards,
>
> Paul
>
>
> On Nov 26, 2007 10:30 AM, Maarten De Meyer <[EMAIL PROTECTED]> wrote:
>
> > Not me, but I'd like to hijack the opportunity to rant:
> >
> > For me personally, the lack of a SOLID_OBB is the biggest flaw in Source.
> > We should chain ourselves to the valve offices until they expose or
> > implement a SOLID_OBB or something equivalent.
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Hi guys,
> > >
> > > I'm trying to make an NPC that is longer than he is wide. For example he
> > > would be walk down a human sized hallway, but not turn around in the
> > > hallway. The problem I ran into is that the hulls are AABB, which means
> > > either I make the box so large he can't fit in the hallway, or I cheat
> > and
> > > make it too small which results in shot traces not hitting him properly
> > > (BaseNPC sets his regular bounding box to match his hull size..)
> > >
> > > So, anybody know of a work around or have any suggestions?
> > > --
> > >
> > > ___
> > > 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] movement code

[Joel R.]

gamemovement.cpp and sdk_gamemovement.cpp are the files you want.
They handle the walking on ground / collision.

On Nov 17, 2007 12:03 AM, Neuwirth Christoph <[EMAIL PROTECTED]> wrote:
> No one?
>
> Neuwirth Christoph schrieb:
>
> > Hello
> >
> > After i got the suggestions from you guys to wait with serious work
> > until ep2 sdk comes out, i decided to learn a bit about the movement
> > code of hl2.
> >
> > 1. How much Difference is between hl1 and hl2 movement code(except hl1
> > is c and hl2 is c++)
> > 2. How is the movement code predicted?
> > 3. is the Movement code shared like hl1 or has each workspace its own
> > movement code?
> > 4. Is it possible to port the hl1 movementcode to c++ even without
> > engine access?(i know a lil offtopic but interesting tough)
> >
> > greetz
> > chris
> >
> > ___
> > 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] Maximize view key needed for hammer.

[Joel R.]

It be neat if they made Hammer open source, that way a bunch of us
awesome and bored programmers can improve and add features, and share
with the community.  Doesn't seem they have anyone working on Valve
Hammer anymore, and its got a plethora of bugs.

On Nov 12, 2007 2:59 PM, Ryan --- <[EMAIL PROTECTED]> wrote:
> Ctrl+A returns the view ports to their original sizes but there is an
> absense of a maximize key.
>
> Any chance of this being added?
>
> ___
> 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] SDK Update Available Tomorrow Morning

[Joel R.]

This is truely awesome.

On Nov 6, 2007 7:44 PM, Mike Durand <[EMAIL PROTECTED]> wrote:
> Hi All-
>
> I wanted to let you all know that I have finished testing the SDK update
> and it will go live tomorrow morning. Thanks very much for your patience
> while I spent extra time testing it out.
>
> As I've said before the main purpose of this release is to get the
> updated content creation tools in the hands of the community. The next
> major release will include the client and server DLL code for Episode 2
> although there may be a couple of minor releases before to address any
> problems.
>
> Here are the interesting things to know about the release tomorrow:
>
> 1. The new SDK contains tools for creating content compatible with both
> the Ep1 and Orange Box versions of the Source Engine.
> 2. By default the SDK launcher will launch the Orange Box versions of
> Hammer, Face Poser, and Model Viewer.
> 3. Adding '-engine ep1' to the launch options for the Source SDK tool
> will set the launcher to run the Ep1 versions of Hammer Face Poser, and
> Model Viewer
> 4. There is a new directory structure underneath
> '%SteamInstallPath%\steamapps\\sourcesdk'
>a. sourcesdk\bin - contains the binaries needed to run the SDK
> Launcher
>b. sourcesdk\bin\ep1\bin - contains the Ep1 tools and the
> GameConfig.txt that is run when the Source SDK is in "Ep1" mode
>c. sourcesdk\bin\orangebox\bin - contains the Orange Box tools and
> the GameConfig.txt that is run when the Source SDK is in "Orange Box"
> mode
> 5. There is a .vmf file for one of the shipping Portal maps in the
> 'sourcesdk_content' directory - testchmb_a_05.vmf. I will add an example
> map for Team Fortress 2 in a subsequent release.
> 6. When running the Orange Box versions of the 'studiomdl' and 'vtex'
> you should include '-nop4' on the command line to bypass our Perforce
> integration with these tools. I will eliminate this need in a subsequent
> release.
>
> We're launching the new SDK in the morning so that I can be available to
> make fixes as soon as you get your hands on the SDK. Once it goes live
> please feel free to e-mail me directly if you see any problems. We
> aren't able to release this version of the SDK as a beta so I will try
> to act as quickly as possible to fix problems and put out an update.
>
> -Mike Durand
>  Valve
>
> ___
> 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] Your version does not match the Servers.

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I'm receiving this error when trying to connect to a server via Steam Server
Browser, however, I can connect if I use the console command: connect
"IP:PORT" .  The server uses HldsUpdateTool method of creating a server
using the HL2MP as game.  I do not get this error if I use Source Dedicated
Server through Steam however.  The forums state some fixes that worked for
Valve games, however they don't work at all for 3rd Party HL2 Mods.

Source Dedicated Server and HldsUpdateTool both show different server
versions.
HL2MP (HldsUpdateTool):
 Protocol version 7
 Exe version 1.0.0.12 (hl2dm)
 Exe build: 18:49:39 Sep  5 2007 (3224)

Source Dedicated Server:
 Protocol version 7
 Exe version 1.0.1.0 (valve)
 Exe build: 18:49:39 Sep  5 2007 (3224)

There really should be a new game type for hldsupatetool to use for Source
SDK Base, but any help would be appreciated on this subject, thanks!
--

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

Re: [hlcoders] Playing the mod offline

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Yea, having an offline mode that requires a connection to the internet, is
rather redundant.  I hope Valve sees this as doing more harm than good.  We
shouldn't need to be connected to steam just to play a single player game or
LAN game.  If they want to see more single player games being added to Steam
they'll have to do away with this feature.  If not for the players, they'll
do it for the $$.

On 10/26/07, Matt Stafford <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> I really, really hate the limitations that we have for offline play. I
> spend
> alot of time at university and half the time when I try to run my mod, I
> get
> the whole 'Cannot play game' thing, and frankly its just bloody annoying
> and
> almost enough to put me off Source modding full stop.
>
> On 10/27/07, Minh <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > I think you have to first run your mod while connected to the internet
> > ONCE,
> > and then after that you can run it in offline mode.
> >
> > - Original Message -
> > From: "Emiel Regis" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Friday, October 26, 2007 2:52 PM
> > Subject: [hlcoders] Playing the mod offline
> >
> >
> > > Hi,
> > >
> > > Our mod is preparing for some offline presentation and we've
> encountered
> > a
> > > problem. When trying to run the mod in steam offline mode, without
> > > internet connection we get:
> > > "Error verifiying steam user ticket ID"
> > >
> > > This doesn't show when trying to play any other game. What is wrong?
> > >
> > > Cheers,
> > > Millz
> > >
> > > ___
> > > 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
> >
> >
>
>
> --
> Matt Stafford (Wraiyth)
> http://www.wraiyth.com
> NightFall, a Half Life 2 Single Player Mod - http://www.nightfallmod.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] Old GMod Hud (How to?)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
engine->Con_NPrintf( number, "Any text you want %s %i %f", "More Text", 150,
150.0f );

The number is a vertical position on the screen.

You can use that or just create your own, which I won't get into cause it's
alot, but look at how they do the chat text.

On 10/23/07, Drak <[EMAIL PROTECTED]> wrote:
>
> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> I can't seem to figure out how garry made this HUD object, that he's had
> in
> the old/new version of GMod.
>
> (http://img521.imageshack.us/img521/811/gmodhudgk2.jpg)
>
>
>
> Is this a HUD element? If I try basing the code off of something like the
> Health Bar, it comes out with the 'large yellow' text.
>
> How did he sent the font to something of that size, and draw the square? I
> didn't find anything new 'HudLayout.res' which made me question it more.
>
> Sorry the question isn't very detailed.. But, if anyone has any ideas on
> this, 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

Re: [hlcoders] Using ApplyBoneMatrixTransform

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Oops forgot about the code to scale. Its very simple really.

This is the function
ApplyBoneMatrixTransform( matrix3x4_t& transform )
{
float scale = sdk_grow.GetFloat();
VectorScale( transform[0], scale, transform[0] );
VectorScale( transform[1], scale, transform[1] );
VectorScale( transform[2], scale, transform[2] );
}

If you only scale certain parts of the matrix, you'll get that skewed model
look.  Can be great if you want to make a squished pancake look for your
model.  Remember it only works on non static-props.

On 10/22/07, Joel R. <[EMAIL PROTECTED]> wrote:
>
> It's the matrix transform of a model.  It defines the orientation,
> location and scale. The bone structure is what animates your model, and its
> tied directly with each poly/tri of the model.  This is why you can
> increase, decrease, and skew the model like it got squished like a pancake.
> This also only works with non-static prop models.  I"m not entirely sure why
> though.
>
> This is how engine's draw models to your screen.  They're model file
> contains a sort of matrix along with vertex data (each point of a
> poly/tri).  Then if the engine wanted to rotate the model, all it had to do
> was rotate the matrix and each vertex will be rotated as well.  But since
> these things carry animations, you want to scale the bone structure as well,
> so the animations get scaled too.
>
>
> On 10/22/07, Garrett <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Hi,
> > I've been trying to figure out how to use
> > C_BaseAnimating::ApplyBoneMatrixTransform to change the appearance of models
> > in game, such as changing the size of the model, but I'm kind of lost.  I
> > tried to trace back through what calls it, but I just couldn't figure where
> > it started and how it works.  If someone could give me a simple example(if
> > there is such a thing as a simple example of this kind of thing) with an
> > explanation of what was going on and how it worked, I think that would help
> > out a lot in my understanding of it.
> >
> > Thanks,
> > Garrett
> >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.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] Using ApplyBoneMatrixTransform

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
It's the matrix transform of a model.  It defines the orientation, location
and scale. The bone structure is what animates your model, and its tied
directly with each poly/tri of the model.  This is why you can increase,
decrease, and skew the model like it got squished like a pancake.  This also
only works with non-static prop models.  I"m not entirely sure why though.

This is how engine's draw models to your screen.  They're model file
contains a sort of matrix along with vertex data (each point of a
poly/tri).  Then if the engine wanted to rotate the model, all it had to do
was rotate the matrix and each vertex will be rotated as well.  But since
these things carry animations, you want to scale the bone structure as well,
so the animations get scaled too.


On 10/22/07, Garrett <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Hi,
> I've been trying to figure out how to use
> C_BaseAnimating::ApplyBoneMatrixTransform to change the appearance of models
> in game, such as changing the size of the model, but I'm kind of lost.  I
> tried to trace back through what calls it, but I just couldn't figure where
> it started and how it works.  If someone could give me a simple example(if
> there is such a thing as a simple example of this kind of thing) with an
> explanation of what was going on and how it worked, I think that would help
> out a lot in my understanding of it.
>
> Thanks,
> Garrett
>
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.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

[hlcoders] afxsocket.h conflict with CThreadLocal (threadtools.h)

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I'm attempting to use the Asynchronous Socket class available in windows,
however when I attempt to use this, I get a duplicate template class with
CThreadLocal.  This class is created in threadtools.h which is linked from
cbase.h.  If I want to use the Async Socket header (afxsocket.h) one of its
headers goes to (afxtls_.h) which also has the CThreadLocal template class.
The problem is "cbase.h" will always have to be called first, so theres no
way to avoid this duplication!

There are defines to avoid duplicating it in threadtools.h, however since
this is created through the precompiled header file cbase.h, there is no way
for those defines to go into effect.  I tried renaming valve's CThreadLocal
and also tried creating the #define __AFXTLS_H__ before "cbase.h" in my .cpp
file.  Both give me several linking errors.  Is this an unforeseen bug?  Or
is there a way around this?
--

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

Re: [hlcoders] Quaternion to AxisAngle

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
Ok I see what my problem was, I was concatting my base Quaternion with the
Quaternion I created using the angle, which messed up the angle result.  The
reason I did that was because I'm working on 6 degrees of freedom, and I
wasn't sure if I have a rotated angle that it would give me a correct angle
based on my "Base Quaternion".

I'll attempt to test this from a different rotation now.

On 10/1/07, Jay Stelly <[EMAIL PROTECTED]> wrote:
>
> Maybe it's something we've fixed?  I added your code:
>
> Quaternion qNewOrientation;
> Vector axis;
> float angle;
>
> AngleQuaternion( QAngle(0,90,0), qNewOrientation );
> QuaternionAxisAngle( qNewOrientation, axis, angle );
> Msg("Q:Axis: %.2f %.2f %.2f :: %.3f\n", VectorExpand(axis),
> angle );
> // If I pass QAngle(0,90,0)  I will get 0.707106 or 90 angle
>
> AngleQuaternion( QAngle(0,270,0), qNewOrientation );
> QuaternionAxisAngle( qNewOrientation, axis, angle );
> Msg("Q:Axis: %.2f %.2f %.2f :: %.3f\n", VectorExpand(axis),
> angle );
> // If I pass QAngle(0,270,0)  I also get 0.707106 or 90 angle
>
> And I get these results:
> Q:Axis: 0.00 0.00 1.00 :: 90.000
> Q:Axis: -0.00 0.00 1.00 :: -90.000
>
> But I'm running the orange box sdk.
>
> Here's the code for QuaternionAxisAngle()
> void QuaternionAxisAngle( const Quaternion &q, Vector &axis, float
> &angle )
> {
> angle = RAD2DEG(2 * acos(q.w));
> if ( angle > 180 )
> {
> angle -= 360;
> }
> axis.x = q.x;
> axis.y = q.y;
> axis.z = q.z;
> VectorNormalize( axis );
> }
>
> Is that the same code you're using?
>
> Jay
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joel R.
> Sent: Monday, October 01, 2007 3:06 AM
> To: hlcoders
> Subject: [hlcoders] Quaternion to AxisAngle
>
> --
> [ Picked text/plain from multipart/alternative ]
> I'm having a problem getting the correct angle.  I seem to be stuck
> getting
> an angle between 0 and 180, due to the W value always being 0.0 to 1.0
> and
> not -1.0 to 1.0.
>
> ---CODE---
> 
> 
> Quaternion qNewOrientation;
> Vector axis;
> float angle;
>
> AngleQuaternion( m_angSpawnAngle, qNewOrientation );
> QuaternionAxisAngle( qNewOrientation, axis, angle );
> 
> 
>
> If I pass QAngle(0,90,0)  I will get 0.707106 or 90 angle
> If I pass QAngle(0,270,0)  I also get 0.707106 or 90 angle
>
> The latter is suppose to be negative.  When I revert the quaternion back
> to
> a QAngle it gets the orientation correctly.
> The formula QuaternionAxisAngle uses is correct because websites show
> the
> same algorithm used.
> Anyone out there familiar with Quaternions know how I could possibly
> solve
> this? Thanks in advance!
> --
>
> ___
> 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] Quaternion to AxisAngle

[Joel R.]

--
[ Picked text/plain from multipart/alternative ]
I'm having a problem getting the correct angle.  I seem to be stuck getting
an angle between 0 and 180, due to the W value always being 0.0 to 1.0 and
not -1.0 to 1.0.

---CODE---

Quaternion qNewOrientation;
Vector axis;
float angle;

AngleQuaternion( m_angSpawnAngle, qNewOrientation );
QuaternionAxisAngle( qNewOrientation, axis, angle );


If I pass QAngle(0,90,0)  I will get 0.707106 or 90 angle
If I pass QAngle(0,270,0)  I also get 0.707106 or 90 angle

The latter is suppose to be negative.  When I revert the quaternion back to
a QAngle it gets the orientation correctly.
The formula QuaternionAxisAngle uses is correct because websites show the
same algorithm used.
Anyone out there familiar with Quaternions know how I could possibly solve
this? Thanks in advance!
--

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