Fix ninja stunlocking

TL;DR Ninja can still stunlock, but for a shorter amount of time and higher energy cost.  Each stun applied is 2.5 seconds, with a 2.5 second cool down.  The ninja may now stun only 6 times on one small-capacity powercell, for a total of a maximum 12 second stunlock if they use all the energy in their cell.
About the PR
There is a conflict in the design of ninja stunlocking with their gloves.
Content.Server/Ninja/Systems/StunProviderSystem.cs Has a comment:
// short cooldown to prevent instant stunlocking
        _useDelay.SetLength((uid, useDelay), comp.Cooldown, id: comp.DelayId);
        _useDelay.TryResetDelay((uid, useDelay), id: comp.DelayId);

However,
Content.Shared/Ninja/Components/StunProviderComponent.cs has the following code:
/// <summary>
    /// Time that someone is stunned for, stacks if done multiple times.
    /// </summary>
    [DataField]
    public TimeSpan StunTime = TimeSpan.FromSeconds(5);

    /// <summary>
    /// How long stunning is disabled after stunning something.
    /// </summary>
    [DataField]
    public TimeSpan Cooldown = TimeSpan.FromSeconds(2);

Why / Balance
Currently, a ninja may apply a 5 second stun every 2 seconds, and may do this 10 times on a full small capacity energy cell.  This requires too little skill and energy to be considered balanced, considering the ninja's entire toolkit.
The PR adjusts the stun length to 2.5 seconds with a 2.5 second cooldown, and increases the energy cost by 166%.  Stunlocking is now still possible, but the ninja can only stunlock for a maximum of 15 seconds (as opposed to 50!!!).  This will incentivize ninjas to be stealthier ambush antags and to find other ways of dealing with threats such as crafting cable cuffs or upgrading their suit cell.  Cuffing only takes 1.5 seconds if the target is stunned, so a 2.5 second stun allows the ninja to be 1 second late with the cuffs and still succeed.
Technical details
Energy requirement for stun increased from 36 to 60 joules
Stun length decreased from 5 seconds to 2.5 seconds
Stun cooldown increased by 0.5 seconds
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
None
PR Changelog
11/10 Stun length increased from 1 second to 2.5 seconds to allow for cuffing.
11/10 Stun cooldown restored to original 2 seconds from 1 second.
11/10 Power cost change adjusted from 72 to 60 joules
11/10 Stun length increased again from 2 seconds to 2.5 seconds for easier cuffing
11/10 Stun cooldown increased to 2.5 to match stun length to prevent stacking while enabling stunlocking.
:cl:

tweak: Made ninja stunlocking shorter and require more suit energy.

"This will incentivize ninjas to find other ways of dealing with threats such as crafting cable cuffs or upgrade their suit cell." but a 1 second stun isnt enough to cuff someone. and frankly all of this is excessive to fix the issue anyway. just increase the stun cooldown. a 5 second stun cant stunlock if the cooldown is 15 seconds. and this would still encourage the ninja to prepare something else since they know they're only gonna get one stun before the enemy has at least 10 seconds of immunity. this is an overcorrection for a minor problem. and frankly, the ninja is kind of meant to be really strong. no one is making prs about how the rat king and dragon can melt a guy in 2 seconds with their swarms but a nonlethal stunblock that drains most of the ninjas power [thus denying them most of their other abilities if they chose to stunlock] isnt an issue that needs fixing imo.

"This will incentivize ninjas to find other ways of dealing with threats such as crafting cable cuffs or upgrade their suit cell." but a 1 second stun isnt enough to cuff someone. and frankly all of this is excessive to fix the issue anyway. just increase the stun cooldown. a 5 second stun cant stunlock if the cooldown is 15 seconds. and this would still encourage the ninja to prepare something else since they know they're only gonna get one stun before the enemy has at least 10 seconds of immunity. this is an overcorrection for a minor problem. and frankly, the ninja is kind of meant to be really strong. no one is making prs about how the rat king and dragon can melt a guy in 2 seconds with their swarms but a nonlethal stunblock that drains most of the ninjas power [thus denying them most of their other abilities if they chose to stunlock] is too strong? it doesnt really seem like an issue that needs fixing imo.

I have increased the stun to 2 seconds, and with the time bonus for cuffing stunned targets, ninjas can now cuff stunlocked targets with a 0.5 second grace period.
An instant 5 second stun with a 15 second cooldown is too strong.  The stun is not intended as an escape tool as the ninja already has teleport.  The stun is a disarming tool, and should not provide a free 5 second window to crit someone with the very strong ninja katana.  By requiring the player to continuously stun the target, it raises the skill floor and ceiling, demanding the ninja to have enough energy and not expose itself to other threats.  Currently, a ninja can 1v2 or even 1v3.
This tweak is not necessarily a nerf as the ninja will still have 5 stun and disarm opportunities on a single power cell. It just modifies the playstyle of using a stun.

This is 100% a nerf, and in my opinion an unneeded one. If you fight a ninja one on one in close range you SHOULD lose that fight. I feel like you should be punished for it if a ninja can take you alone, which the current stun system accomplishes. The issue isnt the ninja here, its people going lone wolf against a ninja and getting upset they lose. If security goes in pairs, this is MUCH less of an issue.
Furthermore, you say they can use 5 stuns, but stuns are not the only thing that consume power. Cloaking, EMPing, etc. all consumes power leaving you with much less ability to stun.
Could the stuns be toned down? Maybe. But this goes way too far in MULTIPLE areas. The power consumption is an extreme nerf, the stun duration is an extreme nerf, etc. You said yourself you are making the stuns FIVE times worse in terms of duration on a single cell, which just feels like a massive overreaction to people getting upset they cant 1v1 a ninja, which is intentional.

// short cooldown to prevent instant stunlocking

this is so you cant apply 60s of stun in 10ms with a macro

This is 100% a nerf, and in my opinion an unneeded and excessive one. If you fight a ninja one on one in close range you SHOULD lose that fight. I feel like you should be punished for it if a ninja can take you alone, which the current stun system accomplishes. The issue isnt the ninja here, its people going lone wolf against a ninja and getting upset they lose. If security goes in pairs, this is MUCH less of an issue.
Furthermore, you say they can use 5 stuns, but stuns are not the only thing that consume power. Cloaking, EMPing, etc. all consumes power leaving you with much less ability to stun.
Could the stuns be toned down? Maybe. But this goes way too far in MULTIPLE areas. The power consumption is an extreme nerf, the stun duration is an extreme nerf, etc.

The only way I feel like these stuns should be changed is increasing the cooldown from 2 to 4 seconds, meaning you can still stunlock one person, but not multiple at once (I have not seen this done, but if it is possible it may be a bit too much.)
TLDR: This PR tries to correct an issue that does not exist in the form of a massive and extremely excessive nerf, so I do not believe it should be merged. You dont see people complaining that guns do too much damage so they reduce the damage to 20% of what it used to be, its both excessive and not neccesary.

This isn't a reaction to players trying to 1v1 a ninja and losing.  The ninja has a diverse toolkit - bullet reflect, teleport, invisibility, high speed, throwing stars, emag, and the best melee weapon in the game.  Stun gloves are unfortunately a one stop shop for every combat situation.  This PR pushes the stun in the direction of a disarm, and still provides the ninja with absolute dominance in melee situations.  The power cost means that the ninja has to be fully charged to have the 100% stunlock duration, and I don't think demanding resource management of a ninja player is excessive.  The stun needing to be reapplied means that the ninja must not be exposed to other threats to sustain it.  I am open to modifying the power cost, but ninjas are currently able to sustain a series of fights for far too long without needing to retreat and recharge.  If the ninja wants to win a 1v1 fight, it should because the player employs the entire toolkit effectively, not because it has one ability that wins with one click.

This is 100% a nerf, and in my opinion an unneeded and excessive one. If you fight a ninja one on one in close range you SHOULD lose that fight. I feel like you should be punished for it if a ninja can take you alone, which the current stun system accomplishes. The issue isnt the ninja here, its people going lone wolf against a ninja and getting upset they lose. If security goes in pairs, this is MUCH less of an issue.
Furthermore, you say they can use 5 stuns, but stuns are not the only thing that consume power. Cloaking, EMPing, etc. all consumes power leaving you with much less ability to stun.
Could the stuns be toned down? Maybe. But this goes way too far in MULTIPLE areas. The power consumption is an extreme nerf, the stun duration is an extreme nerf, etc.

The only way I feel like these stuns should be changed is increasing the cooldown from 2 to 4 seconds, meaning you can still stunlock one person, but not multiple at once (I have not seen this done, but if it is possible it may be a bit too much.)
TLDR: This PR tries to correct an issue that does not exist in the form of a massive and extremely excessive nerf, so I do not believe it should be merged. You dont see people complaining that guns do too much damage so they reduce the damage to 20% of what it used to be, its both excessive and not neccesary.

This isn't a reaction to players trying to 1v1 a ninja and losing. The ninja has a diverse toolkit - bullet reflect, teleport, invisibility, high speed, throwing stars, emag, and the best melee weapon in the game. Stun gloves are unfortunately a one stop shop for every combat situation. This PR pushes the stun in the direction of a disarm, and still provides the ninja with absolute dominance in melee situations. The power cost means that the ninja has to be fully charged to have the 100% stunlock duration, and I don't think demanding resource management of a ninja player is excessive. The stun needing to be reapplied means that the ninja must not be exposed to other threats to sustain it. I am open to modifying the power cost, but ninjas are currently able to sustain a series of fights for far too long without needing to retreat and recharge. If the ninja wants to win a 1v1 fight, it should because the player employs the entire toolkit effectively, not because it has one ability that wins with one click.

Ninjas are VERY frail, and if you stun a HoS/Security officer with an SMG, etc. in their bag or on their back, it allows them to magdump you to crit or atleast damage slowdown in extremely little time. I get what this PR tries to dom but it adresses an issue that is again, minor or nonexistant, with a massive nerf. If you want to nerf the stun, start off with something light, like keeping the power the same, and decreasing the stun duration from 5 to 3 seconds while keeping the cooldown on 2. But this PR does far too much far too severely to fix an issue I still think does not exist.

Feedback has been integrated.
-Stun increased to 2.5 seconds
-Cooldown inscreased to 2.5 seconds
-Power cost changed from 72 to 60 (1/6 of power cell)
Link of new wombo combo in discord #development https://cdn.discordapp.com/attachments/310555209753690112/1305188562496520304/Desktop_2024.11.10_-_<IP_ADDRESS>.mp4?ex=67321f12&is=6730cd92&hm=4870738dd196f3b155335bd6d1fe816a78336f2e4741d457c07f2f067f758e2b&

