RE: [hlcoders] Examples of uses for IEngine-ServerInsertCommand()

2005-06-11 Thread Karl \XP-Cagey\ Patrick
 Yet, even in the case of a full blown scripting language, not having
 InsertCommand() means that any scripts/commands that you wished to
 invoke via a normal Valve cfg file would have the same ordering problem if

 they needed to pass commands back to the server (e.g. exec, changelevel,
 kickid, etc).

One solution to your problem that doesn't require an API change is
instructing users to write a one-line config file that simply calls your
plugin-enabled parser to run on another file.  E.g. have the entire contents
of autoexec.cfg be eventscripts_exec autoexec_script.cfg\n.  Once you have
that arrangement, there aren't any commands that you need to preempt from
the top level scripts--load and manipulate the entire autoexec_script.cfg
file in memory to perform whatever transforms you need, then feed the entire
transformed file to the server in a block.  Delayed insertion removes the
need for preemptive insertion, and as far as your end users know or care,
they're still using Valve's config system.

Placement of the entire config into a one-off file isn't seamless, but it's
not hard for users to understand and it doesn't require much extra work or
drive space.  If HL2 calls two script files, say autoexec.cfg and
server.cfg, at nearly the same time and they both contain a single call into
a one-off, the execution order will appear to be the same to end users even
if the second exec comes before or in the middle of the interpreted commands
from the first file, since the effect of calling the second file would place
its commands after the complete set of commands from the intial file
(assuming the whole file interpret-and-stuff mechanism described above and
synchronous server command execution).

You really don't need out-of-order placement for variable substitution or
subscript execution using this scheme--you could even support calls into
other files and process them entirely in place before you begin inserting
the top level file. You might want to have preemptive insertion for live
evaluation of loop conditions, but that problem can also be solved through
delayed insertion - keep all commands after the evaluation statement in
memory until you get back your result. Simple loop counters can be unrolled
in place instantly, and I'm not sure how much complexity a configuration
script really needs.

My 2 cents,

Karl


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:hlcoders-
 [EMAIL PROTECTED] On Behalf Of Jeremy Swigart
 Sent: Friday, June 10, 2005 6:20 AM
 To: hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] Examples of uses for IEngine-
 ServerInsertCommand()

 I could be wrong, but even if ServerInsertCommand() puts the script
 command at the front of the queue as opposed to the back, that still
 wouldn't be executed until the current script is finished. Sounds like
 really what you need is ServerCommandNow() that executes it right now,
 so that when the next line of the current script runs, it can be sure
 that the results of the script it just invoked is already done. Sounds
 like even with ServerInsertCommand() it is gonna be a pain to get the
 ordering right.

 On 6/10/05, Mattie Casper [EMAIL PROTECTED] wrote:
  Thanks for the suggestion, but, as you may have guessed, this has been
  considered. ;)  Yet, creating an entire scripting engine isn't the goal
 of
  EventScripts. There are lots of different scripting engines out there,
 and they
  definitely have their place for administrators who understand coding.
  EventScripts is trying to be the middle-ground between a
 structured/scoped
  language and the console commands they know and love. As I mentioned
 below, ES
  doesn't yet support looping and the like and may never do so--- it's not
  intended to be a full-powered scripting language.
 
  With EventScripts, we're trying to enhance the console commands so that
 even
  everyday normal console/rcon commands and normal autoexec.cfg/server.cfg
 files
  can take advantage of very simple logic and variable expansion. We don't
 need
  everything a scripting language can do, we just want some basic
 enhancements to
  the command console. Most of these console enhancements would be along
 the lines
  Valve was already been moving, e.g. with setinfo and incrementvar.
 
  Yet, even in the case of a full blown scripting language, not having
  InsertCommand() means that any scripts/commands that you wished to
 invoke via a
  normal Valve cfg file would have the same ordering problem if they
 needed to
  pass commands back to the server (e.g. exec, changelevel, kickid, etc).
 These
  commands would execute *after* the current .cfg file was totally
 resolved and
  not in-place. This wouldn't be intuitive and would likely cause
 problems! It
  wouldn't be a problem if you didn't allow the console to launch scripts,
 but the
  server console is a great place for invoking things like that
 (especially
  remotely).
 
  *** TO CLARIFY, this isn't a problem just for scripting engines! ***
 It's a

