RE: [hlcoders] Examples of uses for IEngine-ServerInsertCommand()
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
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
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?
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?
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?
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
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.
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.
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?
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
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
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 (-:
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
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
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
