Blog update - Client-side scripting and weapons

MaxMax Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
edited June 2007 in NS2 General Discussion
Please post your thoughts on the <a href="http://www.unknownworlds.com/blog/2007/06/clientside_scripting_and_weapo_1.html" target="_blank">latest blog entry</a> here.

By the way, the weapon silhouettes you see in the blog entry are the more organic redesigns I mentioned back in <a href="http://www.unknownworlds.com/forums/index.php?s=5244000514606742528&showtopic=101138" target="_blank">this thread</a>.
«1

Comments

  • KungFuDiscoMonkeyKungFuDiscoMonkey Creator of ns_altair 日本福岡県 Join Date: 2003-03-15 Member: 14555Members, NS1 Playtester, Reinforced - Onos
    Some people might be waiting for the shiny pictures and such, but I'm really enjoying these article about how everything works (though I don't mind the pretty pictures).
  • PastryTheftPastryTheft Join Date: 2006-12-28 Member: 59290Members
    <!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Right now we're at the stage where we've got our scripted entities hooked into the core network system<!--QuoteEnd--></div><!--QuoteEEnd-->

    all of them? <img src="style_emoticons/<#EMO_DIR#>/wow.gif" style="vertical-align:middle" emoid=":0" border="0" alt="wow.gif" /> wow


    and like that green gun =)
  • paradox_42paradox_42 Join Date: 2007-06-19 Member: 61309Members
    edited June 2007
    Great stuff, love these posts.

    These client side scripts how are they controlled? I’m just thinking about how cheat proof these scripts are. If anyone can change there client scripts wouldn’t this be a problem?

    Again love these dev posts, keep up the good work <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
  • cerberus414cerberus414 Join Date: 2005-05-07 Member: 51098Members, Constellation, Reinforced - Shadow
    It's actually funny, because I completely understood what Max was talking about. Right now I'm reading the wiki that he was refering to, and that also makes sense. I find this topic very interesting and will explore further. Thanks for the beefy update. Keep 'em coming!
  • TychoCelchuuuTychoCelchuuu Anememone Join Date: 2002-03-23 Member: 345Members
    <!--quoteo(post=1634695:date=Jun 19 2007, 06:34 PM:name=cerberus5)--><div class='quotetop'>QUOTE(cerberus5 @ Jun 19 2007, 06:34 PM) [snapback]1634695[/snapback]</div><div class='quotemain'><!--quotec-->
    It's actually funny, because I completely understood what Max was talking about.
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    I too find that hilarious!

    I like the bottom left gun in the second gun image. The stock is too long but the rest looks pretty neat.
  • HybridclawHybridclaw Join Date: 2003-11-03 Member: 22271Members
    I was hoping that the aliens would be the team that would get a flamethrower <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
    <img src="http://img.photobucket.com/albums/v354/hybridclaw/flamegorge.jpg" border="0" alt="IPB Image" />
  • schkorpioschkorpio I can mspaint Join Date: 2003-05-23 Member: 16635Members
    <!--quoteo(post=1634705:date=Jun 20 2007, 12:21 PM:name=Hybridclaw)--><div class='quotetop'>QUOTE(Hybridclaw @ Jun 20 2007, 12:21 PM) [snapback]1634705[/snapback]</div><div class='quotemain'><!--quotec-->
    I was hoping that the aliens would be the team that would get a flamethrower <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
    <img src="http://img.photobucket.com/albums/v354/hybridclaw/flamegorge.jpg" border="0" alt="IPB Image" />
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    LOL *burp*


    nice update max <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
  • ScrogneugneuScrogneugneu Join Date: 2007-01-05 Member: 59448Members
    I too was concerned about the script hack problem. If the client side scripted guns are telling the server how much ammo it has left in it's clip, and the server just nods and says "good, thanks for the info", we've got a serious problem. Anyone could make a script for some uber gun that would never run out of ammo and (while we're at it) kill in one bullet. Perhaps we missed a bit of how it works? Is there any security feature included in that, maybe like an option to exclude client-side scripts on a server, selectively (like, allow scripts for Command Console views and such, but do not allow scripts for weapons)?


    Dev posts are great. Although it might just be me, as I'm a programmer, so I kinda like the whole code idea from the beginning <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
  • WyzcrakWyzcrak Pot Pie Aficionado Join Date: 2002-12-04 Member: 10447Forum Moderators, Constellation, NS2 Playtester, Squad Five Blue
    Experience-modifying scripting has been one of my most satisfying returns as a consumer of NS (that's saying a lot, given how much I enjoy the game as a player). The combination of that LUA screenshot (client-side) and the recent advancement into "beta" status of <a href="http://sourcemod.net" target="_blank">SourceMod</a> (server-side) really has me excited about NS2 experience modifications. (Side question: I wonder.. with NS2 not technically a "mod" of HL2, will I be able to create server-side scripts for it using SourceMod? Is "mod" status relevant with something like SourceMod, or does SourceMod apply to anything on the Source engine? I lack both the answer and the time to investigate.)

    Many thanks for this additional look behind the scenes. These posts (discussions) are golden.

    On another note:
    <!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->With [our scripted entities hooked into the core network system], the engine will instantiate client-side versions of the entities when the server tells them they've come into the player's view.<!--QuoteEnd--></div><!--QuoteEEnd-->My machine isn't anything to write home about, and I always notice that my NS1 hiccups the first time I bring up my minimap after the game's started, or the first time I round a corner and see the first observatory my client loads. I know little about how all of this works, but my assumption is that the delay (negligible though it be) is due to the loading, during my gameplay, of certain models and sprites.

    So I ask: is it possible, in NS past or future, to load allllll of the sprites/models/scripts/etc while the map is loading? If not, why (too taxing on the box/network/somethingelse, maybe)?
  • GaidanGaidan Join Date: 2006-10-31 Member: 58132Members
    I too am interested in the client only scripting, does this mean everyone (absolutely everyone) has the option to customize their UI? And if so, to what degree are we talking here - because there are UI changes which are considered hacks (such as warnings as to when someone is reloading, health and even ETA to you). So the question really becomes, what changes are hacking, and what are considered normal.
  • AnimeLOLAnimeLOL Join Date: 2006-11-02 Member: 58275Members
    Great update Max, love the backstory. One question though: if everything is running as scripts and not as compiled code, will there be a slow-down as the script has to be dynamically converted to executions? All the opportunities that scripting allows for customization is great, but what is the cost in terms of system resources?
  • TychoCelchuuuTychoCelchuuu Anememone Join Date: 2002-03-23 Member: 345Members
    <!--quoteo(post=1634722:date=Jun 19 2007, 08:02 PM:name=AnimeLOL)--><div class='quotetop'>QUOTE(AnimeLOL @ Jun 19 2007, 08:02 PM) [snapback]1634722[/snapback]</div><div class='quotemain'><!--quotec-->
    Great update Max, love the backstory. One question though: if everything is running as scripts and not as compiled code, will there be a slow-down as the script has to be dynamically converted to executions? All the opportunities that scripting allows for customization is great, but what is the cost in terms of system resources?
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    No, the difference is that these scripts are written out the long way, which is what vanilla Source converts the macros in to when they are compiled. In this case the NS2 scripts aren't macros, they're the actual scripts.
  • ReeseReese Join Date: 2003-05-08 Member: 16143Members
    <!--quoteo(post=1634715:date=Jun 19 2007, 09:41 PM:name=Scrogneugneu)--><div class='quotetop'>QUOTE(Scrogneugneu @ Jun 19 2007, 09:41 PM) [snapback]1634715[/snapback]</div><div class='quotemain'><!--quotec-->
    I too was concerned about the script hack problem. If the client side scripted guns are telling the server how much ammo it has left in it's clip, and the server just nods and says "good, thanks for the info", we've got a serious problem. Anyone could make a script for some uber gun that would never run out of ammo and (while we're at it) kill in one bullet. Perhaps we missed a bit of how it works? Is there any security feature included in that, maybe like an option to exclude client-side scripts on a server, selectively (like, allow scripts for Command Console views and such, but do not allow scripts for weapons)?
    Dev posts are great. Although it might just be me, as I'm a programmer, so I kinda like the whole code idea from the beginning <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    The important part to remember is that the client's state and the server's state are maintained semi-independently with updates. Say the player starts shooting at a skulk, here is a breakdown of what happens:


    1) The client shows the gun firing, does hit detection based on the location of everything for the T amount of time the gun was fired in directions X, Y, and Z. It shows the green goo if it hits.

    2) The client sends a message to the server telling it that the user held the mouse for T amount of time while pointed in direction X, Y, Z.

    3) The server independently determines if firing for T time in X, Y, and Z would have hit something, and tells the client exactly what happened.

    4) The client updates what it is displaying to correspond with what the server is telling it. This is, at least most of the time, how people can shoot you around walls. Your client allowed you to move until the server decided you were dead, and by the time all that happened you had moved past the corner.

    Granted, it is probably a little more complicated than this, but that is generally how it works. It would be impossible to make an ubergun or infinite ammo client side as the client is only telling the server what the user did and trying to predict how the server would respond while it waits for an answer. The server is always firmly in charge, so there is no need to worry about it.
  • cerberus414cerberus414 Join Date: 2005-05-07 Member: 51098Members, Constellation, Reinforced - Shadow
    edited June 2007
    So is this where the differences between client-side hit detection vs server-side hit detection really shine? Most games I know are client side (all half life 1 mods and source games) but there are a few that aren't like Gears of War. I sorta know how each works but still sorta confused, lol. Can someone explain to me the pros and cons of each.

    The only thing I can think of is that with server-side hit detection, you see what is ACTUALLY happening. If you hide right around a corner, you for a fact know you won't get shot as opposed to client-side hit detection where it "predicts" and cause you to die even if you hide right around a corner. Am I right?

    EDIT: Read this, made lots of sense:
    <!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->
    Client-side - like HL, Doom, UT and others - means that it is your client (the part of the game that's running on your computer) that decides whether you hit or not. Your client takes the information it currently has (location of the enemies) and it sees if you shot at that location. If your client thinks you did, then it sends information to the server saying that you shot that target. This way, you don't lead targets due to network latency, since the detection is performed on your computer.

    With this method however, the server relies on the client (on your computer) to tell it whether you hit or not... and "altered" clients can fool the server and tell the server that you always hit. Hence the abundance of aimbots and "accuracy-hacks" for client-side-detection games.

    Server-side - Like BF42 and BFV - means that the server decides whether you scored a hit or not. The client on your computer doesn't tell the server that it hit the target. Instead, the client sends the information to the server specifying where you fired at. Then when the server receives that information, it is the server that checks whethere there is a target at that location or not. If there is a target, then the server registers the hit, and sends you "feeback" (the flashing crosshair) indicating that it had registered the hit.

    Problem with this method is that it takes time before the information of where you fired at reaches the server (unlike client-side where the detection happens directly on the client), so when you fired at coordinate, say 10, because the target was at coordinate 10, by the time this information reached the server (your ping time), the target may have moved to coordinate 11, and the server will think that you missed. Hence with server-side hit-detection, you had to lead ahead, account for this delay that takes time for the transfer of information. So, the higher your ping, the more you have to lead by.

    This method is more secure though, since there is little ways in which your client could fool the server to think that you hit when it didn't. And hence, any cries of "aimbots" and "accuracy hacks" for BF42 and BFV are completely absurd and only show the ignorance of those that cry about them (they are virtually impossible with server-side hit-detection)
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Dunno how many of you played Gears of War, but when you shoot your gun, it takes like a half a second for it to make a dent in the texture. That tells me that it uses server side hit detection, more secure, harder to cope with.

    This is also what Reese was talking about: server-side hit detection.

    Thank god, NS1 is client side since its hard to kill aliens as it is. Image if you had to lead them. rofl. The drawback: there is more hacking.
  • ReeseReese Join Date: 2003-05-08 Member: 16143Members
    <!--quoteo(post=1634722:date=Jun 19 2007, 10:02 PM:name=AnimeLOL)--><div class='quotetop'>QUOTE(AnimeLOL @ Jun 19 2007, 10:02 PM) [snapback]1634722[/snapback]</div><div class='quotemain'><!--quotec-->
    Great update Max, love the backstory. One question though: if everything is running as scripts and not as compiled code, will there be a slow-down as the script has to be dynamically converted to executions? All the opportunities that scripting allows for customization is great, but what is the cost in terms of system resources?
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    As far as scripting languages go, Lua is pretty fast. In general, games can be divided into two parts: rendering and behavior. The rendering is all being done by Source (in compiled code), so we don't really need to worry about that. I'm going to say that behavior includes all of the networking, which the networking tasks are also being handled by Source in compiled code, so it isn't really a problem. The rest of the behavior is the code that governs how the game actually works, this is what is being written in Lua.. (I.E. what happens when the players presses +use on the armory, among other things).

    In games with AI behavior code can get memory and/or processor intensive, as sophisticated AI takes a lot of resources. Since natural-selection is an entirely multiplayer game, the behavior is relatively simple. For example, the behavior code is relatively modest compared to the hit detection code used by Source, which is highly advanced and looks at player positions back in time to try and compensate for lag. I can almost guarantee that hit detection is a more expensive task considering how often it happens.

    As an added bonus, Lua is a much easier language to write in. Essentially the NS developers are trading speed that they don't really need for a better language to write their code in. One of the benefits here is that Lua practically guarantees that memory is handled correctly, which makes code written in it significantly less likely to experience a memory leak. There are whole classes of potential mistakes (which are easy to make and hard to find in C++) that simply don't exist in Lua. Overall I think this is a very good decision, and have no doubts about the performance we will see from it.
  • ThyReaperThyReaper Join Date: 2006-11-15 Member: 58621Members
    edited June 2007
    <!--quoteo(post=1634718:date=Jun 19 2007, 10:48 PM:name=Wyzcrak)--><div class='quotetop'>QUOTE(Wyzcrak @ Jun 19 2007, 10:48 PM) [snapback]1634718[/snapback]</div><div class='quotemain'><!--quotec-->
    On another note:
    My machine isn't anything to write home about, and I always notice that my NS1 hiccups the first time I bring up my minimap after the game's started, or the first time I round a corner and see the first observatory my client loads. I know little about how all of this works, but my assumption is that the delay (negligible though it be) is due to the loading, during my gameplay, of certain models and sprites.

    So I ask: is it possible, in NS past or future, to load allllll of the sprites/models/scripts/etc while the map is loading? If not, why (too taxing on the box/network/somethingelse, maybe)?
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    That's exactly what causes the pauses - caching the models, sounds, sprites, etc. Look at the pistol code. Three of the lines specify when resources should get cached.

    It is very possible to load all the resources that could be needed for the duration of the game during load time. The guaranteed drawback is a longer load time while the map launches. Also, more memory would be taken up by the various resources that get loaded. If you precache everything, but not all of it gets used, more memory will be used up than was needed.

    Basically, it comes down to load time and memory usage - is it worth it? That becomes preference, in most cases.
  • ReeseReese Join Date: 2003-05-08 Member: 16143Members
    <!--quoteo(post=1634731:date=Jun 19 2007, 11:03 PM:name=cerberus5)--><div class='quotetop'>QUOTE(cerberus5 @ Jun 19 2007, 11:03 PM) [snapback]1634731[/snapback]</div><div class='quotemain'><!--quotec-->
    So is this where the differences between client-side hit detection vs server-side hit detection really shine? Most games I know are client side (all half life 1 mods and source games) but there are a few that aren't like Gears of War. I sorta know how each works but still sorta confused, lol. Can someone explain to me the pros and cons of each.

    The only thing I can think of is that with server-side hit detection, you see what is ACTUALLY happening. If you hide right around a corner, you for a fact know you won't get shot as opposed to client-side hit detection where it "predicts" and cause you to die even if you hide right around a corner. Am I right?

    EDIT: Read this, made lots of sense:
    Dunno how many of you played Gears of War, but when you shoot your gun, it takes like a half a second for it to make a dent in the texture. That tells me that it uses server side hit detection, more secure, harder to cope with.

    This is also what Reese was talking about: server-side hit detection.
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Source does not use client-side hit detection. It uses server-side hit detection with client-side "prediction". You can actually turn this off ( "cl_prediction 0" in console) if you want to see what Source games are like without the prediction. The goal of the prediction is to try and smooth over the delay between firing your gun and seeing the results of it. The drawback is that if your client predicts incorrectly the game will magically change when it receives another server update.

    I doubt client side prediction could predict that you died and cause it to happen on the server. Updates simply are not pushed from the client to the server. The client may decide your health is "really low", but it will let you run around and send commands until it knows you are dead. The server may decide to ignore any commands you send after it decided you died, but updates generally come fast enough that this isn't really an issue.

    You can find detailed information here: <a href="http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html" target="_blank">http://www.valve-erc.com/srcsdk/general/mu...networking.html</a>
  • moultanomoultano Creator of ns_shiva. Join Date: 2002-12-14 Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
    Be careful that building this interface doesn't lock you in to less than ideal solutions further down the line. The one thing that worries me about abstracting away these internals is that it's very difficult to come up with all of the interfaces you'll need up front. Don't let this limit your design. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
  • cerberus414cerberus414 Join Date: 2005-05-07 Member: 51098Members, Constellation, Reinforced - Shadow
    <!--quoteo(post=1634737:date=Jun 19 2007, 11:27 PM:name=Reese)--><div class='quotetop'>QUOTE(Reese @ Jun 19 2007, 11:27 PM) [snapback]1634737[/snapback]</div><div class='quotemain'><!--quotec-->
    Source does not use client-side hit detection. It uses server-side hit detection with client-side "prediction". You can actually turn this off ( "cl_prediction 0" in console) if you want to see what Source games are like without the prediction. The goal of the prediction is to try and smooth over the delay between firing your gun and seeing the results of it. The drawback is that if your client predicts incorrectly the game will magically change when it receives another server update.

    I doubt client side prediction could predict that you died and cause it to happen on the server. Updates simply are not pushed from the client to the server. The client may decide your health is "really low", but it will let you run around and send commands until it knows you are dead. The server may decide to ignore any commands you send after it decided you died, but updates generally come fast enough that this isn't really an issue.

    You can find detailed information here: <a href="http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html" target="_blank">http://www.valve-erc.com/srcsdk/general/mu...networking.html</a>
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    I most definitely agree with you, but I was talking about the Half Life 1 engine :/
  • CxwfCxwf Join Date: 2003-02-05 Member: 13168Members, Constellation
    I was reasonably sure the Halflife 1 Engine worked about the same way--the client "predicts" what it thinks you're shooting at for smoother display, but the server actually decides if you hit or not, after adjusting for ping. As far as I know the server also calculates the random spread of cone-of-fire weapons, so you don't even see the correct spread pattern for your bullet holes--those are client side guesses rather than the real server-side shots.
  • cerberus414cerberus414 Join Date: 2005-05-07 Member: 51098Members, Constellation, Reinforced - Shadow
    IDK, I think Half life 1 is client side with some emphasis on the server-side. The hit registration is still done on the client.
  • MaxMax Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
    Whoah! Lots of good replies here.

    In terms of security, running scripts on the client doesn't really introduce any new opportunities for cheating. For CS:S, DoD, etc. it's running similar types of code on the client, they're just done in compiled C++ code instead of in Lua. The main reason security isn't an issue is because the client is not authoritative. That is, the client never sends any information to the server other than the input it collects from your mouse and keyboard. The weapon firing code may run on your client, but it doesn't really affect the game state. The result of running the weapon code on the server is what really determines if you hit an enemy. It's also common practice to do a quick check of the files on the client to make sure that they haven't been tampered with, since there are other types of cheating that can be accomplished by monkeying with the local files (like wall hacks or aim bots).

    On the topic of performance, Reese summed it up really well. Typically only a small amount of code is performance critical, and that tends to be the lower level stuff like physics simulation and setting up primitives for rendering. If we did find down the road that something we were doing in script was causing a performance drain, we always have the option of converting that to C++ code that we invoke from Lua. Reese also hit the nail on the head about the benefits, and I think I'll be writing some more about that in the near future.
  • KalopsiaKalopsia Join Date: 2003-05-15 Member: 16331Members, Reinforced - Shadow
    Glad to hear things are getting there, some of those gun designs look pretty well done as well. Great job guys, cheers for the update.
  • AnimeLOLAnimeLOL Join Date: 2006-11-02 Member: 58275Members
    <!--quoteo(post=1634732:date=Jun 20 2007, 04:08 AM:name=Reese)--><div class='quotetop'>QUOTE(Reese @ Jun 20 2007, 04:08 AM) [snapback]1634732[/snapback]</div><div class='quotemain'><!--quotec-->
    As far as scripting languages go, Lua is pretty fast. In general, games can be divided into two parts: rendering and behavior. The rendering is all being done by Source (in compiled code), so we don't really need to worry about that. I'm going to say that behavior includes all of the networking, which the networking tasks are also being handled by Source in compiled code, so it isn't really a problem. The rest of the behavior is the code that governs how the game actually works, this is what is being written in Lua.. (I.E. what happens when the players presses +use on the armory, among other things).

    In games with AI behavior code can get memory and/or processor intensive, as sophisticated AI takes a lot of resources. Since natural-selection is an entirely multiplayer game, the behavior is relatively simple. For example, the behavior code is relatively modest compared to the hit detection code used by Source, which is highly advanced and looks at player positions back in time to try and compensate for lag. I can almost guarantee that hit detection is a more expensive task considering how often it happens.

    As an added bonus, Lua is a much easier language to write in. Essentially the NS developers are trading speed that they don't really need for a better language to write their code in. One of the benefits here is that Lua practically guarantees that memory is handled correctly, which makes code written in it significantly less likely to experience a memory leak. There are whole classes of potential mistakes (which are easy to make and hard to find in C++) that simply don't exist in Lua. Overall I think this is a very good decision, and have no doubts about the performance we will see from it.
    <!--QuoteEnd--></div><!--QuoteEEnd-->
    Thanks for the clarification and illuminating post. I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow). Good to hear that Lua is much more efficient. Yeah, without AI, I guess there is a lot of headroom for more resource intensive tasks. I wonder though, if there is a number (2x, 3x, 4x as slow) that compares the performance of compiled C++ to Lua in game.
  • aeroripperaeroripper Join Date: 2005-02-25 Member: 42471NS1 Playtester, Forum Moderators, Constellation
    Loving these blog updates, interesting stuff.
  • paradox_42paradox_42 Join Date: 2007-06-19 Member: 61309Members
    edited June 2007
    <!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->
    ... It's also common practice to do a quick check of the files on the client to make sure that they haven't been tampered with, since there are other types of cheating that can be accomplished by monkeying with the local files (like wall hacks or aim bots).
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    so does this mean that only a server can allow client side ui script mods?
  • ReeseReese Join Date: 2003-05-08 Member: 16143Members
    <!--quoteo(post=1634764:date=Jun 20 2007, 12:46 AM:name=AnimeLOL)--><div class='quotetop'>QUOTE(AnimeLOL @ Jun 20 2007, 12:46 AM) [snapback]1634764[/snapback]</div><div class='quotemain'><!--quotec-->
    Thanks for the clarification and illuminating post. I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow). Good to hear that Lua is much more efficient. Yeah, without AI, I guess there is a lot of headroom for more resource intensive tasks. I wonder though, if there is a number (2x, 3x, 4x as slow) that compares the performance of compiled C++ to Lua in game.
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    It looks like that number is <a href="http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=lua" target="_blank">somewhere in the 25x range</a> That said, as Max mentioned, the Lua code is a small fraction of the entire game, and is nowhere near performance sensitive. Also, don't take that benchmark at face value, there are a lot more smart C++ programmers updating it than there are smart Lua programmers. I'm guessing generally it is 10-15x slower, which is well worth the benefits of having a better language to program in for this case.
  • GaroGaro Join Date: 2005-01-07 Member: 33134Members, Constellation, NS2 Playtester, Reinforced - Diamond, Reinforced - Shadow, WC 2013 - Silver, Subnautica Playtester
    Looks indeed good. I'm quite interested about the posibilities to modify client side UI. Are you planning to allow experienced players to modify client side scripts to modify their ui and to allow them play in multiplayer servers with those modified scripts?

    It sounds a bit dangerous, in terms of creating too good uis which would be considered hacking, but if you could limit the possibilities so that players could not create "hacks" with scripting, it would be pretty darn good!

    - Garo
  • GaidanGaidan Join Date: 2006-10-31 Member: 58132Members
    You didn't answer my question max, Will the client side only scripting allow for custom UIs?
  • GoldenprizeGoldenprize Join Date: 2006-11-05 Member: 58379Members
    edited June 2007
    great update and the gun artworks are great.
    and year, the cheating point is dangerous.
    Because user can made lua scripts that allow complex scripts to use e.g. bunnyhopping by one button or something.
    i know the client calls the server, thats the point.
    The server don't know if the player pressing buttons or lua?!
Sign In or Register to comment.