RE: [hlcoders] STOPP FUCKING

2005-02-23 Thread Karl \XP-Cagey\ Patrick
What, you've never gotten into a one-sided screaming match with an opt-out
email list before?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru'
MacDonald
Sent: Wednesday, February 23, 2005 9:48 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] STOPP FUCKING

His brain is oh too small for that.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank Weima
Sent: Wednesday, February 23, 2005 12:06 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] STOPP FUCKING

Hey look, We got nice people in the mail-script coding team.
It says:

To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders;

Heey! What the... it's at the bottom, maybe you should press it?
Do you Yah... Code!? :-)

Frank


___
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] Bizzare/Random/Frightening crash

2005-02-22 Thread Karl \XP-Cagey\ Patrick
Inconsistent exit crashes can be caused when there are dependencies on
automatically destructed singletons or static variables--the stack you gave
looks like final cleanup, and if the call to RemoveAllPanels uses an object
that has already been destructed (possibly the CBaseViewport itself,
possibly a singleton used by that function call), the result would be
gibberish; calls into that object would have erratic behavior.

The compiler should in theory use a consistent cleanup ordering between
compiles, but there's no requirement specified by the C++ standard that
would enforce this, and if the destruction order isn't consistent for some
reason, it would explain the behavior that you're seeing from compile to
compile.  Any change to apparently unrelated code could potentially result
in the destruction order of singletons being changed.

I'd begin looking for early destruction of resources used by RemoveAllPanels
(including the CBaseViewport itself) as a cause.

Karl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maurino Berry
Sent: Monday, February 21, 2005 9:39 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Bizzare/Random/Frightening crash

unfortunately cleaning it doesnt seem to help very often : I think I'm
going to try compiling on another computer maybe if I can't get any more
suggestions from here.. thanks though :D

_
Designer Mail isn't just fun to send, it's fun to receive. Use special
stationery, fonts and colors.
http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=htt
p://hotmail.com/encaHL=Market_MSNIS_Taglines
  Start enjoying all the benefits of MSNR Premium right now and get the
first two months FREE*.


___
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] Re: [OT] [OT] Safe way of setting weapon damages?

2005-02-14 Thread Karl \XP-Cagey\ Patrick
From Beppo:
 In terms of inherited classes this means that any direct copy of my codes
 that is then changed or an inherited class with changed behaviour is
 actually reusing my codes too. So this falls under the intellectual
 property copyright law.

Do you have a case citation to back that up?  I'd be shocked if it's
possible to violate copyright without making a binary change to the original
code.  I don't believe that's the case--see voogru's post.

When you attempt to prohibit inheritance of a class, I think you're seeking
protection of an idea or method of execution, which is closer to patent law
than copyright (not that I want to open that can of worms).

 But if a mod states in its licensee agreement that you are not allowed to
 change it in any way (agree to perform no after market modifications in
 termy to be allowed to use it) then the whole thing will be copyrighted.
 Either install it by agreeing or do not install it... your choice.

What you're describing is a business contract between the end user and the
software developer that gives additional protection outside of standard
copyright law.  It may seem semantic, but a EULA doesn't expand the law any
more than a credit card transaction (another contract) does (see Deadman
Standing's post).

Blizzard's successful attempts to crush that battle.net imitator in court
illustrate that running a reverse engineered server can be a breach of
contract provided the EULA has a no reverse engineering clause; that wasn't
a copyright case, but Blizzard successfully sued because of the wording of
the original contract and a demonstrated economic impact for Blizzard.
Plugins don't fit the same category because they aren't reverse engineered
and don't modify the original code.

From Lance:
 You do realize that by saying this you're just BEGGING people to make all
 kinds of crazy plugins to screw up the gameplay in your MOD, right?  :)

I think it's unfortunate that people take this sort of thing as a challenge.
Is it really that important to  someone off and prove them wrong if you
weren't otherwise interested in their work?

From Lance again:
 Jason Schultz, an attorney with the non-profit Electronic Frontier
 Foundation, couldn't disagree more. This complaint is absurd, said
 Schultz. The law allows for fair use of other people's copyrighted works
 without any permission needed, and one of the key things that you're
 allowed to do is make copies in order to reverse engineer and understand
 how they work.

