Think of it like creating particles. You're updating the light
constantly - so it doesn't matter if the player isn't there when it's
first created.
To make clear, your entity will be shared.. but the actual light is
created on the clientside version of the entity. The serverside of the
entity just controls its variables.
garry
On 7/26/07, Richard Hough <[EMAIL PROTECTED]> wrote:
--
[ 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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
