-- [ Picked text/plain from multipart/alternative ] Hi Richard, Code the beam as part of the weapon, the player class tends to get big enough doing its own stuff so adding weapon-specific code there should be a last resort.
You'll find sometimes that the player originating the beam is outside the PVS of the player who's supposed to see the beam. Therefore make sure you transmit the player originating the beam to all players who are in the PVS of the beam's endpoint in addition to any other PVS rules (see ShouldTransmit.) Lining up the beam is a hassle. Trying to make it look like the beam is parallel to the muzzle of the gun and maintaining the accurate endpoint could be nearly impossible. You have to consider the SDK's player animation blending, which doesn't orient the player's upper body 100% correct (see sv_showanimstate/cl_showanimstate). A quick workaround is to use FBEAM_SHADEIN to hide that the beam isn't perfect. Regards, Paul On 10/17/07, Richard Hough <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > All, > > I'm looking for some advice on how to best structure my code and was > hoping > that someone could provide some feedback. > > Concept: > Our team is interested in creating a laser beam sight for one of our > weapons. This effect would be an actual beam starting at the muzzle of > the > gun and then intersecting with the world geometry, similar to the sniper > sight from Half-Life 2. When a player on a team activates the laser sight > it would be visible to himself and conditionally visible to the other > players in the game according to their team affiliation. > > Implementation: > The current thought is to implement the beam itself using the C_Beam > construct. To reduce server load the beams should probably be created as > a > client-side effect only, with a bitflag being transmitted between the > server > and all clients to indicate when a player is activating this effect. As > all > clients have the eye-vector information of other clients on the server, > this > information should allow us to create the effect appropriately. > > Question: > A few questions exist about how to properly organize our code for this > system. Firstly, we were looking for some advice as to where to place the > actual code for the system. Since this is a weapon-specific effect, the > first impulse we had was to place the code within the appropriate weapon; > however, a fair argument persists that this should be resident in the > SDKPlayer since (we think) placing it there will make it easier to handle > displaying the beam from other players in the server aside from the > client. > In addition to that we have some concerns regarding how this will look > when > it's finally implemented - do we have the granularity of information we > need > on the client from other players to properly adjust the beam's orientation > at appropriate speeds? There's also the possibility that a better > implementation of what we're going for exists that we don't have the > experience to know about yet as well. > > Any advice that any of you can give would be helpful. While we could just > sludge through the code ourselves and hack something in, learning how to > write efficient code in this SDK is of high value to us and for that we > thought your insight might be helpful. :) > > -Richard "Brackhar" Hough > -- > > _______________________________________________ > 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