The EFF is a rights advocacy group (we fight measures that threaten basic
human rights principles), and can't be considered an objective source.
They've stated that the DMCA is probably unconstitutional and dismiss its
content out of hand.  I'd take analysis of current copyright law and
expected legal decisions from them with a grain of salt, the same way I
treat statements from ACLU lawyers.  Equating the trade of asset patches and
modification of the program for entertainment purposes with understand[ing]
how [programs] work is a stretch.

That said, I hope that the Tecmo case is dismissed because I believe that
people who have bought intellectual property should have the right to modify
it for their personal use (e.g. writing in the margin of a book).



Off-topic: Lance (and any other interested parties), would you mind having
an offline conversation on how to detect modification of a HL1 server?  NS
is committed to allowing plugins, but I'd like to know when the game is
running stock so that I can collect feedback for balancing the sides.

I can look at the module list in Win32, but I'm not sure if that catches all
cases and it's not cross-platform.  It would be even better if I could
fingerprint the modifications to know how popular they are and to see how
common gameplay changes affect balance.

Karl



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



RE: [hlcoders] Re: [OT] [OT] Safe way of setting weapon damages?

2005-02-14 Thread Karl \XP-Cagey\ Patrick
Sorry Lance and Jeffery, attributed this quote to the wrong person in my
last reply, should have been Jeffery:

 You do realize that by saying this you're just BEGGING people to make all
 kinds of crazy plugins to screw up the gameplay in your MOD, right?  :)

Karl



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



RE: [hlcoders] Re: [OT] [OT] Safe way of setting weapon damages?

2005-02-10 Thread Karl \XP-Cagey\ Patrick
 If people blame your mod for what a mutator does, then tell them it
 was the mutator. Egads.

This is, of course, extremely easy to do since new players always tell
developers why they won't give a mod another chance... ;)

I'm all for customization as long as players know it's a customized server.
If there was a simple indicator that a server was running plugins with their
names listed (like there is for mutators), then people could look for
themselves--I haven't played around with plugins for HL2 yet, so I'm not
sure if this interface is already part of the SDK. I miss it in the original
Half-Life engine.

 If a mini mod is liked [like the high damage example] by everybody,
 then yes it should be implimented by the mod team. However, if a mod is
 big enough to have such a mini mod base as, say, natural selection, or any

 of the other large mods [nameless..], then it's pretty much guaranteed
 that the mod team won't listen to anything the community says, or, even
 worse, only listen to fanboys that have a horribly retarded vision for the

 good game.  Thanks, Fluyra [names edited to protect the guilty]!

Ouch?

Actually, there are some cases of widespread plugin functionality that we're
aware of and want to include in future versions (nextmap is a no-brainer).
We don't (can't?) have the full picture of what mods user base is using on a
day-to-day basis, but we do listen (and not just to the bad ideas).

 .ctx's are already useless - I don't see how people think it's
 protection :P When code is running on a computer that people have
 admin / root access to, _nothing_ is unmodifyable. Encrypt and
 hardcode what you like, it's just adding needless and useless
 complexity for you.

 Oh, and who needs a mod's source when you have a debugger :)

I think this is analogous to anti-cheat on the client side.  Any person with
enough knowledge of how game code is layered on top of hardware drivers will
admit that it's impossible to stop all cheating, but making it harder to do
is still beneficial because it keeps the frequency of casual cheating down
(or so the people who invest time in anti-cheat like to think).

In environments where you want a level playing field across servers (i.e.
competitive gaming) it's still worthwhile to at least investigate having
checks to insure servers are running the unaltered mod (or the exact set of
mini-mods required by the league, ladder, or tournament, for that matter).

Karl



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



RE: Re[2]: [hlcoders] Steam: Technology failure

2005-01-31 Thread Karl \XP-Cagey\ Patrick
I don't suppose there's a way to block off topic spammers from the list?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vyacheslav Djura
Sent: Monday, January 31, 2005 7:59 AM
To: Jeffrey botman Broome
Subject: Re[2]: [hlcoders] Steam: Technology failure

