The point is more that casting every entity that passes through the  
trigger to the player isn't smart coding, but in this case, the only  
ent passing through the trigger will probably be players.

Skidz (Ryan)

On 29-Apr-09, at 11:10, "Jonas 'Sortie' Termansen" <hlcod...@maxsi.dk>  
wrote:

> Well, he has to cast to a player point anyways, although I agree,
> CBaseEntiy:IsPlayer() followed by a static_cast<>() should be much  
> faster
> than a dynamic_cast<>()
>
> ----- Original Message -----
> From: "Olly" <oli...@gmail.com>
> To: "Discussion of Half-Life Programming" <hlcoders@list.valvesoftware.com 
> >
> Sent: Wednesday, April 29, 2009 12:07 PM
> Subject: Re: [hlcoders] Checkpoints Triggers
>
>
>> Just FYI there is: CBaseEntity::IsPlayer()
>>
>> 2009/4/29 Jonas 'Sortie' Termansen <hlcod...@maxsi.dk>
>>
>>> I'd make a variable in the player class called int_Rounds (or  
>>> something
>>> clever) and then make a custom trigger, that could be called
>>> Trigger_Checkpoint. Then make a variable in the Trigger_Checkpoint  
>>> called
>>> int_RoundOfThisTrigger (that can be edited through hammer,  
>>> see .fgd).
>>> Then
>>> in the Touch Function of Trigger_Checkpoint, dynamically cast the
>>> baseentity* and see if it's a player. If it is a player, then  
>>> check if
>>> the
>>> pPlayer->int_Rounds = int_RoundsOfThisTrigger-1, and if it is,   
>>> then set
>>> pPlayer->int_Rounds = intRoundsOfThisTrigger. Of course, the logic  
>>> has to
>>> be
>>> expanded, so when the player reaches the goal, the int_Rounds is  
>>> set to
>>> Zero
>>> again. But that should be straightforward.
>>>
>>> Of course, it could be done with some advanced in-map entity
>>> input/output,
>>> but it's much simpler (and more reliable) to do it via programming.
>>>
>>> Have Fun,
>>> Sortie
>>>
>>> ----- Original Message -----
>>> From: "FaMiNe" <fam...@gmail.com>
>>> To: "Discussion of Half-Life Programming"
>>> <hlcoders@list.valvesoftware.com
>>>>
>>> Sent: Tuesday, April 28, 2009 11:50 PM
>>> Subject: [hlcoders] Checkpoints Triggers
>>>
>>>
>>>> I've been looking into this for a while, but I'm still new.
>>>>
>>>> I'm trying to create a checkpoint system, where the player cannot
>>>> activate the next checkpoint until they get the current one (ex:  
>>>> have
>>>> to
>>>> get checkpoint 1 before you can get checkpoint 2).
>>>>
>>>> I created a map entity, and using trigger_multiple as a base for my
>>>> checkpoint trigger, I'm trying to find a place to put a variable  
>>>> that
>>>> contains the previous checkpoint that they grabbed, and a method to
>>>> trigger it in the first place. Since this is a multiplayer mod, I
>>>> expect
>>>> each player instance to have their own checkpoint status variable.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> -- 
>> Sent from Olly's SEGA Game Gear
>> _______________________________________________
>> 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

Reply via email to