devicenullJoin Date: 2003-04-30Member: 15967Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1713762:date=Jun 24 2009, 12:41 PM:name=Rob)--><div class='quotetop'>QUOTE (Rob @ Jun 24 2009, 12:41 PM) <a href="index.php?act=findpost&pid=1713762"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Meh, if you're talking about someone who's willing to damage their eyesight looking through assembler, all bets are off anyway.<!--QuoteEnd--></div><!--QuoteEEnd-->
You haven't heard of HexRays then (it can take a binary and translate it back into C code, it's not perfect but its better then assembly)
@puzl: You are entirely correct, if this is an amxmodx plugin you are legally required to release the source code to it. This is not something that you can say "oh I don't want to, to keep it secure", you *must* release the code.
@Jiriki: Congrats on breaking the GPL. This is not optional. I've had to explain to many people why if they release a Amxmodx plugin, they are legally required to release the source. I hope I don't have to do it again.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->formatex(md5input[141],140,"%s%s%s","9WvcZ9hX",input[251],"KF7L4luQ")<!--c2--></div><!--ec2--> *gasp* What could that be! I hope that's not your checksumming method, that adds "9WvcZ9hX" to the beginning of the data, "KF7L4luQ" to the end, then md5's it!
devicenullJoin Date: 2003-04-30Member: 15967Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1713769:date=Jun 24 2009, 01:21 PM:name=KillerBroetchen)--><div class='quotetop'>QUOTE (KillerBroetchen @ Jun 24 2009, 01:21 PM) <a href="index.php?act=findpost&pid=1713769"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Wrong. In general, obscurity is part of a security chain. For example: Making your web server not exposing his name and version will not make it completely secure against any exploits for this version, yes. But it adds an obstacle for eve, which has to fire up more effort to look if your server is vulnerable. Like a door on a simple house, you can easily crack it, but this is already too much effort for most people.
Well, I totally understand your concern from the point of security. (if you could compromise server administration and such, for example) But your posts sounds somehow like "Weehh, I want to look, copy & paste from other mods". I'm going to script for NS2 too, as soon as it arrives, but since my scripts will be server-side only (to be able to offer some unique game server :)), I don't really care. Depending on what kind of damage/fraud could be done from within a script, of course.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't copy code from other people. I've already started writing lua addons for ns2 :p My point is, there are many people new to coding plugins that start off by copying code. I consider this to be important for people to learn.
@JazzX: I used to be on irc when I actually played NS.. and now I'm back on it :D Indeed, compiled lua plugins provide virtually no security. Compiled amxmodx plugins provide a little more, but not a whole lot (as you can see in my previous post)
locallyunsceneFeeder of TrollsJoin Date: 2002-12-25Member: 11528Members, Constellation
As killer mentioned, if you're writing scripts from scratch for your own server you're under no obligation to distribute to anyone, even under a free software licence. Similarly, as device mentioned, you'd only be legally required to provide the source when distributing if using code with a free software licence(such as an AMXplugin).
I wouldn't have a problem with UWE requiring modifications to be Free or Open Source or just a subset(like administrative plugins don't alter gameplay). Realistically, I doubt total conversion mods(and by extension mods that alter gameplay) would be required to release source code considering this is how UWE got its start.
I'd like to see Free or Open Source requirements for NS2 mods as an experiment. It'd be interesting to see what develops as the code repository grows, but I'd be naive if I didn't think it would scare a lot of developers of larger projects off. I just wonder if the collaborative effort of Open Source or Free software would allow for larger projects to grow in a modding community like it does in other software industry areas.
<!--quoteo(post=1713762:date=Jun 24 2009, 05:41 PM:name=Rob)--><div class='quotetop'>QUOTE (Rob @ Jun 24 2009, 05:41 PM) <a href="index.php?act=findpost&pid=1713762"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Meh, if you're talking about someone who's willing to damage their eyesight looking through assembler, all bets are off anyway.<!--QuoteEnd--></div><!--QuoteEEnd--> I occasionally do this. I read assembler FOR FUN. Usually something I wrote myself, but there is numerous exceptions.
I do see that distributing binaries might give someone a false sense of security (Indeed, I believe this thread features a stunningly excellent example), but I believe that should be coped with through education rather than legislation. Making rules won't prevent people being misinformed, what Lua features should we disable to prevent people from writing exploitable database code?
<!--quoteo(post=0:date=Jun 24 2009, 06:38 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 06:38 PM)</div><div class='quotemain'><!--quotec-->I don't copy code from other people. I've already started writing lua addons for ns2 :p My point is, there are many people new to coding plugins that start off by copying code. I consider this to be important for people to learn.<!--QuoteEnd--></div><!--QuoteEEnd--> Why do you believe that there will be a shortage of open source code to copy from, even if binaries are accepted by the engine? Do you think people will chose to distribute binaries by default if given the option?
<!--quoteo(post=0:date=Jun 24 2009, 06:38 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 06:38 PM)</div><div class='quotemain'><!--quotec-->Indeed, compiled lua plugins provide virtually no security. Compiled amxmodx plugins provide a little more, but not a whole lot (as you can see in my previous post)<!--QuoteEnd--></div><!--QuoteEEnd--> I agree, but aren't you undermining the "what if the source got lost" argument? You are saying that Lua code is easy to decompile, so it provides no security. Yet, it's too hard to decompile to make recovering sources feasible?
Edit: Spelling - removed some errors, introduced some new.
<!--quoteo(post=1713759:date=Jun 24 2009, 07:26 PM:name=puzl)--><div class='quotetop'>QUOTE (puzl @ Jun 24 2009, 07:26 PM) <a href="index.php?act=findpost&pid=1713759"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Jiriki, you do know that you *have* to release the source to the ENSL plugin, right? Amxmodx requires plugin source to be licensed under the GPL, unless you get an exception.<!--QuoteEnd--></div><!--QuoteEEnd--> Yes I know. Guilty on all accounts. Actually I haven't bothered / remembered (I haven't thought about in a year) to get the exception because currently so few people use it outside our own servers. I think its zero now. If I would get any complaints from AMXX staff, I would either remove it or get an exception. Also the guys who made some kind of anti-cheat plugin got an exception, just for security reasons.
Besides the plugin is a continuation from CALns plugin by JazzX. I don't think it was banned by AMXX devs.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->But putting that aside, if you depend on it being difficult to decompile a plugin for its operation then you have some major issues in your assumptions.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not depending on it. It's to limit the damage. We have multi clanning rules, but anyone could use package forwarding and swapping steam accounts, but that doesn't mean multi clanning rules are useless.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Even compiled binaries are easy to decompile, maybe not into easily readable C code, but the very existence of metamod demonstrates that even fully compiled programs are not free from inspection by users. Your example of DRM does nothing to support your premise, in fact it undermines it deeply.<!--QuoteEnd--></div><!--QuoteEEnd--> Nobody said it was "free" from inspection. Anyone could really reverse-engineer HL client, the whole game, but the fact is, its a lot harder when there is no source available. VAC doesn't stop all cheats, in fact, client security can never be 100%, but it doesn't make it useless.
Similarly a metal lock in a bicycle won't stop a thief who has a van or steel saw but that doesn't mean locks for bicycles are useless.
Are you also saying releasing NS1 source code wouldn't make it easier to find abusable bugs?
devicenullJoin Date: 2003-04-30Member: 15967Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1713776:date=Jun 24 2009, 02:34 PM:name=locallyunscene)--><div class='quotetop'>QUOTE (locallyunscene @ Jun 24 2009, 02:34 PM) <a href="index.php?act=findpost&pid=1713776"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As killer mentioned, if you're writing scripts from scratch for your own server you're under no obligation to distribute to anyone, even under a free software licence. Similarly, as device mentioned, you'd only be legally required to provide the source when distributing if using code with a free software licence(such as an AMXplugin).<!--QuoteEnd--></div><!--QuoteEEnd--> Correct.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I wouldn't have a problem with UWE requiring modifications to be Free or Open Source or just a subset(like administrative plugins don't alter gameplay). Realistically, I doubt total conversion mods(and by extension mods that alter gameplay) would be required to release source code considering this is how UWE got its start.
I'd like to see Free or Open Source requirements for NS2 mods as an experiment. It'd be interesting to see what develops as the code repository grows, but I'd be naive if I didn't think it would scare a lot of developers of larger projects off. I just wonder if the collaborative effort of Open Source or Free software would allow for larger projects to grow in a modding community like it does in other software industry areas.<!--QuoteEnd--></div><!--QuoteEEnd-->
Requiring the source to be open has not scared people off of making large gameplay changes for HL1/HL2, why would it stop it in NS2? I'd assume that anyone making a mod large enough to license the engine will be allowed to do what they want.
<!--quoteo(post=1713781:date=Jun 24 2009, 03:08 PM:name=Private)--><div class='quotetop'>QUOTE (Private @ Jun 24 2009, 03:08 PM) <a href="index.php?act=findpost&pid=1713781"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why do you believe that there will be a shortage of open source code to copy from, even if binaries are accepted by the engine? Do you think people will chose to distribute binaries by default if given the option?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I do. I've seen it happen in other games (Go try to find the source code for any of the popular COD4 mods, or basically anything in this series)
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I agree, but aren't you undermining the "what if the source got lost" argument? You are saying that Lua code is easy to decompile, so it provides no security. Yet, it's too hard to decompile to make recovering sources feasible?<!--QuoteEnd--></div><!--QuoteEEnd--> As an example, the amxmodx plugin was easily decompiled, but it's not in a state where I can easily recompile it.. I basically have a list of assembly instructions, with some enhanced comments showing me functions/variable names. It's not enough to easily rebuild the plugin from scratch. I'm unsure of how the lua decompiler works.. I have no idea of the quality of the code it produces.
<!--QuoteBegin-Jiriki+--><div class='quotetop'>QUOTE (Jiriki)</div><div class='quotemain'><!--QuoteEBegin-->Yes I know.<!--QuoteEnd--></div><!--QuoteEEnd--> So I'm mystified as to why you didn't release the source.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Nobody said it was "free" from inspection. Anyone could really reverse-engineer HL client, the whole game, but the fact is, its a lot harder when there is no source available. VAC doesn't stop all cheats, in fact, client security can never be 100%, but it doesn't make it useless.
Similarly a metal lock in a bicycle won't stop a thief who has a van or steel saw but that doesn't mean locks for bicycles are useless.<!--QuoteEnd--></div><!--QuoteEEnd--> Right, but when you can strip the protection as easily as running a freely available program, it makes it useless. And be sure if NS2 allows compiled plugins I will make a website allowing you to upload a plugin and have it decompiled.
<!--quoteo(post=1713791:date=Jun 24 2009, 03:46 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 03:46 PM) <a href="index.php?act=findpost&pid=1713791"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Requiring the source to be open has not scared people off of making large gameplay changes for HL1/HL2, why would it stop it in NS2? I'd assume that anyone making a mod large enough to license the engine will be allowed to do what they want.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm confused. Are you saying you can get the source from any HL1/HL2 mod?
Devicenull, I edited my previous post. I would remove it if I would get any complaints. And it was developed from CAL plugin made by JazzX, which was closed-source, and as far as I know wasn't banned by Amxx. I don't know if he got the exception or not, but I didn't really see it any different in terms of function of the plugin. And in case not, its not his fault, its mine.
devicenullJoin Date: 2003-04-30Member: 15967Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1713793:date=Jun 24 2009, 03:54 PM:name=Rob)--><div class='quotetop'>QUOTE (Rob @ Jun 24 2009, 03:54 PM) <a href="index.php?act=findpost&pid=1713793"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm confused. Are you saying you can get the source from any HL1/HL2 mod?<!--QuoteEnd--></div><!--QuoteEEnd-->
Not mods like you are thinking of, but there have been many plugins that drastically change gameplay (CSSDM, WCS, GunGame, etc)
<!--quoteo(post=1713795:date=Jun 24 2009, 04:07 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 04:07 PM) <a href="index.php?act=findpost&pid=1713795"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Not mods like you are thinking of, but there have been many plugins that drastically change gameplay (CSSDM, WCS, GunGame, etc)<!--QuoteEnd--></div><!--QuoteEEnd-->
So, before there was a bit of a line between plugins and more traditional mods, right? I'm not sure what people wrote stuff like CSSDM in, I'm guessing C++ using game dll hooks somehow rather than compiling the game dll itself, but the key word here is <i>guessing</i>.
As puzl has pointed out earlier, though, it would appear that the traditional mods and the plugins will be essentially the same thing with NS2, or at least use the same development and distribution designs and technologies. Does this change the equation at all?
My experience with LUA has so far been modding the DOW2 game. And well I have done nothing more then simple war gear adding, and Reading through most of the missions, I think how they did it there was a good idea.
All Lua that the game uses should be in some sort of zip or 7z package. I don't care if they use raw code or not, but seeing how all of DOW2 has raw LUA, I don't think it slows it down much.
A zip or 7z file of the raw lua is much smaller then Lua files themselves, and a lot faster to run a CRC/MD5 verification on, as there is overheard from both size and file numbers. This would allow for both verification that users all have the same mods installed, and that they did not change anything.
As for requiring that modders release source code, well, It is really up to the Devs, as this game will be moddable right from the start, and I don't think the layer of compiled code will add much to making the code unchangeable/hacked. If you want that you want the game to run a CRC/MD5 on each client. Ideally you want to send a random string that has to be added into the CRC generator, in the game, so that they can't lie as easy, as the CRC will change every time to a known CRC that is random. It a lot harder to fake a CRC that is randomly generated on the fly from a random data stream + the real data stream. At least what I think I know of CRC will cause that, as they have to pad false data to get the CRC, adding new data will require more false data of a different type. Breaking the Send back correct CRC, and the pad with data to make this CRC look correct problems.
Then again do you really need such a system in CAL?
<!--quoteo(post=1713800:date=Jun 24 2009, 02:28 PM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Jun 24 2009, 02:28 PM) <a href="index.php?act=findpost&pid=1713800"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Anyway on topic. If LUA has easy decompilbility, its probably better to have source plugins. Unless it would bring speed benefit of course.
I can definitely understand the philosophy of LGPL. Don't get me wrong. I think releasing source code is a good thing in general.<!--QuoteEnd--></div><!--QuoteEEnd-->
Just completed my testing with two available decompilers.
Heres the code I started with <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function quadratic() print ("Enter the coefficients-") print ("Enter a:") a=io.read() print ("Enter b:") b=io.read() print ("Enter c:") c=io.read()
d=b*b-4*a*c --finds the discriminant
if d>0 then --when discriminant is positive x=((-b)+math.sqrt(d))/(2*a) y=((-b)-math.sqrt(d))/(2*a) print ("the roots are",x," and",y)
elseif d==0 then --when discriminant is zero x=(-b)/(2*a) y=(-b)/(2*a) print ("the roots are",x," and",y)
else --when discriminant is negative x=(-b)/(2*a) y=(math.sqrt(d*(-1)))/(2*a) print ("the roots are",x," and",y) end end<!--c2--></div><!--ec2-->
I compiled the code, then ran it through both decompilers. Heres the de-compilation from the better of the two.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->quadratic = function() print("Enter the coefficients-") print("Enter a:") a = io.read() print("Enter b:") b = io.read() print("Enter c:") c = io.read() d = b * b - 4 * a * c if d > 0 then x = (-b + math.sqrt(d)) / (2 * a) y = (-b - math.sqrt(d)) / (2 * a) print("the roots are", x, " and", y) elseif d == 0 then x = -b / (2 * a) y = -b / (2 * a) print("the roots are", x, " and", y) else x = -b / (2 * a) y = math.sqrt(d * -1) / (2 * a) print("the roots are", x, " and", y) end end<!--c2--></div><!--ec2-->
I find that LUA compilation for the purposes of security completely useless.
edit: On a side note: the compiled lua script was 1.21Kb, while the uncompiled script was 809 bytes
Thanks flying_moose, then there's definitely not a security benefit from the compiled code in LUA.
Eternity_lost, I'm obviously no NS developer here, but I thought the server-side scripts were not uploaded to the client (only assets like models) or did I miss your point?
Don't the compiled plugins bring a speed benefit btw?
The way I understand it, Lua compiles the scripts at runtime so technically thats the only part of the process your speeding up. Thus. compiled scripts do indeed benefit from SPEED OF LOADING - ie: they loaded faster into memory, but they should then run at the same speed.
and I HOPE that server-side scripts wont need to be uploaded to the client.
<!--quoteo(post=1713876:date=Jun 25 2009, 12:25 AM:name=Dalin Seivewright)--><div class='quotetop'>QUOTE (Dalin Seivewright @ Jun 25 2009, 12:25 AM) <a href="index.php?act=findpost&pid=1713876"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Flying_Moose: Did you use the -s option on luac to strip the the byte code of debug information?<!--QuoteEnd--></div><!--QuoteEEnd-->
Results in 782bytes - nice find. (Still decompiles fine)
Did another test on a much larger lua script (86Kb), compile with -s results in 43.8Kb
Hmph. Here's the man page for luac: <a href="http://www.lua.org/manual/3.2/luac.html" target="_blank">http://www.lua.org/manual/3.2/luac.html</a>
I venture a guess that in its binary format, it doesn't translate programmer's identifiers to its own symbols like a c compiler would do. That's the only way I can figure that you get back out "function Quadratic" instead of "function F_SYM_1" or something even more cryptic.
I could annoy you / your decompiler by running my lua script trough an obfuscater first :P However, the argument that bytecode distribution offers speed advantages is void. If UWE isn't stupid, they will implement a simple caching mechanism, that all scripts get compiled once and the optimized/stripped bytecode gets deployed in a cache folder for faster load up next time. Until the engine detects that the source file is newer than the cache.
Btw, depending on the amount of lua files, compiling/parsing can affect performance, for a couple of seconds in the loading phase.
<!--quoteo(post=1713850:date=Jun 24 2009, 09:25 PM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Jun 24 2009, 09:25 PM) <a href="index.php?act=findpost&pid=1713850"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Thanks flying_moose, then there's definitely not a security benefit from the compiled code in LUA.
Eternity_lost, I'm obviously no NS developer here, but I thought the server-side scripts were not uploaded to the client (only assets like models) or did I miss your point?
Don't the compiled plugins bring a speed benefit btw?
Now I really don't care either way.<!--QuoteEnd--></div><!--QuoteEEnd-->
That part really depends on exactly what the engine supports by default.
The Half-life engine supports servers running commands on clients, and that is what the what the current Plug in uses, to tell clients to take screen shots and what not.
Now I do expect NS2 to support something along this lines, although I would like it to be more of the run this plug in, then a do these commands type of thing, at least then you can block known bad plugins on the user side. Who after all would like to join a server that makes you run a plugin that erases all your binding when you die.
Granted you need to be running the same game changing plugins as the server, with I hope a mod manager of some kind, maybe a only load these plugins when you connect so you have a passive mod manager system. That would be nice, decide you want to play co, just connect to a server and it downloads the mod for you, and does not touch anything else, and you then just need to connect to a co server to play, and if you go to classic server, it just unloads all co plugins there are.
There are known ways to verify machines that are all running the same version of a script ( something that the devs have to do so you don't get server client mismatches. ) This is done often by a hash method in most games, and is simple just to make sure both clients have the same version and mods installed.
A hash of the file, should be unique, but like all hashes that are a fix size, and do not also include file size, there is a possibility to have a collision, namely a file that has the same hash as another but is not bit identical.
But when you add a small random bit of data before you hash it, the odds that someone has a working fake plug in with the same hash/lies what hash it has, becomes even harder because this hash if done with a good algorithm, as the even one bit off should cause massive changes in the hash, that is why they use it for file verification.
Basically the main point here is that there is lots of well know methods to make sure files are correct, just about any OS has some in them, even windows although it a bit hidden from the user, I have got CRC errors on a hard drive that was then determined to be going bad, and quite a few of the p2p systems I looked at do a hashing of files to make sure you get the right file. And making sure that everyone is running the same plug in is not hard at all, and with a little effort you can make it very hard for someone to make a fake plug in or lie about what they got.
LUA uses a Just in time compiler, so the first time the file is load per game session it might have a slight delay, but like I said, in DOW2 that uses LUA for every mission and a lot of the underlying system, I do not notice a thing differnt in loading time over a game that does not, in fact it loads faster on my system then most games.
<!--quoteo(post=1713923:date=Jun 25 2009, 01:21 PM:name=Eternaly_Lost)--><div class='quotetop'>QUOTE (Eternaly_Lost @ Jun 25 2009, 01:21 PM) <a href="index.php?act=findpost&pid=1713923"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->LUA uses a Just in time compiler<!--QuoteEnd--></div><!--QuoteEEnd-->
<weisenheimer-mode: on> No, it doesn't. Lua is interpreted to byte code which is then executed on a simple stack based machine. But there is also an implementation of lua with JIT: <a href="http://luajit.org/luajit_features.html" target="_blank">http://luajit.org/luajit_features.html</a> <weisenheimer-mode: off>
I know that you mean that Lua is interpreted "Just in time" in terms of "the source files will be translated when they are needed" ;)
Ok at this point in time i think i should say the thing know one want's to believe... They should of used C# for scripting. It's like java and it executes almost at the speed of C++, and sometimes surpasses it. For the windows version they could of binded to the actual .net framework and it'd fun fast as hell. And yes you can unload assemblies that are loaded into memory. If i can figure that out then they can. And for the weird ports to other non microsoft platforms they could use some opensource virtual machine like mono and get almost the same performance.
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.
<!--quoteo(post=1714296:date=Jun 27 2009, 03:44 AM:name=FocusedWolf)--><div class='quotetop'>QUOTE (FocusedWolf @ Jun 27 2009, 03:44 AM) <a href="index.php?act=findpost&pid=1714296"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ok at this point in time i think i should say the thing know one want's to believe... They should of used C# for scripting. It's like java and it executes almost at the speed of C++, and sometimes surpasses it. For the windows version they could of binded to the actual .net framework and it'd fun fast as hell. And yes you can unload assemblies that are loaded into memory. If i can figure that out then they can. And for the weird ports to other non microsoft platforms they could use some opensource virtual machine like mono and get almost the same performance.
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.<!--QuoteEnd--></div><!--QuoteEEnd-->
Except those aren't really scripting languages. The fun thing about LUA is that you don't even need a compiler to make changes to the game. This way, it's not a requirement to buy hundreds of dollars of IDE from Microsoft or use some crappy 3rd party tool, or something even more dastardly just to mod the game.
Now, if you want to start a new Windows only project, C#'s a major contender. Despite its (I think, anyway) over reliance on OOP, it's got a HUGE library of capabilities through .Net. As you said there are things like Mono for other platforms, but they focus on only specific parts of the API (gui especially). Major parts of functionality you have in Windows won't be in Mono, and you'll be forced to go to the least common denomiator.
<!--quoteo(post=1714327:date=Jun 27 2009, 05:43 AM:name=Rob)--><div class='quotetop'>QUOTE (Rob @ Jun 27 2009, 05:43 AM) <a href="index.php?act=findpost&pid=1714327"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Except those aren't really scripting languages. The fun thing about LUA is that you don't even need a compiler to make changes to the game. This way, it's not a requirement to buy hundreds of dollars of IDE from Microsoft or use some crappy 3rd party tool, or something even more dastardly just to mod the game.<!--QuoteEnd--></div><!--QuoteEEnd--> Actually FocusedWolf is right in that C# can be executed as script with ease. Also no hundred dollar tool would be required. C# Express is a free IDE from Microsoft that is only missing a few features from the full IDE, and anyone who's still in college can pick up the full Visual Studio 2008 IDE for free.
However he's still wrong because he cant bother to spell check his posts for grammar/spelling even though the forum has a built in spelling checker.
Edit: (Also introducing something as powerful as C# into an addon system like this could be dangerous. Many people install addons onto their server without verifying that the source-code wont do anything harmful, and C# is MUCH more dangerous in that respect then LUA)
Currently the forums are bugged. Many (if not all) shouldn't have access to the built in spell checker let alone the formatting options. We can use BBCodes manually still of course. Also, edits/replies at least for me, show all line break HTML tags, which if they aren't replaced manually, show up as text in the actual post.
Anyways, Lua is just as dangerous as C# is. They should be run in a sandbox environment which protects the OS from maliscious intent, for example, we shouldn't be able to access the filesystem from Lua's built in functions, but we should have to use a filesystem implementation from the devs that would only allow us to access certain folders such as the games directory.
As far as C# goes, without the .NET Framework, it is practically the same thing as Java and likewise for Javas libraries. Any language can be used in a script form, for the case of C#, the .NET Framework would have to be removed because AFAIK, it isn't cross-platform compliant at all (hence the Mono project). For the case of Java, I have to say when I worked with it initially, I really enjoyed it. Using it as a scripting language for a game thought would be IMO, a mistake. Firstly, it would probably have to be stripped down severely. If the scripting language consisted of only a language that had the same syntax as Java, then there wouldn't be any point on calling it Java. The Java libraries have a lot of crap in it that would go unused and thus would take up useful space. Judging by <a href="http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=luajit&lang2=luajit&box=1" target="_blank">this benchmark site</a> it appears that Java 6 (client) may be faster than Lua, but I think the general friendliness, syntax, and power from Lua outweight this speed.
C# is good for amateur/enterprise apps, perhaps game engines and handling ASP.NET pages. C# as a scripting language, I really don't see as working very well - and besides, as previously mentioned C# is basically just another way to use the .NET Framework. Nothing more. Visual Studio is merely decent. Its just another product that people wanted 1000 features in, and it wasn't pulled off very well. Its slow and I think it forces programmers to develop an unhealthy requirement for "fully-featured" IDEs. Sure, you can debug C# in VS and sure its free with the Express versions, but it is nothing compared to even a basic notepad with command-line built-in and syntax highlighting.
To sum it up, Lua is small, powerful, beautiful (in the sense that you can do amazing things with it very quickly) and doesn't suffer from "What part of the Framework was that method in again? I know, I'll just use IntelliSense and waste more of my valuable time!" syndrome. The only downside to Lua I have found is that games that implement it as their scripting language, likely don't implement a debugger as well. NS2 has a version of Decoda bundled with it, AFAIK, so there is that.
If people want to obscure logic, they'll likely be able to do it even if NS2 only loads Lua source.
In order for NS2+Lua to be useful, it'll need to leave in support for loading (typically C-written) libraries as modules, or at least offer its own basic networking/HTTP/SQL/etc. interface (unlikely). Either way, logic can get moved out to somewhere obscured whether via a library or networking support.
Licensing is also going to nullify a bit of forcing loading of the source only. I can understand the security viewpoint, but NS2 could feature basic security settings per-script/plugin to avoid issues with any in-game file I/O library or compiled library loading (default to restrictive, force server config modification to expand script permissions). As it is, novice/naive coders would borrow from other scripts that already have licensing that prohibit modification or replication.
I will not be surprised if NS2 supports loading of source-only anyway, since it keeps everyone on the same page (and defaulting to "open" may be a good idea, even if it's easy to get around).
devicenullJoin Date: 2003-04-30Member: 15967Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1714296:date=Jun 27 2009, 03:44 AM:name=FocusedWolf)--><div class='quotetop'>QUOTE (FocusedWolf @ Jun 27 2009, 03:44 AM) <a href="index.php?act=findpost&pid=1714296"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ok at this point in time i think i should say the thing know one want's to believe... They should of used C# for scripting. It's like java and it executes almost at the speed of C++, and sometimes surpasses it. For the windows version they could of binded to the actual .net framework and it'd fun fast as hell. And yes you can unload assemblies that are loaded into memory. If i can figure that out then they can. And for the weird ports to other non microsoft platforms they could use some opensource virtual machine like mono and get almost the same performance.
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.<!--QuoteEnd--></div><!--QuoteEEnd-->
They should pick {insert favorite language} because it's {fast|easy|secure|clever|etc...}.
No matter what language is chosen, people will want it in another language. It's a fact of life. Lua is used successfully by many games, are you saying it's good enough for them, but not good enough for NS2?
There's no point arguing what scripting language they should use, because they've already chosen LUA and coded half the game with it. Besides, I think the devs have more than enough experience to make such a choice anyway.
Comments
You haven't heard of HexRays then (it can take a binary and translate it back into C code, it's not perfect but its better then assembly)
@puzl: You are entirely correct, if this is an amxmodx plugin you are legally required to release the source code to it. This is not something that you can say "oh I don't want to, to keep it secure", you *must* release the code.
@Jiriki: Congrats on breaking the GPL. This is not optional. I've had to explain to many people why if they release a Amxmodx plugin, they are legally required to release the source. I hope I don't have to do it again.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->formatex(md5input[141],140,"%s%s%s","9WvcZ9hX",input[251],"KF7L4luQ")<!--c2--></div><!--ec2-->
*gasp* What could that be! I hope that's not your checksumming method, that adds "9WvcZ9hX" to the beginning of the data, "KF7L4luQ" to the end, then md5's it!
Well, I totally understand your concern from the point of security. (if you could compromise server administration and such, for example) But your posts sounds somehow like "Weehh, I want to look, copy & paste from other mods". I'm going to script for NS2 too, as soon as it arrives, but since my scripts will be server-side only (to be able to offer some unique game server :)), I don't really care. Depending on what kind of damage/fraud could be done from within a script, of course.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't copy code from other people. I've already started writing lua addons for ns2 :p My point is, there are many people new to coding plugins that start off by copying code. I consider this to be important for people to learn.
@JazzX: I used to be on irc when I actually played NS.. and now I'm back on it :D Indeed, compiled lua plugins provide virtually no security. Compiled amxmodx plugins provide a little more, but not a whole lot (as you can see in my previous post)
I wouldn't have a problem with UWE requiring modifications to be Free or Open Source or just a subset(like administrative plugins don't alter gameplay). Realistically, I doubt total conversion mods(and by extension mods that alter gameplay) would be required to release source code considering this is how UWE got its start.
I'd like to see Free or Open Source requirements for NS2 mods as an experiment. It'd be interesting to see what develops as the code repository grows, but I'd be naive if I didn't think it would scare a lot of developers of larger projects off. I just wonder if the collaborative effort of Open Source or Free software would allow for larger projects to grow in a modding community like it does in other software industry areas.
I occasionally do this. I read assembler FOR FUN. Usually something I wrote myself, but there is numerous exceptions.
I do see that distributing binaries might give someone a false sense of security (Indeed, I believe this thread features a stunningly excellent example), but I believe that should be coped with through education rather than legislation. Making rules won't prevent people being misinformed, what Lua features should we disable to prevent people from writing exploitable database code?
<!--quoteo(post=0:date=Jun 24 2009, 06:38 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 06:38 PM)</div><div class='quotemain'><!--quotec-->I don't copy code from other people. I've already started writing lua addons for ns2 :p My point is, there are many people new to coding plugins that start off by copying code. I consider this to be important for people to learn.<!--QuoteEnd--></div><!--QuoteEEnd-->
Why do you believe that there will be a shortage of open source code to copy from, even if binaries are accepted by the engine? Do you think people will chose to distribute binaries by default if given the option?
<!--quoteo(post=0:date=Jun 24 2009, 06:38 PM:name=devicenull)--><div class='quotetop'>QUOTE (devicenull @ Jun 24 2009, 06:38 PM)</div><div class='quotemain'><!--quotec-->Indeed, compiled lua plugins provide virtually no security. Compiled amxmodx plugins provide a little more, but not a whole lot (as you can see in my previous post)<!--QuoteEnd--></div><!--QuoteEEnd-->
I agree, but aren't you undermining the "what if the source got lost" argument? You are saying that Lua code is easy to decompile, so it provides no security. Yet, it's too hard to decompile to make recovering sources feasible?
Edit: Spelling - removed some errors, introduced some new.
Yes I know. Guilty on all accounts. Actually I haven't bothered / remembered (I haven't thought about in a year) to get the exception because currently so few people use it outside our own servers. I think its zero now. If I would get any complaints from AMXX staff, I would either remove it or get an exception. Also the guys who made some kind of anti-cheat plugin got an exception, just for security reasons.
Besides the plugin is a continuation from CALns plugin by JazzX. I don't think it was banned by AMXX devs.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->But putting that aside, if you depend on it being difficult to decompile a plugin for its operation then you have some major issues in your assumptions.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not depending on it. It's to limit the damage. We have multi clanning rules, but anyone could use package forwarding and swapping steam accounts, but that doesn't mean multi clanning rules are useless.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Even compiled binaries are easy to decompile, maybe not into easily readable C code, but the very existence of metamod demonstrates that even fully compiled programs
are not free from inspection by users. Your example of DRM does nothing to support your premise, in fact it undermines it deeply.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nobody said it was "free" from inspection. Anyone could really reverse-engineer HL client, the whole game, but the fact is, its a lot harder when there is no source available. VAC doesn't stop all cheats, in fact, client security can never be 100%, but it doesn't make it useless.
Similarly a metal lock in a bicycle won't stop a thief who has a van or steel saw but that doesn't mean locks for bicycles are useless.
Are you also saying releasing NS1 source code wouldn't make it easier to find abusable bugs?
Correct.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I wouldn't have a problem with UWE requiring modifications to be Free or Open Source or just a subset(like administrative plugins don't alter gameplay). Realistically, I doubt total conversion mods(and by extension mods that alter gameplay) would be required to release source code considering this is how UWE got its start.
I'd like to see Free or Open Source requirements for NS2 mods as an experiment. It'd be interesting to see what develops as the code repository grows, but I'd be naive if I didn't think it would scare a lot of developers of larger projects off. I just wonder if the collaborative effort of Open Source or Free software would allow for larger projects to grow in a modding community like it does in other software industry areas.<!--QuoteEnd--></div><!--QuoteEEnd-->
Requiring the source to be open has not scared people off of making large gameplay changes for HL1/HL2, why would it stop it in NS2? I'd assume that anyone making a mod large enough to license the engine will be allowed to do what they want.
<!--quoteo(post=1713781:date=Jun 24 2009, 03:08 PM:name=Private)--><div class='quotetop'>QUOTE (Private @ Jun 24 2009, 03:08 PM) <a href="index.php?act=findpost&pid=1713781"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why do you believe that there will be a shortage of open source code to copy from, even if binaries are accepted by the engine? Do you think people will chose to distribute binaries by default if given the option?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I do. I've seen it happen in other games (Go try to find the source code for any of the popular COD4 mods, or basically anything in this series)
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I agree, but aren't you undermining the "what if the source got lost" argument? You are saying that Lua code is easy to decompile, so it provides no security. Yet, it's too hard to decompile to make recovering sources feasible?<!--QuoteEnd--></div><!--QuoteEEnd-->
As an example, the amxmodx plugin was easily decompiled, but it's not in a state where I can easily recompile it.. I basically have a list of assembly instructions, with some enhanced comments showing me functions/variable names. It's not enough to easily rebuild the plugin from scratch. I'm unsure of how the lua decompiler works.. I have no idea of the quality of the code it produces.
<!--QuoteBegin-Jiriki+--><div class='quotetop'>QUOTE (Jiriki)</div><div class='quotemain'><!--QuoteEBegin-->Yes I know.<!--QuoteEnd--></div><!--QuoteEEnd-->
So I'm mystified as to why you didn't release the source.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Nobody said it was "free" from inspection. Anyone could really reverse-engineer HL client, the whole game, but the fact is, its a lot harder when there is no source available. VAC doesn't stop all cheats, in fact, client security can never be 100%, but it doesn't make it useless.
Similarly a metal lock in a bicycle won't stop a thief who has a van or steel saw but that doesn't mean locks for bicycles are useless.<!--QuoteEnd--></div><!--QuoteEEnd-->
Right, but when you can strip the protection as easily as running a freely available program, it makes it useless. And be sure if NS2 allows compiled plugins I will make a website allowing you to upload a plugin and have it decompiled.
I'm confused. Are you saying you can get the source from any HL1/HL2 mod?
Not mods like you are thinking of, but there have been many plugins that drastically change gameplay (CSSDM, WCS, GunGame, etc)
I can definitely understand the philosophy of LGPL. Don't get me wrong. I think releasing source code is a good thing in general.
So, before there was a bit of a line between plugins and more traditional mods, right? I'm not sure what people wrote stuff like CSSDM in, I'm guessing C++ using game dll hooks somehow rather than compiling the game dll itself, but the key word here is <i>guessing</i>.
As puzl has pointed out earlier, though, it would appear that the traditional mods and the plugins will be essentially the same thing with NS2, or at least use the same development and distribution designs and technologies. Does this change the equation at all?
All Lua that the game uses should be in some sort of zip or 7z package. I don't care if they use raw code or not, but seeing how all of DOW2 has raw LUA, I don't think it slows it down much.
A zip or 7z file of the raw lua is much smaller then Lua files themselves, and a lot faster to run a CRC/MD5 verification on, as there is overheard from both size and file numbers. This would allow for both verification that users all have the same mods installed, and that they did not change anything.
As for requiring that modders release source code, well, It is really up to the Devs, as this game will be moddable right from the start, and I don't think the layer of compiled code will add much to making the code unchangeable/hacked. If you want that you want the game to run a CRC/MD5 on each client. Ideally you want to send a random string that has to be added into the CRC generator, in the game, so that they can't lie as easy, as the CRC will change every time to a known CRC that is random. It a lot harder to fake a CRC that is randomly generated on the fly from a random data stream + the real data stream. At least what I think I know of CRC will cause that, as they have to pad false data to get the CRC, adding new data will require more false data of a different type. Breaking the Send back correct CRC, and the pad with data to make this CRC look correct problems.
Then again do you really need such a system in CAL?
I can definitely understand the philosophy of LGPL. Don't get me wrong. I think releasing source code is a good thing in general.<!--QuoteEnd--></div><!--QuoteEEnd-->
Just completed my testing with two available decompilers.
Heres the code I started with
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function quadratic()
print ("Enter the coefficients-")
print ("Enter a:")
a=io.read()
print ("Enter b:")
b=io.read()
print ("Enter c:")
c=io.read()
d=b*b-4*a*c --finds the discriminant
if d>0 then --when discriminant is positive
x=((-b)+math.sqrt(d))/(2*a)
y=((-b)-math.sqrt(d))/(2*a)
print ("the roots are",x," and",y)
elseif d==0 then --when discriminant is zero
x=(-b)/(2*a)
y=(-b)/(2*a)
print ("the roots are",x," and",y)
else --when discriminant is negative
x=(-b)/(2*a)
y=(math.sqrt(d*(-1)))/(2*a)
print ("the roots are",x," and",y)
end
end<!--c2--></div><!--ec2-->
I compiled the code, then ran it through both decompilers. Heres the de-compilation from the better of the two.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->quadratic = function()
print("Enter the coefficients-")
print("Enter a:")
a = io.read()
print("Enter b:")
b = io.read()
print("Enter c:")
c = io.read()
d = b * b - 4 * a * c
if d > 0 then
x = (-b + math.sqrt(d)) / (2 * a)
y = (-b - math.sqrt(d)) / (2 * a)
print("the roots are", x, " and", y)
elseif d == 0 then
x = -b / (2 * a)
y = -b / (2 * a)
print("the roots are", x, " and", y)
else
x = -b / (2 * a)
y = math.sqrt(d * -1) / (2 * a)
print("the roots are", x, " and", y)
end
end<!--c2--></div><!--ec2-->
I find that LUA compilation for the purposes of security completely useless.
edit:
On a side note: the compiled lua script was 1.21Kb, while the uncompiled script was 809 bytes
Eternity_lost, I'm obviously no NS developer here, but I thought the server-side scripts were not uploaded to the client (only assets like models) or did I miss your point?
Don't the compiled plugins bring a speed benefit btw?
Now I really don't care either way.
Thus. compiled scripts do indeed benefit from SPEED OF LOADING - ie: they loaded faster into memory, but they should then run at the same speed.
and I HOPE that server-side scripts wont need to be uploaded to the client.
Results in 782bytes - nice find. (Still decompiles fine)
Did another test on a much larger lua script (86Kb), compile with -s results in 43.8Kb
I venture a guess that in its binary format, it doesn't translate programmer's identifiers to its own symbols like a c compiler would do. That's the only way I can figure that you get back out "function Quadratic" instead of "function F_SYM_1" or something even more cryptic.
Btw, depending on the amount of lua files, compiling/parsing can affect performance, for a couple of seconds in the loading phase.
Eternity_lost, I'm obviously no NS developer here, but I thought the server-side scripts were not uploaded to the client (only assets like models) or did I miss your point?
Don't the compiled plugins bring a speed benefit btw?
Now I really don't care either way.<!--QuoteEnd--></div><!--QuoteEEnd-->
That part really depends on exactly what the engine supports by default.
The Half-life engine supports servers running commands on clients, and that is what the what the current Plug in uses, to tell clients to take screen shots and what not.
Now I do expect NS2 to support something along this lines, although I would like it to be more of the run this plug in, then a do these commands type of thing, at least then you can block known bad plugins on the user side. Who after all would like to join a server that makes you run a plugin that erases all your binding when you die.
Granted you need to be running the same game changing plugins as the server, with I hope a mod manager of some kind, maybe a only load these plugins when you connect so you have a passive mod manager system. That would be nice, decide you want to play co, just connect to a server and it downloads the mod for you, and does not touch anything else, and you then just need to connect to a co server to play, and if you go to classic server, it just unloads all co plugins there are.
There are known ways to verify machines that are all running the same version of a script ( something that the devs have to do so you don't get server client mismatches. ) This is done often by a hash method in most games, and is simple just to make sure both clients have the same version and mods installed.
A hash of the file, should be unique, but like all hashes that are a fix size, and do not also include file size, there is a possibility to have a collision, namely a file that has the same hash as another but is not bit identical.
But when you add a small random bit of data before you hash it, the odds that someone has a working fake plug in with the same hash/lies what hash it has, becomes even harder because this hash if done with a good algorithm, as the even one bit off should cause massive changes in the hash, that is why they use it for file verification.
Basically the main point here is that there is lots of well know methods to make sure files are correct, just about any OS has some in them, even windows although it a bit hidden from the user, I have got CRC errors on a hard drive that was then determined to be going bad, and quite a few of the p2p systems I looked at do a hashing of files to make sure you get the right file. And making sure that everyone is running the same plug in is not hard at all, and with a little effort you can make it very hard for someone to make a fake plug in or lie about what they got.
LUA uses a Just in time compiler, so the first time the file is load per game session it might have a slight delay, but like I said, in DOW2 that uses LUA for every mission and a lot of the underlying system, I do not notice a thing differnt in loading time over a game that does not, in fact it loads faster on my system then most games.
<weisenheimer-mode: on>
No, it doesn't. Lua is interpreted to byte code which is then executed on a simple stack based machine. But there is also an implementation of lua with JIT: <a href="http://luajit.org/luajit_features.html" target="_blank">http://luajit.org/luajit_features.html</a>
<weisenheimer-mode: off>
I know that you mean that Lua is interpreted "Just in time" in terms of "the source files will be translated when they are needed" ;)
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.<!--QuoteEnd--></div><!--QuoteEEnd-->
Except those aren't really scripting languages. The fun thing about LUA is that you don't even need a compiler to make changes to the game. This way, it's not a requirement to buy hundreds of dollars of IDE from Microsoft or use some crappy 3rd party tool, or something even more dastardly just to mod the game.
Now, if you want to start a new Windows only project, C#'s a major contender. Despite its (I think, anyway) over reliance on OOP, it's got a HUGE library of capabilities through .Net. As you said there are things like Mono for other platforms, but they focus on only specific parts of the API (gui especially). Major parts of functionality you have in Windows won't be in Mono, and you'll be forced to go to the least common denomiator.
Actually FocusedWolf is right in that C# can be executed as script with ease.
Also no hundred dollar tool would be required. C# Express is a free IDE from Microsoft that is only missing a few features from the full IDE, and anyone who's still in college can pick up the full Visual Studio 2008 IDE for free.
However he's still wrong because he cant bother to spell check his posts for grammar/spelling even though the forum has a built in spelling checker.
Edit:
(Also introducing something as powerful as C# into an addon system like this could be dangerous. Many people install addons onto their server without verifying that the source-code wont do anything harmful, and C# is MUCH more dangerous in that respect then LUA)
Anyways, Lua is just as dangerous as C# is. They should be run in a sandbox environment which protects the OS from maliscious intent, for example, we shouldn't be able to access the filesystem from Lua's built in functions, but we should have to use a filesystem implementation from the devs that would only allow us to access certain folders such as the games directory.
As far as C# goes, without the .NET Framework, it is practically the same thing as Java and likewise for Javas libraries. Any language can be used in a script form, for the case of C#, the .NET Framework would have to be removed because AFAIK, it isn't cross-platform compliant at all (hence the Mono project). For the case of Java, I have to say when I worked with it initially, I really enjoyed it. Using it as a scripting language for a game thought would be IMO, a mistake. Firstly, it would probably have to be stripped down severely. If the scripting language consisted of only a language that had the same syntax as Java, then there wouldn't be any point on calling it Java. The Java libraries have a lot of crap in it that would go unused and thus would take up useful space. Judging by <a href="http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=luajit&lang2=luajit&box=1" target="_blank">this benchmark site</a> it appears that Java 6 (client) may be faster than Lua, but I think the general friendliness, syntax, and power from Lua outweight this speed.
C# is good for amateur/enterprise apps, perhaps game engines and handling ASP.NET pages. C# as a scripting language, I really don't see as working very well - and besides, as previously mentioned C# is basically just another way to use the .NET Framework. Nothing more. Visual Studio is merely decent. Its just another product that people wanted 1000 features in, and it wasn't pulled off very well. Its slow and I think it forces programmers to develop an unhealthy requirement for "fully-featured" IDEs. Sure, you can debug C# in VS and sure its free with the Express versions, but it is nothing compared to even a basic notepad with command-line built-in and syntax highlighting.
To sum it up, Lua is small, powerful, beautiful (in the sense that you can do amazing things with it very quickly) and doesn't suffer from "What part of the Framework was that method in again? I know, I'll just use IntelliSense and waste more of my valuable time!" syndrome. The only downside to Lua I have found is that games that implement it as their scripting language, likely don't implement a debugger as well. NS2 has a version of Decoda bundled with it, AFAIK, so there is that.
In order for NS2+Lua to be useful, it'll need to leave in support for loading (typically C-written) libraries as modules, or at least offer its own basic networking/HTTP/SQL/etc. interface (unlikely). Either way, logic can get moved out to somewhere obscured whether via a library or networking support.
Licensing is also going to nullify a bit of forcing loading of the source only. I can understand the security viewpoint, but NS2 could feature basic security settings per-script/plugin to avoid issues with any in-game file I/O library or compiled library loading (default to restrictive, force server config modification to expand script permissions). As it is, novice/naive coders would borrow from other scripts that already have licensing that prohibit modification or replication.
I will not be surprised if NS2 supports loading of source-only anyway, since it keeps everyone on the same page (and defaulting to "open" may be a good idea, even if it's easy to get around).
And ya... "Decoda" which came about because the sheer lack of a good lua development IDE... well that wasn't needed... sorry... C# and visual studio 2008 ftw. Theirs even the express versions of visual studio that are free to download... The devs should of put a little thought into this... I'm even sure java would of made a fine scripting interface for the engine.<!--QuoteEnd--></div><!--QuoteEEnd-->
They should pick {insert favorite language} because it's {fast|easy|secure|clever|etc...}.
No matter what language is chosen, people will want it in another language. It's a fact of life. Lua is used successfully by many games, are you saying it's good enough for them, but not good enough for NS2?