Err, if the pistol has no rate of fire (ie entire clip emptier like the pistol is now) that would take under a second, so what use would you have to move your crosshair in that case anyway?
And if the rate of fire was capped, why would you be lazy enough to be constricted to having your crosshair locked while you sit and wait for your clip to empty?
ChocolateThe Team MascotJoin Date: 2006-10-31Member: 58123Members
edited June 2007
Just a thought, but if we were to add a secondary fire for a GL it might be neat to put:
<b>Trajectory View:</b> If you've ever played Gears of War on Xbox 360 you'll notice there are two ways to shoot a grenade: blind throwing (fast way of throwing) and a slower way that lets you see where the grenade will land. We could add that slower way in NS2 as a secondary fire, the drawback would be that you'd have to stand still or takes time to find the trajectory.
<b>Structure Lockon:</b> This would be similar to the previous idea except it would lock on to the structure and maybe tilt at the correct angle to hit it. The drawback could be the same as the ones above.
This could also apply for the hand grenade or any other projectiles of that sort.
<b>Other Ideas:</b> I think even the HMG could have some type of semi-lock on in a small radius on the screen at expense of ROF. Perhaps if the flashlight becomes a weapons like in Doom 3 (I seriously doubt that) perhaps the LMG or the Pistol could have a built in flashlight. This bridges of into the "Pods" idea so maybe a built in flashlight could be the default "Pod".
Anyway, thats just my two res <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
edited June 2007
<!--quoteo(post=1635422:date=Jun 23 2007, 10:58 AM:name=ThyReaper)--><div class='quotetop'>QUOTE(ThyReaper @ Jun 23 2007, 10:58 AM) [snapback]1635422[/snapback]</div><div class='quotemain'><!--quotec--> I think you're confusing some of the variables. self.clip is how much ammo is in the current clip, and self.ammo is the amount of extra ammo on hand. When self.ammo == 0, there's nothing to reload, and so there is no case to handle.
Also, the code you proposed doesn't make sense anyway. You're subtracting clipsize from ammo, even though that case would only occur when ammo is 0 already, thus making ammo negative (<img src="style_emoticons/<#EMO_DIR#>/confused-fix.gif" style="vertical-align:middle" emoid="???" border="0" alt="confused-fix.gif" />). <!--QuoteEnd--></div><!--QuoteEEnd-->
i wasnt trying to give working exact code, just giving the gist of what was missing. i know my code wont work. i was in a hurry at the time and didnt find it necessary to look up what each variable name was, its pretty self explanatory what variable should go where.
am i completely wrong in thinking the code should be this way? im dadgum near positive that theres nowhere in this code that covers reloading when there is no ammo in the clip. am i just missing it?
hold on. nevermind ive been completely reading this code wrong the whole time. mixed up my variables. nevermind, everythings fine.
What sort of overheads are you looking at when parsing this code at runtime? Is it compiled to any kind of bytecode or is it interpreted as plaintext? Is running these scripts going to result in a big increase in server load?
<!--quoteo(post=1635541:date=Jun 24 2007, 06:58 PM:name=homicide)--><div class='quotetop'>QUOTE(homicide @ Jun 24 2007, 06:58 PM) [snapback]1635541[/snapback]</div><div class='quotemain'><!--quotec-->I dont see it making the development process any faster for the NS2 team..in fact, I see it making it significantly longer. <!--QuoteEnd--></div><!--QuoteEEnd-->
Did you read the blog entry? The benefit of having this script system in place is to enable very rapid balance tweaks in situ, rather than having to recompile and distribute a new set of dlls. Balancing is one of the most time-consuming parts of making a multiplayer game as unique as NS.
<!--quoteo(post=1635464:date=Jun 23 2007, 09:25 PM:name=Max)--><div class='quotetop'>QUOTE(Max @ Jun 23 2007, 09:25 PM) [snapback]1635464[/snapback]</div><div class='quotemain'><!--quotec--> Oh and the bug I mentioned before is that when you reload the pistol it discards the bullets currently in the clip. You could say that's by design (which of course I would have done if anyone had spotted it before me!) but it wasn't my intent when writing the code. <!--QuoteEnd--></div><!--QuoteEEnd-->
i vote for it to stay that way <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />, maybe we will bug the commander for ammo a bit more frequently, but its his job and we dont want to manually fill the clip with single bullets ;d
I actually think the pistol shouldn't have a combat secondary fire, what about a mini motion sensor that alerts the commander to enemy movement? Or even places the kind of alien, location, and health?
A cool secondary fire for the pistol would be a marine version of parasite - an electronic tag that allows only the commander to see the location of whatever's tagged.
It would be cool to tag a pesky fade and have the commander coordinate an ambush as he'd be the only person able to see its location. Could make it tech that needs to be researched on the obs for a nominal amount of res and 30 seconds or so.
<!--quoteo(post=1635729:date=Jun 25 2007, 04:47 AM:name=rsd)--><div class='quotetop'>QUOTE(rsd @ Jun 25 2007, 04:47 AM) [snapback]1635729[/snapback]</div><div class='quotemain'><!--quotec--> A cool secondary fire for the pistol would be a marine version of parasite - an electronic tag that allows only the commander to see the location of whatever's tagged.
It would be cool to tag a pesky fade and have the commander coordinate an ambush as he'd be the only person able to see its location. Could make it tech that needs to be researched on the obs for a nominal amount of res and 30 seconds or so. <!--QuoteEnd--></div><!--QuoteEEnd-->
Awesome update Max. This is going to make weapon development so simple and fast. Doing this in C++ can be quite a bit of work.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted?
<!--quoteo(post=1635768:date=Jun 25 2007, 11:34 AM:name=Flayra)--><div class='quotetop'>QUOTE(Flayra @ Jun 25 2007, 11:34 AM) [snapback]1635768[/snapback]</div><div class='quotemain'><!--quotec--> Awesome update Max. This is going to make weapon development so simple and fast. Doing this in C++ can be quite a bit of work.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted? <!--QuoteEnd--></div><!--QuoteEEnd-->
Counterstrike is nothing <i>except</i> shooting people. There's almost no strategy, very little teamwork, and the game itself is incredibly simple. Compare that to the complexity of NS and the strategy, tactics, and teamwork it takes to win a game, and you'll realize that nobody really cares about the recoil and fire rate of the LMG versus the HMG, which is a much smaller issue. Also, since both sides are so wildly different, the difference between the AK-47 and the M4A1 doesn't really exist.
Yeah, pretty much the exact same thought on my side.
If you have in-depth gameplay there is no real need for mysteries.
But if your gameplay is rather shallow, having lots of mysteries is a good thing. --- The only real NS mystery imho was to non-random shotgun spread combined with the random shotgun decal ^^ People just did not want to accept it and the only way to convince them was to point out, that the strance icon in the scoreboard means that you were right <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Alcapwn"War is the science of destruction" - John AbbotJoin Date: 2003-06-21Member: 17590Members
<!--quoteo(post=1635768:date=Jun 25 2007, 02:34 PM:name=Flayra)--><div class='quotetop'>QUOTE(Flayra @ Jun 25 2007, 02:34 PM) [snapback]1635768[/snapback]</div><div class='quotemain'><!--quotec--> Awesome update Max. This is going to make weapon development so simple and fast. Doing this in C++ can be quite a bit of work.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted? <!--QuoteEnd--></div><!--QuoteEEnd-->
Nah, just leave all of it open.
Most people wont look at the lua code, the select few who do (Competetive players) would figure it out anyway.
So, it looks like the code is still bugged when reloading with no ammo in reserve: There is no fail test for reloading, so you can attempt to reload 0 bullets repeatedly without actually doing anything. You won't reload negative bullets or anything, but you will play the animation repeatedly, locking yourself into "self:SetActivity(Activity.Reload)", which will prevent you from, you know, actually <i>firing</i>. This could be a bad thing.
Also, I want to second the call to remove the auto-reload on idle. If you want to reload, and cant find the "reload" button, you can always pull the trigger one more time which calls the "auto-reload on failed attack" sequence.
Er, now that I look at it, theres one more thing missing: Currently, when you try to fire an empty gun, it makes a "click" sound as you try and fail to shoot, and only AFTER the failed shot do you start reloading. This code skips the failed shot and just reloads immediately. That clicking sound is very important to immersion. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
<!--quoteo(post=1635469:date=Jun 23 2007, 04:44 PM:name=anty)--><div class='quotetop'>QUOTE(anty @ Jun 23 2007, 04:44 PM) [snapback]1635469[/snapback]</div><div class='quotemain'><!--quotec-->That's exactly what I was thinking when I read the post.
You could even use this like the global weapon pricing that is used in CSS. If done well, this could be a big help to balance the public games. <!--QuoteEnd--></div><!--QuoteEEnd-->
Glad to know I wasn't the only one. I'm more curious though about whether the NS2 team recognizes that.
<!--quoteo(post=1635868:date=Jun 26 2007, 12:36 AM:name=Cxwf)--><div class='quotetop'>QUOTE(Cxwf @ Jun 26 2007, 12:36 AM) [snapback]1635868[/snapback]</div><div class='quotemain'><!--quotec--> So, it looks like the code is still bugged when reloading with no ammo in reserve: There is no fail test for reloading, so you can attempt to reload 0 bullets repeatedly without actually doing anything. You won't reload negative bullets or anything, but you will play the animation repeatedly, locking yourself into "self:SetActivity(Activity.Reload)", which will prevent you from, you know, actually <i>firing</i>. This could be a bad thing.
Also, I want to second the call to remove the auto-reload on idle. If you want to reload, and cant find the "reload" button, you can always pull the trigger one more time which calls the "auto-reload on failed attack" sequence.
Er, now that I look at it, theres one more thing missing: Currently, when you try to fire an empty gun, it makes a "click" sound as you try and fail to shoot, and only AFTER the failed shot do you start reloading. This code skips the failed shot and just reloads immediately. That clicking sound is very important to immersion. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> <!--QuoteEnd--></div><!--QuoteEEnd--> Ammo is the number of bullets you have in reserve and clip is the number of bullets in the gun, so it doesn't do anything if you try to reload when you have no ammo.
Reload on idle is the standard HL weapon mechanism. It means that if you pull out a gun that needs to be reloaded or pick up ammo, it will automatically reload. I don't see why you wouldn't want this since the reload isn't getting in the way of firing. You can't fire an empty weapon and you can switch weapons while you're reloading.
I agree about the click sound, although this isn't the final code. It's actually just prototype code to test that we have the mechanisms in place to do the scripted weapons. Charlie is going to be building the weapons while I work on some other low level stuff.
Well, sounds like you're way ahead of me on this (which was to be expected after all), so I'll leave the coding to you from now on. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
<!--quoteo(post=1635768:date=Jun 25 2007, 07:34 PM:name=Flayra)--><div class='quotetop'>QUOTE(Flayra @ Jun 25 2007, 07:34 PM) [snapback]1635768[/snapback]</div><div class='quotemain'><!--quotec--> It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't think being able to see the code will really take away any mystery of how the weapons work, reading the variables and having a 'feel' for the weapon in game are quite different.
and oh god with the dynamic balance, nooooo, did the entire CSS community boycotting it not tell you something? Dynamic weapon damage would be even worse than just balancing cash. I can only really speak for myself but having absolutely no idea how many accurate shots it was going to take for me to kill something would be a serious turn off for the game, I'd probably still play for everything that makes NS unique but it'd bug the hell out of me.
The current balance issues of NS public games (basically occasional team stacking of the vets) is because of how polarised the community has become (and could be solved by just auto-assigning everyone), that's not going to be nearly so much of an issue with NS2, at least not to start with.
I think more of the dynamic balancing you're getting scared about is there for testing purposes. It is very valuable to be able to change values on the fly while testing, than have to stop testing to exit out, change values, recompile, redistribute, and try again. I doubt this is something that would ship with the game. There would need to be some consistency across servers after all.
<!--quoteo(post=1635782:date=Jun 25 2007, 02:59 PM:name=TychoCelchuuu)--><div class='quotetop'>QUOTE(TychoCelchuuu @ Jun 25 2007, 02:59 PM) [snapback]1635782[/snapback]</div><div class='quotemain'><!--quotec-->Counterstrike is nothing <i>except</i> shooting people. There's almost no strategy, very little teamwork, and the game itself is incredibly simple. Compare that to the complexity of NS and the strategy, tactics, and teamwork it takes to win a game...<!--QuoteEnd--></div><!--QuoteEEnd-->
I actually lol'd so hard.
</offtopic>
There isn't much point hiding the code for stuff like that, the people who care enough to look it up will find out eventually anyway.
I'm not talking about competetive play, I'm talking about pubs. Clans are going to figure out the numbers whether or not they're in an easily available LUA script.
<!--quoteo(post=1636037:date=Jun 27 2007, 02:40 AM:name=scaryface)--><div class='quotetop'>QUOTE(scaryface @ Jun 27 2007, 02:40 AM) [snapback]1636037[/snapback]</div><div class='quotemain'><!--quotec--> I'm personally worried that giving people all the code will make it easier to hack. <!--QuoteEnd--></div><!--QuoteEEnd-->
If they would create an open source game then that would be the truth, but a scripting language does not allow you to create a hack more easily. This is mainly due to having to packet sniff.
And besides: Unless they revamp the source engine heavily then hacks for any source game will work with NS2. Just think of it like going from BF2 to BF2142. BF2142 is essentially a standalone mod for BF2, with the engine being nearly untouched. This resulted that within the FIRST DAY of the beta people were already hacking. All they needed to do was to change 2 lines of code in their working BF2 hacks.
keep lots of it mystery. Even the fact that we know exactly how fast the pistol can shoot is a bad thing, because if you think about it. If we didn't know, then players who can't shoot the pistol as fast (without lame scripts or mwheel) will assume that's the way it is, then have a sense of amazement when they watch pro players unload a clip so quickly. Or the maximum speed of a skulk bunnyhopping, people want to feel like they can always improve, never be capped, even if there is a cap, you don't tell them about it. It keeps a game thriving. Imagine if in starcraft if the developers told everyone exactly how everything works, it would have nerfed starcrafts popularity a lot because people would have just 'known' exactly what is best all the time and htings.
Do you know what i mean? I kind of confused myself, but i think i got the point across.
<!--quoteo(post=1636097:date=Jun 27 2007, 01:31 PM:name=haymo)--><div class='quotetop'>QUOTE(haymo @ Jun 27 2007, 01:31 PM) [snapback]1636097[/snapback]</div><div class='quotemain'><!--quotec--> Imagine if in starcraft if the developers told everyone exactly how everything works, it would have nerfed starcrafts popularity a lot because people would have just 'known' exactly what is best all the time and htings.
Do you know what i mean? I kind of confused myself, but i think i got the point across. <!--QuoteEnd--></div><!--QuoteEEnd-->
Ohmmm, what great mysteries does starcraft have? To me it always seemed, that everything about this game is known. Even the way how pathfinding works is known and the rest is just damage types vs armor types (represented by unit size) and a little bit of math. There is seriously no mystery behind anything in starcraft and there never was. (Unless you are referring to the AI <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)
Comments
And if the rate of fire was capped, why would you be lazy enough to be constricted to having your crosshair locked while you sit and wait for your clip to empty?
<b>Trajectory View:</b>
If you've ever played Gears of War on Xbox 360 you'll notice there are two ways to shoot a grenade: blind throwing (fast way of throwing) and a slower way that lets you see where the grenade will land. We could add that slower way in NS2 as a secondary fire, the drawback would be that you'd have to stand still or takes time to find the trajectory.
<b>Structure Lockon:</b>
This would be similar to the previous idea except it would lock on to the structure and maybe tilt at the correct angle to hit it. The drawback could be the same as the ones above.
This could also apply for the hand grenade or any other projectiles of that sort.
<b>Other Ideas:</b>
I think even the HMG could have some type of semi-lock on in a small radius on the screen at expense of ROF.
Perhaps if the flashlight becomes a weapons like in Doom 3 (I seriously doubt that) perhaps the LMG or the Pistol could have a built in flashlight. This bridges of into the "Pods" idea so maybe a built in flashlight could be the default "Pod".
Anyway, thats just my two res <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
I think you're confusing some of the variables. self.clip is how much ammo is in the current clip, and self.ammo is the amount of extra ammo on hand. When self.ammo == 0, there's nothing to reload, and so there is no case to handle.
Also, the code you proposed doesn't make sense anyway. You're subtracting clipsize from ammo, even though that case would only occur when ammo is 0 already, thus making ammo negative (<img src="style_emoticons/<#EMO_DIR#>/confused-fix.gif" style="vertical-align:middle" emoid="???" border="0" alt="confused-fix.gif" />).
<!--QuoteEnd--></div><!--QuoteEEnd-->
i wasnt trying to give working exact code, just giving the gist of what was missing. i know my code wont work. i was in a hurry at the time and didnt find it necessary to look up what each variable name was, its pretty self explanatory what variable should go where.
am i completely wrong in thinking the code should be this way? im dadgum near positive that theres nowhere in this code that covers reloading when there is no ammo in the clip. am i just missing it?
hold on. nevermind ive been completely reading this code wrong the whole time. mixed up my variables. nevermind, everythings fine.
--Scythe--
I dont see it making the development process any faster for the NS2 team..in fact, I see it making it significantly longer.
In the end it sounds like a nice feature but hopefully it doesn't end up eating far more time than it is suppose to save.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Did you read the blog entry? The benefit of having this script system in place is to enable very rapid balance tweaks in situ, rather than having to recompile and distribute a new set of dlls. Balancing is one of the most time-consuming parts of making a multiplayer game as unique as NS.
--Scythe--
Oh and the bug I mentioned before is that when you reload the pistol it discards the bullets currently in the clip. You could say that's by design (which of course I would have done if anyone had spotted it before me!) but it wasn't my intent when writing the code.
<!--QuoteEnd--></div><!--QuoteEEnd-->
i vote for it to stay that way <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />, maybe we will bug the commander for ammo a bit more frequently, but its his job and we dont want to manually fill the clip with single bullets ;d
It would be cool to tag a pesky fade and have the commander coordinate an ambush as he'd be the only person able to see its location. Could make it tech that needs to be researched on the obs for a nominal amount of res and 30 seconds or so.
A cool secondary fire for the pistol would be a marine version of parasite - an electronic tag that allows only the commander to see the location of whatever's tagged.
It would be cool to tag a pesky fade and have the commander coordinate an ambush as he'd be the only person able to see its location. Could make it tech that needs to be researched on the obs for a nominal amount of res and 30 seconds or so.
<!--QuoteEnd--></div><!--QuoteEEnd-->
That would make Motion Tracking obsolete.
That would make Motion Tracking obsolete.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Parasite doesn't make Scent of Fear obsolete, and SoF has a limited range.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted?
Awesome update Max. This is going to make weapon development so simple and fast. Doing this in C++ can be quite a bit of work.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Counterstrike is nothing <i>except</i> shooting people. There's almost no strategy, very little teamwork, and the game itself is incredibly simple. Compare that to the complexity of NS and the strategy, tactics, and teamwork it takes to win a game, and you'll realize that nobody really cares about the recoil and fire rate of the LMG versus the HMG, which is a much smaller issue. Also, since both sides are so wildly different, the difference between the AK-47 and the M4A1 doesn't really exist.
If you have in-depth gameplay there is no real need for mysteries.
But if your gameplay is rather shallow, having lots of mysteries is a good thing.
---
The only real NS mystery imho was to non-random shotgun spread combined with the random shotgun decal ^^
People just did not want to accept it and the only way to convince them was to point out, that the strance icon in the scoreboard means that you were right <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Awesome update Max. This is going to make weapon development so simple and fast. Doing this in C++ can be quite a bit of work.
Now I'm starting to wonder though, do we want to expose every bit of the game code? Ie, is it better to have some "mystery" around weapon and ability behavior? It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out. It seems odd to hide some of the code, but I wonder if it makes sense to allow some Lua code to be encrypted?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Nah, just leave all of it open.
Most people wont look at the lua code, the select few who do (Competetive players) would figure it out anyway.
Also, I want to second the call to remove the auto-reload on idle. If you want to reload, and cant find the "reload" button, you can always pull the trigger one more time which calls the "auto-reload on failed attack" sequence.
Er, now that I look at it, theres one more thing missing: Currently, when you try to fire an empty gun, it makes a "click" sound as you try and fail to shoot, and only AFTER the failed shot do you start reloading. This code skips the failed shot and just reloads immediately. That clicking sound is very important to immersion. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
You could even use this like the global weapon pricing that is used in CSS. If done well, this could be a big help to balance the public games.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Glad to know I wasn't the only one. I'm more curious though about whether the NS2 team recognizes that.
So, it looks like the code is still bugged when reloading with no ammo in reserve: There is no fail test for reloading, so you can attempt to reload 0 bullets repeatedly without actually doing anything. You won't reload negative bullets or anything, but you will play the animation repeatedly, locking yourself into "self:SetActivity(Activity.Reload)", which will prevent you from, you know, actually <i>firing</i>. This could be a bad thing.
Also, I want to second the call to remove the auto-reload on idle. If you want to reload, and cant find the "reload" button, you can always pull the trigger one more time which calls the "auto-reload on failed attack" sequence.
Er, now that I look at it, theres one more thing missing: Currently, when you try to fire an empty gun, it makes a "click" sound as you try and fail to shoot, and only AFTER the failed shot do you start reloading. This code skips the failed shot and just reloads immediately. That clicking sound is very important to immersion. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
Ammo is the number of bullets you have in reserve and clip is the number of bullets in the gun, so it doesn't do anything if you try to reload when you have no ammo.
Reload on idle is the standard HL weapon mechanism. It means that if you pull out a gun that needs to be reloaded or pick up ammo, it will automatically reload. I don't see why you wouldn't want this since the reload isn't getting in the way of firing. You can't fire an empty weapon and you can switch weapons while you're reloading.
I agree about the click sound, although this isn't the final code. It's actually just prototype code to test that we have the mechanisms in place to do the scripted weapons. Charlie is going to be building the weapons while I work on some other low level stuff.
Keep up the good work!
It seems like some of the depth that Counter-strike has is all the craziness in it's aiming and recoil and people figuring it out.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't think being able to see the code will really take away any mystery of how the weapons work, reading the variables and having a 'feel' for the weapon in game are quite different.
and oh god with the dynamic balance, nooooo, did the entire CSS community boycotting it not tell you something? Dynamic weapon damage would be even worse than just balancing cash. I can only really speak for myself but having absolutely no idea how many accurate shots it was going to take for me to kill something would be a serious turn off for the game, I'd probably still play for everything that makes NS unique but it'd bug the hell out of me.
The current balance issues of NS public games (basically occasional team stacking of the vets) is because of how polarised the community has become (and could be solved by just auto-assigning everyone), that's not going to be nearly so much of an issue with NS2, at least not to start with.
I actually lol'd so hard.
</offtopic>
There isn't much point hiding the code for stuff like that, the people who care enough to look it up will find out eventually anyway.
cs metagame > ns metagame; but you can't really blame people for jumping to conclusions on internet forums. ignorance is bliss.
I'm personally worried that giving people all the code will make it easier to hack.
<!--QuoteEnd--></div><!--QuoteEEnd-->
If they would create an open source game then that would be the truth, but a scripting language does not allow you to create a hack more easily. This is mainly due to having to packet sniff.
And besides: Unless they revamp the source engine heavily then hacks for any source game will work with NS2. Just think of it like going from BF2 to BF2142. BF2142 is essentially a standalone mod for BF2, with the engine being nearly untouched. This resulted that within the FIRST DAY of the beta people were already hacking. All they needed to do was to change 2 lines of code in their working BF2 hacks.
Do you know what i mean? I kind of confused myself, but i think i got the point across.
Imagine if in starcraft if the developers told everyone exactly how everything works, it would have nerfed starcrafts popularity a lot because people would have just 'known' exactly what is best all the time and htings.
Do you know what i mean? I kind of confused myself, but i think i got the point across.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Ohmmm, what great mysteries does starcraft have? To me it always seemed, that everything about this game is known. Even the way how pathfinding works is known and the rest is just damage types vs armor types (represented by unit size) and a little bit of math. There is seriously no mystery behind anything in starcraft and there never was. (Unless you are referring to the AI <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)