Don't like this... <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if Shared.GetTime() > (self.timeBlinkStarted + .15) then
local energyCost = input.time * kBlinkEnergyCost - 0.15 * kBlinkEnergyCost
player:DeductAbilityEnergy(energyCost)
end<!--c2--></div><!--ec2-->
Tried that, also tried as you suggested. Tried it on different lines... Even tried hardcoding the energy deduction in. All ways end up with not draining any energy at all. And as soon as I remove the compensation, it works like normal.
Oh, and with the delayed invulnerability: the game doesn't start. Trying to access GetIsAlive: a nil value.
Do you think you could get it to print the value of energyCost to the console, so that you can check that the value is as it should be (and not some negative value for instance), before it tries to deduct the energy? input.time is definitely in seconds, right?
Now that I think of it, how is input.time actually defined? Because if it isn't defined as the time between starting to blink and the current time, then it's the wrong correction, if it even needs correction. As an experiment, restore the line to what it was before, but change the <b>.15</b> to <b>2</b> seconds, or something high like that. Then watch how the energy actually drains. If, after 2 seconds, it starts to drain smoothly, then it could be that input.time is the difference in time between frames where there is input (like, a delta), so it doesn't actually need the compensation, it's already continuous. If it drops sharply after two seconds, then it would require compensation.
I didn't understand this bit. What do these lines do? <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking() return true<!--c2--></div><!--ec2-->
<!--quoteo(post=1890940:date=Dec 20 2011, 12:41 AM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Dec 20 2011, 12:41 AM) <a href="index.php?act=findpost&pid=1890940"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As it currently works: If I put my head in the sand, I can still see you, but you can't see me.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually it's more 'I turn invisible, I can see you but you can't see me'.
As the fade presumably has the ability to jump in and out of his dimension of blue tinted minty freshness at will, he can also presumably sense what is in both dimensions, so as to avoid appearing in a wall or suchlike.
So making marines visible to the fade is a reasonable sense-analog that humans can interpret.
It's also much better for gameplay as I don't really want everything not-geometry to disappear when I blink and reappear afterwards, that's just be needlessly confusing.
<!--quoteo(post=1891307:date=Dec 22 2011, 03:54 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Dec 22 2011, 03:54 PM) <a href="index.php?act=findpost&pid=1891307"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do you think you could get it to print the value of energyCost to the console, so that you can check that the value is as it should be (and not some negative value for instance), before it tries to deduct the energy? input.time is definitely in seconds, right?
Now that I think of it, how is input.time actually defined? Because if it isn't defined as the time between starting to blink and the current time, then it's the wrong correction, if it even needs correction. As an experiment, restore the line to what it was before, but change the <b>.15</b> to <b>2</b> seconds, or something high like that. Then watch how the energy actually drains. It could be that input.time is the difference in time between frames where there is input (like, a delta), so it doesn't need the compensation.
I didn't understand this bit. What do these lines do? <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking() return true<!--c2--></div><!--ec2--><!--QuoteEnd--></div><!--QuoteEEnd-->
I can and I will do that later. Can grab the code to print it in the console from the skulk view rotation thread, as I don't recall it of the top of my head. Supposedly that code is what makes you immune to damage. I just removed the commatation that Yuuki had put there and put in the if.
I guess it depends when the function Fade:GetCanTakeDamageOverride() is actually called. Maybe the if statement isn't really valid within the function, leading to the game breaking; and you have to instead find where the function is called, then apply the if statement there (if [condition], call function).
I don't imagine it would be possible to have the if statement encapsulate the actual function? Yeah, probably not.
Edit: Or it could be that the if statement needs an "else" instruction, but what? Maybe "return self:GetIsBlinking()"? "return false"? The else instruction would probably need to be whatever it looks like with Yuuki's commentation in effect (i.e. empty?), but then I can't understand why it wouldn't work, since if it didn't satisfy the condition, it would be empty anyway.
input.time is the time between two frames, not the actual time.
The original code is :
return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking()
So you can take damage only when you're not blinking. Alien.GetCanTakeDamageOverride don't do much I think, i.e. return true all the time. I would do :
if self:GetIsBlinking() and Shared.GetTime() >= (Blink.timeBlinkStarted + .10) then return false end
Ah ok, so it never needed the compensation. Energy drain begins after the first 0.15 seconds (i.e. the first 0.15 seconds are "free", or they only cost the activation cost anyway).
Has this code been tried yet? <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if self:GetIsBlinking() and Shared.GetTime() >= (Blink.timeBlinkStarted + .10) then return false end
<!--quoteo(post=1891459:date=Dec 23 2011, 05:51 PM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Dec 23 2011, 05:51 PM) <a href="index.php?act=findpost&pid=1891459"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What is tap-blink ?<!--QuoteEnd--></div><!--QuoteEEnd--> Take a look at luns and Harimau's post on page 6. I would quote them, but I'm on my cell and can't for the love of god bother to erase large volumes of text.
I don't think that it's needed or even practically usable if it's significantly changed from blink. We alreade have the drain deley, and once we get the invulnerability delay working it will change from tap to hold mode during the blink. I don't think most of us are able to change direction during the first .1 seconds in any useful way anyhow. Should be able to trigger a second blink out cloud too to show when and where the fade got immune.
<!--quoteo(post=1891459:date=Dec 24 2011, 12:51 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Dec 24 2011, 12:51 AM) <a href="index.php?act=findpost&pid=1891459"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What is tap-blink ?<!--QuoteEnd--></div><!--QuoteEEnd--> Basically it's keeping the current version, but adding the NS1 (tap/click to blink) version on top of that. Tapping Blink (rather than holding it down) will do a 0.15 second blink - this does, however, imply that the minimum blink duration must be 0.15 seconds. This 0.15 second blink would coincide with the initial period of invulnerability delay and activation-cost-only.
So a simple way to describe it is: If current.time < (blink.starttime + 0.15) then blink for the whole 0.15 seconds (activation cost only, no invulnerability)
In this case you actually lose some fine control, because you can't use blink for less than 0.15 seconds - however, it (the option of tapping instead of holding) sort of standardises a "mini-blink" and so makes it easier to use - less versatile*, but more robust. It's also, of course, more akin to NS1's implementation. * But as Fluid Core observes above (I think), the difference between blinking for 0.1 seconds versus 0.15 seconds is practically negligible, so it's fine this way.
Biggest problem with the current blink is you can escape any situation, even well planned ambushes, by mashing the blink button
Yuukis mod looked like it was making a good start on fixing the problem, by making fades vulnerable in-blink, balanced with more effective momentum conservation. Seems to have some cool implications in terms of marine weapons, and cool possibilities in terms of marines being able to body block fades again.
Doesn't a "tap blink", bolted onto current blink, just reintroduce the problems yuuki was trying to solve?
swalkSay hello to my little friend.Join Date: 2011-01-20Member: 78384Members, Squad Five Blue
edited December 2011
<!--quoteo(post=1891479:date=Dec 24 2011, 03:02 AM:name=_Thresh_)--><div class='quotetop'>QUOTE (_Thresh_ @ Dec 24 2011, 03:02 AM) <a href="index.php?act=findpost&pid=1891479"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Biggest problem with the current blink is you can escape any situation, even well planned ambushes, by mashing the blink button
Yuukis mod looked like it was making a good start on fixing the problem, by making fades vulnerable in-blink, balanced with more effective momentum conservation. Seems to have some cool implications in terms of marine weapons, and cool possibilities in terms of marines being able to body block fades again.
Doesn't a "tap blink", bolted onto current blink, just reintroduce the problems yuuki was trying to solve?<!--QuoteEnd--></div><!--QuoteEEnd--> You can body block fades even though they are in blink mode. But directional blinking kinda screws that part up, since it makes it much easier to avoid being blocked.
SewlekThe programmer previously known as SchimmelJoin Date: 2003-05-13Member: 16247Members, NS2 Developer, NS2 Playtester, Squad Five Gold, Subnautica Developer
edited December 2011
i would suggest you to ignore any implementation of "GetCanTakeOverride" of a class you derive from, unless you really need the result from there as well. since it's not implemented anywhere, just return true/false in the class fade
I really like the idea of the mod. So far fighting against Fades has been way too frustrating, and I - personally - consider them overpowered.
Adding momentum to the blink-phase makes it much more interesting. And this would also coincide with my Anti-Fade-Shield idea. So the fade would have to use that momentum to get to a structure or a Marine within less then a second after he gets out of blink phase before the shield-radius.
And maybe it would encourage the fade to get out of blink-phase if his vision would get blurrier the longer he stay in blink-phase. So that at some point he can not see anything from the "real world" anymore.
I really like the idea of the mod. So far fighting against Fades has been way too frustrating, and I - personally - consider them overpowered.
Adding momentum to the blink-phase makes it much more interesting. And this would also coincide with my Anti-Fade-Shield idea. So the fade would have to use that momentum to get to a structure or a Marine within less then a second after he gets out of blink phase before the shield-radius.
And maybe it would encourage the fade to get out of blink-phase if his vision would get blurrier the longer he stay in blink-phase. So that at some point he can not see anything from the "real world" anymore.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't think we need any shields to block off hallways. That just slows down gameplay.
"fade blink changes: there is now an absolute blink time (not more, not less) direction cannot be changed during blink only initial blink energy higher speed
intention was to promote precisely aimed blinks and to allow prediction work better for other clients. The difference in reaction time for Marines and Fades is reduced, which should make "invisible" first hit less likely."
I tested out vanilla NS2 fade pretty thoroughly tonight for the first time and it was too easy for me to take out 2-3 marines all by myself just by blinking everywhere and hitting them, then run away and walk back camouflaged and do it all over again.
blinking needs to seriously drain their energy.
As a marine I have emptied full magazines into a fade at pretty much point blank range (with others shooting at it too) and they just turn and blink away without dying... it's ridiculous.
something needs to be done and I'm glad you folks are making efforts here.
seevee, wow, I don't know what to say, but you just resurrected a thread back in December 2011, things have changed, fades are garbage, if you think they are op give me a shotgun and you take your fade, 1v1 multiple times
Comments
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if Shared.GetTime() > (self.timeBlinkStarted + .15) then
local energyCost = input.time * kBlinkEnergyCost - 0.15 * kBlinkEnergyCost
player:DeductAbilityEnergy(energyCost)
end<!--c2--></div><!--ec2-->
Tried that, also tried as you suggested. Tried it on different lines... Even tried hardcoding the energy deduction in. All ways end up with not draining any energy at all. And as soon as I remove the compensation, it works like normal.
Oh, and with the delayed invulnerability: the game doesn't start. Trying to access GetIsAlive: a nil value.
Now that I think of it, how is input.time actually defined? Because if it isn't defined as the time between starting to blink and the current time, then it's the wrong correction, if it even needs correction. As an experiment, restore the line to what it was before, but change the <b>.15</b> to <b>2</b> seconds, or something high like that. Then watch how the energy actually drains. If, after 2 seconds, it starts to drain smoothly, then it could be that input.time is the difference in time between frames where there is input (like, a delta), so it doesn't actually need the compensation, it's already continuous. If it drops sharply after two seconds, then it would require compensation.
I didn't understand this bit. What do these lines do?
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking()
return true<!--c2--></div><!--ec2-->
Actually it's more 'I turn invisible, I can see you but you can't see me'.
As the fade presumably has the ability to jump in and out of his dimension of blue tinted minty freshness at will, he can also presumably sense what is in both dimensions, so as to avoid appearing in a wall or suchlike.
So making marines visible to the fade is a reasonable sense-analog that humans can interpret.
It's also much better for gameplay as I don't really want everything not-geometry to disappear when I blink and reappear afterwards, that's just be needlessly confusing.
Now that I think of it, how is input.time actually defined? Because if it isn't defined as the time between starting to blink and the current time, then it's the wrong correction, if it even needs correction. As an experiment, restore the line to what it was before, but change the <b>.15</b> to <b>2</b> seconds, or something high like that. Then watch how the energy actually drains. It could be that input.time is the difference in time between frames where there is input (like, a delta), so it doesn't need the compensation.
I didn't understand this bit. What do these lines do?
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking()
return true<!--c2--></div><!--ec2--><!--QuoteEnd--></div><!--QuoteEEnd-->
I can and I will do that later. Can grab the code to print it in the console from the skulk view rotation thread, as I don't recall it of the top of my head. Supposedly that code is what makes you immune to damage. I just removed the commatation that Yuuki had put there and put in the if.
But now I need to get going!
I don't imagine it would be possible to have the if statement encapsulate the actual function? Yeah, probably not.
Edit: Or it could be that the if statement needs an "else" instruction, but what? Maybe "return self:GetIsBlinking()"? "return false"? The else instruction would probably need to be whatever it looks like with Yuuki's commentation in effect (i.e. empty?), but then I can't understand why it wouldn't work, since if it didn't satisfy the condition, it would be empty anyway.
The original code is :
return Alien.GetCanTakeDamageOverride(self) and not self:GetIsBlinking()
So you can take damage only when you're not blinking. Alien.GetCanTakeDamageOverride don't do much I think, i.e. return true all the time. I would do :
if self:GetIsBlinking() and Shared.GetTime() >= (Blink.timeBlinkStarted + .10) then
return false
end
return Alien.GetCanTakeDamageOverride(self)
Has this code been tried yet?
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if self:GetIsBlinking() and Shared.GetTime() >= (Blink.timeBlinkStarted + .10) then
return false
end
return Alien.GetCanTakeDamageOverride(self)<!--c2--></div><!--ec2-->
Also, any news on tap-blink?
Take a look at luns and Harimau's post on page 6. I would quote them, but I'm on my cell and can't for the love of god bother to erase large volumes of text.
I don't think that it's needed or even practically usable if it's significantly changed from blink. We alreade have the drain deley, and once we get the invulnerability delay working it will change from tap to hold mode during the blink. I don't think most of us are able to change direction during the first .1 seconds in any useful way anyhow. Should be able to trigger a second blink out cloud too to show when and where the fade got immune.
Basically it's keeping the current version, but adding the NS1 (tap/click to blink) version on top of that.
Tapping Blink (rather than holding it down) will do a 0.15 second blink - this does, however, imply that the minimum blink duration must be 0.15 seconds.
This 0.15 second blink would coincide with the initial period of invulnerability delay and activation-cost-only.
So a simple way to describe it is:
If current.time < (blink.starttime + 0.15) then blink for the whole 0.15 seconds (activation cost only, no invulnerability)
In this case you actually lose some fine control, because you can't use blink for less than 0.15 seconds - however, it (the option of tapping instead of holding) sort of standardises a "mini-blink" and so makes it easier to use - less versatile*, but more robust. It's also, of course, more akin to NS1's implementation.
* But as Fluid Core observes above (I think), the difference between blinking for 0.1 seconds versus 0.15 seconds is practically negligible, so it's fine this way.
Yuukis mod looked like it was making a good start on fixing the problem, by making fades vulnerable in-blink, balanced with more effective momentum conservation. Seems to have some cool implications in terms of marine weapons, and cool possibilities in terms of marines being able to body block fades again.
Doesn't a "tap blink", bolted onto current blink, just reintroduce the problems yuuki was trying to solve?
Yuukis mod looked like it was making a good start on fixing the problem, by making fades vulnerable in-blink, balanced with more effective momentum conservation. Seems to have some cool implications in terms of marine weapons, and cool possibilities in terms of marines being able to body block fades again.
Doesn't a "tap blink", bolted onto current blink, just reintroduce the problems yuuki was trying to solve?<!--QuoteEnd--></div><!--QuoteEEnd-->
You can body block fades even though they are in blink mode.
But directional blinking kinda screws that part up, since it makes it much easier to avoid being blocked.
I really like the idea of the mod.
So far fighting against Fades has been way too frustrating, and I - personally - consider them overpowered.
Adding momentum to the blink-phase makes it much more interesting. And this would also coincide with my Anti-Fade-Shield idea. So the fade would have to use that momentum to get to a structure or a Marine within less then a second after he gets out of blink phase before the shield-radius.
And maybe it would encourage the fade to get out of blink-phase if his vision would get blurrier the longer he stay in blink-phase. So that at some point he can not see anything from the "real world" anymore.
I really like the idea of the mod.
So far fighting against Fades has been way too frustrating, and I - personally - consider them overpowered.
Adding momentum to the blink-phase makes it much more interesting. And this would also coincide with my Anti-Fade-Shield idea. So the fade would have to use that momentum to get to a structure or a Marine within less then a second after he gets out of blink phase before the shield-radius.
And maybe it would encourage the fade to get out of blink-phase if his vision would get blurrier the longer he stay in blink-phase. So that at some point he can not see anything from the "real world" anymore.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't think we need any shields to block off hallways.
That just slows down gameplay.
<a href="http://www.youtube.com/watch?v=rtTS17HHjX4" target="_blank">http://www.youtube.com/watch?v=rtTS17HHjX4</a>
"fade blink changes:
there is now an absolute blink time (not more, not less)
direction cannot be changed during blink
only initial blink energy
higher speed
intention was to promote precisely aimed blinks and to allow prediction work better for other clients. The difference in reaction time for Marines and Fades is reduced, which should make "invisible" first hit less likely."
Hope it becomes like this.
blinking needs to seriously drain their energy.
As a marine I have emptied full magazines into a fade at pretty much point blank range (with others shooting at it too) and they just turn and blink away without dying... it's ridiculous.
something needs to be done and I'm glad you folks are making efforts here.