Feedback has been integrated. -Stun increased to 2.5 seconds -Cooldown inscreased to 2.5 seconds -Power cost changed from 72 to 60 (1/6 of power cell)
Link of new wombo combo in discord #development https://cdn.discordapp.com/attachments/310555209753690112/1305188562496520304/Desktop_2024.11.10_-_<IP_ADDRESS>.mp4?ex=67321f12&is=6730cd92&hm=4870738dd196f3b155335bd6d1fe816a78336f2e4741d457c07f2f067f758e2b&

Better, still think the CD should stay 2 and stun time maybe 3

Better, still think the CD should stay 2 and stun time maybe 3

I still think the power usage should still be 1/10th
Though im overall against this PR

Better, still think the CD should stay 2 and stun time maybe 3

I still think the power usage should still be 1/10th Though im overall against this PR

Same for me, not a neccessary nerf.

if you want to remove stunlocking all you have to do is increase cooldown to be longer than the stun duration not completely destroy the ability

if you want to remove stunlocking all you have to do is increase cooldown to be longer than the stun duration not completely destroy the ability

And if this is the case a lil popup saying your gloves are ready again would be cool

if you want to remove stunlocking all you have to do is increase cooldown to be longer than the stun duration not completely destroy the ability

The purpose of this PR is not to remove stunlocking.  The purpose of this PR is to make stunlocking more mechanically demanding and more resource intensive while retaining the disarming and stunning capability of the gloves.
I will show some math:
Currently, a ninja may apply a stacking 5 second stun every 2 seconds.  This means a target can be stunned for between 23 seconds (if spam clicking and applying the stun every 2 seconds) and 50 seconds (if applying the stun every 5 seconds) if 10 stuns are applied.

But lets say we only stun our target 3 times since we don't want to use all of our energy.  If we apply the 5 second stun every 2 seconds, 3 times, starting at 0 seconds, we get a total stunlock of 9 seconds.  If we don't spam click and apply every 5 seconds, we get a stunlock for 15 seconds.  In both cases, this only costs 30% of our total energy.  9 seconds is insanely strong.  15 seconds is even stronger.

The ninja's energy katana deals 30 slash damage and can attack every .90 seconds.  Thus is can crit an unarmored target in 4 hits in 3.5 seconds and a target wearing captain's carapace in 7 hits in 6.50 seconds.  This does not account for bloodloss damage or the 5 shock every stun deals.  If you apply 3 stuns (15 shock), you can crit a target wearing captain's carapace with 6 hits (180 slash - 50% slash resist). Likewise, you can crit an unarmored target with 2 stuns and 3 katana hits.

Should the ninja be dominant in 1v1 situations? Yes.  Should the ninja achieve this dominance through one ability that guarantees victory provided they can click on someone 3 times? I argue no.  The ninja has a diverse toolkit:

Bullet reflect
EMP
E-mag gloves
Stun gloves
Invisibility
High speed
Teleport (independent of suit charge)
Recall katana
Throwing stars that stun in 2 hits
Explosive charge

Does the ninja have kill objectives? No.  Is the ninja supposed to reward stealthy players or combat-oriented players? I argue stealthy.  And once again, this PR does NOT remove stunlocking.  Anyone who can use the toggle harm and switch hands hotkeys can still stunlock, and it is a fun combo to pull off.  The stun cost is now more reasonable, and the nerf to duration makes it more of a disarming tool than an "I win" button.

My testing indicates that the power nerf is balanced. Before or after stunning someone 5 times, you can:

I mean these numbers seem okay and I totally forgot you can find medium cells in maint flashlights.
My main issue sorta revolves around the idea that if someone stupidly walks up to me I dont wonna juggle buttons to punish them for doing so.
From my recent ninja games, the 5s stun is just about enough to crit someone if youre not interrupted, but if you ARE interrupted then you are at a big disadvantage and have to juggle between them. (Recent ninja game, cap and CE jumped me, and despite CE having no weapon other than a saw I wouldve bled out to death if I didnt have gauze, and wouldve absolutely died if a random tider decided to whack me at that point)
These numbers sound okay for a roundstart ninja considering you can still upgrade your power capacity. Mainly my problem here is the stun duration.
I do understand your point and the values are reasonable, however to me it still sorta just feels like a very random into-the-ground nerf. Also could you provide the numbers for medium and high powercells?

From my recent ninja games, the 5s stun is just about enough to crit someone if youre not interrupted, but if you ARE interrupted then you are at a big disadvantage and have to juggle between them. (Recent ninja game, cap and CE jumped me, and despite CE having no weapon other than a saw I wouldve bled out to death if I didnt have gauze, and wouldve absolutely died if a random tider decided to whack me at that point)

Ninja should win 1v1s, they should be taking at least some damage in 1v2s.    If you take a bad fight, there should be consequences, and you prepared with gauze and retreated.  Is your expectation that ninja should be able to run through the station taking fights without ever taking damage?   The ninja is a stealth predator antag.  If you are getting jumped, you aren't using the tools as intended.  I'm not demanding perfect combat play with this stun nerf, I'm reigning in the stun so ninja becomes a proper stealth antag.

I do understand your point and the values are reasonable, however to me it still sorta just feels like a very random into-the-ground nerf. Also could you provide the numbers for medium and high powercells?

It is not into the ground, the stun still absolutely destroys in a 1v1.  You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again.  I cannot stress how much I feel that people are overreacting to this.  Ninja code is bad.  Ninja code is not necessarily balanced.  Yes, it is a hard antag to play.  No, it doesn't need the current stun strength.
Small powercell has 360 joules, which equals
-6 stuns (with PR, 10 without) or
-3 minutes 20 seconds of cloak or
-2 EMPs (EMP has a 6 tile range, lasts 60 seconds, and removes 100,000 joules from nearby devices) or
-25 throwing stars (2 throwing stars stamcrits)
Medium capacity has 720, so each stun would cost 1/12 of a powercell instead of 1/20
-12 stuns (with PR. 20 without) or
-6 minutes 40 seconds of cloak or
-4 EMPs or
-50(!) throwing stars
High capacity has 1080, so each stun would cost 1/18 instead of 1/30.
-18 stuns (with PR, 30 without) or
-10 minutes of cloak or
-6 emps or
-75 throwing stars

It is not into the ground, the stun still absolutely destroys in a 1v1. You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again. I cannot stress how much I feel that people are overreacting to this. Ninja code is bad. Ninja code is not necessarily balanced. Yes, it is a hard antag to play. No, it doesn't need the current stun strength.

I do agree I overreact to this a little, but seeing the numbers I can say I agree with the energy increase, but I think the stun duration should stay around the same or at least within 3-4s.
As far as ive seen ninja stuff, they stunlock to steal items without killing, but this also depends. If the stun duration is 2s this just means you gotta stun -> whack -> stun -> whack and then loot the corpse.
Though this depends on ninjas not being assholes so tough stuff.
But yeah seeing the numbers I agree with the power usage changes at least.

It is not into the ground, the stun still absolutely destroys in a 1v1. You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again. I cannot stress how much I feel that people are overreacting to this. Ninja code is bad. Ninja code is not necessarily balanced. Yes, it is a hard antag to play. No, it doesn't need the current stun strength.

I do agree I overreact to this a little, but seeing the numbers I can say I agree with the energy increase, but I think the stun duration should stay around the same or at least within 3-4s.
As far as ive seen ninja stuff, they stunlock to steal items without killing, but this also depends. If the stun duration is 2s this just means you gotta stun -> whack -> stun -> whack and then loot the corpse. Though this depends on ninjas not being assholes so tough stuff.
But yeah seeing the numbers I agree with the power usage changes at least.

The PR makes the stun duration 2.5s (I forgot to update it in a few places, apologies).  This is enough time to cuff someone if you want to strip them for more than a headset.  I am open to adjusting the stun to 3 or even 3.5 seconds provided we make the cooldown the same amount of time to prevent stacking.

It is not into the ground, the stun still absolutely destroys in a 1v1. You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again. I cannot stress how much I feel that people are overreacting to this. Ninja code is bad. Ninja code is not necessarily balanced. Yes, it is a hard antag to play. No, it doesn't need the current stun strength.

I do agree I overreact to this a little, but seeing the numbers I can say I agree with the energy increase, but I think the stun duration should stay around the same or at least within 3-4s.
As far as ive seen ninja stuff, they stunlock to steal items without killing, but this also depends. If the stun duration is 2s this just means you gotta stun -> whack -> stun -> whack and then loot the corpse. Though this depends on ninjas not being assholes so tough stuff.
But yeah seeing the numbers I agree with the power usage changes at least.

The PR makes the stun duration 2.5s (I forgot to update it in a few places, apologies). This is enough time to cuff someone if you want to strip them for more than a headset. I am open to adjusting the stun to 3 or even 3.5 seconds provided we make the cooldown the same amount of time to prevent stacking.

How about a 3.5s stun and 3s cooldown to prevent needing perfect timing & connection, or better yet, leave duration at 5, cooldown set to 4, since double cooldown and increased power cost is already a severe nerf.

The PR makes the stun duration 2.5s (I forgot to update it in a few places, apologies). This is enough time to cuff someone if you want to strip them for more than a headset. I am open to adjusting the stun to 3 or even 3.5 seconds provided we make the cooldown the same amount of time to prevent stacking.

3.5 sounds great
I don't really care for the stacking so feel free to keep the cooldown at 3.5 too then

or better yet, leave duration at 5, cooldown set to 4, since double cooldown and increased power cost is already a severe nerf.

