This example isn't comprehensive, so you can't just copy and paste. However, it should be a good template to base your own solution off. I chose to use React but you can use any framework.
Note: Sentry has a Vite plugin. As of Astro 1.9.0, Astro runs Vite plugins twice during the build process, which results in map files being submitted twice. Until this is resolved, it doesn't seem like an acceptable solution.
| @-moz-document domain("www.funimation.com") | |
| { | |
| div.ribbon, section.header-promo-ribbon-wrap { | |
| display: none !important; | |
| } | |
| main#main-content { | |
| padding: 0px !important; | |
| } |
| /** | |
| * An AI Behavior Tree Decorator written in Angelscript, returns the value of a specified boolean key. | |
| * | |
| * Note that while you can implement TickAI(), in most cases, Decorators rarely need to tick, and | |
| * PerformConditionCheckAI is usually all you need to implement. | |
| */ | |
| class UBTDecorator_ExampleDecorator : UBTDecorator_BlueprintBase | |
| { | |
| default NodeName = "Example Decorator"; |
Each entity in source engine has two hitboxes - one in quake physics world, and another in havok (or vphys) physics world. This second hitbox is called "physics shadow".
Depending on type of the entity one of the hitboxes is dominant. Each frame results of havok physics simulation for barrels, rollermines, vehicles and etc will be copied over quake hitboxes of entities. For NPCs, rockets and elevators state is copied in reverse direction - quake to havok.
Player is special. Normally quake hitbox will overwrite havok shadow, but only if its movement is not blocked by any havok hitboxes. Player's hitbox will be copied in reverse - from havok to quake - if (a) havok hitbox is valid (not stuck in quake world), (b) player is touching a vphys object.
Quickclip works, because in vehicles havok hitbox has collisions masked out for everything except pickups (health, ammo). When you exit a vehicle, collision mask for havok physics should be changed to normal, but only if vehicle is present in the world. Barnacle fo
| #!/bin/bash | |
| # | |
| # /etc/kernel/postinst.d script to sign akmods kmods after kernel upgrade | |
| # | |
| # Author: Michael Goodwin Date: 2016-09-21 | |
| # 1. Copy this script to /etc/kernel/postinst.d/ and `chmod +x` it | |
| # | |
| # 2. Create signing keys (store these somewhere useful and safe): | |
| # $ mkdir -p /etc/pki/tls/private/mok |
| "set_weapon_mode" attribute documentation | |
| accurate as of TF2 version ~20160327 (updated for ~20190501) | |
| reverse engineering by sigsegv | |
| General Notes | |
| ============= | |
| There are many attributes in the game that map to attribute class "set_weapon_mode", with many different names: | |
| - "fists have radial buff" | |
| - "set cloak is feign death" |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
