--
[ Picked text/plain from multipart/alternative ]
Yeah, I predicted the network load, hence why I had that flag to make sure
to only deploy the dynamic light once. If I deploy the light clientside, do
I need to worry about other players not seeing the dynamic light? Or does
the effects-CL_AllocDlight handle this?
Thanks a lot for your help, I appreciate it.
On 7/26/07, Garry Newman <[EMAIL PROTECTED]> wrote:
>
> Oh I see, I thought you were doing it clientside. I do it like this
> clientside:
>
> dlight_t *dl = effects->CL_AllocDlight( 0 );
> VectorCopy (m_vecOrigin, dl->origin);
> dl->decay = 200;
> dl->radius = 255;
> dl->color.r = 255;
> dl->color.g = 220;
> dl->color.b = 128;
> dl->die = gpGlobals->curtime + 0.1f;
>
> If the index passed to CL_AllocDlight is 0 it creates a light if it
> can. If it's > 0 then it replaces the last light you created that was
> using that index (if there is one).
>
> Since you can't actually attach these to entities the done thing seems
> to be to set the key to the index of your entity and update it every
> think.
>
> I looked into the te->DynamicLight code, and it seems to be calling
> the code in c_te_dynamiclight.cpp. It's always using the key
> LIGHT_INDEX_TE_DYNAMIC, which I've never used and have no idea about.
>
> Ok all that probably doesn't help at all. So:
>
> Calling te->DynamicLight serverside in the think seems pretty stupid.
> It's going to be networking a load of crap every 0.1 seconds.
>
> What I think you really want to do is add a clientside version of your
> entity and do the effects->CL_AllocDlight in Simulate or Think.
>
> There's a perfect example of this in dynamiclight.cpp and
> c_dynamiclight.cpp.
>
> phew
>
>
> garry
>
> On 7/26/07, Richard Hough <[EMAIL PROTECTED]> wrote:
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Sure thing. The following code is inside of the think function for the
> > flare.
> >
> > if(GetAbsVelocity() == Vector(0,0,0) && m_bFlareDeployed == false){
> > CBroadcastRecipientFilter filter;
> >
> > te->DynamicLight( filter, 0.0,
> > (&this->GetAbsOrigin()), 255, 30, 20,
> random->RandomFloat(2,4),
> > 400.0, 20, 4.0 );
> > m_bFlareDeployed = true;
> > }
> >
> > This boils down to a 400 unit red flare with no delay centered at the
> origin
> > of the flare model. The intensity is randomly generated within a range
> to
> > add some variety, and the flare should last for 20 seconds with a 4
> second
> > fadeout.
> >
> > Thanks for your help.
> >
> > On 7/26/07, Garry Newman <[EMAIL PROTECTED]> wrote:
> > >
> > > How are you making the lights? Can you paste the code?
> > >
> > > On 7/26/07, Richard Hough <[EMAIL PROTECTED]> wrote:
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Browsing through the code this sounds like a reasonable answer, but
> > > > unfortunately I'm not sure of how to answer your question of what ID
> I
> > > am
> > > > using. For the TE system you don't pass in any sort of ID when you
> > > create a
> > > > dynamic light, nor do I see an obvious place within the object
> hierarchy
> > > to
> > > > go about modifying this ID even if I wanted to. As far as I can
> tell
> > > > there's not even an entindex in the basetempentity hierarchy - at
> least,
> > > > there's no obvious way to retrieve it like in normal entities.
> > > >
> > > > Is there another system that I should perhaps be using instead of
> > > tempent?
> > > > Or am I just not understanding a simple principle of the system?
> > > >
> > > > On 7/26/07, Garry Newman <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > What ID are you using to spawn the dynamic lights? Networked
> entities
> > > > > usually use the entindex.. I'm not sure what the tempents are
> > > > > reporting as their entindex but it sounds like they're reporting
> the
> > > > > same thing so each tempent is editing the same light..
> > > > >
> > > > >
> > > > > garry
> > > > >
> > > > >
> > > > > On 7/26/07, Richard Hough <[EMAIL PROTECTED]> wrote:
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > I have a quick question for the list. I'm currently trying to
> > > create a
> > > > > > flare that begins emitting light for twenty seconds after coming
> to
> > > > > rest.
> > > > > > I've been successful in creating the flare, firing it, and
> turning
> > > on
> > > > > the
> > > > > > first light, having borrowed much of the code from
> > > weapon_flaregun.cpp.
> > > > > > However, I'm running into a problem when multiple flares are
> fired.
> > > > > >
> > > > > > Currently triggering of the light is handled by the think
> function
> > > in
> > > > > the
> > > > > > flare. When the flare has ceased to move, it spawns a temporary
> > > dynamic
> > > > > > light entity with an empty recipient filter (I've not found much
> > > > > > documentation on the filter, so I'll need to play with this to
> > > figure
> > > > > out if
> > > > > > it should be empty or not). This works perfectly when one flare
> is
> > > > > fired,
> > > > > > however as soon as the second flare is fired the first dynamic
> light
> > > > > source
> > > > > > dissapears. The model for the flare remains and the other
> portion
> > > of
> > > > > the
> > > > > > thinkfunc that spits out sparks continues to work, but it seems
> as
> > > if I
> > > > > > can't have two light sources spawned by the te->dynamiclight at
> the
> > > same
> > > > > > time. Any thoughts here? Am I using the right system for what
> I
> > > want,
> > > > > or
> > > > > > should I be looking elsewhere?
> > > > > >
> > > > > > Furthermore, if someone has some advice on how to create a
> dynamic
> > > light
> > > > > > source that's capable of movement so I needn't wait for the
> flare to
> > > > > stop
> > > > > > moving, that would be appreciated.
> > > > > > --
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
>
>
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