Setting stun duration to 5 seconds and cooldown to 4 seconds with 6 charges is a BUFF to spam clicking, not a nerf.
Currently, with stun duration 5 and cooldown 2, with 10 stuns and spam clicking:
Stun 1 - Stun for 5 seconds (0 to 5 seconds).
Stun 2 (at 2 seconds) - Stun is extended to stay on for 5 more seconds (now 2 to 7 seconds).
Stun 3 (at 4 seconds) - Stun is extended again (now 4 to 9 seconds).
Stun 4 (at 6 seconds) - Stun is extended again (now 6 to 11 seconds).
Stun 5 (at 8 seconds) - Stun is extended again (now 8 to 13 seconds).
Stun 6 (at 10 seconds) - Stun is extended again (now 10 to 15 seconds).
Stun 7 (at 12 seconds) - Stun is extended again (now 12 to 17 seconds).
Stun 8 (at 14 seconds) - Stun is extended again (now 14 to 19 seconds).
Stun 9 (at 16 seconds) - Stun is extended again (now 16 to 21 seconds).
Stun 10 (at 18 seconds) - Stun is extended again (now 18 to 23 seconds).
Total: 23 seconds.  Without spam clicking and near perfect timing, 50 seconds.
If stun duration is 5 and cooldown is set to 4, with 6 stuns and spam clicking:
Stun 1 - Stun for 5 seconds (0 to 5 seconds).
Stun 2 (at 4 seconds) - Stun extends by 5 more seconds (4 to 9 seconds).
Stun 3 (at 8 seconds) - Stun is extended again by 5 seconds (8 to 13 seconds).
Stun 4 (at 12 seconds) - Stun is extended again by 5 seconds (12 to 17 seconds).
Stun 5 (at 16 seconds) - Stun is extended again by 5 seconds (16 to 21 seconds).
Stun 6 (at 20 seconds) - Stun is extended again by 5 seconds (20 to 25 seconds).
Total: 25 seconds.  Without spam clicking and near perfect timing, 30 seconds
With this PR, with stun duration 2.5 and cooldown 2.5 and spam clicking:
Stun 1 - Stun turns on for 2.5 seconds (0 to 2.5 seconds).
Stun 2 (at 2.5 seconds) - Stun turns on for another 2.5 seconds (2.5 to 5 seconds).
Stun 3 (at 5 seconds) - Stun turns on for another 2.5 seconds (5 to 7.5 seconds).
Stun 4 (at 7.5 seconds) - Stun turns on for another 2.5 seconds (7.5 to 10 seconds).
Stun 5 (at 10 seconds) - Stun turns on for another 2.5 seconds (10 to 12.5 seconds).
Stun 6 (at 12.5 seconds) - Stun turns on for another 2.5 seconds (12.5 to 15 seconds).
Total: 15 seconds.  Spam clicking and perfect timing achieve the same effect.
Requiring the ninja to recharge in between stunlocks is GOOD for balance.
Preventing stun stacking is GOOD for balance.
Setting cooldown equal to stun duration is GOOD for the ninja, because they don't waste 5 charges and lose 25 seconds of potential stun time from spam clicking.
To address perfect timing/connection issues I am open to setting the cooldown to being 0.20 duration to account for ping but we can't balance a fast paced antag around people with 200 ms ping, and there is already input buffering to handle packet loss and ping in the first place.
With a 2.5 second instant proc stun, a ninja can stun once and cuff.  They can also stun, switch hands, harm intent, attack, switch hands, deactivate harm intent, and stun again, until the charge runs out.  That's 6 stuns, which deals 30 shock, and 6 attacks, which is 180 slash.  It's a guaranteed crit on anyone with less than 61% slash resist, and cap carapace only has 50%.
The ninja has not lost any combat capability.  The stun has been reigned in to be an ambush, disarm, and stunlock tool instead of an "I win" button that can be used multiple times without recharging.  Needing to reapply the stun in between attacks to prevent the target from being able to do literally anything while you kill them is not unreasonable or excessive in the slightest.
I am play testing this.  I am doing the math.  I am doing the work.  I am patiently explaining all of it.  Please consider the evidence with an open mind.

It is not into the ground, the stun still absolutely destroys in a 1v1. You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again. I cannot stress how much I feel that people are overreacting to this. Ninja code is bad. Ninja code is not necessarily balanced. Yes, it is a hard antag to play. No, it doesn't need the current stun strength.

I do agree I overreact to this a little, but seeing the numbers I can say I agree with the energy increase, but I think the stun duration should stay around the same or at least within 3-4s.
As far as ive seen ninja stuff, they stunlock to steal items without killing, but this also depends. If the stun duration is 2s this just means you gotta stun -> whack -> stun -> whack and then loot the corpse. Though this depends on ninjas not being assholes so tough stuff.
But yeah seeing the numbers I agree with the power usage changes at least.

The PR makes the stun duration 2.5s (I forgot to update it in a few places, apologies). This is enough time to cuff someone if you want to strip them for more than a headset. I am open to adjusting the stun to 3 or even 3.5 seconds provided we make the cooldown the same amount of time to prevent stacking.

How about a 3.5s stun and 3s cooldown to prevent needing perfect timing & connection, or better yet, leave duration at 5, cooldown set to 4, since double cooldown and increased power cost is already a severe nerf.

Cuff time is 3s and that does not account for ping on top of reaction time, so you are basically relying on victim letting you cuff them even at 3.5s if you do not have nearly no latency at all

or better yet, leave duration at 5, cooldown set to 4, since double cooldown and increased power cost is already a severe nerf.

Setting stun duration to 5 seconds and cooldown to 4 seconds with 6 charges is a BUFF to spam clicking, not a nerf.
Currently, with stun duration 5 and cooldown 2, with 10 stuns and spam clicking: Stun 1 - Stun for 5 seconds (0 to 5 seconds). Stun 2 (at 2 seconds) - Stun is extended to stay on for 5 more seconds (now 2 to 7 seconds). Stun 3 (at 4 seconds) - Stun is extended again (now 4 to 9 seconds). Stun 4 (at 6 seconds) - Stun is extended again (now 6 to 11 seconds). Stun 5 (at 8 seconds) - Stun is extended again (now 8 to 13 seconds). Stun 6 (at 10 seconds) - Stun is extended again (now 10 to 15 seconds). Stun 7 (at 12 seconds) - Stun is extended again (now 12 to 17 seconds). Stun 8 (at 14 seconds) - Stun is extended again (now 14 to 19 seconds). Stun 9 (at 16 seconds) - Stun is extended again (now 16 to 21 seconds). Stun 10 (at 18 seconds) - Stun is extended again (now 18 to 23 seconds). Total: 23 seconds. Without spam clicking and near perfect timing, 50 seconds.
If stun duration is 5 and cooldown is set to 4, with 6 stuns and spam clicking: Stun 1 - Stun for 5 seconds (0 to 5 seconds). Stun 2 (at 4 seconds) - Stun extends by 5 more seconds (4 to 9 seconds). Stun 3 (at 8 seconds) - Stun is extended again by 5 seconds (8 to 13 seconds). Stun 4 (at 12 seconds) - Stun is extended again by 5 seconds (12 to 17 seconds). Stun 5 (at 16 seconds) - Stun is extended again by 5 seconds (16 to 21 seconds). Stun 6 (at 20 seconds) - Stun is extended again by 5 seconds (20 to 25 seconds). Total: 25 seconds. Without spam clicking and near perfect timing, 30 seconds
With this PR, with stun duration 2.5 and cooldown 2.5 and spam clicking: Stun 1 - Stun turns on for 2.5 seconds (0 to 2.5 seconds). Stun 2 (at 2.5 seconds) - Stun turns on for another 2.5 seconds (2.5 to 5 seconds). Stun 3 (at 5 seconds) - Stun turns on for another 2.5 seconds (5 to 7.5 seconds). Stun 4 (at 7.5 seconds) - Stun turns on for another 2.5 seconds (7.5 to 10 seconds). Stun 5 (at 10 seconds) - Stun turns on for another 2.5 seconds (10 to 12.5 seconds). Stun 6 (at 12.5 seconds) - Stun turns on for another 2.5 seconds (12.5 to 15 seconds). Total: 15 seconds. Spam clicking and perfect timing achieve the same effect.
Requiring the ninja to recharge in between stunlocks is GOOD for balance. Preventing stun stacking is GOOD for balance. Setting cooldown equal to stun duration is GOOD for the ninja, because they don't waste 5 charges and lose 25 seconds of potential stun time from spam clicking.
To address perfect timing/connection issues I am open to setting the cooldown to being 0.20 seconds less than stun duration to account for ping but we can't balance a fast paced antag around people with 200 ms ping, and there is already input buffering to handle packet loss and ping in the first place.
With a 2.5 second instant proc stun, a ninja can stun once and cuff. They can also stun, switch hands, harm intent, attack, switch hands, deactivate harm intent, and stun again, until the charge runs out. That's 6 stuns, which deals 30 shock, and 6 attacks, which is 180 slash. It's a guaranteed crit on anyone with less than 61% slash resist, and cap carapace only has 50%.
The ninja has not lost any combat capability. The stun has been reigned in to be an ambush, disarm, and stunlock tool instead of an "I win" button that can be used multiple times without recharging. Needing to reapply the stun in between attacks to prevent the target from being able to do literally anything while you kill them is not unreasonable or excessive in the slightest.
I am play testing this. I am doing the math. I am doing the work. I am patiently explaining all of it. Please consider the evidence with an open mind.

I respect that you are this dedicated to this PR, but it still is simply too extreme of a nerf to do all at once, Furthermore, increasing the charge cost and cooldown is NOT a buff, it consumes more power and you cannot add an additional stun for longer, which is also detrimental in situations with multiple opponents, and I do not see how it can be beneficial in ANY situation, as it only limits you. (You can choose to wait 4 seconds anyway)
I get what you are trying to do here, but its simply too much of a nerf to the ability, regardless of what ninja still has left. Ninja shouldnt NEED to grab a pair of cuffs to win a fight without draining over half of their cell considering a HoS in their hardsuit can take 4-6 stabs before going crit.
I can see you justify changing the cooldown to be 4 seconds (making it equal may unfairly punish players with worse ping, not certain, but itd be safer to leave SOME wiggle room.) And increasing the power cost, but doing both severely in the same PR is already pushing it, let alone also halving the stun time, its too many nerfs for an issue that MULTIPLE experienced people agree is not anywhere near as severe as this nerf is treating it as, so I am still in favour of either closing this PR or changing only the power consumption and POSSIBLE the cooldown.

It is not into the ground, the stun still absolutely destroys in a 1v1. You can't stand up, you drop your weapon, and it gives the ninja a free 30 slash + 5 shock attack, and the ninja can do it over and over again. I cannot stress how much I feel that people are overreacting to this. Ninja code is bad. Ninja code is not necessarily balanced. Yes, it is a hard antag to play. No, it doesn't need the current stun strength.

I do agree I overreact to this a little, but seeing the numbers I can say I agree with the energy increase, but I think the stun duration should stay around the same or at least within 3-4s.
As far as ive seen ninja stuff, they stunlock to steal items without killing, but this also depends. If the stun duration is 2s this just means you gotta stun -> whack -> stun -> whack and then loot the corpse. Though this depends on ninjas not being assholes so tough stuff.
But yeah seeing the numbers I agree with the power usage changes at least.

