RE: [hlcoders] Server Plugin vs. Interface
-- [ Picked text/plain from multipart/alternative ] I wish I knew why my E-mails have been turning into ugly plain text and removing my formatting... so ugly. Fair enough, I should probably have stated a bit more about this is general, but thank you for pointing this out as I've obviously left out important reference info.This project is, in fact, it's own mod (and that's an understatement). That being said, a server plugin making changes to entities can network entity data and change the client, if required. This is why it was an option for the port IO.Interfaces still make a good side option for communicating directly with the client, or perhaps better phrased as the client requesting data from the interface.Anywho, now I'm just reiterating myself. Thank you luckyduke for the response and feedback. Does anybody else have suggestions as to what would be the best method of implementation?> From: [EMAIL PROTECTED]> To: hlcoders@list.valvesoftware.com> Subject: Re: [hlcoders] Server Plugin vs. Interface> Date: Thu, 16 Aug 2007 10:04:08 -0600> > --> [ Picked text/plain from multipart/alternative ]> Server plugins run on the server only. You can't create "client-side"> plugins.> > You will have to write your own mod to do anything on the client.> > > > On 8/16/07, Meow Mew <[EMAIL PROTECTED]> wrote:> >> > --> > [ Picked text/plain from multipart/alternative ]> >> > Hey, I was hoping I could get some advice from some of you fellow> > coders. Actually writing up the code isn't a problem, but I was having> > difficulty with design and following the structure already in the Valve> > engine.Here's the laydown of what I'm doing:So basically, I'm writing an> > interface for optional port IO for independent hardware to control signal> > pulses. Scent machines, fMRI scanners, head tracking, basically any random> > piece of hardware should be able to plug into a port and send data> > bits. All in all, it's just port IO that I want to be able to hook into the> > logical entity connections. Something like "OnTriggerPulse" or something,> > no big deal. Also, it'll need an input along the lines of> > "SendTriggerPulse". I'm sure the entity can store it's own port number and> > data bits.There's also another module that needs implemented that might be> > hardware specific. Eye tracking has it's own SDK dlls that are vendor> > specific, the client needs to get a HUD update (maybe from server) and the> > server needs to parse the last known position to track entity locations when> > projecting 2D eye positions to 3D (which requires the client view matrix).So> > the design questions are:Should either of these be implemented with the> > plugin interface? The eye tracker is vendor specific, so additional vendors> > may need to create their own plugins for compatibility. This is much more> > extensible, but plugins seem to have inappropriate communication with the> > server and client for passing large datasets.Should either of these use> > the IBaseInterface interface to allow the server or client to access the> > data being polled by these abstract pieces of hardware? This could easily> > resolve an issue of collecting data on the server and client, but adds a> > dependability and a limit to the extensibility that involves the interface> > ID. There can only be one INTERFACEVERSION_VENGINESERVER afterall, and thus> > there could only be one INTERFACEVERSION_VEYETRACKER active at one> > time. This would be much more limiting to the port IO in the event that> > multiple external hardware's would wish to send data bit pulses to control> > logic.Is there a proper combination of the two for either of these> > modules?Would adding more data to CUserCmd be advisable? I know that this> > class actually has a limit to it's size on the engine (which isn't apparent> > on the client or server) that is related to saving replays, and the dynamic> > sized vectors required for the eye tracker to store all possible fixations> > could cause problems. Also, the advantage to a plugin or interface is they> > are possible to remove or have invalid, but CUserCmd must have predictable> > size, meaning the data can be empty, but not removable.Anyway, any> > suggestions are appreciated. I could use some feedback just to wrap my head> > around the methodology I'd want to implement, and to get a better feel for> > the intent of the Valve design.> > _> > Recharge--play
[hlcoders] Server Plugin vs. Interface
-- [ Picked text/plain from multipart/alternative ] Hey, I was hoping I could get some advice from some of you fellow coders. Actually writing up the code isn't a problem, but I was having difficulty with design and following the structure already in the Valve engine.Here's the laydown of what I'm doing:So basically, I'm writing an interface for optional port IO for independent hardware to control signal pulses. Scent machines, fMRI scanners, head tracking, basically any random piece of hardware should be able to plug into a port and send data bits. All in all, it's just port IO that I want to be able to hook into the logical entity connections. Something like "OnTriggerPulse" or something, no big deal. Also, it'll need an input along the lines of "SendTriggerPulse". I'm sure the entity can store it's own port number and data bits.There's also another module that needs implemented that might be hardware specific. Eye tracking has it's own SDK dlls that are vendor specific, the client needs to get a HUD update (maybe from server) and the server needs to parse the last known position to track entity locations when projecting 2D eye positions to 3D (which requires the client view matrix).So the design questions are:Should either of these be implemented with the plugin interface? The eye tracker is vendor specific, so additional vendors may need to create their own plugins for compatibility. This is much more extensible, but plugins seem to have inappropriate communication with the server and client for passing large datasets.Should either of these use the IBaseInterface interface to allow the server or client to access the data being polled by these abstract pieces of hardware? This could easily resolve an issue of collecting data on the server and client, but adds a dependability and a limit to the extensibility that involves the interface ID. There can only be one INTERFACEVERSION_VENGINESERVER afterall, and thus there could only be one INTERFACEVERSION_VEYETRACKER active at one time. This would be much more limiting to the port IO in the event that multiple external hardware's would wish to send data bit pulses to control logic.Is there a proper combination of the two for either of these modules?Would adding more data to CUserCmd be advisable? I know that this class actually has a limit to it's size on the engine (which isn't apparent on the client or server) that is related to saving replays, and the dynamic sized vectors required for the eye tracker to store all possible fixations could cause problems. Also, the advantage to a plugin or interface is they are possible to remove or have invalid, but CUserCmd must have predictable size, meaning the data can be empty, but not removable.Anyway, any suggestions are appreciated. I could use some feedback just to wrap my head around the methodology I'd want to implement, and to get a better feel for the intent of the Valve design. _ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Stereoscopic - EMagin Z800, NVidia 3D
-- [ Picked text/plain from multipart/alternative ] I was hoping somebody could give me a hand with resolving stereoscopic issues in our build. This may require help from a Valve employee due to the nature of the code. We have an old license of the Source engine code-drop, so if this issue was resolved in the vanilla DLLs through updates, we were unable to replicate the fixes ourselves. I am uncertain if Half-life 2 still contains these stereoscopic issues.The problem is that during stereoscopic rendering, the NVidia drivers create the frame indexed stereovision 3D images from the data sent to the GPU, and because the frustum culling is based upon the view matrix, data outside of the standard frustum is simply not sent to the GPU to render. The stereoscopic effect in the NVidia drivers is created by altering the view matrix to the left and to the right for each eye in page flipped rendering, which effectively makes an invalid frustum and invalid culling. The edges of each eye view have missing models and missing BSP world data that normally would not be seen from the "middle" of the eyes, but each eye has different perspective on.Also, the 2D elements seem to be set in a static 3D location, and each view matrix offset for each eye seems to send the HUD incorrectly in both directions as the view matrix moves.I was hoping to find a way to alternate the game view for frustum culling and for 2D elements, but not send in that same view to the rendering. So basically, I want the culling and 2D locations to be based upon each eye's location, but the rendering of all objects to be based upon the "middle" of each eye as per usual. However, I can't find where the view matrix is being set.I tried to change the temporary CViewSetup class instatiation in the CViewRender::RenderView function, but this somehow changed the GPU view matrix even though I can't find the DirectX call. I've only found that the projection matrix is set upon the CViewSetup class sent into the IVRenderView->ViewSetup3D function, but this shouldn't be throwing off the rendering since the projection is only using the FOV and near and far clip distances (all of which should be the same for each stereoscopic eye anyway).If anybody could please help me understand how I can correct the culling and 2D element locations for stereoscopic, it would be immensely appreciated. _ Live Earth is coming. Learn more about the hottest summer event - only on MSN. http://liveearth.msn.com?source=msntaglineliveearthwlm -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Replay Disappearing Bug
Hey Yahn, I was curious if anybody over there had a chance to try the repro? Just wondering if there was any feedback. You guys are really busy, so it would be easy to slip through the cracks. From: "Yahn Bernier" <[EMAIL PROTECTED]> Reply-To: hlcoders@list.valvesoftware.com To: Subject: RE: [hlcoders] Replay Disappearing Bug Date: Thu, 8 Feb 2007 11:32:45 -0800 We'll have someone here try and repro this. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Meow Mew Sent: Thursday, February 08, 2007 11:25 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Replay Disappearing Bug Here's a video displaying how the bug works. I apologize for the poor quality, as YouTube managed to mangle the video quite a bit. The first time the console is typed in is the beginning of the demo recording. The second time is the ending of the demo recording. You can see that the Alyx model reappears when the demo is no longer recording. http://www.youtube.com/watch?v=d6WeCkEO8i4 Thanks goes out to previous answers, but none of the animation changes mentioned previously had any effect. I could really use some help in figuring this one out. A Find in Files involving anything to do with demo recording and playback doesn't bring any clear answer to focus. Any other suggestions or assistance is definitely appreciated. >From: "Meow Mew" <[EMAIL PROTECTED]> >Reply-To: hlcoders@list.valvesoftware.com >To: hlcoders@list.valvesoftware.com >Subject: [hlcoders] Replay Disappearing Bug >Date: Wed, 07 Feb 2007 15:58:12 -0500 > >I was hoping somebody could point me in the right direction for >resolving a bug I came across. I do work with a valid liscence of all >of the Valve engine, so please don't hesitate to point me in the right >direction if you happen to be a Valve employee (if you use generic >terms to avoid posting non-SDK code I would still appreciate it tremendously). > >During the recording of a replay (DEM file) in a single-player game, I >found that characters playing an animation can stop rendering >themselves after colliding with the player. An easy re-creation of >this is to make a high area to jump off of onto a characters head (try >not to at the character during collision). If an animation was setup >through VCD or scripted sequence, the model will cease to render for >that instance of the character. > The model will render again if that entire visibility set reloads >(walking behind an occluder also seems to work). > >This only happens while recording a DEM file, and also only happens if >the character is animated. The collision does NOT need to be with the >player (I've seen it happen when a character ran into a mailbox), but I >do believe the player has to not be looking directly at the character >when it vanishes. > Also, this is even EASIER to create if you set the solid type of the >character to SOLID_VPHYSICS instead of SOLID_BBOX. > >I really need to be able to record a run of the world with no obvious >flaws that would change the users experience. We're using the demo >playbacks to overlay eye-tracking information and change textures >during the playback for pixel detection of entities. The user would >most likely change his/her natural eye responses if objects vanish, and >this hurts the results of the research studies. Please help if you >can! > >_ >Laugh, share and connect with Windows Live Messenger >http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http: >//imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=h >mtagline > > >___ >To unsubscribe, edit your list preferences, or view the list archives, >please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > _ From predictions to trailers, check out the MSN Entertainment Guide to the Academy Awards(r) http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1 ___ 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 what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Replay Disappearing Bug
Many thanks Yahn! If it helps to reproduce it, I can give a few more details about how I commonly ran tests. Currently, our MOD does not have the npc_alyx in it, so that movie was using cycler_actor with the Alyx model assigned. The animation was done with a scripted sequence (start on spawn) of the "sexyidle" animation. I've gotten it to work with all of our custom models, classes, and animations, but just wanted to be sure I gave details on how I reproduced it with content that wasn't in-house. From: "Yahn Bernier" <[EMAIL PROTECTED]> Reply-To: hlcoders@list.valvesoftware.com To: Subject: RE: [hlcoders] Replay Disappearing Bug Date: Thu, 8 Feb 2007 11:32:45 -0800 We'll have someone here try and repro this. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Meow Mew Sent: Thursday, February 08, 2007 11:25 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Replay Disappearing Bug Here's a video displaying how the bug works. I apologize for the poor quality, as YouTube managed to mangle the video quite a bit. The first time the console is typed in is the beginning of the demo recording. The second time is the ending of the demo recording. You can see that the Alyx model reappears when the demo is no longer recording. http://www.youtube.com/watch?v=d6WeCkEO8i4 Thanks goes out to previous answers, but none of the animation changes mentioned previously had any effect. I could really use some help in figuring this one out. A Find in Files involving anything to do with demo recording and playback doesn't bring any clear answer to focus. Any other suggestions or assistance is definitely appreciated. >From: "Meow Mew" <[EMAIL PROTECTED]> >Reply-To: hlcoders@list.valvesoftware.com >To: hlcoders@list.valvesoftware.com >Subject: [hlcoders] Replay Disappearing Bug >Date: Wed, 07 Feb 2007 15:58:12 -0500 > >I was hoping somebody could point me in the right direction for >resolving a bug I came across. I do work with a valid liscence of all >of the Valve engine, so please don't hesitate to point me in the right >direction if you happen to be a Valve employee (if you use generic >terms to avoid posting non-SDK code I would still appreciate it tremendously). > >During the recording of a replay (DEM file) in a single-player game, I >found that characters playing an animation can stop rendering >themselves after colliding with the player. An easy re-creation of >this is to make a high area to jump off of onto a characters head (try >not to at the character during collision). If an animation was setup >through VCD or scripted sequence, the model will cease to render for >that instance of the character. > The model will render again if that entire visibility set reloads >(walking behind an occluder also seems to work). > >This only happens while recording a DEM file, and also only happens if >the character is animated. The collision does NOT need to be with the >player (I've seen it happen when a character ran into a mailbox), but I >do believe the player has to not be looking directly at the character >when it vanishes. > Also, this is even EASIER to create if you set the solid type of the >character to SOLID_VPHYSICS instead of SOLID_BBOX. > >I really need to be able to record a run of the world with no obvious >flaws that would change the users experience. We're using the demo >playbacks to overlay eye-tracking information and change textures >during the playback for pixel detection of entities. The user would >most likely change his/her natural eye responses if objects vanish, and >this hurts the results of the research studies. Please help if you >can! > >_ >Laugh, share and connect with Windows Live Messenger >http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http: >//imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=h >mtagline > > >___ >To unsubscribe, edit your list preferences, or view the list archives, >please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > _ From predictions to trailers, check out the MSN Entertainment Guide to the Academy Awards(r) http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1 ___ 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/l
RE: [hlcoders] Replay Disappearing Bug
Here's a video displaying how the bug works. I apologize for the poor quality, as YouTube managed to mangle the video quite a bit. The first time the console is typed in is the beginning of the demo recording. The second time is the ending of the demo recording. You can see that the Alyx model reappears when the demo is no longer recording. http://www.youtube.com/watch?v=d6WeCkEO8i4 Thanks goes out to previous answers, but none of the animation changes mentioned previously had any effect. I could really use some help in figuring this one out. A Find in Files involving anything to do with demo recording and playback doesn't bring any clear answer to focus. Any other suggestions or assistance is definitely appreciated. From: "Meow Mew" <[EMAIL PROTECTED]> Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Replay Disappearing Bug Date: Wed, 07 Feb 2007 15:58:12 -0500 I was hoping somebody could point me in the right direction for resolving a bug I came across. I do work with a valid liscence of all of the Valve engine, so please don't hesitate to point me in the right direction if you happen to be a Valve employee (if you use generic terms to avoid posting non-SDK code I would still appreciate it tremendously). During the recording of a replay (DEM file) in a single-player game, I found that characters playing an animation can stop rendering themselves after colliding with the player. An easy re-creation of this is to make a high area to jump off of onto a characters head (try not to at the character during collision). If an animation was setup through VCD or scripted sequence, the model will cease to render for that instance of the character. The model will render again if that entire visibility set reloads (walking behind an occluder also seems to work). This only happens while recording a DEM file, and also only happens if the character is animated. The collision does NOT need to be with the player (I've seen it happen when a character ran into a mailbox), but I do believe the player has to not be looking directly at the character when it vanishes. Also, this is even EASIER to create if you set the solid type of the character to SOLID_VPHYSICS instead of SOLID_BBOX. I really need to be able to record a run of the world with no obvious flaws that would change the users experience. We're using the demo playbacks to overlay eye-tracking information and change textures during the playback for pixel detection of entities. The user would most likely change his/her natural eye responses if objects vanish, and this hurts the results of the research studies. Please help if you can! _ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ From predictions to trailers, check out the MSN Entertainment Guide to the Academy Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Replay Disappearing Bug
I didn't notice that actually. Turns out that's not it, but thanks for the heads up regardless! From: "Nate Nichols" <[EMAIL PROTECTED]> Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Replay Disappearing Bug Date: Wed, 7 Feb 2007 15:44:00 -0600 Hi, I don't know if you noticed this before, but there is a possibly related bug w/ demo recording (with a fix) here: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Animations_are_jittery This may not fix your problem, but they may have a similar root cause. Good luck, Nate On 07/02/07, Meow Mew <[EMAIL PROTECTED]> wrote: I was hoping somebody could point me in the right direction for resolving a bug I came across. I do work with a valid liscence of all of the Valve engine, so please don't hesitate to point me in the right direction if you happen to be a Valve employee (if you use generic terms to avoid posting non-SDK code I would still appreciate it tremendously). During the recording of a replay (DEM file) in a single-player game, I found that characters playing an animation can stop rendering themselves after colliding with the player. An easy re-creation of this is to make a high area to jump off of onto a characters head (try not to at the character during collision). If an animation was setup through VCD or scripted sequence, the model will cease to render for that instance of the character. The model will render again if that entire visibility set reloads (walking behind an occluder also seems to work). This only happens while recording a DEM file, and also only happens if the character is animated. The collision does NOT need to be with the player (I've seen it happen when a character ran into a mailbox), but I do believe the player has to not be looking directly at the character when it vanishes. Also, this is even EASIER to create if you set the solid type of the character to SOLID_VPHYSICS instead of SOLID_BBOX. I really need to be able to record a run of the world with no obvious flaws that would change the users experience. We're using the demo playbacks to overlay eye-tracking information and change textures during the playback for pixel detection of entities. The user would most likely change his/her natural eye responses if objects vanish, and this hurts the results of the research studies. Please help if you can! _ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline ___ 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 _ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Replay Disappearing Bug
I was hoping somebody could point me in the right direction for resolving a bug I came across. I do work with a valid liscence of all of the Valve engine, so please don't hesitate to point me in the right direction if you happen to be a Valve employee (if you use generic terms to avoid posting non-SDK code I would still appreciate it tremendously). During the recording of a replay (DEM file) in a single-player game, I found that characters playing an animation can stop rendering themselves after colliding with the player. An easy re-creation of this is to make a high area to jump off of onto a characters head (try not to at the character during collision). If an animation was setup through VCD or scripted sequence, the model will cease to render for that instance of the character. The model will render again if that entire visibility set reloads (walking behind an occluder also seems to work). This only happens while recording a DEM file, and also only happens if the character is animated. The collision does NOT need to be with the player (I've seen it happen when a character ran into a mailbox), but I do believe the player has to not be looking directly at the character when it vanishes. Also, this is even EASIER to create if you set the solid type of the character to SOLID_VPHYSICS instead of SOLID_BBOX. I really need to be able to record a run of the world with no obvious flaws that would change the users experience. We're using the demo playbacks to overlay eye-tracking information and change textures during the playback for pixel detection of entities. The user would most likely change his/her natural eye responses if objects vanish, and this hurts the results of the research studies. Please help if you can! _ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Demo Playback
I was hoping somebody could point me in the right direction for resolving an issue we've been having. We need to record and playback demos, an ability easily used and implemented in Halflife 2. It seems when we try it in our own mod, the recording reports back as fine, but the playback of the demo won't function. The error comes with a listing of Valve textures we don't use as missing, and more importantly, the DT_AlyxEmpTool data table entry is mismatched on the server and client. This is highly irregular as we've removed Alyx and her Emp tool and that data table is not in our codebase. A listing of the demo information reports the following which I can't decipher as irregular or not: Network protocol: 7 Demo version: 2 Server name: localhost:0 How is a data table being imported that is not in our server or client libraries? Is it somehow using the hl2 DDLs which are in a completely different directory chain? We actually have the engine code liscenced and as of yet I see no problems, but it's a very big project. If it's somehow hidden to hardcoded HL2 libraries, I could easily change it if I could find out where or how. _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Bone Followers
There was a previous post on the $keyvalues command bone_followers before, but since I hadn't truly done tests or needed something that uses them, I never realized there are unresolved difficulties. This is all during the model compilation stage of the content pipeline. To at least explain, a bone follower is how you get the physics to follow an animation on an animated prop instead of prop_physics. You don't want gravity or other physics to move the thing around, but you do want the animation to accurate block the player or other physics. They are automatically implemented in doors as shadow controllers, but you need the key values in other props as a working interface. The problem I've been having is every time I add the key value, I get weird rotation/offsets on my physics. The vcollide_wireframe command in game seems to show what I'd expect out of my collision model, but model viewer and how the game actually pushes the player around show something different. However many times I test, what I see in model viewer is what the game physics does, regardless of the vcollide_wireframe saying otherwise. Here's how the rotation/offset of the model ends up looking in modelviewer: http://img350.imageshack.us/my.php?image=modelviewerdrawer7oq.png and here's how the vcollide_wireframe shows how I WANTED it to look in game, but it never actually works how this displays. This is how the collision model was made to look. http://img178.imageshack.us/my.php?image=gamedrawer8dw.png Ravendoor is a model in the props_lab that comes with Halflife2, and it uses the bone followers too. It turns out that it has the exact same weird rotation/offset happening to it's collision model except in reverse. Was there just a compensation for the strange angles and movement in their collision model? http://img350.imageshack.us/my.php?image=modelviewerravendoor0bx.png http://img350.imageshack.us/my.php?image=gameravendoor2ni.png If anybody can please help or clarify why the physics gets rotated when using this command and if there's a simple solution (that hopefully doesn't involve trying to re-orient all of our physics incorrectly so they match again after the offsets occur). Any suggestions or advice or welcome and many thanks before-hand to any support available. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Client - Server Ragdoll Control
As previous E-mails have shown, I'm having lots of difficulty working with a data glove hardware driven model. The goal is to have the data glove completely move an articulated arm model, colliding with other entities, and constrained realistically (so finger bones don't break too often). I have created both a server, and a client ragdoll with proper constraints to start with. Initial tests of implementing a shadow controller also seem in order (although I won't know for sure until I'm passing in my expected bone orientations from the hardware). The shadow controller is acting as expected and seemingly using the ragdoll constraints as long as I update my shadows before the ragdoll. The problem I came across is that it seems in single player games, only the server will do proper collisions with a ragdoll. My hardware is tied into the client, and also the view model is only ever fully accurate to screen on the client as well (so that I can have the arm follow the player). The dilemma is that I can have a client ragdoll but with no collisions, or I can have a server ragdoll with my data on the wrong DLL. Either problem being solved would work wonderfully, so I would be ecstatic if I could get a hand. So far, Jay Stelly has been remarkably useful in pointing me in the right direction with the shadow controllers and ragdoll (all of which I believe I have the neccessary understanding of now). So it comes down to two simple questions. How can I allow collisions of ragdoll to other props on the client? Alternatively, how can I send my data from the client to the server? There seems to be a ton of ways to send information from server to client, but vice versa gets tricky. I know I can try to send it through console commands, but with how much data I need to send, the console will become cluttered and rendered utterly useless for other testing. The only alternative I can see right now is changing the CUserCmd to include my data, but I'm really not positive on that idea. If anybody can help, I'll be very appreciative. When this is finished (as it is getting rather close), I'll be putting screens on the developer forums and code snippets upon request (although you can get code snippets now if you want). _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Simulated Animations
Thanks for the suggestions. It seems that there are a few things needing clarification however, and I'm glad to answer you question and offer more insight as to how my difficulty is set up. Firstly, this is a singleplayer mod (well, not a mod as we have liscencing, but close enough). When I'm moving parts of the hand, I'm going to be using ragdoll and pushing bones with forces. This should avoid the traces altogether. The collision problem I'm having is just simply setting the unanimated model to follow my player. It's like if I were to attach a solid metal rod to my player and walk around. I'd expect it to knock things (prop_physics) over. It does not however, and I'm not entirely sure why. My first guess is that it's because I'm having to set the position to follow the player, and setting the position is forcing a collision in a way the physics doesn't understand. I'm not entirely sure how to fix this at all. As for the viewmodel, I stated before that I have already researched the viewmodel and am attempting to render my model in the exact same way as is. The biggest difference is that the viewmodel has a client and a server implementation, and my ragdoll does not. Also, I could not over-ride the CalcViewModelView function in my player because it is not a virtual function and is called from base class pointers in view.cpp and hltvcamera.cpp. It is also called from ItemPostFrame, but this function is virtual and overridden in my player class. The other two functions call CalcView directly before CalcViewModelView, so I overrode that function as well. After all this is done, the following stutters, and I have no idea why. It follow correctly in a sense, just not smoothly. I'm not sure if I need to network my ragdoll, and if I do, why. On 2/13/06, Aaron Schiff <[EMAIL PROTECTED]> wrote: Is this a multiplayer mod? When moving a part of the hand, you'll want to do traces, and see if that action is actually possible ...if you want all movement to be possible, you should research how the viewmodel is rendered and render it that way (closer on the z axis) _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Simulated Animations
This is a continuation of my problems involve with getting a data glove controlling a ragdoll simulated hand model. To catch up, I've been following advice from Jay Stelly so far, and have no problems thus far with any of his solutions to controlling bones. The recurring problems seem to be with spawning and creating a working model however. Okay, here's the problem. I need a model to follow the player as his arm/hand, and I need to manually edit it's bone data via ragdoll. Here's my process I went through and the problems I'm now faced with. Sounds generally simple enough, until I realized that the player model rotates in a way unlike what you see. The view model class is setup to follow the player's eye positions and angles much more accurately (as opposed to the GetAbsAngles), and it takes in weapon models to set as it's own whenever you switch weapons. So you never really switch weapons entities, you just play a Holster animation then swap models on the same entity. So in order to follow the player, I thought to try to make the entity a weapon. I then realized I cannot control animations. The view model is an obnoxious entity that over-rides the playing of sequences from anything derived from BaseCombatWeapon. So I made my own entity to get started on some trial and error. I created an client-side only entity that derived from C_ClientRagdoll. I initiated and spawned it through my player's spawn. So I took my own entity and tried to follow the example of the view model to follow the player's position. Annoyingly, the CalcViewModelView function on the player is not virtual and the base player has the classname for the view model in it's header, so my personal player class has no control over that function (without editing base player, and I'm trying to avoid for Valve updates). In the end, I could make my own CalcView and ItemPostFrame functions to send my new entity the current status of the view model. When the game runs however, the position of my model stutters and does indeed follow the player, but in a jumpy fashion. I was wondering if I had to do something server-side, but I have no idea what. First problem is, how do you get something that is not a weapon to follow the player accurately without having stutter? The other problem I'm having is collision. I expected collision to just follow the model around appropriately. It turns out that when I bump things with my hand, which does indeed have tested collision models, nothing happens. The hand model just goes through objects. Is this because I'm updating the position of my model to follow the player? Is it instead because it is inside the player's bounding box and decides to no longer trace collision? How can I get my model to collide and push things down when I bump them? The movetype, movecollide, and collision groups have been played with a bit, but I'm not sure what combination will do what. It seems no matter what I try, when the arm is following my player around, nothing can collide with it. Code is available upon request if anybody understands or wishes better comprehension of the problem. Please give me a hand, there's a deadline coming that is going to kill me. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Simulated Animations
As I understand your question, you just want a bunch of bone orientations to come from your code rather than a pre-defined animation. That is exactly what the ragdoll code does, but the bulk of the code for ragdolls is about doing the simulation; none of that is likely to be useful for this purpose. In reality, you should just look at how ragdolls override the animation data in one function: C_BaseAnimating::BuildTransformations() this calls m_pRagdoll->RagdollBone() in the case of ragdolls. If you hook this code in the same way, you can simply do a: matrix3x4_t &xform = pBoneToWorld->GetBoneForWrite( boneIndex ); and then put whatever transform you like into xform then set boneSimulated[boneIndex] = true; // keeps the animation code from overwriting your changes for each bone that you want to replace. That's it. Jay So you're suggesting to simply replace the RagdollBone() call with my own data transformations? Well, in theory that's simple enough. I have a few questions regarding that though. Okay, a lot of questions, but I'd rather get them all out now and save a lot of back and forth. When you are editing the matrix given back from GetBoneToWrite( boneIndex ), what is the scope of this matrix? Is it in local space covering only it's position and orientation from it's parent bone, or is it global space after concatenating all parents? Basically, what does this matrix use for it's origin? So if I need an arm and hand, with good natural physics/collisions with the world around them, that I can re-orient the bones with, is just changing the orientations as described above enough? I'm trying to read as much of the code as possible so I don't have any surprises. The physics system is something I haven't tackled yet, and time doesn't permit much with a bad deadline. I was looking through all the ragdoll code, and I was wondering since I need collision to occur in my model of the hand if I needed any other ragdoll code? The model will be built and loaded with it's own collision data, but I'm not sure how well collision data will update if I manually move bone orientations around. I was searching and I couldn't even find how the physics told the ragdolls how to move in the first place. Is it updated via the physics.dll behind the scenes completely? Where did the ragdoll objects get piped to another library if this is true. Does using CreatePolyObject() create an object that updates it's data from the other DLL? Summarizing, where the ragdolls get their actual data or do the calculations to determine the data to move the model accurately is beyond me at this point. I may even be going the wrong way with this. Somebody else suggested I try using Bone Followers, but the Bone Follower update doesn't appear to do anything but update a shadow. In fact, the Bone Follower code doesn't appear to do much at all. Also, related question but not of major importance as of yet. If I wanted to pick things up with this modeled hand, would the physics system be good enough? Give friction and mass to all the fingers, then surround an object with the fingers, and lifting; would that actually pick the object up, or would it need to be done some other way? Thanks for everybody's input, and especially to Jay right now for getting me started. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Simulated Animations
I normally wouldn't be asking on the mailing list as I like to resolve my own issues. This problem however, is a doozy. We need to make an interface for a force feedback data glove. The hardware reading is all in place, and I've already completed piping in the new hardware into the client.dll. The difficulty arises in how to control a model of a hand and arm to accurately follow my data. Let me explain. We have created a model that has all the neccesary bones to match up to the data glove. When I move the data gloves sensors for a thumb movement, I need to copy over the orientation into the model we're using in order to let the visual model have the exact same thumb movement. A virtual reality simulated hand is the concept. Now, it's the tying in to the model data that I'm a bit wary of. I know I could make it an animated prop, or derived thereof, but how can I force the bones to orient? I'm attempting to look at the ragdoll code, as a controlled form of ragdoll not using physics almost seems like what I want, but I'm very unfamiliar with the ragdoll structures and data members. This particular part of the Valve code seems less commented and readable than others. So does anybody have much familiarity with the ragdoll code, or dynamically controlling bones in any fashion? I'd very much appreciate any help or suggestions. Thanks _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Particle Attachment Updating
The problem seems to be slightly misunderstood. My problem is not related to particles themselves not updating when I'm not in a line of sight. It's the Emmitter that won't update it's position. Particles are still spewing out of the emmitter just fine, with all the values I expect. The emmitter itself should be moving however. It is derived from BaseEntity in a roundabout way, and should use it's moveparent and parent attachments to change it's position. I'm not great at text art, but I'll give it a go to explain. Here are the particles emmitting from a hand attachment. I parent the particles to the hand and set the parent attachment so that the emmitter immediately goes to that location. This is what I want from the begginning. '' ' ' ' ' ' | | | | | | | |- | | | | | Now I animate the hand. It moves right. The hand moves, but the particle emmitter does not '' ' ' ' ' ' | | | | | | | |- | | | | | I don't understand this behavior. A parented and attached entity should always update to the move parent. What I WANT would be this. '' ' ' ' ' ' | | | | | | | |- | | | | | If I leave the vis leaf, and come back, the particles go to that location as to where the hand is in the animation. However, it continues to not FOLLOW the hand as it continues to animate. So if it goes even further to the right, or back to the left, once again the emmitter isn't in the right location to emit particles from. All tests are still being done with env_smokestack being parented to the anim_attachment_LH attachment of Breen. It has not worked with the env_fire either, both of which I desperately need. Tony \"omega\" Sergi wrote: There's a comment in the code somewhere about how for performance, particles aren't updated when they're not in view of the player. Look at the sparks for example, fire off the crossbow and as soon as it hits, turn away really quickly, pause for a couple seconds, then turn back around and you'll see the sparks finish their animation and dissipate. Tim Holt wrote: Just thinking out loud w/o looking at code... I bet there's some way to modify the env_smokestack code a bit to make them persistent and update on say, range to the viewer instead of just having a direct line of sight. Maybe clone the smokestack code to create a new entity, and give it a new "checkbox" type attribute that says update even when not in view? I wonder if the code for the fire does the same thing? I'm trying to remember if I have seen fires sort of "spring up" every time I look at them or not. _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Particle Attachment Updating
Jorge "Vino" Rodriguez wrote: Sounds like you're doing your particles server side. I'm not as experienced with HL2 as opposed to HL1, but if a particle ceases to update when you leave PVS, this tells me that the thinking is being done on the server, and not updating the client when he moves out of PVS. If I'm correct, then I recommend you move the code to the client, where any good particle system belongs. That's an interesting point about how the think functions work. The part that makes this bazaar is that I didn't even make this particle system or edit it in any way. The example I'm using is Valve's env_smokestack entity, so I truly hope the people at Valve aren't making their particles serverside. There is a client-side entity as it is however, so even though I'm in the process of double checking this, I'm doubting this is the problem. Thanks for the input, hopefully I can still find out why this is happening. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Particle Attachment Updating
I'm having, and have been having, a terrible time trying to attach (InputSetParentAttachment through Hammer usually) the SmokeStack particle effect to a custom model. Here's what I'm looking to achieve: We have smoking characters who MUST have smoke coming from their cigarette or mouth when they exhale. This is a requirement basically for grant money for the most part, so there are no sidesteps to this visualization. We've opted to have the exhale from the mouth only for now. Baby steps. Also, we're going to need fire on a lighter, which is having the same problem... but, baby steps. All my below examples are referring to using the SmokeStack entity on a custom model for the most part. The problem: When you attach a particle effect to an attachment point on the model (after parenting of course), it WILL NOT UPDATE it's position after the initial move. Yes, particles are emmitting. Yes, they went to the attachment location. However, when the model animates or moves, the particle effect continues to emit only at the location the attachment point was when first attached. The emmitter doesn't follow or update it's position as the attachment point moves around. Particles just simply continue to emit from the same spot even though it should move. Quirks: 1) This problem does NOT occur in debug mode, only release mode. In debug mode, everything is fine. This makes it incredibly difficult to accurately trace. Also, I can't find any #ifdef __DEBUG or anything of the sort that would make the slightest difference. 2) This problem has happened on HL2 models such as Breen or Alyx. When these characters are moved around in Hammer for their spawn location, sometimes the problem goes away unexplicably. I have not yet had the problem go away on custom models. 3) Turning on wireframe mode and walking around bends and corners can bring you to a different visleaf where the particles stop rendering. When you return to the visleaf which renders the particles, the position of the emmitter DOES update to the location of the attachment at that time. It does not continue to update in any fashion however afterwards, but just stays at the location it was in when you returned to that visleaf. Plea: Please somebody give me a hand with this. I've tried as much as I can think of, but the attachment follow code just simply goes back to BaseEntity, which is where it works for everything else that isn't a particle. I've already looked at the grenades that emit smoke and have the smoke follow the grenades around, but the code seems completely identical to the smokestack, or at least I'm not seeing something of key importance. Suggestions are welcome. I'll respond with how following that suggestion has worked (even if I've already done it) to keep people well informed. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Problems with custom gamerules and player
I'm still relatively new with the source engine, but I hit a dead end that I ran out of ideas on where to look. I'm trying to have full custom files with no half-life content at all anymore. Our company liscenced the engine for our own purposes, and we have no monsters, headcrabs, or weaponry. It's not even really a FPS. So we finally decided to dig in and throw all this unneccesary code out of our projects. We were trying to learn by using a HL2 Singleplayer Mod to get familiar with it all. I went through and removed all the files in the HL2 folders in both the client and server projects, and replaced all files and classes that were required to be created with my own. Here's the list of files I had to replace content in: Client: c_basehlplayer.h & c_basehlplayer.cpp c_hl2_playerlocaldata.h & c_hl2_playerlocaldata.cpp hl2_clientmode.cpp clientmode_hlnormal.h & clientmode_hlnormal.cpp hl_prediction.cpp hl_in_main.cpp vgui_rootpanel_hl2.cpp Server: script_intro.h & script_intro.cpp hl2_client.cpp hl2_eventlog.cpp hl_movedata.h hl2_player.h & hl2_player.cpp hl2_player_shared.h hl2_playerlocaldata.h & hl2_playerlocaldata.cpp hl_playermove.cpp Both: hl_gamemovement.cpp hl2_gamerules.h & hl2_gamerules.cpp hl2_usermessages.cpp At first I was getting an error message from the engine that reads: "OnGameRulesCreationStringChanged: missing gamerules class 'CVR2' on the client" CVR2 is the name of my gamerules object, similar to the Half-Life 2 one. I'm not sure which part of this process I forgot to do, but it shuts down the game immediately with no gamerules object created. After realizing my code wasn't updating the DLLs because of source control, I re-built my projects and got a different problem. When I run, I immediately get disconnected with these messages: No matching RecvTable for SendTable 'DT_VR2_Player'. No matching RecvTable for SendTable 'DT_VR2Proxy'. Missing RecvProp for DT_BasePlayer - DT_LocalPlayerExclusive/m_bFalling The falling variable I added long ago in BasePlayer, and it was working fine for so long. As for the other two, I have what appear to be matching tables in the client and server projects. Here's what they look like Player Client: IMPLEMENT_CLIENTCLASS_DT(C_VR2_Player, DT_VR2_Player, CVR2_Player) RecvPropDataTable( RECVINFO_DT(m_VR2Local),0, &REFERENCE_RECV_TABLE(DT_VR2Local) ), RecvPropBool( RECVINFO( m_fIsSprinting ) ), END_RECV_TABLE() Server: IMPLEMENT_SERVERCLASS_ST(CVR2_Player, DT_VR2_Player) SendPropDataTable(SENDINFO_DT(m_VR2Local), &REFERENCE_SEND_TABLE(DT_VR2Local), SendProxy_SendLocalDataTable), SendPropBool( SENDINFO(m_fIsSprinting) ), END_SEND_TABLE() Proxy Client: BEGIN_RECV_TABLE( CVR2Proxy, DT_VR2Proxy ) RecvPropDataTable( "vr2_gamerules_data", 0, 0, &REFERENCE_RECV_TABLE( DT_VR2GameRules ), RecvProxy_VR2GameRules ) END_RECV_TABLE() Server: BEGIN_SEND_TABLE( CVR2Proxy, DT_VR2Proxy ) SendPropDataTable( "vr2_gamerules_data", 0, &REFERENCE_SEND_TABLE( DT_VR2GameRules ), SendProxy_VR2GameRules ) END_SEND_TABLE() It seems to be convinced I don't have the recieve tables on the client-side, but they're obviously there and they seem to match my server tables as well. I have to be misunderstanding something important in this whole process. I just have no way of knowing where to look. I'm willing to send source code to anybody who would take a quick look. Thanks for any help. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
