Re: [hlcoders] Open Source Mods (again)
Yeah, like the ZHLT tools - you can download the source code mess around with it, and then submit any changes to the person that maintains the tools - look at http://www.zhlt.info to see how many programmers have in fact worked on the tools. Adam --- Nate Nichols <[EMAIL PROTECTED]> wrote: > I don't know it for a fact, but my guess is that > these mods are > open-source in the sense that the smallish group of > modders would show > you the code they wrote if you asked, or they would > post small > interesting bits as tutorials or examples. It's not > open-source in > the sense that it's a large community of coders > submitting diffs and > bugfixes back into a large central repository. > That's my hunch > anyway. > > Nate > > On 13/01/07, Nikolaos Tzimoulis > <[EMAIL PROTECTED]> wrote: > > Err... sorry to be bothering you again with this > matter. > > > > I've been doing a bit researching about the open > source mods you > > mentioned. I could find their releases and their > source code but I > > couldn't understand how they did their open-source > development. I > > didn't find them registered to any sites like > sourceforge.net and I > > didn't find any other means by which one can > submit code to the > > project. Am I missing something here? > > > > Also, it seems that they're using the whole > altered SDK rather than > > just diff files. I guess that's all right, then? > > > > > > Nicholas > > > > > > > This message was sent using IMP, the Internet > Messaging Program. > > > > > > > > ___ > > 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 > > Nigredo Studios http://www.nigredostudios.com We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
On Saturday 13 January 2007 3:36 am, Justin Krenz wrote: > You want vphysics collisions because they're more accurate than OBBs. > You can't predict a vphysics collision because you rely on the vphysics > simulation code which will only tell you of a collision once it's > actually occuring. Is that correct? > > If that is correct, then I suggest you use the OBB trace or an AABB > tracehull to detect if the ship is going to hit something as suggested > already. Now, if it is going to hit an object, then you can perform a > more accurate vphysics collidable trace on it to ensure that it does hit > the more accurate vphysics collision model of the ship. Look in > triggers.cpp line 1716 for an example of how to do this. This would > require you do the same on the client and server and handle everything > about the collision on your own. Roll-your-own broadphase and collide. The broadphase won't be able to handle more than a single ent colliding with the BBox, given that traces only return the single ent hit. (Well, with an iterative procedure and custom tracefilter that iteratively adds each intersecting ent, maybe). I'm also not going to be able to simulate the angles on each collision, as I don't have the worldposition of the intersect point, so I can't apply the correct collision torque. Short of VALVe feeling nice, this might be the only solution though. Unless... (off-list for my insane idea.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Open Source Mods (again)
I don't know it for a fact, but my guess is that these mods are open-source in the sense that the smallish group of modders would show you the code they wrote if you asked, or they would post small interesting bits as tutorials or examples. It's not open-source in the sense that it's a large community of coders submitting diffs and bugfixes back into a large central repository. That's my hunch anyway. Nate On 13/01/07, Nikolaos Tzimoulis <[EMAIL PROTECTED]> wrote: Err... sorry to be bothering you again with this matter. I've been doing a bit researching about the open source mods you mentioned. I could find their releases and their source code but I couldn't understand how they did their open-source development. I didn't find them registered to any sites like sourceforge.net and I didn't find any other means by which one can submit code to the project. Am I missing something here? Also, it seems that they're using the whole altered SDK rather than just diff files. I guess that's all right, then? Nicholas This message was sent using IMP, the Internet Messaging Program. ___ 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] Open Source Mods (again)
Err... sorry to be bothering you again with this matter. I've been doing a bit researching about the open source mods you mentioned. I could find their releases and their source code but I couldn't understand how they did their open-source development. I didn't find them registered to any sites like sourceforge.net and I didn't find any other means by which one can submit code to the project. Am I missing something here? Also, it seems that they're using the whole altered SDK rather than just diff files. I guess that's all right, then? Nicholas This message was sent using IMP, the Internet Messaging Program. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] That sure is helpful Justin. I think we may be able to hack together something with that. I remember finding an algorithm to compute an AABB from an arbitrary collide that we could trace the hull of to do a broadphase collision. Then we could do it accurately with TestEntityTriggerIntersection_Accurate. I'm not quite sure how performance would be affected, but it could work. We are also working on a split collision routine which uses two physics objects (with one "tied to" the other) with mutually exclusive collision groups. This would allow players to collide with a 12 or 13 convex model (since these ships can be pretty big) and the world and other ships could collide with a single convex model. It makes the broadphase stage a bit slower, because it is testing double the objects, but it should provide a speed up, especially in tight spots like the hangar. I'm gonna give John a call and see what we can work out with this. We'll keep this discussion open because Multiplayer vehicles of this sort are a big topic. Thanks Justin. On 1/13/07, Justin Krenz <[EMAIL PROTECTED]> wrote: > > Ok, so let me see if I understand you: > > You want vphysics collisions because they're more accurate than OBBs. > You can't predict a vphysics collision because you rely on the vphysics > simulation code which will only tell you of a collision once it's > actually occuring. Is that correct? > > If that is correct, then I suggest you use the OBB trace or an AABB > tracehull to detect if the ship is going to hit something as suggested > already. Now, if it is going to hit an object, then you can perform a > more accurate vphysics collidable trace on it to ensure that it does hit > the more accurate vphysics collision model of the ship. Look in > triggers.cpp line 1716 for an example of how to do this. This would > require you do the same on the client and server and handle everything > about the collision on your own. > > > John Sheu wrote: > > On Friday 12 January 2007 3:34 pm, Justin Krenz wrote: > >> Does "SweepCollideable(...)" not support OBB? I know const.h says > >> SOLID_OBB is not implemented, but from what little I played with it, > >> SweepCollideable seemed to correctly orient the entity's bounding box > >> before doing the trace. > > > > Not sure, but I'm not a fan of BBox collisions. We have this fancy > VPhysics > > doohickey, and so I'd rather get some more accurate collisions out of > it. > > > >> As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject > >> *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the > space > >> ship entity to alert you that a collision is taking place and then > >> override the response (return false, halt its velocity, and create > >> opposing reaction force) to make things "less crazy?" > > > > I have something similar going on in the codebase as it stands, with an > > added "VPhysicsPreCollision" call in the physics code that does some > velocity > > fixups before collisions. Trying to fix it there I think is trying to > fix > > the wrong problem though. > > > > Essentially, when you collide, the player is expecting to be banged > around a > > bit. Going crazy on collision is not very distracting. The problem is > that > > since we cannot predict collisions, I have to switch prediction off on > the > > client whenever we come into physics contact, and only switch it on when > we > > come out. There's a jolt as prediction switches off, another as it > switches > > on, and what's in between is rather laggy. If you want a true smooth > > experience, you're going to have to predict all the time, and that > requires > > more than we currently have in VPhysics. > > > > IIRC turbophysics does well for player interactions against > VPhysics. It does > > little for player interactions against CWorld. Unfortunately, the > latter is > > where most of our interactions lie. > > > > -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] Multiplayer Vehicles
Ok, so let me see if I understand you: You want vphysics collisions because they're more accurate than OBBs. You can't predict a vphysics collision because you rely on the vphysics simulation code which will only tell you of a collision once it's actually occuring. Is that correct? If that is correct, then I suggest you use the OBB trace or an AABB tracehull to detect if the ship is going to hit something as suggested already. Now, if it is going to hit an object, then you can perform a more accurate vphysics collidable trace on it to ensure that it does hit the more accurate vphysics collision model of the ship. Look in triggers.cpp line 1716 for an example of how to do this. This would require you do the same on the client and server and handle everything about the collision on your own. John Sheu wrote: On Friday 12 January 2007 3:34 pm, Justin Krenz wrote: Does "SweepCollideable(...)" not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. Not sure, but I'm not a fan of BBox collisions. We have this fancy VPhysics doohickey, and so I'd rather get some more accurate collisions out of it. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things "less crazy?" I have something similar going on in the codebase as it stands, with an added "VPhysicsPreCollision" call in the physics code that does some velocity fixups before collisions. Trying to fix it there I think is trying to fix the wrong problem though. Essentially, when you collide, the player is expecting to be banged around a bit. Going crazy on collision is not very distracting. The problem is that since we cannot predict collisions, I have to switch prediction off on the client whenever we come into physics contact, and only switch it on when we come out. There's a jolt as prediction switches off, another as it switches on, and what's in between is rather laggy. If you want a true smooth experience, you're going to have to predict all the time, and that requires more than we currently have in VPhysics. IIRC turbophysics does well for player interactions against VPhysics. It does little for player interactions against CWorld. Unfortunately, the latter is where most of our interactions lie. -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
Re: [hlcoders] gpGlobals NULL pointer crash on load
looks like im not the only person getting this: http://www.chatbear.com/unity2/4991/875,1166952565,869/1021531?v=flatold On 1/9/07, Mike Durand <[EMAIL PROTECTED]> wrote: I am able to duplicate this so I'll find the problem and let you know what's going on. Sorry about that. -Mike Durand Valve ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
