[hlcoders] Blue Wireframe on Attachments
-- [ Picked text/plain from multipart/alternative ] Hello all, I am still getting an issue with attachments on player models for multiplayer. The view models are fine but when the world model is attached to the other player's model the weapon itself is rendered in a blue wireframe. The materials are right, everything seems to be fine. Could this be result of a code update? Oh and the model is fine in the model viewer. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Downloadables Bug? VALVE?
-- [ Picked text/plain from multipart/alternative ] The three times I've asked before, the response was always "yes, we'll add that next update," so I'm happy they at least said why it wasn't being added this time. The following suggestions would all address the concern, which I believe is server-side cheats showing player info on the screen in arbitrary locations. (Although, if that's what someone is doing, wouldn't they just update their ClientScheme.res file anyway?) 1. Maybe a restricted version (or new message) could be added? Only 0 and 1 for positions in the X direction? 2. Or a networked version of IVEngineServer::Con_NXPrintf? (Possibly with a larger font.) Grant (L. Duke) On 3/19/07, David Anderson <[EMAIL PROTECTED]> wrote: > > > And I'm sure it's just an oversight that they missed putting the > > CenterPrintText definition in the file to begin with. > > Unfortunately, this is not the case. We asked Valve about this two > years ago, and we were told it was on purpose. They don't want people > drawing to the screen. > > I think your solution of allowing clients to disable it is a good idea. > Of course, Valve is more concerned about: > 1) Restricting modability > 2) Creating a uniform gaming "experience" (what) > > So, I don't think this will ever be accepted. Sigh. > > ---David Anderson > http://www.bailopan.net/ > > Spencer 'voogru' MacDonald wrote: > > Well, I can see the need for things like restricting commands sent down > by > > the server, I mean it's not cool when a 13 year old admin binds every > key to > > "kill" > > > > But, it appears that according to valve, displaying a string on the > client > > is far worse than binding all someone's keys to kill, because unlike > > cl_restrict_server_commands, there isn't even an option to allow players > to > > enable HudMsgs without editing the clientscheme.res, and since a > majority of > > players don't know what the console is, you can pretty much forget about > it. > > > > The stuff on the HUD goes away when they leave the server, binding all > of > > their keys to kill doesn't go away. > > > > If it's that much of a problem, add a cvar to allow a client to see the > > HudMsg's or not, except this time, default it to ON. If they have > > hallucinations or go in a mad frenzy when they see a HudMsg they have > the > > option of turning it off. > > > > But personally, HudMsgs have been used in HL1 for all kinds of various > > purposes, what's the problem with having it in HL2? Isn't HL2 supposed > to > > have more features? Not less? > > > > And I'm sure it's just an oversight that they missed putting the > > CenterPrintText definition in the file to begin with. > > > > - voogru. > > > > -Original Message- > > From: Jay Croghan [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 15, 2007 5:31 AM > > To: hlcoders@list.valvesoftware.com > > Subject: RE: [hlcoders] Downloadables Bug? VALVE? > > > > Lately Valve have been of the opinion that their users are a heard of > > sheep with absolutely no self-intuition. > > > > As was said before and will be again, that attitude will be the death > > of Valve and it's games. > > > > - Jay > > > > > > Quoting Spencer 'voogru' MacDonald <[EMAIL PROTECTED]>: > > > >> Intrusive? Make the font a little smaller maybe? > >> > >> If it's abused it's the users choice to leave the server. > >> > >> - voogru. > >> > >> > >> -Original Message- > >> From: David Anderson [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, March 13, 2007 10:28 PM > >> To: hlcoders@list.valvesoftware.com > >> Subject: Re: [hlcoders] Downloadables Bug? VALVE? > >> > >> I never knew that text could be so intrusive. Is it: > >> > >>a) The colors (think of the children!), > >>b) The letters themselves (which could, on occasion, be combined to > >> form words), or, > >>c) The fact that they can be arbitrarily positioned? > >> > >> There's already a way to do "b" (white, centered), so I'm guessing > there > >> must be something abjectly heinous about the other two. If such is the > >> case, why not add something for coloring but not positioning, or > >> something for positioning but not coloring? > >> > >> ---David Anderson > >> http://www.bailopan.net/ > >> > >> Yahn Bernier wrote: > >>> Alfred and I discussed and there was too much concern that it would be > >>> abused so we're going to leave it out for now. I think there are > other > >>> ways for plugins to present info to clients that aren't as intrusive. > >>> > >>> Yahn > >>> > >>> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf Of LDuke > >>> Sent: Tuesday, March 13, 2007 12:40 PM > >>> To: hlcoders@list.valvesoftware.com > >>> Subject: Re: [hlcoders] Downloadables Bug? VALVE? > >>> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] The downloadables bug > >>> fix is something a lot of plugin developers and server admins are very > >>> happy about having. Than
Re: [hlcoders] Downloadables Bug? VALVE?
> And I'm sure it's just an oversight that they missed putting the > CenterPrintText definition in the file to begin with. Unfortunately, this is not the case. We asked Valve about this two years ago, and we were told it was on purpose. They don't want people drawing to the screen. I think your solution of allowing clients to disable it is a good idea. Of course, Valve is more concerned about: 1) Restricting modability 2) Creating a uniform gaming "experience" (what) So, I don't think this will ever be accepted. Sigh. ---David Anderson http://www.bailopan.net/ Spencer 'voogru' MacDonald wrote: Well, I can see the need for things like restricting commands sent down by the server, I mean it's not cool when a 13 year old admin binds every key to "kill" But, it appears that according to valve, displaying a string on the client is far worse than binding all someone's keys to kill, because unlike cl_restrict_server_commands, there isn't even an option to allow players to enable HudMsgs without editing the clientscheme.res, and since a majority of players don't know what the console is, you can pretty much forget about it. The stuff on the HUD goes away when they leave the server, binding all of their keys to kill doesn't go away. If it's that much of a problem, add a cvar to allow a client to see the HudMsg's or not, except this time, default it to ON. If they have hallucinations or go in a mad frenzy when they see a HudMsg they have the option of turning it off. But personally, HudMsgs have been used in HL1 for all kinds of various purposes, what's the problem with having it in HL2? Isn't HL2 supposed to have more features? Not less? And I'm sure it's just an oversight that they missed putting the CenterPrintText definition in the file to begin with. - voogru. -Original Message- From: Jay Croghan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 5:31 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Downloadables Bug? VALVE? Lately Valve have been of the opinion that their users are a heard of sheep with absolutely no self-intuition. As was said before and will be again, that attitude will be the death of Valve and it's games. - Jay Quoting Spencer 'voogru' MacDonald <[EMAIL PROTECTED]>: Intrusive? Make the font a little smaller maybe? If it's abused it's the users choice to leave the server. - voogru. -Original Message- From: David Anderson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 10:28 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Downloadables Bug? VALVE? I never knew that text could be so intrusive. Is it: a) The colors (think of the children!), b) The letters themselves (which could, on occasion, be combined to form words), or, c) The fact that they can be arbitrarily positioned? There's already a way to do "b" (white, centered), so I'm guessing there must be something abjectly heinous about the other two. If such is the case, why not add something for coloring but not positioning, or something for positioning but not coloring? ---David Anderson http://www.bailopan.net/ Yahn Bernier wrote: Alfred and I discussed and there was too much concern that it would be abused so we're going to leave it out for now. I think there are other ways for plugins to present info to clients that aren't as intrusive. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LDuke Sent: Tuesday, March 13, 2007 12:40 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Downloadables Bug? VALVE? -- [ Picked text/plain from multipart/alternative ] The downloadables bug fix is something a lot of plugin developers and server admins are very happy about having. Thank you. What about the "CenterPrintText font definition is missing from ClientScheme.res" ? Did that just not make it in, or is there some other reason that it won't be added? Grant (L. Duke) On 2/24/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: Sure -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LDuke Sent: Saturday, February 24, 2007 6:04 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Downloadables Bug? VALVE? -- [ Picked text/plain from multipart/alternative ] Another bug that's been around for a while: The CenterPrintText font definition is missing from ClientScheme.res so that a HudMsg doesn't get displayed. One of the guys at Turtlerock said he'd add it to the to-do list months ago. Would it be possible to add this fix to the next update also? I've been trying to show a timer in an unobtrusive place on the screen for a CAL match plugin for DODS, but there is really no way to do this right now. The plugin interface doesn't seem to obey the time parameter so can't be updated (plus it prints right on top of the flag status icons), the center say and hint text are too much in the way of the player's view. It would be an eas
RE: [hlcoders] Entity not respawning
Hi Emiel- The Source SDK and the engine version that it uses are 32-bit and we don't have any plans to change that right now. Sorry. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emiel Regis Sent: Sunday, March 18, 2007 5:32 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Entity not respawning Hi, I've got a serious problem. My CTF flag entity, after being spawned by flagspawn brush entity (http://rafb.net/p/eDfnq145.html) and being picked up should respawn after hitting players own flag point (as CTF works). It does, but only one time - after entity is respawned you can still pick it, but it doesn't allow you to touch your own flag anymore... Also although code for red flag and blue flag is same, it doesn't work or TEAM_REBELS at all... Could somebody help me please? Another question - how do you enable hl2 running in 64-bit? I have 64 bit proc (Pentium D) and windows x64, yet hl2 is still running in 32 bit mode. These are my files: ctf_flagblue.cpp - http://rafb.net/p/kv4E6514.html ctf_flagred.cpp - http://rafb.net/p/4Fikc325.html Regards, Emiel Regis ___ 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] User messages: reliable vs. unreliable
-- [ Picked text/plain from multipart/alternative ] Okay, it makes sense now. Thanks for your help Yahn. Regards, Paul On 3/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > Yeah. Entity data is unreliable, so it goes last after any reliable > payload. However, if you have reliable stuff queued from a previous > send, it's possible that the current reliable payload can be delayed for > several packets before being sent. So you can't rely on it being on the > client instantaneously. > > I'd have to look again at the code to see if unreliable user message > precede the entity data or not, can't remember at this point. I think > they might not. > > Unreliable messages do just dissappear. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski > Sent: Monday, March 19, 2007 10:30 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] User messages: reliable vs. unreliable > > -- > [ Picked text/plain from multipart/alternative ] > So: reliable user messages first, entity data second, unreliable user > messages last into the packet and that is how they are unpacked on the > client? Also, reliable messages are re-sent if dropped, but the > unreliable messages just disappear? > > Regards, > > Paul > > On 3/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > > > Reliable data is placed into the UDP packet before unreliable data > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > > Peloski > > Sent: Monday, March 19, 2007 7:51 AM > > To: hlcoders@list.valvesoftware.com > > Subject: [hlcoders] User messages: reliable vs. unreliable > > > > -- > > [ Picked text/plain from multipart/alternative ] Hi guys, > > > > I would like to spawn an entity and send a user message from the > > entity's Spawn function (so it the entity creation and user messages > > will likely be in the same packet), on the client I'd like the client > > side version of the entity to be initialized first, and then have user > > > message dispatched second. > > > > If I don't call MakeReliable() on the filter, that's exactly what > > seems to happen all the time. But, if I call MakeReliable(), the > > message seems to be processed before the entity is initialized on the > > client. Any explanation for this behavior? What exactly does a > > reliable filter do differently in terms of the time the message is > processed on the client? > > I notice the code path coming from the engine is different (longer) > > when the message is reliable, but what's happening? > > > > I know there are other ways to do this, but, I'm just curious and > > would like to save altering how my system works. > > > > Regards, > > > > Paul > > -- > > > > ___ > > 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
RE: [hlcoders] User messages: reliable vs. unreliable
Yeah. Entity data is unreliable, so it goes last after any reliable payload. However, if you have reliable stuff queued from a previous send, it's possible that the current reliable payload can be delayed for several packets before being sent. So you can't rely on it being on the client instantaneously. I'd have to look again at the code to see if unreliable user message precede the entity data or not, can't remember at this point. I think they might not. Unreliable messages do just dissappear. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski Sent: Monday, March 19, 2007 10:30 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] User messages: reliable vs. unreliable -- [ Picked text/plain from multipart/alternative ] So: reliable user messages first, entity data second, unreliable user messages last into the packet and that is how they are unpacked on the client? Also, reliable messages are re-sent if dropped, but the unreliable messages just disappear? Regards, Paul On 3/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > Reliable data is placed into the UDP packet before unreliable data > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Peloski > Sent: Monday, March 19, 2007 7:51 AM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] User messages: reliable vs. unreliable > > -- > [ Picked text/plain from multipart/alternative ] Hi guys, > > I would like to spawn an entity and send a user message from the > entity's Spawn function (so it the entity creation and user messages > will likely be in the same packet), on the client I'd like the client > side version of the entity to be initialized first, and then have user > message dispatched second. > > If I don't call MakeReliable() on the filter, that's exactly what > seems to happen all the time. But, if I call MakeReliable(), the > message seems to be processed before the entity is initialized on the > client. Any explanation for this behavior? What exactly does a > reliable filter do differently in terms of the time the message is processed on the client? > I notice the code path coming from the engine is different (longer) > when the message is reliable, but what's happening? > > I know there are other ways to do this, but, I'm just curious and > would like to save altering how my system works. > > Regards, > > Paul > -- > > ___ > 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
Re: [hlcoders] User messages: reliable vs. unreliable
-- [ Picked text/plain from multipart/alternative ] So: reliable user messages first, entity data second, unreliable user messages last into the packet and that is how they are unpacked on the client? Also, reliable messages are re-sent if dropped, but the unreliable messages just disappear? Regards, Paul On 3/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > Reliable data is placed into the UDP packet before unreliable data > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski > Sent: Monday, March 19, 2007 7:51 AM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] User messages: reliable vs. unreliable > > -- > [ Picked text/plain from multipart/alternative ] Hi guys, > > I would like to spawn an entity and send a user message from the > entity's Spawn function (so it the entity creation and user messages > will likely be in the same packet), on the client I'd like the client > side version of the entity to be initialized first, and then have user > message dispatched second. > > If I don't call MakeReliable() on the filter, that's exactly what seems > to happen all the time. But, if I call MakeReliable(), the message seems > to be processed before the entity is initialized on the client. Any > explanation for this behavior? What exactly does a reliable filter do > differently in terms of the time the message is processed on the client? > I notice the code path coming from the engine is different (longer) when > the message is reliable, but what's happening? > > I know there are other ways to do this, but, I'm just curious and would > like to save altering how my system works. > > Regards, > > Paul > -- > > ___ > 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] User messages: reliable vs. unreliable
Reliable data is placed into the UDP packet before unreliable data -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski Sent: Monday, March 19, 2007 7:51 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] User messages: reliable vs. unreliable -- [ Picked text/plain from multipart/alternative ] Hi guys, I would like to spawn an entity and send a user message from the entity's Spawn function (so it the entity creation and user messages will likely be in the same packet), on the client I'd like the client side version of the entity to be initialized first, and then have user message dispatched second. If I don't call MakeReliable() on the filter, that's exactly what seems to happen all the time. But, if I call MakeReliable(), the message seems to be processed before the entity is initialized on the client. Any explanation for this behavior? What exactly does a reliable filter do differently in terms of the time the message is processed on the client? I notice the code path coming from the engine is different (longer) when the message is reliable, but what's happening? I know there are other ways to do this, but, I'm just curious and would like to save altering how my system works. Regards, Paul -- ___ 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] User messages: reliable vs. unreliable
--
[ Picked text/plain from multipart/alternative ]
While i'm not sure exactly what you're doing, you could simply do:
void ClientEntity::OnDataChanged( DataUpdateType_t updateType )
{
if( updateType == DATA_UPDATE_CREATED )
{
do your message or whatever on the client here
}
}
instead of sending a message.
On 3/19/07, Paul Peloski <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Hi guys,
>
> I would like to spawn an entity and send a user message from the entity's
> Spawn function (so it the entity creation and user messages will likely be
> in the same packet), on the client I'd like the client side version of the
> entity to be initialized first, and then have user message dispatched
> second.
>
> If I don't call MakeReliable() on the filter, that's exactly what seems to
> happen all the time. But, if I call MakeReliable(), the message seems to
> be
> processed before the entity is initialized on the client. Any explanation
> for this behavior? What exactly does a reliable filter do differently in
> terms of the time the message is processed on the client? I notice the
> code
> path coming from the engine is different (longer) when the message is
> reliable, but what's happening?
>
> I know there are other ways to do this, but, I'm just curious and would
> like
> to save altering how my system works.
>
> Regards,
>
> Paul
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
-omega
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] User messages: reliable vs. unreliable
-- [ Picked text/plain from multipart/alternative ] Hi guys, I would like to spawn an entity and send a user message from the entity's Spawn function (so it the entity creation and user messages will likely be in the same packet), on the client I'd like the client side version of the entity to be initialized first, and then have user message dispatched second. If I don't call MakeReliable() on the filter, that's exactly what seems to happen all the time. But, if I call MakeReliable(), the message seems to be processed before the entity is initialized on the client. Any explanation for this behavior? What exactly does a reliable filter do differently in terms of the time the message is processed on the client? I notice the code path coming from the engine is different (longer) when the message is reliable, but what's happening? I know there are other ways to do this, but, I'm just curious and would like to save altering how my system works. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Entity not respawning
-- [ Picked text/plain from multipart/alternative ] Hi Emiel. Making a Star Wars mod? I would suggest a different approach. Instead of having the flag itself be picked up and carried by the player, why don't you try letting the flag spawning entity just disappear when the player touches it? Then you can create a new entity to follow the player around. When the new entity dies it signals back to the spawn entity to become visible again. I like this approach because a flag sitting at the spawn and a flag being carried by the player have two very different behaviors and properties, and you can localize these into two different classes instead of having to decide between them at run-time in one class. I always find this approach to be easier to implement, but your results may vary. -- Jorge "Vino" Rodriguez -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
