RE: [hlcoders] About UTIL_TraceModel?
If you want to do this continuously you should make it an entity like trigger_vphysics. Basically this just boils down to creating the vphysics object for the entity (your func_cold) and calling: VPhysicsGetObject()->BecomeTrigger(). Then you'll get StartTouch() EndTouch() callbacks when things touch the trigger. Look at bool CBaseVPhysicsTrigger::CreateVPhysics() for an example of this. If you want to do it instantaneously then you can use physcollision->TraceCollide() to see if two vcollides intersect. There's an example of this for trigger transition: static bool TestEntityTriggerIntersection_Accurate( CBaseEntity *pTrigger, CBaseEntity *pEntity ) Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nick > Sent: Monday, June 19, 2006 7:05 PM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] About UTIL_TraceModel? > > -- > [ Picked text/plain from multipart/alternative ] I am having > difficulties trying to code a method, that will allow me to > detect if a model (prop_physics) entity is in contact with a > custom map brush entity (func_cold). > > > > I don't know where to start but someone suggested that > UTIL_TraceModel might work, but i couldn't find any > explanation of how it works. > > void UTIL_TraceModel( const Vector &vecStart, const Vector > &vecEnd, const Vector &hullMin, const Vector &hullMax, > CBaseEntity *pentModel, int collisionGroup, trace_t *ptr ); > > > What do I put for const Vector &vecStart, const Vector > &vecEnd, const Vector &hullMin, const Vector &hullMax, ? > -- > > ___ > 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] About UTIL_TraceModel?
-- [ Picked text/plain from multipart/alternative ] That's not the way you should do it. Try this: in triggers.cpp, find out how the vphysics trigger works. -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] About UTIL_TraceModel?
-- [ Picked text/plain from multipart/alternative ] I am having difficulties trying to code a method, that will allow me to detect if a model (prop_physics) entity is in contact with a custom map brush entity (func_cold). I don't know where to start but someone suggested that UTIL_TraceModel might work, but i couldn't find any explanation of how it works. void UTIL_TraceModel( const Vector &vecStart, const Vector &vecEnd, const Vector &hullMin, const Vector &hullMax, CBaseEntity *pentModel, int collisionGroup, trace_t *ptr ); What do I put for const Vector &vecStart, const Vector &vecEnd, const Vector &hullMin, const Vector &hullMax, ? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] DX9 SDK vertex lit shader problems
Are you compiling the shaders (fxc files) and the C++ shader code (custom shader DLL)? It sounds like you have one and not the other. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ted Maul > Sent: Monday, June 19, 2006 12:58 PM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] DX9 SDK vertex lit shader problems > > This is quite long, sorry :P > > I'm using sdk_vertexlit_and_unlit_generic_bump_ps20 from the > advanced folder in the SDK shaders. It's completely > unmodified -- the only change I've made is to spam the > lighting information to console. > > This is what happens when the player model steps outside (and > into the influence of the light_environment): > http://img398.imageshack.us/img398/4522/dx9shaderproblem16zv.jpg > http://img465.imageshack.us/img465/1517/dx9shaderproblem26co.jpg > > This is what it should -- and occasionally does -- look like. > http://img263.imageshack.us/img263/4036/dx9shaderproblem36xm.jpg > > For some reason, there's a second light acting on the model > that's being treated as a directional light (according to the > lightCombo) even though it doesn't seem to be directional > light (the direction is a unit vector in the x axis and the > map has no lights of that type). What's strange is that the > other light can be either in the first or second light slot > seemingly arbitrarily (though that lightCombo does specify > two directional lights so it wouldn't matter if that light > actually was directional). > > There are also similar problems that are less obvious when > moving between lights inside buildings (point lights rather > than directional) > -- instead of the smooth lighting transition that happens > with the default dx9 shaders, the lighting flickers when > between some lights and switches instantly and seemingly > arbitrarily around. Changing all directional lights to > behave light point lights in the shader itself improves the > worst of the problems -- namely, the bright coloured lighting > outside -- but the inconsistent lighting throughout levels is > still a big problem. > > Has anyone else encountered this problem or have any ideas > what might be causing it anyway? > > My best guess is that the lightCombo enumerations are out of > sync with what the current engine uses (and maybe some other > stuff is out too) but I don't think that's the whole story > and I can't really see anything obvious that could be causing > it and I don't think the much of the lighting code is exposed > to mods. I'd appreciate any help since we can't move on with > writing some custom player shader effects for our mod until > we have the basics working. > > If you need any more info just ask. 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] OnGameRulesCreationStringChanged
-- [ Picked text/plain from multipart/alternative ] With the help of Yahn & Alfred, it was determined that it was a global object's constructor using an uninitialized interface that made the crash. It was fixed by making it into a CAutoGameSystem -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] DX9 SDK vertex lit shader problems
This is quite long, sorry :P I'm using sdk_vertexlit_and_unlit_generic_bump_ps20 from the advanced folder in the SDK shaders. It's completely unmodified -- the only change I've made is to spam the lighting information to console. This is what happens when the player model steps outside (and into the influence of the light_environment): http://img398.imageshack.us/img398/4522/dx9shaderproblem16zv.jpg http://img465.imageshack.us/img465/1517/dx9shaderproblem26co.jpg This is what it should -- and occasionally does -- look like. http://img263.imageshack.us/img263/4036/dx9shaderproblem36xm.jpg For some reason, there's a second light acting on the model that's being treated as a directional light (according to the lightCombo) even though it doesn't seem to be directional light (the direction is a unit vector in the x axis and the map has no lights of that type). What's strange is that the other light can be either in the first or second light slot seemingly arbitrarily (though that lightCombo does specify two directional lights so it wouldn't matter if that light actually was directional). There are also similar problems that are less obvious when moving between lights inside buildings (point lights rather than directional) -- instead of the smooth lighting transition that happens with the default dx9 shaders, the lighting flickers when between some lights and switches instantly and seemingly arbitrarily around. Changing all directional lights to behave light point lights in the shader itself improves the worst of the problems -- namely, the bright coloured lighting outside -- but the inconsistent lighting throughout levels is still a big problem. Has anyone else encountered this problem or have any ideas what might be causing it anyway? My best guess is that the lightCombo enumerations are out of sync with what the current engine uses (and maybe some other stuff is out too) but I don't think that's the whole story and I can't really see anything obvious that could be causing it and I don't think the much of the lighting code is exposed to mods. I'd appreciate any help since we can't move on with writing some custom player shader effects for our mod until we have the basics working. If you need any more info just ask. Thanks! :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Execute server commands from a VGUI
Quoting Garry Newman <[EMAIL PROTECTED]>: > What's to stop a client just > binding a key to "vgui_screen_opendoor 234" or whatever? Or am I being > simple about it? Could you do some kind of basic encryption of the command? I know it's just security by obscurity but it might be a simple approach that takes care of 99% of the problem. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