The PR makes the stun duration 2.5s (I forgot to update it in a few places, apologies). This is enough time to cuff someone if you want to strip them for more than a headset. I am open to adjusting the stun to 3 or even 3.5 seconds provided we make the cooldown the same amount of time to prevent stacking.

How about a 3.5s stun and 3s cooldown to prevent needing perfect timing & connection, or better yet, leave duration at 5, cooldown set to 4, since double cooldown and increased power cost is already a severe nerf.

Cuff time is 3s and that does not account for ping on top of reaction time, so you are basically relying on victim letting you cuff them even at 3.5s if you do not have nearly no latency at all
Though if 2 ninja stars cause stamcrit, then generating them ahead of time should be enough.

If 2 stars cause stamcrit, then thats something to consider, but I still think this balance change should be done gradually, and then if it turns out to not be enough, another one can be made.

Cuff time is 3s and that does not account for ping on top of reaction time, so you are basically relying on victim letting you cuff them even at 3.5s if you do not have nearly no latency at all

Per https://github.com/space-wizards/space-station-14/blob/master/Content.Shared/Cuffs/Components/HandcuffComponent.cs ,
Cuff time is 3.5 seconds, but receives a - 2 second bonus if the target is stunned.  So cuffing takes 1,5 seconds, on a 2.5 second stun.  So you can be an entire second late (which is a lot of time) and still cuff.

Furthermore, increasing the charge cost and cooldown is NOT a buff,

I wrote that having a 5 second stun with 4 second cooldown as you suggested with only 6 charges is a buff to spam clicking.  It makes it more efficient compared to 5 second stun with 2 second cooldown and 10 charges.

5s stun, 4s cd, 6 stuns spam clicking = 25s total stun
5s stun, 2s cd, 10 stuns spam clicking = 23s total stun.

it consumes more power and you cannot add an additional stun for longer, which is also detrimental in situations with multiple opponents,

The ninja should be dominant in 1v1, not in situations with multiple opponents.  The detrimental effect is intentional.  We want them to be stealthy, we want them to ideally retreat from combat, and if they are engaging in combat, it should be because they planned an ambush.

and I do not see how it can be beneficial in ANY situation, as it only limits you. (You can choose to wait 4 seconds anyway)

Currently if you click too early, your total stun is shorter than if you click perfectly on time.  Your energy spent is now always worth the full amount of stun time rather than spending the energy and receiving diminishing returns on the stun time. Spam clicking would be consistent with this PR, mitigating latency and reaction time issues.

I get what you are trying to do here, but its simply too much of a nerf to the ability, regardless of what ninja still has left. Ninja shouldnt NEED to grab a pair of cuffs to win a fight without draining over half of their cell considering a HoS in their hardsuit can take 4-6 stabs before going crit.

The ninja should need to be prepared for a fight and should have to expend resources to avoid risk in fights.  They have the luxury of choosing when to fight.  They have AA.  They have super speed.  They have teleport.  They can disengage from combat and recharge whenever they want. The HoS and Captain should represent the hardest targets for the ninja to defeat.  The ninja should not have an "I win" button.  As established earlier, with this PR, a ninja may stun and attack 5 times, dealing 25 shock and 150 slash, which equals 100 total damage and a crit state on a target with 50% slash resist.  They would still have the equivalent of 33 seconds of invisibility or 2 throwing stars after doing so with a small capacity powercell.  Gloves and teleport do not require power.  With a medium capacity, they would be able to stun 5 times, EMP, AND cloak for 133 seconds afterward.  So I'm really not understanding your argument about the power nerf being too severe.  I can keep showing the math.  But you haven't told me why the ninja needs so much power.
The thesis behind this PR is that the ninja needs to become a more stealth oriented ambush style antag.  They still have exactly the same tools as before, they just need to actually use their brain about resource management and being stealthy to be successful.

doing both severely in the same PR is already pushing it, let alone also halving the stun time, its too many nerfs for an issue that MULTIPLE experienced people agree is not anywhere near as severe as this nerf is treating it as, so I am still in favour of either closing this PR or changing only the power consumption and POSSIBLE the cooldown.

This nerf is not anywhere as severe as people are claiming it is.  I have demonstrated that mathematically.
This nerf makes it harder for a ninja to deal with 1v2 situations, which is good.
This nerf incentivizes the ninja to manage their resources, which is good.
Multiple experienced people agreeing with you doesn't mean you are right.
This PR has already been adjusted with feedback. I will change the stun to 3 seconds with a 2.8 second cooldown if that is the arbitrary condition on it being merged.  I refuse to allow the goalposts to be moved any further than that. If necessary I will create a brand new PR.

basing the stun duration around cuffing is odd since ninja have to steal or craft cuffs from lv, and having to cuff every single person you kill in maints would be annoying

basing the stun duration around cuffing is odd since ninja have to steal or craft cuffs from lv, and having to cuff every single person you kill in maints would be annoying

I'm not sure if you're reading what I've been writing.
The stun is a disarming tool that gives the ninja a free 30 slash hit and deals 5 shock.  You can re-apply it to stunlock someone while you kill them.  You do not need to cuff every single person you kill in maints, because again, the ninja has a 30 slash weapon, can stun 6 times on a full small-capacity battery, and most targets will go down in 4 sword attacks alone.

basing the stun duration around cuffing is odd since ninja have to steal or craft cuffs from lv, and having to cuff every single person you kill in maints would be annoying

I'm not sure if you're reading what I've been writing.
The stun is a disarming tool that gives the ninja a free 30 slash hit and deals 5 shock. You can re-apply it to stunlock someone while you kill them. You do not need to cuff every single person you kill in maints, because again, the ninja has a 30 slash weapon, can stun 6 times on a full small-capacity battery, and most targets will go down in 4 sword attacks alone.

The stun is not a disarming tool. The stun is a tool to incapacitate a target to allow you to kill or optionally rob/cuff them. You are TURNING it into a disarming tool with this PR, which I still dont think is justified. And both mathmatically and practically, the changes you are making are severe. Again, Id udnerstand if you want to nerf the cooldown OR the power consumption, maybe both if you dont overdo it, but nerfing the ability in all 3 ways simultaniously is still not justified, and I feel like the fact that several people are saying the exact same thing means something.
You also mention a buff to spam clicking, which if you are wasting your charges recklessly thats not something I feel like we should consider for this PR. Also, while I am not sure on this, I BELIEVE that the stun stacks, meaning if you click them 5 times with no clicks being on cooldown, I dont think the timing matters, which invalidates that entire argument even though it was not relevant to begin with.
As for the charges, you keep saying they have 6 charges by default, which is mathmatically true, but practically false, since while you are playing as a ninja, you will ALWAYS use your cloak to move around with less chance of detection, and optionally may need to use your other abilities after that, resulting in you never engaging in a fight at 100%. I feel like right now the ninja is in a fine spot balance wise, and ninjas are still 100% killable while being far from a pushover.
Also, you saying "I refuse to allow the goalposts to be moved any further than that." feels odd to me. Its up to the maintainers if this PR gets merged, so odds are if you arent willing to take feedback and be flexible with that instead of making it slightly less extremely nerfed and calling it a day, they could easily just reject it, which I still hope happens.
Im going to stop responding to this PR now, because its not going anywhere. You keep pointing out numbers that apply in optimal conditions which you will not be able to replicate in a real round. The ninja is currently in a solid state balance wise, and not ANYWHERE near overpowered enough to warrant a nerf which 3+ people repeatedly state is extreme, regardless of your numbers which again, only apply in ideal conditions as opposed to practical and realistic scenarios.

i think everything that can be said has been said. this is an excessive nerf, and the community is clearly communicating that to you. please close this pr.

The stun is not a disarming tool. The stun is a tool to incapacitate a target to allow you to kill or optionally rob/cuff them. You are TURNING it into a disarming tool with this PR, which I still dont think is justified. And both mathmatically and practically, the changes you are making are severe.

This PR does not change anything that you are claiming it does in this statement.  It still incapacitates and allows you to kill or rob or cuff them.  It just actually consumes a meaningful amount of energy now, and requires you to more actively sustain the stun if you want a longer stun duration.

Again, Id udnerstand if you want to nerf the cooldown OR the power consumption, maybe both if you dont overdo it, but nerfing the ability in all 3 ways simultaniously is still not justified.

Why isn't it justified though?  I have shown over and over again just how powerful the stun is, and how powerful it still would be.  I have shown that the power balancing still allows the ninja to access their kit alongside the stun increase.  EMP costs 180, cloak costs 1.8 per second (very low).  The stun costing 60 is much more reasonable considering a total of 360 joules that can be refilled from any APC, Substation, or SMES indefinitely.  And by just grabbing a medium powercell, you get twice as much power.

I feel like the fact that several people are saying the exact same thing means something.

No, it doesn't, at least not explicitly.  Simply repeating "excessive" is not an argument.  Please, someone, make a case for WHY the ninja needs the current stun strength and power consumption levels to be an effective antag.

As for the charges, you keep saying they have 6 charges by default, which is mathmatically true, but practically false, since while you are playing as a ninja, you will ALWAYS use your cloak to move around with less chance of detection, and optionally may need to use your other abilities after that, resulting in you never engaging in a fight at 100%. I feel like right now the ninja is in a fine spot balance wise, and ninjas are still 100% killable while being far from a pushover.

As established earlier, cloak only uses 1.8 joules per second so you still have 33 seconds of cloak if you use 5 charges on a small capacity powercell. Currently the ninja has laughably little resource management aside from counting the number of teleport charges.

Also, you saying "I refuse to allow the goalposts to be moved any further than that." feels odd to me. Its up to the maintainers if this PR gets merged, so odds are if you arent willing to take feedback and be flexible with that instead of making it slightly less extremely nerfed and calling it a day, they could easily just reject it, which I still hope happens.

This PR is intended to significantly modify the way an ability is used while retaining its functionality.  Making a PR that changes basically nothing is a waste of everyone's time.  I did take feedback and updated the PR, and I will continue to take feedback on the idea.

Im going to stop responding to this PR now, because its not going anywhere. You keep pointing out numbers that apply in optimal conditions which you will not be able to replicate in a real round. The ninja is currently in a solid state balance wise, and not ANYWHERE near overpowered enough to warrant a nerf which 3+ people repeatedly state is extreme, regardless of your numbers which again, only apply in ideal conditions as opposed to practical and realistic scenarios.

If you're out of arguments or feedback, that's fine.  We're all volunteers here.  Your perception that ninja is balanced currently is just that, a perception.  You have not made a specific case for why the ninja currently is balanced, or would become unbalanced with this PR, you have not presented any evidence aside from "people agree with me."  The purpose of this balance adjustment is to incentivize stealthier playstyles.  I have made a strong case challenging that perception and that case will remain here until it is reviewed by a maintainer.

i think everything that can be said has been said. this is an excessive nerf, and the community is clearly communicating that to you. please close this pr.

If you're out of arguments or feedback, that's fine. We're all volunteers here. Your perception that ninja is balanced currently is just that, a perception. You have not made a specific case for why the ninja currently is balanced, or would become unbalanced with this PR, you have not presented any evidence aside from "people agree with me." The purpose of this balance adjustment is to incentivize stealthier playstyles. I have made a strong case challenging that perception and that case will remain here until it is reviewed by a maintainer.

the community is clearly communicating that to you. please close this pr.

The community is not a monolithic entity, I personally think the PR is a step in the right direction, what's the right direction? Nerfing ninja to be a more balanced and interesting antag and not a McGuffin of individually overpowered mechanics.

this is an excessive nerf

I disagree, 2.5/2.5 still permits the ability to be an instant melee-range on-demand stun that takes up no inventory space and is almost guaranteed to be on-standby 24/7, hear what I just said? That's already overpowered and most antag players would give up a liver for something like this.
What 2.5/2.5 does is prevent using it on several targets at once, which I'd argue is good.
2.5/2.5 also allows the stunned person to have counterplay if the ninja makes a mistake, which I'd argue is excellent and makes ninja encounters less one-dimensional.
Now for my own opinion, I think the stungloves are great, but you could cut them out of the kit and possibly make ninja a more interesting and balanced antagonist, why? Your kit remains an overpowered McGuffin and taking out the cherry on top wont undo it.
You still have:
One of the best melee weapons in the game
The best mobility in the game
An infinite emag
On-demand invisibility
Long-range 2-hit damaging stunbaton (stars)
On-demand LoS-locked teleport
On-demand EMP
More.
Point is, you won't suddenly become a joke if you can't instantly stun someone if they're in melee range.
Until then, 2.5/2.5 is a lukewarm suggestion that says "hey your kit has other stuff", pretty good compromise.

Hey, just a reminder to everyone. Please remain civil and provide constructive criticism to PRs. Contributors are the lifeblood of this project and it's important that you treat with respect just as they are expected to treat you.

The purpose of this balance adjustment is to incentivize stealthier playstyles.

Not providing direct feedback on the changes because honestly I haven't given it enough thought yet, but just wanted to comment that I don't know how much a change in how stuns work will change this much. I feel like people who want to treat the ninja as a killer are still going to do just that. I can say that I've been lucky enough to play ninja quite a bit and complete green text pretty much every run. I think I've killed someone maybe once or twice during all my runs. There's just no reason to need to kill at all (which I actually like, being able to cause chaos without directly taking someone out of the round, even temporarily)

instant melee-range on-demand stun that takes up no inventory space and is almost guaranteed to be on-standby 24/7

Agreed that the stun is obviously very strong currently (I mean you can keep someone stunned the entire time you complete a comms or record console hijacking, lets be real that may be a bit much). And I think I even agree with nerfing it to some degree, however, I don't think a stun change necessarily points people to be more stealthy. A majority of ninja's I've observed that try to get in fights with more than one person tend to lose. Hell, there's a comedic amount of ninja's that lose to HoP walking into the bridge pulling out their disabler when they spot the (lets be honest, still obvious) "cloak". And a big part of that is just having to fumble with items (like having to have your sword out to dash, which is made worse with the hotbar action swapping issue - though I believe I may have seen a PR fixing that?)
The short of what I'm saying is, yes, ninja strong, but dunno if changing the stun will "push" people to be more stealthy.

Increasing the stun delay and power consumption is fine, but please keep the stun time the same, if it's extremely low then you are encouraging just killing the target instead (or just anti QoL if you want the ninja to spam click instead)

I feel like people who want to treat the ninja as a killer are still going to do just that. I can say that I've been lucky enough to play ninja quite a bit and complete green text pretty much every run. I think I've killed someone maybe once or twice during all my runs.
There's just no reason to need to kill at all (which I actually like, being able to cause chaos without directly taking someone out of the round, even temporarily)

The short of what I'm saying is, yes, ninja strong, but dunno if changing the stun will "push" people to be more stealthy

These are good points.  My belief is nerfing the stun (which is deserved to begin with) will sharpen the difference between disengaging from combat and engaging in combat.  If crew gets the drop on the ninja, the ninja should have to choose between committing a significant amount of power, time, and risk to neutralize them through combat rather than teleporting away and setting up an ambush later.  Ninjas should be punished for exposing themselves.  Teleport charges are limited meaningfully, but currently stungloves are not, so this PR should make the choice between them more meaningful.
And yes I agree, if a ninja decides they are going to be a maints murdergoblin, adjusting stun won't change that meaningfully.

Increasing the stun delay and power consumption is fine, but please keep the stun time the same, if it's extremely low then you are encouraging just killing the target instead (or just anti QoL if you want the ninja to spam click instead)

I understand the interpretation of this being anti QoL, because it is, but only for murdering people with the stunlock.  With the current stun length and cooldown, it does require switching back and forth between hands and harm intent to stunlock and murder, which is demanding but absolutely doable.  Stripping, however, does not require this mechanically intensive combo and therefore the ninja is incentivized to strip, and stunlock murdering is much harder.
I would not classify the 2.5s stun time as extremely low, but I am now leaning towards 3 seconds.  The sec stun baton requires 3 hits to stamcrit and stamcrit applies a 6 second stun (if I am interpreting https://github.com/space-wizards/space-station-14/blob/master/Content.Shared/Damage/Components/StaminaComponent.cs correctly).  So half the duration of a stamcrit applied in one click seems fair.
I will now update the PR to 3 second stun time, 2.90 second cooldown.

https://github.com/user-attachments/assets/f0a2a4a7-71be-404c-b32e-226c9af3218e

1984


Please remove tests classes from lib

We are integrating the library in an Android project through:
implementation 'org.bouncycastle:bcpkix-jdk15on:1.64'
and the latest version includes test classes which want to access a non-existing file:
org.bouncycastle.pqc.crypto.qtesla.QTeslaKeyEncodingTests.testDecodeEncodePrivateKeyQT3P()
BufferedReader var1 = new BufferedReader(new InputStreamReader(this.getClass().getResourceAsStream("/org/bouncycastle/pqc/crypto/test/q3pIII.txt")));
We have the problem that on Android all found tests are run automatically, also those present in imported libs, thus our CI is failing whlie executing the tests and we don't have a reliable way of excluding files from imported libs, so please if you could fix this!

Can you identify where the class is coming from? The bcpkix jar does not appear to contain it.

Yes, it comes from bcprov-jdk15on-1.64.jar which is added automatically when you add bouncycastle:bcpkix
It's this class

Thanks, found it. Oh dear... will see that it's removed in 165,

Thanks, will this be in H1 2020?

We're hoping for the next few weeks. It's now up in https://www.bouncycastle.org/betas

I have the same issue. I can't update to 1.63 or 1.64 as then my instrumentation tests start failing. And sadly there is no easy way to exclude one instrumentation test from the set. The testOptions DSL only works with unit tests.

does your testing work with the latest beta?

Hei!
Yes. If I use the following two artifacts:

bcprov-jdk15to18-165b10.jar
bcpkix-jdk15on-165b15.jar

then my Android project both builds fine, and all of my instrumentation tests are green. And there are no extra instrumentation tests included from the "bcprov" artifact.
Just in case I also executed all my integration tests, everything seems to be working fine there also.
So good work!
Just in case if this is in any way relevant - I didn't know which "bcprov" artifact to take and tested with all of them.
The "bcprov-jdk15on-165b15.jar" gave a Jetifier error. I assume it is of a wrong Java version for my build and this is how it should be. (Ignore the artifact name, I renamed it there.)
`* What went wrong:
Execution failed for task ':myappname:javaPreCompileDebug'.

Could not resolve all files for configuration ':myappname:debugCompileClasspath'.
Failed to transform bcprov-jdk15on-1.65b15.jar (org.bouncycastle:bcprov-jdk15on:1.65b15) to match attributes {artifactType=android-classes, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-api}.
Execution failed for JetifyTransform: \maven\org\bouncycastle\bcprov-jdk15on\1.65b15\bcprov-jdk15on-1.65b15.jar.
Failed to transform '\maven\org\bouncycastle\bcprov-jdk15on\1.65b15\bcprov-jdk15on-1.65b15.jar' using Jetifier. Reason: null. (Run with --stacktrace for more details.)`

Secondly, maybe more interestingly, the "bcprov-jdk14-165b13.jar" gave this error. Did something change there with the ASN1Encodable class? Or is this also expected?
<myapppath>/HardwareKeyStore.java:396: error: for-each not applicable to expression type         for (ASN1Encodable digest : digests) {                                     ^   required: array or java.lang.Iterable   found:    ASN1Set
Tested with:

Gradle 6.1.1
Android Gradlew Plugin 3.5.3
versionCompileSdk = 28
versionBuildTools = '28.0.3'
versionMinSdkVersion = 16
versionTargetSdk = 23
Samsung Galaxy Tab S3 9.7 API 28

Thanks again!


Don't delete ClearML jobs S3 bucket files on staging deployments

They will help with troubleshooting tests - and enabling us to re-run them.  We should be able to use the ASPNETCORE_ENVIRONMENT=Staging env parameter to key off of.

Took a different turn - now just don't delete S3 bucket files if the build faulted - that allows us to recreate what happened and debug.


[CBC Gem] Broken regex

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2021.12.25. (update instructions)
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
Canada
Description
No CBC Gem videos can be downloaded to an error with the regex added in #1913 by @DavidSkrundz
Not sure what's causing this. The regex is bad but not sure why exactly.
Verbose log
[debug] Command-line config: ['https://gem.cbc.ca/media/schitts-creek/s06e01', '-v']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, err utf-8, pref UTF-8
[debug] yt-dlp version 2021.12.25 [87e049962]
[debug] Python version 3.10.1 (CPython 64bit) - Linux-5.15.10-arch1-1-x86_64-with-glibc2.33
[debug] exe versions: ffmpeg 4.4.1 (setts), ffprobe 4.4.1, phantomjs 2.1.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
[debug] Using fake IP <IP_ADDRESS> (CA) as X-Forwarded-For
[debug] Loading cbcgem.claims_token from cache
[debug] [gem.cbc.ca] Extracting URL: https://gem.cbc.ca/media/schitts-creek/s06e01
[gem.cbc.ca] schitts-creek/s06e01: Downloading JSON metadata
[gem.cbc.ca] schitts-creek/s06e01: Downloading JSON metadata
[gem.cbc.ca] schitts-creek/s06e01: Downloading m3u8 information
[gem.cbc.ca] schitts-creek/s06e01: Downloading secret XML
ERROR: invalid group reference 11 at position 1
Traceback (most recent call last):
  File "/home/makeworld/.local/pipx/venvs/yt-dlp/lib/python3.10/site-packages/yt_dlp/YoutubeDL.py", line 1352, in wrapper
    return func(self, *args, **kwargs)
  File "/home/makeworld/.local/pipx/venvs/yt-dlp/lib/python3.10/site-packages/yt_dlp/YoutubeDL.py", line 1421, in __extract_info
    ie_result = ie.extract(url)
  File "/home/makeworld/.local/pipx/venvs/yt-dlp/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 599, in extract
    ie_result = self._real_extract(url)
  File "/home/makeworld/.local/pipx/venvs/yt-dlp/lib/python3.10/site-packages/yt_dlp/extractor/cbc.py", line 371, in _real_extract
    formats.extend(self._find_secret_formats(formats, video_id))
  File "/home/makeworld/.local/pipx/venvs/yt-dlp/lib/python3.10/site-packages/yt_dlp/extractor/cbc.py", line 343, in _find_secret_formats
    'url': re.sub(r'(QualityLevels\()\d+(\))', fr'\1{bitrate}\2', base_url),
  File "/usr/lib/python3.10/re.py", line 209, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/usr/lib/python3.10/re.py", line 326, in _subx
    template = _compile_repl(template, pattern)
  File "/usr/lib/python3.10/re.py", line 317, in _compile_repl
    return sre_parse.parse_template(repl, pattern)
  File "/usr/lib/python3.10/sre_parse.py", line 1036, in parse_template
    addgroup(int(this[1:]), len(this) - 1)
  File "/usr/lib/python3.10/sre_parse.py", line 980, in addgroup
    raise s.error("invalid group reference %d" % index, pos)
re.error: invalid group reference 11 at position 1

Maybe this is the issue:
In #2020 the regex was updated:
-                    'url': re.sub(r'(QualityLevels\()\d+(\))', fr'\<1>{bitrate}\2', base_url),
+                    'url': re.sub(r'(QualityLevels\()\d+(\))', fr'\g<1>{bitrate}\2', base_url),

@pukkandan closed the PR in favour of b69fd25, which updates it a different way:
-                    'url': re.sub(r'(QualityLevels\()\d+(\))', fr'\<1>{bitrate}\2', base_url),
+                    'url': re.sub(r'(QualityLevels\()\d+(\))', fr'\1{bitrate}\2', base_url),

Ok I tested myself and can confirm this was the issue. If #2020 was implemented this issue would be fixed.

oh! because the bitrate is a number 🤦

Yeah that makes sense. Not sure if the g is needed but the angle brackets are at least. Probably would be good to leave the g in just in case.

yes. g is needed. Backref can be either \1 or \g<1>. But since bitrate is a number, \1{bitrate} got interpretted as a group


Unix.Unix_error(Unix.ECONNREFUSED, "connect", "") fails silently

This tool seems very promising! Thanks for making the work available.
I'm trying to get it configured initially. I suspect I'm doing something wrong in the configuration, and I'll keep investigating that, but this behavior seems undesirable regardless, so I figured it merited a report.
When I run benchpress in its currently configured state with default verbosity, I get
$ benchpress run -c config.sexp --task test-on-raft
/bin/sh: 1: z3: not found
/bin/sh: 1: cvc4: not found
testing with 1 provers, 0 problems…
OK
STAT:
provers
----------
sat
----------
unsat
----------
sat+unsat
----------
errors
----------
unknown
----------
timeout
----------
memory
----------
total
----------
total_time
ANALYSIS:
provers
----------
improved
----------
ok
----------
disappoint
----------
bad
----------
errors
----------
total

and a clean exit code. When I pump to max verbosity, I find
[2021-01-26T19:34:15|t0] [info:] run-main.main for paths
[2021-01-26T19:34:15|t0] [debug:api]
  create client cl_id=0 host="<IP_ADDRESS>" port=8090
[2021-01-26T19:34:15|t0] [debug:]
  get-cmd-out "grep -c processor /proc/cpuinfo"
[2021-01-26T19:34:15|t1] [debug:] send progress api to the server
[2021-01-26T19:34:15|t1] [debug:api] make API call task_update
[2021-01-26T19:34:15|t1] [debug:]
  error when trying to connect to API: Unix.Unix_error(Unix.ECONNREFUSED, "connect", "")
[2021-01-26T19:34:15|t0] [debug:] par-map: create pool j=3
[2021-01-26T19:34:15|t0] [debug:] par-map: stop pool
testing with 1 provers, 0 problems…
[2021-01-26T19:34:15|t0] [debug:] par-map: create pool j=1
[2021-01-26T19:34:15|t0] [debug:] par-map: stop pool
[2021-01-26T19:34:15|t0] [info:]
  benchmark done in 0.072s, uuid=dc58297a-da7a-4fc2-bc4a-02f304d739d6
[2021-01-26T19:34:15|t0] [debug:] saving metadata…
[2021-01-26T19:34:15|t0] [debug:] closing db…
OK
STAT:
provers
----------
sat
----------
unsat
----------
sat+unsat
----------
errors
----------
unknown
----------
timeout
----------
memory
----------
total
----------
total_time
ANALYSIS:
provers
----------
improved
----------
ok
----------
disappoint
----------
bad
----------
errors
----------
total

So it looks like something in my misconfigured system is causing the connection to be refused. But instead of failing with an error, benchproess is reporting everything to be OK.
This is running on an install pinned to master. My system (although not relevant for the silent error):
Linux system76-pc 5.8.0-7630-generic #32~1609193707~20.04~781bb80~dev-Ubuntu SMP Tue Jan 5 21:22:25 U x86_64 x86_64 x86_64 GNU/Linux

Oh, sorry about that. The API thing is a bit misleading and not especially critical. What it means is that benchpress (the tool that runs provers, and is ephemeral) tries to contact benchpress-server to tell it all about this new task (so that the web API can show the list of active tasks). It's not a fatal error because the web server is not required for actual use, and results will be stored anyway (in some XDG directory, on my machine it's ~/.local/share/benchpress, as returned by benchpress dir state).

Oh, sorry about that. The API thing is a bit misleading and not especially critical. What it means is that benchpress (the tool that runs provers, and is ephemeral) tries to contact benchpress-server to tell it all about this new task (so that the web API can show the list of active tasks). It's not a fatal error because the web server is not required for actual use, and results will be stored anyway (in some XDG directory, on my machine it's ~/.local/share/benchpress, as returned by benchpress dir state).

Ah! That makes sense. Thanks :) So if I had benchpress-server runing, then I wouldn't have this, presumably! So the lack of any results is due to something totally unrelated. Thank you for explaining!

Ah! That makes sense. Thanks :) So if I had benchpress-server runing, then I wouldn't have this, presumably! So the lack of any results is due to something totally unrelated. Thank you for explaining!

Yes, that's how it should be. You can try running benchpress-server to see if it makes  a distinction (tbh the list of active tasks in the web UI is very, very poorly implemented anyway). A running instance can be found here if you want to see what it looks like.

Yes, that's how it should be. You can try running benchpress-server to see if it makes  a distinction (tbh the list of active tasks in the web UI is very, very poorly implemented anyway). A running instance can be found here if you want to see what it looks like.


Update fb data-href with current page url

@longhotsummer

We need to check if the page is embedded, and share THAT url. Also, we need to do it before Facebook does its magic to turn that FB share thingy into an actual button.
You'll have to check if window.parent.location is available to a child iframe.
If the page isn't embedded, then just use the existing setting.


Issue/1451 improve performances of lsm_service_resources_list (#6868)

Pull request opened by the merge tool on behalf of #6868

Merged in 99a276e6796ed2b5837b26832ef22b17421a9049


Test Referral System Screens & report which data endpoints needed

Test Referral System Screens & report which data endpoints needed

Front-end works 100% like in the design, thanks to @alexsirbu04
Referral Backend Endpoints:

Total amount of referrals
Total amount of SocX Coins earned through referral’s
Invite URL
Invite Code

Question @ChristBKK: Should the message when sharing be fixed or should it come from backend, to be different for every user?

@alexcroitoru95  I think we are fine with a fixed message. Can we do the username as a variable flexible?


Clean up subdirectories when pruning

The pruning functionality included in this gem makes it easy to clean up old screenshots.
By configuring Capybara::Screenshot.register_filename_prefix_formatter, you can set your own path for screenshots to be captured at, which may include a more complicated directory structure (for example, for one of my projects, we want to organise screenshots based on the spec file that generated them, with the filename including the line number of the example).
At the moment, Pruner only cleans up *.{html,png}, meaning that more complex directory structures are not pruned. This switches to using the glob **/*.{html,png}, delving into subdirectories, and then deleting any empty subdirectories at the end.

Thanks for this @timrogers.
I like this change, but am a little worried about the implications of this. It seems a bit dangerous that we would delete files in folders that we have no idea are related to the gem itself.  Would it not be better to allow a custom path to be provided, or perhaps a flag to enable directory recursive wildcard pruning?

Hmm, you're right. I'm making the assumption here that you only store screenshots within the directory structure, but it's correct that you might store other things too. I'll look at making recursive pruning optional.

Are the failures anything to do with me by the way? It looks like the message raised by Capybara has changed to mention a "visible link or button".


Rewrite XQC API version to 0.2.0 and add User-Agent

Context:
The current version of StrawberryFields sends an incorrect version header to the Xanadu Quantum Cloud API.
Description of the Change:

Update the Accept-Version header of requests sent from the strawberryfields.api.connection module to 0.2.0 instead of 1.0.0
Add a custom User-Agent string which sends a header in the standard format StrawberryFields/0.17.0 where 0.17.0 is the current version of StrawberryFields

Benefits:

Allows compability with the XQC platform in future iterations where API versioning will be more strict
The User-Agent string gives important contextual information to the XQC API which can be used to provide custom behaviour in the future (for example, rewriting behaviour in the case of problematic requests, or providing deprecation notices in the event of lifecycle changes in the API)

Possible Drawbacks:
N/A
Related GitHub Issues:
N/A

@antalszava @thisac Yeah, that's the idea. Depending on the speed of work on our end they may be frequent, but how you decide to release these on your end is up to you. For example we'll have version 0.3.0 coming out soon with our new device API, which will give you access to dynamic device information, but maybe you don't have time to integrate that on your side for a while. That's fine because we'll continue to support old versions for a period.

@jswinarton before you merge this in, can you update the changelog? Thanks!


Automated cherry pick of #4326: fix: baremetal diskconfig empty adaptor index

Cherry pick of #4326 on release/2.12.
#4326: fix: baremetal diskconfig empty adaptor index

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.12@2835fed). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release/2.12   #4328   +/-   ##
==============================================
  Coverage                ?   6.85%
==============================================
  Files                   ?     501
  Lines                   ?   85121
  Branches                ?       0
==============================================
  Hits                    ?    5839
  Misses                  ?   78789
  Partials                ?     493

Flag
Coverage Δ

#aFlag
6.85% <ø> (?)

Impacted Files
Coverage Δ

pkg/compute/baremetal/types.go
0% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2835fed...481b8cf. Read the comment docs.


Android  How to generate asserts/envs/flower_road_no_sun_2k/m0_nx.rgb32f ?

When I try android sample : textured-object,  it needs envs/flower_road_no_sun_2k/m0_nx.rgb32f , I didn't find documents to illustrate how to generate this file ,  how can i get it ？
private fun loadIndirectLight(assets: AssetManager, name: String, engine: Engine): Pair<IndirectLight, Texture> {
    val (w, h) = peekSize(assets, "$name/m0_nx.rgb32f")
}

Please use the Discussions tab for questions. It's generated at build time by our Gradle plugin which itself invokes cmgen: cmgen -x out_dir/ envmap.hdr

Ok, thanks,  I noticed Discussions tab, I will use it later.


webRTCMultipleRoutesEnabled is deprecated since Chrome 48

privacy.network.webRTCIPHandlingPolicy should be used instead
Ref: https://developer.chrome.com/extensions/privacy

Refer to README.md.
In Chromium version 48+, the extension provides user control over webRTCIPHandlingPolicy, defaulting to default_public_interface_only.
In older versions of Chromium, legacy options are supported. This includes webRTCMultipleRoutesEnabled for Chromium version 42 - 47, and webRTCNonProxiedUdpEnabled for Chromium version 47.
To clarify, webRTCMultipleRoutesEnabled is used only if the version of Chrome is below 48.


sth.columns() data in incomplete when RETURNING is used

Hi,
import Sqlite from "better-sqlite3";

const dbh = new Sqlite( ":memory:", {} );

dbh.exec( `
    CREATE TABLE IF NOT EXISTS"test" (
        "id" integer PRIMARY KEY NOT NULL
    )
` );

var sth = dbh.prepare( `SELECT * FROM "test"` );
console.log( JSON.stringify( sth.columns() ) );

var sth = dbh.prepare( `INSERT INTO "test" ("id") VALUES (1), (2) RETURNING *` );
console.log( JSON.stringify( sth.columns() ) );

Output:
[{"name":"id","column":"id","table":"test","database":"main","type":"integer"}]
[{"name":"id","column":null,"table":null,"database":null,"type":null}]

In second case columns data is incomplete, it doesn't contains type specification.
Is it possible to return full result columns description?

Unfortunately this seems to be a bug (or at least an oversight) by the SQLite3 team. I would bring up the issue with them.

Did you forwarded this issue to sqlite or I should do this?

You can do it if you want to.
Mention that the column metadata interfaces such as sqlite3_column_origin_name() and sqlite3_column_decltype() don't work with the RETURNING clause.

This seems to be fixed in version 7.4.3

seems, that fixed

issue can be closed


@shopify/address GraphQL server is down

Overview
https://atlas.shopifycloud.com/graphql is down now.
@shopify/address is using GraphQL for fetching addresses.
https://github.com/Shopify/quilt/blob/e955ed8c7d66875ddf006c9c226c4f68ff60fa02/packages/address-consts/src/index.ts#L96

Looks resolved now 👍

Looks resolved now 👍


Tag for project

Please have a look at the https://help.github.com/en/github/administering-a-repository/classifying-your-repository-with-topics — the topics describe a repository in GitHub.

https://cdn1.savepice.ru/uploads/2020/6/28/523f0c8ff3de4787152058d0816e8cd1-full.png
(Topics)
https://cdn1.savepice.ru/uploads/2020/6/28/50b3665206438db7b0d6514586414438-full.png

I have added a "forth" tag. I hope that helps.


Link to #1 problems

It go to negative number past 0 in tries!

I think it is going to be good now

done.


Request dedicated GitHub repo for code samples

Your GitHub appears to be a dumping ground for code snippets, but I sure people would like better examples that match to real world use cases and have someone clean and organize the GitHub.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9a5cfa38-0e6c-4346-dafc-84ea5c513fcf
Version Independent ID: c6787f0f-3e9a-6efb-0e6e-5ccb957d3f4a
Content: File uploads in ASP.NET Core
Content Source: aspnetcore/mvc/models/file-uploads.md
Service: unspecified
Product: asp.net-core
GitHub Login: @ardalis
Microsoft Alias: riande

Thanks @tony-long ... This will improve when the topic is addressed on the overhaul/update on https://github.com/aspnet/Docs/issues/5331.
Let's leave this issue open, and it will close when the PR merges.

@tony-long keep in mind the primary use of the repo is to contain snippets that are imported into the produced documents. Providing samples is secondary.

Thanks for the quick response – I’m very impressed with all of you guys!

From: Rick Anderson<EMAIL_ADDRESS>Sent: Friday, May 25, 2018 9:04:16 PM
To: aspnet/Docs
Cc: tony-long; Mention
Subject: Re: [aspnet/Docs] Organize Your GitHub (#6611)
@tony-longhttps://github.com/tony-long keep in mind the primary use of the repo is to contain snippets that are imported into the produced documents. Providing samples is secondary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/Docs/issues/6611#issuecomment-392234686, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHqJbCqvs8OdAVt2zq6xnC4RkQsFr6_Iks5t2NRAgaJpZM4UOrju.

@SyntaxC4 @dend 	this is a frequent ask. Can you share the plans?


持续写入时，一些老数据会查不到，但是重启后又能够被正确查询(When writing continuously, some old data can not be queried, but it can be queried correctly after restart)

持续写入时，能被查询到的数据总量维持在一定的阈值内，但是重启后又能够查询到之前写入的所有数据(When writing continuously, the total amount of data that can be queried remains within a certain threshold, but all of the data can be queried correctly after restart)

fix this bug in pr

fixed in master and rel/0.11


Get NearbyPokemon expiration-time and position

Hi,
how can i get the expiration-time and position of an pokemon in the nearby-list of a map-cell?
The only information i get are DistanceMeters (all time null), EncounterId and PokedexNumber.
Thank you for your help :)

I've been using WildPokemon and MapPokemon for positions. They both give the Latitude and Longitude positions.
For Lured Pokemon (gotten from LureInfo.ActivePokemonId under a Fort/Pokestop), I just use the position of the Pokestop at the moment. Not sure if there is a way to get the actual location.

#243 my comment

Thank you. So i think i need to move the player to get all the pokemons around a position right?
But i often got the problem that WildPokemon and MapPokemon are empty, in positions where some Online-Map-Viewer show some pokemons.
Can someone give me a code-snippet about how i can get all catchable Pokemons in a radius of 100m?

api.Heartbeat(function (err, hb) {
        var mapPokemon = [];
        var nearbyPokemon = [];
        var pokeStops = [];

        if (err) {
            console.log(err);
            return callback({ nearbyPokemon : nearbyPokemon, mapPokemon : mapPokemon, pokeStops : pokeStops });
        };

        // NearbyPokemon
        for (var i = hb.cells.length - 1; i >= 0; i--) {
            if (hb.cells[i].NearbyPokemon[0]) {
                var pokemon = api.pokemonlist[parseInt(hb.cells[i].NearbyPokemon[0].PokedexNumber) - 1];
                nearbyPokemon.push(pokemon);

                console.log('[+] There is a ' + pokemon.name + ' at ' + /*hb.cells[i].NearbyPokemon[0].DistanceMeters.toString() +*/ ' meters');
            }

            // Pokestops
            for (var j = hb.cells[i].Fort.length - 1; j >= 0; j--) {   // You should check if it is near enough to use!!
                var fort = hb.cells[i].Fort[j];

                // 0 = GYM, 1 = PokeStop
                if (fort.FortType == 1 && fort.Enabled) {
                    pokeStops.push(fort);
                }
            }
        }

        if (nearbyPokemon.length == 0) {
            console.log('[+] There is no pokemon near you');
        }

        // Show MapPokemons (catchable) & catch
        for (i = hb.cells.length - 1; i >= 0; i--) {
            for (var j = hb.cells[i].MapPokemon.length - 1; j >= 0; j--) {
                var currentPokemon = hb.cells[i].MapPokemon[j];
                mapPokemon.push(currentPokemon);

                var pokedexInfo = api.pokemonlist[parseInt(currentPokemon.PokedexTypeId) - 1];
                console.log('[+] There is a ' + pokedexInfo.name + ' near!! I can try to catch it! ');
            }
        }
}}


Model Auto Detect with config object, first draft, works fine.

Waiting for your comments / changes / ideas
Config Object location (for now, first idea of mine):

The config object looks like this:
using System.Collections.Generic;
using SysSslProtocols = System.Security.Authentication.SslProtocols;

namespace FluentFTP {

	public class FtpAutoDetectConfig {

		/// <summary>
		/// Use a new cloned FtpClient for testing connection profiles (true) or use the source FtpClient (false)
		/// </summary>
		public bool CloneConnection { get; set; } = true;

		/// <summary>
		/// Find all successful profiles (false) or stop after finding the first successful profile (true)
		/// </summary>
		public bool FirstOnly { get; set; } = true;

		/// <summary>
		/// Also try the very seldom used Implicit mode
		/// Default is try implicit, otherwise many would need a code change
		/// as per the previous versions of AutoDetect.
		/// Recommendation: Change this default to "false"
		/// </summary>
		public bool IncludeImplicit { get; set; } = true;

		/// <summary>
		/// Do not try the insecure unencrypted mode (even if it might work)
		/// Default is allow insecure, otherwise many would need a code change
		/// as per the previous versions of AutoDetect.
		/// </summary>
		public bool RequireEncryption { get; set; } = false;
		/// Recommendation: Change this default to "true"

		public List<SysSslProtocols> ProtocolPriority = new List<SysSslProtocols> {
			SysSslProtocols.Tls11 | SysSslProtocols.Tls12,
			// Do not EVER use "Default". It boils down to "SSL or TLS1.0" or worse.
			// Do not use "None" - it can connect to TLS13, but Session Resume won't work, so a successful AutoDetect will be a false truth.
		};

	}
}

Looks good, thanks!

I think we should leave the old function signatures so it does not break the cases where people are using them. Maybe in a later release we can get rid of them. This is so we have a softer migration.


Policy to Trigger on PR Comment

what

Added a new trigger policy

why

Trigger a spacelift stack when a comment is added to a PR

references

Related to https://github.com/cloudposse/github-action-atmos-affected-trigger-spacelift

/terratest


upload pictures convert to webp

Is your feature request related to a problem? Please describe.
for help to speed up the site change image format to webp

all image is convert to webp
gif annimation stop to work

add in FAQs
I posting a animated images and the animation don't work ?
it's normal all uploaded image is convert to webp (for pages speed loading)


StaticTopLevelPolicyElementEvaluator instantiation problem.

Hi. i'm trying to create a custom policy provider. i need to use
@Value("classpath*:**/policies/**.xml)
private Resource[] resources;

and use those resources as files for policy providing. its a spring resource thing.
but meanwhile in the process i'm facing:
protected StaticTopLevelPolicyElementEvaluator getPolicy(String policyId,
			Optional<PolicyVersionPatterns> policyPolicyVersionPatterns) throws IndeterminateEvaluationException {
...
}

what i read at mongodb policy provider reference or CorRefPolicyProvider code i see a static class called PolicyEvaluators which is responsible for instantiating this. but this class is in core-pdp-engine and in wiki says that i should have core-pdp-api dependency. so my question is shall i go and implement my own PolicyEvaluator or i should use the one in core-pdp-engine to instantiate it?

StaticTopLevelPolicyElementEvaluator is a very generic interface for a policy evaluator. The PolicyEvaluators#getInstance(...) methods are just some convenient ways to create such type of object from a XACML/XML-schema-derived Policy(Set), parsed with JAXB framework. If you indeed use XML/JAXB classes as input, then yes, it is a good idea to reuse PolicyEvaluators helper class; and in this case you can just replace core-pdp-api with core-pdp-engine as dependency in your POM, because core-pdp-engine already depends on core-pdp-api.
If you don't use XACML literally (you may use a JSON variant of your own or some kind of simplified policy format for convenience), or you are not using JAXB for XML-to-Java mapping, it may not be a good idea (not efficient) to use PolicyEvaluators as is.
In any case, you do not have to PolicyEvaluators in all cases (it is just a helper class), and core-pdp-api is just the minimum required dependency to implement a PolicyProvider.

thanks for answer. this helper class helps a lot. i'm going to reuse it.


Use the $start function to register the console_error_panic_hook

This would be a nice usability improvement.
Probably depends on https://github.com/rust-lang-nursery/rust-wasm/issues/108, I suppose.

Yes please, I need a $start function for nebulet.


Feature Request - support for YubiKey 4 and YubiKey 4 Nano

Currently the Enrollment Station appears not to support the 4 and 4 Nano. If you guys need some devices to test with, please e-mail<EMAIL_ADDRESS>and I'd be happy to send as many as you need. Great work on this project!

Thanks a lot Chris. I will email you so that we can fix this and #7


maximizing the windows on start.

I am able to maximize the windows by selecting "Maximize WIndows" from Command Palette but how can i set it default in the config file ?

Hi @HiCodin ,
Is the editor.fullScreenOnStart configuration property not working for you? I'm wondering if there has been a regression from the fix in #195
Also, did you build from source? Or download a release binary?

@extr0py ah I failed to properly specify my requirement. editor.fullScreenOnStart is working as intended. But What I meant for this request is that instead of choosing Maximize Window from the Command Palette every time I open Oni, is there a way to set it default or have Oni remembered the last opened window size ?

Ah thanks for the clarification, @HiCodin
Yes, I agree, having a way to persist some of this state (like window position) on close and then reopen would be very helpful. I'll keep this open to track that. We can start with just the window position & size.

@extr0py Thanks ! is there anyway I can help you with ? Really liking this. :)

@HiCodin, if you're willing to implement this yourself and submit a Pull Request here are a couple pointers.
Implement it ourselves: https://github.com/electron/electron/issues/526
or
Use library: https://github.com/mawie81/electron-window-state (might be abandoned)
Note that we already have a config.js (look at Config.ts) which we could use to persist the size/position.  Also, main.js (at the root of the project) is where the closed and window-all-closed events are handled, although our Config instance is only available from the Oni process main.js creates so you'd have to use events like 'rebuild-menu' to communicate with it.  You can send events to Oni with mainWindow.webContents.send("<event name>", <args>) or send events to main.js with ipcRenderer.send("<event name>", <args>).  Menu.js has examples of sending to Oni, browser/src/index.tsx has examples of sending to main.js.  I'm guessing you'd want to send a reset-size event after the Config is done loading and send a save-size event during the close event.

@keforbes alright. I'll take a look at the things you mentioned. Thanks !

Great tips, @keforbes ! Thanks!
I was thinking about the config.js approach when I was looking at showing some notification UI for the language service providers - one challenge is that, with our current format (js), it might be difficult to write-back because it is unstructured.

Write-back to config.js - there'd be some interesting challenging issues here. It might be technically possible by parsing the AST and dropping in new config values, but I think this would be very difficult to get correct in general.
Use a separate json file (ie, like persisted.json) to store these persisted values. We could add an API like setPersistedValue("editor.windowDimensions")/getPersistedValue("editor.windowDimensions").
Use the localStorage API . This provides a convenient way to read/write to a key value dictionary, but would only be available in the BrowserWindow process. Otherwise, it'd be similiar to the above.

With regard to the editor.fullScreenOnStart option. It makes Oni "true" full screen instead of just maximized whereas I just really wanted it maximized.

Unless we really want to keep track of the dimensions from the last window opened we can close this issue.

@bryphe After option for maximization for Oni was merged, would we really want to keep track of the dimensions of the last window opened?
If not, this issue could be closed since @HiCodin's problem actually was maximization (same as mine).

@badosu , sounds good. I was thinking about having some potential configuration options persist, but we have #571 tracking that anyway. And as you mentioned this has a setting so isn't as pressing anymore. I'll go ahead and close it out, thanks for checking in!


Print "entering directory" message to mimic make and pacify emacs' compilation-mode

Since ninja chdir's into the output directory & refers to source files using ../../ prefixes, emacs' compilation-mode (and in particular, next-error) stopped working.  I originally solved the problem by having my ninja-wrapping shell-script emit an appropriate line, but this is more principled:
diff --git a/src/ninja.cc b/src/ninja.cc
index c70aa43..cb7d2fa 100644
--- a/src/ninja.cc
+++ b/src/ninja.cc
@@ -449,6 +449,7 @@ int main(int argc, char** argv) {
 #endif
       Fatal("chdir to '%s' - %s", working_dir, strerror(errno));
     }
+    printf("ninja: Entering directory `%s'\n", working_dir);
   }

   bool rebuilt_manifest = false;

(note that wrapping the %s with `' is what make does and what emacs looks for, and that the first character there is a back-quote, not an apostrophe)

FWIW, I set my compile command to cd out/Debug && ninja chrome and things seem to work.  But your patch seems ok too.

Ping?
(your approach works fine if emacs gets to see the 'cd' command, but not if a wrapper script is used or -C is used, so I'd still like my patch to land upstream; I've been using it for months and it works great)

Sorry for the delay, pushed.  (With an additional comment.)


⚠ ClamAV has degraded performance

In d7d38fd, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 59 ms

Resolved: ClamAV performance has improved in e33509a.


Hide translate button for FinalFormSearchTextField

A project is using the component and it was found unnecessary to have the translate button. Should be fine to hide the search button for this search field component in general.


new error in CI build process which I don't understand

This was a simple update to IMG, but building the LDD now errors. It looks like something else was updated in a different script for LDD building. Perhaps related to a log directory? I'm not sure how to track that down or if I just need to add a log directory somewhere.
https://github.com/pds-data-dictionaries/ldd-img/runs/1432294382

@thareUSGS FYI I am looking into this

@thareUSGS so I think this was just an issue with your branch being slightly out of sync with master. per the last merge for the IM release, I made a couple updates to the CI/CD that were not on your v1820 branch. I rebased the branch and created a new one for your here: https://github.com/pds-data-dictionaries/ldd-img/tree/v1820_rebased . So I would just work off of that.
the "long-running branch" workflow you are using can work great, just make sure you rebase on occasion to make sure you pick up any changes that happen on master.

here is the successful CI/CD run on the new branch: https://github.com/pds-data-dictionaries/ldd-img/actions/runs/379671571


How to call the specific model defined in a models dictionary value list?

As shown below in the example config.json:
https://github.com/fruitbars/simple-one-api/blob/2e02dfae6b65958898c0684fcb86b2d3ead82683/config.json#L18
In this case, I wonder how to call the specific model defined in a models' dictionary value list.
Regards,
Zhao

Got it. Just open http://<IP_ADDRESS>:9090/v1/models and see the models list and then use any of them at will.


Missing pg_tables

Description
Metabase
Error during planning: Unable to fetch table provider for 'pg_catalog.pg_tables': failed to resolve: failed to find table: pg_catalog.pg_tables

Query
WITH table_privileges AS (SELECT NULL AS role, t.schemaname AS schema, t.tablename AS table, pg_catalog.has_table_privilege(current_user, concat('"', t.schemaname, '"', '.', '"', t.tablename, '"'), 'SELECT') AS select, pg_catalog.has_table_privilege(current_user, concat('"', t.schemaname, '"', '.', '"', t.tablename, '"'), 'UPDATE') AS update, pg_catalog.has_table_privilege(current_user, concat('"', t.schemaname, '"', '.', '"', t.tablename, '"'), 'INSERT') AS insert, pg_catalog.has_table_privilege(current_user, concat('"', t.schemaname, '"', '.', '"', t.tablename, '"'), 'DELETE') AS delete FROM pg_catalog.pg_tables AS t WHERE t.schemaname !~ '^pg_' AND t.schemaname <> 'information_schema' AND pg_catalog.has_schema_privilege(current_user, t.schemaname, 'USAGE')) SELECT t.* FROM table_privileges AS t WHERE t.select OR t.update OR t.insert OR t.delete

Hit the same issue with dbt:
Database Error
  Error during planning: Unable to fetch table provider for 'pg_tables': failed to resolve: failed to find table: pg_tables

I'll start taking a look at this one. I suspect it'll be similar to adding the pg_type table.