Hello Jeffrey,

Monday, January 31, 2005, 4:44:07 PM, you wrote:
JbB RETURN IT and get your money back (most places have
JbB consumer protection laws where you are legally allowed to return
JbB something if you discover that it doesn't work as advertised).
I do not want to return the product, I just want to launch Steam in
offline mode and Valve doesn't care if I am able or unable to launch
it in offline mode and their support is silent. That is all. Sorry
that I WANT TO WRITE CODE and I WANT TO LAUNCH EDITOR but I CAN'T.

--
Best regards,
 Vyacheslavmailto:[EMAIL PROTECTED]


___
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] Minor bug with GetUserMessageInfo.

2005-01-16 Thread Karl \XP-Cagey\ Patrick
If index 0 is valid (which the first check indicates is true), N items would
be in indices 0 through N-1 and the original check is correct.

 if ( index  0 || index = (int)m_UserMessages.Count() )

 Shouldn't this be:

 if ( index  0 || index  (int)m_UserMessages.Count() )

 Or am I mistaken?

 Thanks.

 - voogru.


___
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] Minor bug with GetUserMessageInfo.

2005-01-16 Thread Karl \XP-Cagey\ Patrick
Actually...

(i = 0  i  m_Size) is true for i = 0 .. N-1
(i  0  i = m_UserMessages.Count()) is true for items outside i = 0 ..
M-1

They are correct as written if m_Size equals m_UserMessages.Count(), the
first is meant to range check, and the second is meant to handle items
outside the valid range.  If GetUserMesageInfo is throwing an exception and
is meant to return false instead, it's another point in the logic that's a
problem (like m_Size not actually equaling m_UserMessages.Count()), not the
choice of operators.

Karl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Spencer voogru
MacDonald
Sent: Sunday, January 16, 2005 9:40 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Minor bug with GetUserMessageInfo.

Yeah, I guess so.

Though the CUserMessages::IsValidIndex function does the same check, but
does if(i = 0  i  m_Size).

Either way, one of these is wrong, because the GetUserMessageInfo should be
returning false when I try to get the information for an index that doesn't
exist.


-Original Message-
From: Karl XP-Cagey Patrick [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 16, 2005 11:20 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Minor bug with GetUserMessageInfo.

If index 0 is valid (which the first check indicates is true), N items would
be in indices 0 through N-1 and the original check is correct.

 if ( index  0 || index = (int)m_UserMessages.Count() )

 Shouldn't this be:

 if ( index  0 || index  (int)m_UserMessages.Count() )

 Or am I mistaken?

 Thanks.

 - voogru.


___
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] Server Plugins - Interfaces?

2005-01-10 Thread Karl \XP-Cagey\ Patrick
In response to your last question:

http://list.valvesoftware.com/mailman/private/hlcoders/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian
Marschalek
Sent: Monday, January 10, 2005 7:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Server Plugins - Interfaces?

Hi everyone,

If I understood the server plugin example correctly, I can only access
certain features through interfaces. Now I wonder if there's a list of
interfaces I can use in a server plugin? What I'm looking for especially is
a good method of disconnecting a client. I know that the engine interface
has a execute client method, but somehow executing a disconnect on a
client to kick him from a server does not feel right. I wonder if I have
access to the same methods that disconnect a user when I execute an rcon
kick command?

BTW: Does anyone know of a searchable archive of this list?

best regards,
Chris

___
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] Weird missing dll error

2004-06-05 Thread Karl \XP-Cagey\ Patrick
MSVCR70.dll is a .Net runtime... are you linking to any 3rd party dlls?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 11:48 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Weird missing dll error


Almost at random times during a game this pops up and the server crashes.
But its fairly rare.

The dynamic link library MSVCR70.dll could not be found in the specified
path

then it goes on to point to a number of locations including my steam/...
half-life/ dir

What the heck is that all about? I'm using VS 6.0 with standard compile
options that came with the sdk.




___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



RE: [hlcoders] Re: Document

2004-05-24 Thread Karl \XP-Cagey\ Patrick
By following the link to Symmantec's virus DB I posted earlier, you'll note
that this attachment name is being broadcast by the virus I linked.

