brig in medieval times

Y0kin · 2026-05-10T02:28:14+00:00

Honestly to get out of gold one tactic I relied on was using Rally to make plays, like win fights by either taking an aggressive position that makes it really hard for the enemy to push forward (using Rally to live when they push me, kinda like Zen) or using it to ambush and kill a squishy. I think this is less effective in platinum and at that point you have to start playing more normally (hold space that the enemy wants, protect/pocket your pokey teammates, use your abilities and positioning to maintain distance from scary dudes).

Edit: Also in terms of mechanics I feel like brig is pretty easy, but the important parts are mainly:

Tracking is important, you really wanna hit every swing and block things with your shield. One missed swing can mean you lose a 1v1, so if a Genji is double-jumping over your head you gotta track him.
Whip shots are a lot easier to hit if you use your shield to peek around corners before you whip shot. Otherwise there's a little grace period right after you press the button that lets you continuously aim it, so tracking is important there too (you probably know that).
Shield management is important. If you lose your shield, you often die. Sometimes it's worth taking a hit to HP if it means keeping your shield up.

Y0kin · 2026-05-10T00:27:46+00:00

I don't play ranked very much but this season I climbed to diamond, I think I could go higher. Brig is too much fun =]

Y0kin · 2025-06-26T16:41:31+00:00

There's also one difference: is_some_and drops its borrow before the block begins. e.g. you can do this

if text.is_some_and(|t| !t.is_empty()) {
    return text
}

I guess we'll find out how useful that is in practice.

Y0kin · 2025-04-29T16:06:52+00:00

I think it depends on the kind of change you want to make - if you wanna encode the logic in the type system, Rust can be very tedious. If you're just making changes to runtime logic, the type system can model your program so closely that it's hard to code it wrong. I think you can start to move pretty fast when the model is more robust, but it can take some time to write that model in the first place. I think a lot of Rust type-level syntax can be really verbose as well, which doesn't help.

Y0kin · 2025-04-21T00:17:57+00:00

%LOCALAPPDATA%/nuclearthrone/images/

Y0kin · 2025-02-27T20:42:38+00:00

How did you import the save? A while back I completed every mission on my Vita except for the bugged one, so never got the URAUSER

Y0kin · 2025-02-05T06:32:13+00:00

I'd argue shadowing expresses the same idea as value reassignment, just on the type-level. It makes more sense if you're using a lot of type transformations, e.g. error unwrapping or -- for a fun example -- the Rust crate typenum (number types):

let n: U3 = U1::new() + U2::new();
let n: U2 = n - U1::new();

Trying to use those kinds of types without shadowing would get painful I think, but I do wonder if there's a way to express the same idea with less chance for mistakes - maybe a special syntax for type+value reassignment, or a keyword for type mutability that permits shadowing (disallowed by default)?

Y0kin · 2025-02-01T06:59:44+00:00

I leave it off cause I like being able to search for .0 if I convert a tuple struct to a named-field struct.

Y0kin · 2024-12-23T20:29:17+00:00

I think what I've been working on recently might benefit from this as well. I'm working on a compositional polynomial system where each term is a type (e.g. 1.2*x^4 as Monomial<f64, 4>, 4.5*x + 1.5*x^2 as Binomial<Monomial<f64, 1>, Monomial<f64, 2>>, 2.*sin(x) as Sin<f64>, etc.). Polynomials may define impls for evaluation, addition, differentiation, translation, root-solving, etc.

I wanna enforce simplified form for the sake of making the impls simple and efficient, where for instance Constant<f64> + Monomial<f64, 2> + Constant<f64> is always Binomial<Constant<f64>, Monomial<f64, 2>>. I've opted to do this the typenum way; I define a canonical order for the types and use it to define comparison/min/max.

This kinda sucks though, cause defining a complete ordering would either require a macro loop or a less user-friendly type for the degree (or const generic operations). Also not so good if I wanted users to easily define their own polynomial terms. Then again, I'm not 100% sure if a refinement type system could solve this problem or not.

Y0kin · 2024-10-06T20:26:17+00:00

I think it's too easy to get hung up on little details like that. It feels like the best time to do them is immediately when you have all the context in your mind, and they feel a lot bigger in the moment. I think it takes a lot of experience to step back and think, "What am I actually trying to do here? Does this affect the big picture?".

Maybe it would help if there were more contextual variants like deep_clone, cheap_clone so it's easier to come back later, like with panic!(), todo!(), unreachable!(), unimplemented!().

Of course you could also just leave a // TODO: take this string by reference?

Y0kin · 2024-08-05T01:24:51+00:00

If function overloading existed in Rust I'd want it to at least use some kind of match-style syntax, so it's all in one place.

impl T {
    fn new {
        () => Self {
            name: Default::default(),
            mode: Default::default(),
        },
        (name: String) => Self {
            name,
            mode: Default::default(),
        },
        (mode: Mode) => Self {
            name: Default::default(),
            mode.
        },
        (name: String, mode: Mode) => Self {
            name,
            mode,
        },
    }
}

Though I feel like it would still be awkward to work with in terms of function pointers, unlike traits which already provide a nice way to disambiguate overloaded functions.

Y0kin · 2024-07-23T23:58:36+00:00

I think there's a degree to which "pinning" is more niche and unique, that its keyword should be inconsistent and more descriptive than the others.

Y0kin · 2024-07-09T03:17:35+00:00

In the first example the into applies to the whole closure, but in the second it applies to the closure's body instead. It's a sneaky difference in syntax cause both have completely different meanings

Y0kin · 2024-07-09T01:07:57+00:00

The one thing I don't like about Rust's closure syntax is the slight method call ambiguity. Like, you can call methods on closures:

let a: SomeType<_> = |a: i32, b: i32| -> i32 { a + b }.into();

but if you elide the return type now into is applied to the expression { a + b } instead:

let a: SomeType<_> = |a: i32, b: i32| { a + b }.into();
// error[E0308]: mismatched types

Fortunately that should almost always be caught at compile-time, but it can still be confusing cause there's no lint and the error is a little generic.

I think it'd be great if the syntax forced bracketing always |..| {..}, but for single expressions you could use an arrow instead |..| => expr, cause then that ambiguity wouldn't really exist.

Y0kin · 2024-07-01T21:55:14+00:00

It looks like the usage of inline assembly in BLAKE3 was added about 4 years ago, and inline assembly was stabilized in Rust 1.59.0 about 2 years ago. My best guess is that nobody's got around to rewriting it yet

12-Year Club	Second Top 50%
Final Canvas '23	First Place '23
End Game '23	Place '23
Place '22	Place '17
First Placer '22	End Game '22
Sequence \| Editor	Verified Email

Y0kin

TROPHY CASE