Conspiracy theories aside, the name isn't specific to this particular attack
and doesn't indicate a sentient presence behind this individual email.  The
idiot who designed the worm is trying to use names that are likely to be
clicked on by random internet users, and CS has a wide audience.

Karl
XP-Cagey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of McCormack, Chris
Sent: Monday, May 24, 2004 2:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Re: Document

These are getting content specific now. Time to do something about it ?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Alfred
Sent: 23 May 2004 22:19
To: Hlcoders
Subject: [hlcoders] Re: Document


--
[ Converted text/html to text/plain ]

--
[ Counter_strike.hta of type application/octet-stream deleted ]
--


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


***
This e-mail and its attachments are confidential
and are intended for the above named recipient
only. If this has come to you in error, please
notify the sender immediately and delete this
e-mail from your system.
You must take no action based on this, nor must
you copy or disclose it or any part of its contents
to any person or organisation.
Statements and opinions contained in this email may
not necessarily represent those of Littlewoods.
Please note that e-mail communications may be monitored.
The registered office of Littlewoods Limited and its
subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152.



___
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] ^_^ mew-mew (-:

2004-05-17 Thread Karl \XP-Cagey\ Patrick
StealthMode -

You've said you want to drop the issue, but you also have some
misconceptions that really ought to be addressed.  If you want the
conversation to end with this email, so be it.



 My network is clean, I can guarantee that.

Since we already know that the from field of the email is being spoofed,
it's already been concluded that the state of your network has no bearing on
the worm's ability to specify you as a sender.  Your email address--a simple
byte string--only needs to be present on an infected machine.



 Like I said check the header, and thanks, because your reply confirms it
 is someone specifically spoofing emails, and not a worm (worms dont pick
 up on addresses IN an email, only ones FROM an emails FROM area).

So worms like W32/[EMAIL PROTECTED] that are sophisticated enough to pack their
own SMTP engines and scan hard drives to harvest addresses are somehow
unable to look at email content, even though that information is usually
stored on hard drives?

Where are you getting your information from?  Check McAfee or Symantec's
virus information sites for information on what modern worms are programmed
to do.  Take a look at Symantec's step-by-step list of the worm's actions in
particular.

http://securityresponse.symantec.com/avcenter/venc/data/[EMAIL PROTECTED]
http://us.mcafee.com/virusInfo/default.asp?id=descriptionvirus_k=125089



 Lastly, no emails were spoofed to this list in my name, however to
 individuals they were. What does that tell you?

It tells me that the worm hasn't sent anything to the list using your email
address in the from field.  Since the contaminated message was sent to the
list was on the 12th and you began your recent posts here almost 24 hours
afterward, that doesn't exactly shock me.



Karl
XP-Cagey



___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



[hlcoders] Debug Assertion Failed in H:\Steam\Steam.exe

2004-05-07 Thread Karl \XP-Cagey\ Patrick
I'm not sure if it's coincidence or not, but since updating Steam to the
latest release today I haven't been able to successfully start a listen
server for any game.  Did you guys release a debug build of Steam.exe on
accident?

I'm seeing the following debug assertion dialog:

Debug Assertion Failed

Program: H:\Steam\Steam.exe
File: Src\EngineClientConnection.cpp
Line: 1178

False

(Press Retry to debug the application-JIT debugging must be enabled)

If I choose 'Abort' from the assertion dialog, the following is written to
the console:

SteamGetEncryptedUserIDTicked failed (4)
reason--

The behavior is the same when I run Steam offline (unplugging myself from
the LAN).  The value of sv_lan is 1 in my listenserver.cfg file.  Steam
appears to be shutting itself down in the background after it hits the
assertion.

At the suggestion of members of the steam forums, I've tried regrabbing
platform.gcf, but that didn't fix the problem.

Karl
XP-Cagey



___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



RE: [hlcoders] Debug Assertion Failed in H:\Steam\Steam.exe

2004-05-07 Thread Karl \XP-Cagey\ Patrick
Thanks! :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Taylor Sherman
Sent: Friday, May 07, 2004 7:43 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Debug Assertion Failed in H:\Steam\Steam.exe

Delete the Steam.dll that's in your Counter-Strike directory. :)

Taylor



___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders