there were a lot of events recorded by gharchive.org of which 2,660,756 were push events containing 3,929,892 commit messages that amount to 300,694,594 characters filtered with words.py@e23d022007... to these 72 messages:
Makes Telekinesis + Russian Revolver Interaction more fair (#79740)
Fixes #77238
Basically, you were able to just spam kill people with the russian revolver if you had telekinesis, which isn't really fair. Now, after taking a leaflet out of the the discussion in that issue report, you can still pull off the same party trick... once...
Basically, let's just say that when you focus on firing the gun in your mind... you're also pointing it directly at your mind (your brain (your skull (you instantly die))). This occurs even if the projectile doesn't actually touch you (because that would be hellish to account for) but you're the one who's playing russian roulette man
You still get to do some collateral damage because that's still a very funny interaction but you only get to do it once per life. I don't know if people will be happy to revive you after you "shoot" them. Also, the way it's coded means that you can still leave the revolver on the table and fire it at your foot or something, or just use it normally, as a telekinesis user. This only applies to distance-based firings.
The russian revolver is specifically coded to prevent you from damaging other people, and this was a pretty silly way to sidestep that based on the checks. Instead, let's make it so that you can still do this admittedly funny interaction, but with enough reason to not do it (the reason being that you'll always get fucking blatted).
🆑 balance: After a string of unfortunate incidents, persons with telekinesis have been strongly warned against playing Russian Roulette, as they tend to hyperfixate on the gun a bit too much and end up firing it directly at their head. /🆑
Reworks stop, drop, roll into a gradual, interruptable thing, that repeats until extinguished (#79694)
Related: #78017
Stop drop and roll is no longer instant -5 fire stacks -> stun -> wait.
Now, when you stop drop and roll, every time you roll you will lose 1 firestack.
A roll is triggered every 0.8 seconds. Moving, getting up, or becoming incapacitated / stunned will stop you from rolling. (This number puts it roughly equivalent to its current rate.)
While rolling, your hands are blocked (you cannot use items, hold things, etc.) Additionally, you will roll until all firestacks are cleared.
Getting stunned for 6 seconds because you decide to stop and roll is a little silly. Reasonably you could stop rolling and get back up should the need arise, such as "oh god there's more fire I gotta relocate".
By changing it to a gradual thing, it makes it a bit more reasonable and fair.
- New players who immediately slam "STOP DROP ROLL" because the alert on their screen tells them to are no longer helpless for 6 whole seconds
- People who hit the resist key, intending to interact with something else (such as a bola) are no longer stuck rolling when they did not want to
🆑 Melbert balance: Stop, drop, and roll no longer instantly clears 5 fire stacks off of you - Instead, it will clear 1 fire stack off of you every time you roll, with a roll every 0.8 seconds. balance: Stop, drop, and roll no longer stuns you for 6 seconds. Instead, it will knock you to the floor while you are rolling. Moving around or getting up will cancel the roll, and you cannot use items while rolling around. balance: Stop, drop, and roll will now repeat until the fire is put out or you get up. /🆑
Fixes Relay Attackers Misfire (#79731)
Fixes #76079
Basically we were both not getting all of the args that we recieve from
COMSIG_ITEM_AFTERATTACK which included the very important
proximity_flag which tells us if the person was in range to actually
hurt us or not. This means that clicking a mob with this element with a
stack of metal from across the room would cause them to aggro, which
makes no sense whatsoever. Let's actually use that proximity check.
We listen for projectiles hitting us separately, don't worry.
It just makes no damn sense, fixes some weird ass behavior.
🆑 fix: Bar Bots (and several other mobs) will no longer aggro on you if you click on them with a "forceful" item from halfway across the room. /🆑
timed move function for autonomous
I can't take it anymore. I'm sick of Xiangling. I try to play Diluc. My Xiangling deals more damage. I try to play Yoimiya. My Xiangling deals more damage. I try to play Cyno. My Xiangling deals more damage. I don't even try to play Dehya. I want to play Klee. Her best team has Xiangling. I want to play Raiden, Childe - they both want Xiangling. She grabs me by the throat. I fish for her. I cook for her. I give her the Catch. She isn't satisfied. I pull Engulfing Lightning. "I don't need this much er" She tells me. "Give me more field time." She grabs Bennett and forces him to throw himself off enemies. "You just need to funnel me more. I can deal more damage with Homa." I can't pull for Homa, I don't have enough primogems. She grabs my credit card. It declines. "Guess this is the end." She grabs Gouba. She says "Gouba, get them." There is no hint of sadness in his eyes. Nothing but pure, no icd pyro application. What a cruel world.
sched/core: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- BOOM
Debugging showed that this only appears to happen when we take the new code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling")
and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0 CPU1 CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
// migrate X to cpu 0
LOCK rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK rq(1)->lock
LOCK rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu && ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu, !VAL)
cpu = select_task_rq(X, X->wake_cpu, ...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1.
(Most of the previous ttwu() races were found on very large PowerPC)
Nevertheless, this fully explains the observed failure case.
Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this.
Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney [email protected] Tested-by: Paul E. McKenney [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Signed-off-by: Ingo Molnar [email protected] Link: https://lkml.kernel.org/r/[email protected]
[CI Fix] The Demonic Frost-Miner will not attack corpses. (#79294)
Fixes #79147.
Prevents the Demonic Frost-Miner from shooting at corpses by returning
early from OpenFire(). Also adds the "gutted" status effect to the
corpses in its arena so it won't try to gut them.
#78826 introduced an unfortunate bug by placing corpses in the Frost Miner's arena. There were a combination of three factors at play here: that the Miner attacks corpses, that it happens to use colossus bolts in its attacks, which dust corpses, and that some unfortunate quirk of life code causes runtimes if, as far as I can tell, a life tick goes off when a mob is at the wrong point in the dusting process. The time this process takes happened to perfectly coincide with the Monkey Business unit test (being the first test that takes a significant period of time), causing it to randomly fail.
So, this fixes a flaky test that has been a pain in the ass for the last five days, is the big thing.
Also, it can't possibly have been intended for the Miner to run around obliterating the aesthetic corpses in its arena within the first 15 seconds of any given round. Completely ruining the mood!
I'll point out that this particular boss may have been forgotten in #77731, which set out to make only the colossus still gib/dust you, but even were that not the case I think it would be a bit silly for the Miner to be busy shooting lifeless corpses when a player shows up to challenge it, rather than standing in its scary ritual circle.
🆑 fix: The Demonic Frost-Miner will no longer run around destroying the corpses in its arena the moment the round begins. /🆑
Adds Paddy, the Security Mech (#79376)
-
Adds a new combat mech, Paddy. Paddy is a modified Ripley MK-I, intended for use by the station's security force. Like the MK-I, the Paddy features an open-air cockpit design (and thus does not protect from ranged weapons), but maintains the speed of the base unit. Constructing a Paddy is similar to constructing a MK-II, though the kit requires combat-mech level research. Sprites by DrDiasyl -- The paddy has an internal cargo bay capable of holding up to four individuals (loaded with a hydraulic claw). If the pilot exits the Paddy, any loaded individuals are likewise ejected. Individuals can attempt to resist their way out of the mech, but it requires the mech to be stationary for 45 seconds. If they do this, all individuals in the holding cell are ejected.
-
Adds a new mech equipment piece, the hydraulic claw. Similar to a clamp, this Paddy-exclusive item can load mobs into the Paddy's cargo bay. Humanoid mobs are handcuffed upon loading. The hydraulic claw is unlocked on the same tech node as the Paddy.
-
Adds a round-start Paddy, carrying one peacekeeper disabler and one hydraulic claw, to each security area on all maps. Round-start Paddys are also pre-locked with security access. Security now has access to a mech charger, and a small bay for it all. Map edits were done by Maurukas.
-
Also did some minor cleanup of various mech-related code. Ripley mech cargo is no longer stored in the mech, but within the "ejector" object. This doesn't have any player-facing changes, but it is easier to organize behind the scenes. additionally, if Ripleys are destroyed now, they drop their stored objects rather than deleting them.
Playing lone security is probably one of the least fun aspects of the game. Arresting any assistant is inevitably setting yourself up against the tide as a whole; You try to stun any one person and they crawl out of the woodworks to get in your way, drag off the arrestee, and probably try to steal your gear.
The Paddy is set up to be functional against low-threat targets, but not particularly good against anything with purpose. The round-start Paddy carries the disabler equipment, as well as the law claw, to detain individuals in a somewhat safe manner. Being that you're inside an exosuit, you're immune to shovespam that plagues the halls, and you don't risk dropping important gear quite as easily.
However, The open canopy gives you no protection at all from ranged attacks, nor from atmos hazards. Being that you're in an exosuit, you cannot use other items or equipment. The AI will have trouble finding you to open a door, due to your name not jumping their camera to your location.
🆑 Zxaber, DrDiasyl, Maurukas add: A new security-focused combat mech, the Paddy, has been added, intended to be particularly helpful for lone sec officers. You will find one in the Security main office, and a replacement can be built with late-game mech research. fix: Ripley MK-I and MK-II mechs no longer qdel their stored items when destroyed. /🆑
Co-authored-by: Vire [email protected]
Hey what if I made Sleeping Carp better at nonlethal takedowns and also deflect with combat mode instead of throw mode (but cost more) (#79517)
It's been a hot minute hasn't it?
When I initially reworked Sleeping Carp, we didn't have combat mode. Now that we do, and that Sleeping Carp has substantially less defensive power to justify having to make a choice between deflection and attacking, it's probably about time we updated this aspect back to what it was before my rework. Sorta.
Now, we can have all the deniability of the previous method, while also letting you reliably protect yourself from ranged attacks at all times while it matters. Because of this, I increased the price up to 17 TC because of this change just to be on the safe side. The higher uptime of projectile immunity while also being able to attack during that time makes this a lot stronger overall.
Secondly, Sleeping Carp presently just isn't as good as a good ol' baton. It takes a lot more hits to accomplish the same task that a baton can. Many people feel like they can't even reasonably fight anyone for fear of the baton, or they would rather use a baton and kill someone at their leisure. So we've updated some of the moves in order to facilitate Sleeping Carp as a substantial contender for 1v1 fighting, and lessen the need for a baton by adding a lot more Stamina damage overall to the various attacks;
Keelhaul: Now a Shove Shove combo. Does literally zero lethal damage, but now temporarily blinds and dizzies the target as well as its previous effects. The amount of lethal damage it did was...extremely small, so this isn't a particularly big loss.
Grabs and Shoves: Deal some amount of stamina damage (20). You need to be in combat mode in order to perform these special attacks (more deniability). Grabbing someone while they have 80 Stamina damage or more will cause them to fall unconscious. Yes, I really did just want to add a Vulcan Nerve Pinch, what do you want from me?
That's it actually. Oh, I guess they are heavy sleepers now too. Because its funny.
I often get told (read: thrown various insults and slurs at me while mentioning this as the justification) that Sleeping Carp is not very strong anymore since it lost all that invisible armor I added way back + I removed the stuns in my initial rework. This made some people upset (I think at least one person wished for my death).
So, having given it at least 2 years, I wanted to recapture parts of what made the older Sleeping Carp (before my rework) strong, some of the benefits of the new version, and introduce a brand new aspect; nonlethal takedowns. This makes it beneficial for pacifists, as well as for kidnapping.
This should not meaningfully make Sleeping Carp any stronger against the things that typically ruin its day. I suspect in a straight joust with a baton, Sleeping Carp will still struggle. But against what should be its strong points (lone targets and ranged weapons), it will be strong once again rather than clumsily unable to do very much at all.
🆑 balance: Harnessing Shoreline Quay (bluespace energy, probably), a mystical energy (total bullshit) that permeates the Astral Waterways (bluespace quantum dimensions, probably), Sleeping Carp users can now once against deflect projectiles with their bare hands when focused in on battle (in combat mode). balance: The Keelhaul technique is now nonlethal (a philosophical acknowledgement of the familial bond of sleep and death), but causes the target to become temporarily blind and dizzy along with its previous effects. balance: Sleeping carp users, while in combat mode, deal Stamina damage with their grabs and shoves. If the target of their grab has enough Stamina damage (80), they are knocked unconscious from a well placed nerve pinch. balance: Sleeping carp users find it very hard to wake up once they fall asleep.... /🆑
msx2_flop.xml: Added 54 items (49 working) and replaced one item with a better dump. (#11698)
- Replaced VS Rotation (Japan) with a better dump. [file-hunter]
- Removed Ultima IV - Quest of the Avatar (Japan, alt disk 2) (disk 2 is from an English translation).
- Removed Vectron (Netherlands) and Vectron (Netherlands, alt) (extracted from a compilation).
- Removed Zoo (Netherlands, alt) and Zoo (Netherlands, alt 2) (hacked versions)
Konami Game Collection Bangai-hen (Japan, alt) [file-hunter] The Legend of Shonan (Japan) [file-hunter] Sailor-fuku Senshi Felis (Japan) [file-hunter] Tempo Typen (Netherlands) [file-hunter] Tenkyuhai Special - Tougen no Utage (Japan) [file-hunter] Tenkyuhai Special - Tougen no Utage II (Japan) [file-hunter] Thanatos (Japan) [file-hunter] Tokimeki Sports Gal (Japan) [file-hunter] Tominaga Koukou Tantei-bu (Japan) [file-hunter] Trilogy Kuki Youka Shinden (Japan) [file-hunter] The Tucs (Japan) [file-hunter] Tulip Ichigou (Japan) [file-hunter] Ultima II - The Revenge of the Enchantress (Japan) [file-hunter] Undead Line (Woomb) [file-hunter] Wizardry Scenario #3 - The Legacy of Llylgamyn (Japan) [file-hunter] Xak - The Art of Visual Stage (Japan, Woomb) [file-hunter] Yoshida Koumuten Data Library Vol. 2 (Japan) [file-hunter] Yoshida Koumuten Data Library Vol. 3 (Japan) [file-hunter] Yume Pro RPG Shaon-ban (Japan) [file-hunter] Yumeji Asakusa-Kitan (Japan) [file-hunter] Yuurei-kun (Japan) [file-hunter] Zoo (Europe) [file-hunter] GAME100 (Japan) [file-hunter] Go! Volcano [NAGI-P SOFT] Las Aventuras de Rudolphine Rur (Spanish) [Dwalin] MSX Light [MSXdev] Siege [NAGI-P SOFT] Teddy's in Action Part 2 [file-hunter] Terrahawks [file-hunter] Tetravex (Netherlands) [file-hunter] Tetris Master (Japan) [file-hunter] Tetris Master - Operation Maison Ikkoku (Japan) [file-hunter] Tetris Master - Operation Orange Road (Japan) [file-hunter] Tetris Master - Operation Ranma 1/2 (Japan) [file-hunter] Tetris Master - Series 1 Ranma 1/2 (Japan) [file-hunter] Thunderbirds are Go (Netherlands, promo) [file-hunter] Thunderbirds to the Rescue (Netherlands, promo) [file-hunter] Tile Golf [NAGI-P SOFT] Triplex (Netherlands) [file-hunter] Trivial Pursuit (Netherlands) [file-hunter] Trivial Pursuit - Aanvulling Jaareditie 1995 (Netherlands) [file-hunter] Tunez: Garfield Edition [file-hunter] The UHF Painter (Italy) [file-hunter] War World FM-PAC Demo (Netherlands) [file-hunter] Wiz Kids (Japan) [file-hunter] Yupipati (demo) [file-hunter] Zombie Night [Alberto Sgaggero] Zoo Rally (Russia) [file-hunter] Zoto (Germany?) [file-hunter]
HBI-V1 Video Digitizer (Japan) [file-hunter] Himitsu no Hanazono (Japan) [file-hunter] Veldslag (Netherlands) [file-hunter] Zeeslag (Netherlands) [file-hunter] Zeeslag (Netherlands, demo) [file-hunter]
Eoehoma Firearms (& friends) (#2315)
Holy shit, this should not have taken a year to make
Adds the E-10, E-11, E-40, E-50, and E-60 to the game. Weapons manufactured by defunct firearms company Eoehoma Firearms.
Founded in 77 FS, Eoehoma was a early pioneer of ‘hybrid’ Solarian and Kalixcian laser weapons. The company went bankrupt due to increasingly poor and risky decision making, and all of it's patents were bought out by Nanotrasen. While Nanotrasen's Emitters bear a striking resemblance to the E-50, otherwise Nanotrasen has not produced any of Eoehoma's old weapons, instead focusing on Sharplite designed weapons.
Other changes:
- NT and Sharplite weapons have different fire sounds from each other
- Laser weapons buffed to 20 -> 25 damage
- Pulse shots don't destroy walls and are now 50 -> 40 damage
- Emitter shots now do 30 -> 60 damage
- Various grammar fixes
- Removes some non-lore compliant mentions
- Adds a manufacturer indicator to many guns
- Ports tgstation/tgstation#60353
- Resprites various laser weaponry, notably the pulse guns.
- Deathsquad and ERT/LP hardsuits have been redone
ceredits to tetrazeta for the unfinished deathsquad sprite, i simply
finished it and touched it up
One of the last things i remember the old leads planned was to buff lasers to make them stand up to the various ballistics better. Also allows Pulse Rifles to be more used in events by nerfing them to not be comedically overpowered. Now they are just Overpowered.
More ruin content and such. I'm sure the maptainers will make good use of this stuff.
And sprites, i fucking love sprites
🆑 retlaw34, tetrazeta add: Eoehoma Firearms, a new guns manufacturer! add: ERT and "Asset Protection" Hardsuits have gotten a new look! add: New laser fire sounds
balance: Lasers now do slightly more damage balance: Pulse rifles don't destroy walls anymore and do slightly less damage, and have lost their stun mode. balance: Emitters do 60 damage and create turf fires on hitting a non-supermatter object. fix: Various laser weapons that had broken autofire (E-TAR and the Tesla Cannon) now work
spellcheck: Grammar on some descriptions was corrected. /:cl:
Signed-off-by: retlaw34 [email protected] Co-authored-by: Mark Suckerberg [email protected] Co-authored-by: thgvr [email protected]
Does Penance So The Ghosts Go Away (#2442)
"This is AI c-Caldwell - Reporting return of essential station functions to Minya League Installation 'Trifuge' following pirate attack - ///far too long ago/// - All vessels are invited to dock and partake of our services, including an active Ore Refinery, world class bar, and purchasable storefronts //please come, I'm so lonely/// The Minya League, and myself, would like to extend our gratitude to ///-who else but me?///. Installation 'Trifuge' is located in orbit of the Star 'Anselhome', at the L5 point of Anselhome and habitable world, 'Hofud'. Noting active travel advisory - Hofud is currently ///nothing but ash left by monsters///. Independent Vessels are advised to avoid landing until Minya League Ships can deliver disaster relief to the planet ///not that they'll be coming....///"
"This message will repeat in approximately 20 galactic standard minutes"
Remaps the shitty outpost 1 (indie space) outpost that I made like 6 months ago. it sucks. Anyone who doesn't think it sucks probably has stockholm symdromed themselves into liking it. Also this one has lore and room for expansion. It's main features are:
- Decent amount of maint for outpost antics
- REASONABLE amount of storefronts -abandoned feel
- bar
- Ore refinery so my holy mandate can be implemented when I decide I'm done with my break.
There are your screenshots.
I'd like the voices in my walls to stop whispering to me about the horrific mistakes I've made. They seem pretty upset about this one.
🆑 Erika Fox add: Outpost 1 has been remapped into something fathomably less ass. It's a bit smaller, probably, but I'm going to call that a good thing. add: random number spawner. It's good for hull numbers that shouldn't be static. imageadd: a really bad sprite for a service directions sign. add: Another elevator template (coincidentally demonstrating how that system works in code)
/:cl:
Co-authored-by: spockye [email protected]
Massive Ruin Fixes + Removals PR (#2334)
This PR is made so I can stop getting angry at the ruins beyond saving that are still ingame. My criteria for a ruin being removed is if another ruin already does its niche better, if the ruin is outdated and/or the ruin is excessively small or unbalanced. For ruins that dont meet this criteria but are still outdated, they will be getting balance fixes and touch ups or a total remap.
This PR is a draft for now because I will need to update the PR changelog and description as I make changes and communicate with the maptainers on what stays and what goes.
Adds departmental RND lootdrop spawners for circuit imprinters, protolathes and techfabs. Excludes omnisci and basic boards from the drops. Fixed a space tile under a door and replaced the omnilathe with a medical lathe on dangerousresearch Fixed the whitesands saloon not spawning which may have caused some sandplanets to spawn without a ruin Fixed harmfactory's nonfunctional traps to now be as lethal as intended. Also changed the loot in the vault to better reflect the ruin's theme and difficulty (cargo techfab board instead of omnilathe, adv plasma cutter instead of combat medkit, less gold more cash, kept the cyberarm implant). Fixed provinggrounds magical SMES FINALLY by adding a terminal on the back. The map should finally function as intended. Fixed a few dirs on fire extinguisher cabinets and blast door assemblies in singularity_lab Removed mechtransport.dmm for being small and bad Removed some leftover gasthelizards.dmm cruft (VILE) Removed nucleardump for being an utter mess of an oldcode ruin Removed gondolaasteroid for being large and empty besides gondolas. better suited for a jungle planet IMO. Removed Jungle_Spider. Literally just a box with spiders and cloning equipment. Small, bad, hard to find, unjustified loot. Removed Golem_Hijack. Like jungle spider but it was free rnd, an AI core, a full BSRPED and three golem corpses. With no enemies or obstacles. Removed rockplanet_clock for being a tiny lootbox that doesnt fit with the lore. Also had a quantumn pad. Removed whitesands_surface_youreinsane. Its a silly little reference to an old event that unfortunately resulted in a subpar ruin. Could return as a wasteplanet greeble ruin, but it has to go for now.
Normally I'm all for remapping instead of removing ruins, but some ruins are very much beyond saving. Clearing out space for better ruins to take the spotlight is always nice. Some older ruins are fine but are missing certain things or have loot that worked fine in the past, but doesn't reflect the balance we want for ruins in the present.
I will be PR'ing ruins to replace the ones I remove.
🆑 add: departmental RND lootdrop spawners for imprinters, protolathes and techfabs fix: dangerous_research.dmm now no longer has a space tile under a door and a medical lathe instead of an omnilathe fix: whitesands_surface_camp_saloon can now spawn again after its remap into a functional ruin fix: harmfactory.dmm's traps now work and loot has been adjusted to fit the ruin better fix: provinggrounds.dmm now has a working SMES and power fix: singularity_lab fire extinguishers and a few poddoors now have correct dirs del: mechtransport.dmm and associated code del: gasthelizards areas del: nucleardump.dmm and associated code del: gondolaasteroid.dmm and associated code del: jungle_spider.dmm and associated code del: whitesands_golem_hijack.dmm and associated code del: rockplanet_clock.dmm and associated code del: whitesands_surface_youreinsane.dmm and associated code /🆑
Signed-off-by: zevo [email protected]
Life is one big road with lots of signs. So when you riding through the ruts, don't complicate your mind. Flee from hate, mischief and jealousy. Don't bury your thoughts, put your vision to reality. Wake Up and Live!
Revert "if you die in a mech you are ejected" (#79768)
Reverts tgstation/tgstation#79380 this is literally what the mech removal tool is for. gameplay reasons for that tool missing do not mean that we need to remove its use - if you want a better solution then let people purchase it... or just smash the mech- you saving their life and them being sad about their mech is really funny the original pr being marked as qol when that was a specific balance change is very stupid
🆑 del: if you die in a mech you again don't automatically eject /🆑
✨ Feat(vm): Add precompiles as an option (#664)
Norswap requested precompiles. Norswap gets precompiles.
With precompiles one will be able to write arbitrary javascript that runs when a contract is called. They can even do gross stuff like append to a dom. Fwiw this will also be how evmts cheat codes work but before we weren't planning on exposing this to end users.
While implementing this feature I found an annoying bug. If you don't include an argument in your precompile the entire thing fails to execute. Opened pr to fix issue here ethereumjs/ethereumjs-monorepo#3158
The types are currently wrong. It takes an Ethjs address instead of a HexString address unlike the rest of the evmts pr. This is because patching the types as I wished was tediously hard as a result of ethereumjs not exporting specific types I need. Later I will do a pr to ethereumjs about this. For now we do some typescript magic to infer the type but because of the type is a union type it's difficult to patch and I gave up for now.
Unit test testing a precompile
- I read the contributing docs (if this is your first contribution)
Your ENS/address:
Co-authored-by: Will Cory [email protected]
feat(examples): add p/demo/seqid (#1378)
A very simple ID generation package, designed to be used in combination
with avl.Trees to push values in order.
The name was originally seqid (sequential IDs), but after saying it a
few times I realised it was close to "squid" and probably would be more
fun if I named it that way ;)
There's another piece of functionality that I want to add, which is a way to create simple base32-encoded IDs. This depends on #1290. These would also guarantee alphabetical ordering, so a list of them can be easily sorted and you'd get it in the same order they were created. They would likely be 13 characters long, but I'm also thinking of making a compact version which works from [0,2^35) which is 7 chracters, and then smoothly transitions over to the 13 characters version when the ID is reached.
(I've experience with both base64 and base32 encoded IDs as 64-bit numbers, as I used both systems. The advantage of base32 is that it makes IDs case insensitive, all the while being at most 13 bytes instead of 11 for base64.)
In GnoChess, we used simple sequential IDs combined with
zeroPad9
to create IDs which were both readable and sortable. I want to make a
more "canonical" solution to this which does not have a upper limit at 1
billion entries.
Make sign language unaffected by the Social Anxiety quirk's direct speech effects (#79809)
Alternative title: "Make going non-verbal make you less anxious."
This is a two line change to social_anxiety.dm to quit out its
handle_speech method when user has the TRAIT_SIGN_LANG trait.
This stops the Social Anxiety quirk from applying its
stutters/fillers/blockers for as long as the speaker is using sign
language.
This does nothing to any of social anxiety's non-verbal effects, those
are still active regardless and entirely unaffected.
Primarily: I think giving people the choice between using anxious talk or sign language, and thus the different hurdles inherent to both, makes for a more interesting gameplay interaction than simply blanket-applying the quirk's speech effects to both.
Secondarily: Social Anxiety's non-verbal penalties are entirely unaffected. One will still get the penalties from making eye contact and occasionally make eye contact with objects. Notably this includes the stuttering making eye contact could get you, which still makes your signing shaky. You're still anxious, after all. On top of this, it still costs more to pick up Signer than Social Anxiety allows for, and thus the change doesn't simply make the combination free points.
Tertiarily: when one has trouble speaking verbally, non-verbal communication can be helpful in overcoming that hurdle. This is especially so when the trigger for said anxiety is speaking verbally in the first place. This is part of why I was so enamoured by the combination before a broader and, mind you, fairly needed fix to sign language made these interact differently.
🆑 balance: signers no longer suffer from social anxiety's speech changes when they go non-verbal. Other effects are maintained. /🆑
[MISSED MIRRORS] Linters, part two (#25138)
- Split Run Linters step into multiple steps (#78265)
Splits the big "Run Linters" step into multiple steps. Also since all of these steps are independent of eachother, I've made them all run regardless of if the job is currently failing.
Proof of testing:
Fail in install tools, all linting steps are skipped: https://github.com/distributivgesetz/tgstation/actions/runs/6151628214/job/16692089726 Fail in Run DreamChecker, other steps continue to run: https://github.com/distributivgesetz/tgstation/actions/runs/6151664705/job/16692203569?pr=2
Pictured: me breaking CI for a day
igVideo.1.mov
Going through the Run Linters step has always been a slog. Finding an error is like finding a needle in a haystack. Seeing what command exactly went wrong is going to go a long way in helping people find out which linters have failed.
nothing playerfacing
- Fixes TFE being useless after #78265 (#78433)
I thought set +e would still make the shell exit with an error if any
command failed, I didn't think that it would just use the exit code of
the last command. I am dumb, I'm an idiot and I want to cry.
-
Update ci_suite.yml
-
Fix some odd vscode highlighting errors in workflow files (#78274)
few errors which were odd and annoying
stealing PRs from san7890, they wanted to do this nothing playerfacing
- Only cancel concurrent CI in the same PR (#73398)
More merge queue bullshit. Cancels are counted as failures, and even though on my test branch it worked completely fine, when trying on two real PRs, it did not.
This makes it so merges into master might mess with CI clogging again, but also merge queue is going to do that on its own, and the gain is worth it.
- Remove cache purge key that has never worked and has meant that our cache has never worked (#71529)
ci_suite.yml runs on your fork. This means you do not have access to secrets. Every user has had the purge key of blank.
WE have it set to something. Which means the master cache that every PR pulls from has been unable to match.
This means our cache has been at the max limit all this time, constantly clearing out old caches, and never reusing any.
- Caches Node and Python Bootstrap for GH Actions (#78307)
I was planning on doing this a lot earlier but ran into some weird roadblocks, but this time I finally did the research and it's done properly.
We do a lot of useless work on every single CI run, and in the interest
of saving the world's energy (by a matter of at least 10 seconds per my
testing), lets stop doing so much extra work by caching both the work we
do on the python bootstrap installation (we literally call it cache
for a reason) and the Node installation by sharing it between github
actions runners.
Here's a random CI run on master where you can see that the Install Tools portion takes about 19 seconds -
https://github.com/tgstation/tgstation/actions/runs/6167104927/job/16737570519
Here's the CI run I was testing with where you can see we slim it down
to about 6 seconds for the Install Tools step, but with a second-or-so
taken to restore the cache since the runner needs to download+unzip the
cache. it tends to be shorter or longer by a second at times but i'm
certain this is just noise -
https://github.com/san7890/bruhstation/actions/runs/6167245722/job/16737919874
On average, we save about 10 seconds a run on Run Linters, which is meant to be the fastest CI step. Future improvements would lie in making either maplint or the tgui test suite faster, but that would be a much more complicated and code-intensive task. cache go weeeee
Nothing that concerns players.
- Conditionally run TGS tests (#73704)
Also add test merge support for pull requests
Co-authored-by: distributivgesetz [email protected] Co-authored-by: Mothblocks [email protected] Co-authored-by: san7890 [email protected] Co-authored-by: Jordan Dominion [email protected]
[MISSED MIRROR] Puts all traits in the globalvars file + CI Testing (#79642) (#25131)
- Puts all traits in the globalvars file + CI Testing (#79642)
Fixes #76349
I didn't know that people needed to add any new traits to a global list so they can be easily read in View Variables, and was pretty shocked to find out many other people didn't know it was a thing. Let's make it a thing by testing it using a new CI Python Linter to check this. But oh no-
There were about 200+ missing traits. Alright, so let's do the following:
- Move trait defines to their own dedicated folder in the
_DEFINESfolder. - Split up the traits mega-file into different files, for better organization. One for the macros, one for the sources, and a few for the "trait declarations"
- Run the linter a load of times and add everything to the globalvars file, removing anything that's no longer used and figuring out where the best categorization of it is. also minor code improvements. also rename all of the ones that look weird. also fix list indentations
- Also alphabetize the lists because it's easy
- Move everything to a new
traits_by_typelist, while keeping the admin one the way it is for the time being while we figure out a better way to show that list to admins. - Profit
Mapping trait injectors will now work for any type of trait. You shouldn't add any trait via this injector though, but you're no longer limited to coders remembering to add it to that critical list you needed.
Lays the framework for a better view variables experience. This work is too lengthy to presently do, but hopefully we can get this done sooner rather than later. we will need a code-accessible way to view these traits for such a framework to be implemented, so let's just do that.
Future steps are to break down the mega-declarations file into a folder full of separate files by typepath, but that requires a lot of auditing. Does need to happen one day though, there's a lot of mob traits mingled with datum traits and auuugh we gotta do this later this PR is already massive.
there's probably ways to game this but this catches my mistakes so good luck to everyone else (it should work for 99% of everyone)
Nothing applicable to players. However, to mappers, the mapping trait injector should always be able to add any kind of trait (which is rather good for the times when you need it).
-
Update tgstation.dme
-
Update _traits.dm
-
Comment these out for now
Co-authored-by: san7890 [email protected]
Avance Comunicador
Hell yeah bby, some frontend shit again, I'd say 30% done. Still need to implement the phrase creation logic depending on the users image choice
Add all Platformer music to Jukebox
Alright, I am a nuisance and I love my job LOL This is honestly what happens when you have crackhead energy at 5 am and a friend says, Here do this and your like screw it why not? So, without further ado, here are all the music ones now too. I MIGHT be done with the torturous pushes now until Bryce or Adam is alive and can see what I did BWAHAHAHAHAHAHA
telephony: Force Class 0 SMS to Class 1
This kills Flash SMS messages. Fuck you airtel
Change-Id: Ifb0c9e8bae5c12868d178fbdaeceb2cc72a0ffb6
Gizmo Arrows (#10550)
- Add an arrow gizmo as suggested by #9400
(excuse my Protomen music)
2023-11-13.22-30-00.mp4
Wasn't horribly hard when i remembered i can change coordinate systems whenever I want. Gave them four tips (as suggested by @alice-i-cecile in discord) instead of trying to decide what direction the tips should point.
Made the tip length default to 1/10 of the arrow's length, which looked good enough to me. Hard-coded the angle from the body to the tips to 45 degrees.
- actual doc comments
- doctests
-
ArrowBuilder.with_tip_length()
- Added
gizmos.arrow()andgizmos.arrow_2d() - Added arrows to
2d_gizmosand3d_gizmosexamples
N/A
Co-authored-by: Nicola Papale [email protected]
Basic blob mobs (#78520)
I remembered today that blob code is ass, especially blob spores. There's still a lot to improve but I cleaned up some of it by converting these mobs. Now they use a newer framework and more signal handling as compared to circular references.
I expect the behaviour here to largely be the same as it was or similar. I haven't added anything fancy or new.
This is a reasonably big PR but at least all of the files are small? Everything here touched every other thing enough that it didnt make sense to split up sorry.
Other things I did in code:
- Experimented with replacing the
mob/blobsubtype with a component. Don't know if this is genius or stupid. - AI subtree which just walks somewhere. We've used this behaviour a lot but never given it its own subtree.
- Blob Spores and Zombies are two different mobs now instead of being one mob which just changes every single one of its properties.
- Made a few living defence procs call super, because the only thing super does was send a signal and we weren't doing that for no reason. Also added a couple extra signals for intercepts we did not have.
🆑 fix: Blob spores will respond to rallies more reliably (it won't runtime every time they try and pathfind). fix: Blobbernaut pain animation overlays should align with the direction the mob is facing instead of always facing South refactor: Blob spores, zombies, and blobbernauts now all use the basic mob framework. They should work the same, but please report any issues. /🆑
Co-authored-by: MrMelbert [email protected] Co-authored-by: san7890 [email protected]
ice demon basic mobs (#78539)
ice demons are now basic mobs. they still have their behavior where they can teleport around the player, run away from him and shoot him. they now also have a new ability they will only use when they are on their last legs, they will spawn weak and slow afterimage clones of theirselves to attack the player. damaging these clones will also damage the original ice demons. ice demons can also now be very easily countered as they are very afraid of fires. they will run away from you if they see u holding a lit torch/flare/welding tool and while running away they will freeze the floors around them to try to slip u to stop u from chasing them. ice demons now also get a new unique trophy! this trophy will summon 2 friendly spirits that will help you kill ur target, but these spirits will dissappear after a very short while.
bearkilling.mp4
🆑 refactor: ice demons have been refactored into basic mbos. please report any bugs add: ice demons now have a unique trophy /🆑
Stop hiding both menu and notebookbar softlocking
Previously, when using the Collapse_Notebookbar postmessage or equivalent ui_defaults (SpreadsheetToolbar=false, etc.), particularly in compact mode, it was possible to additionally hide the menu bar. As the button to show the menu bar is on the notebookbar, this meant that you couldn't reactivate either notebookbar or menubar until you refreshed the page. This is particularly annoying in integrators that may not provide an easy way to reload the page
This commit makes it so that hiding the menu bar automatically uncollapses the notebookbar and won't let it be collapsed again. Whether the notebook bar should be collapsed (the last thing done to it was a collapse) is remembered and restored after the menu bar is shown again, so if you send a postmessage that will affect the state of the notebookbar after the menu is shown (even though it will not affect the notebookbar's state immediately)
Caveats:
- If you are hiding the notebookbar to limit the control the user has, that's broken by this commit as it makes it impossible to hide both the menu and notebook bars at the same time.
- The notebook bar will be hidden again when re-showing the menu bar, however there still isn't a way to hide the notebook bar in normal use (i.e. without using either postmessage or ui_defaults) while in compact mode (although there is a workaround to show it- switching into tabbed mode and then back!). It might be nice to have one.
Other considered solutions:
- We could add a new button that allowed you to reopen the menu if both
menu and notebookbar were hidden
- Not sure there's much benefit to this over just doing what we're doing here, and it's harder to implement
- We could disable the button to hide the menu bar when the notebookbar
is collapsed
- As far as I know, there's no button in the UI to show the notebook bar. This would make it impossible to hide the menu bar if the notebookbar was hidden via postmessage or ui_defaults
Signed-off-by: Skyler Grey [email protected] Change-Id: Ieab6d72a6be181aba88e9a5b21dda16a369b9e54
Refactor icemoon wolves into basic mobs and add taming + pack behavior (#79736)
Ports icemoon wolves over to the basic mob framework with a bit of extra stuff:
- Wolves call for help when attacked within a decently large radius. Because you know, pack animals.
- Wolves can now be tamed with a slab of meat
- When tamed, wolves can be ridden like goliath mounts. Ride wolf, life good. Pretend you're playing ARK and start shivering to death in thatch huts for that High Roleplay experience.
- Tamed wolves have access to a bunch of pet commands (following, point fetching, point attacking, play dead, etc) and will also defend their owners vehemently if they're attacked.
You can probably tame multiple if you wanted to.
What part about riding wolves isn't entertaining? I don't really play /tg/ that much so I can't argue too much about the balance implications this might pose, but it's undoubtedly a stupid little gimmick and is likely to be used by bored assistants and miners with too much time on their hands.
Especially robust individuals will probably find a million things to do with a basic mob capable of fetching, attacking on command and generally being able to defend themselves decently well.
🆑 yooriss refactor: Icemoon wolves now use the basic mob framework and should act more intelligently, defending their pack. add: Icemoon wolves can be tamed with slabs of meat and can be ridden as mounts once friendly. Being rather large dogs, they also have access to most of the pet commands you'd expect, such as fetching things, and violently mauling people their owners point at. /🆑
Co-authored-by: san7890 [email protected]
Update base for Update on "AOTAutograd: handle set_(), detect metadata mutations that cancel out"
This should be enough to get voznesenskym 's FSDP branch to plumb set_() through AOTAutograd properly and have everything properly no-op out. Main changes are:
(1) graph break on aten::set_.source_Tensor_storage_offset (we could support it but it isn't needed, seems safer to graph break)
(2) Functionalization: add a "proper" functionalization kernel for aten::set_.source_Tensor. The previous one we had was codegen'd and it was wrong (it would just clone() and call set_(), which does not do the right thing). I also manually mark on the FunctionalTensorWrapper when a given tensor has been mutated by a set_() call.
(3) AOTAutograd: I added a new field, InputAliasInfo.mutates_storage_metadata, so we can distinguish between "regular" metadata mutations, and metadata mutations due to set_() calls. This is mainly because at runtime, one requires calling as_strided_() to fix up metadata, while the other requires calling set_().
(4) Made AOTAutograd's detection for metadata mutations / set_() mutations smarter and detect no-ops (if the storage and metadata are all the same).
I also killed was_updated() and was_metadata_updated(), and replaced them with (existing) has_data_mutation() and (new) has_data_mutation(), which can more accurately distinguish between data-mutation vs. set_() calls vs. metadata-mutation
This PR is still silently correct in one case though, which I'd like to discuss more. In particular, this example:
def f(x):
x_view = x.view(-1)
x.set_(torch.ones(2))
x_view.mul_(2)
return
If you have an input that experiences both a data-mutation and a x_old.set_(x_new) call, there are two cases:
(a) the data mutation happened on the storage of x_new. This case should be handled automatically: if x_new is a graph intermediate then we will functionalize the mutation. If x_new is a different graph input, then we will perform the usual copy_() on that other graph input
(b) the data mutation happened on the storage of x_old. This is more of a pain to handle, and doesn't currently work. At runtime, the right thing to do is probably something like:
def functionalized_f(x):
x_view = x.view(-1)
# set_() desugars into a no-op; later usages of x will use x_output
x_output = torch.ones(2)
# functionalize the mutation on x_view
x_view_updated = x.mul(2)
x_updated = x_view_updated.view(x.shape)
# x experienced TWO TYPES of mutations; a data mutation and a metatadata mutation
# We need to return both updated tensors in our graph
return x_updated, x_output
def runtime_wrapper(x):
x_data_mutation_result, x_set_mutation_result = compiled_graph(x)
# First, perform the data mutation on x's old storage
x.copy_(x_data_mutation_result)
# Then, swap out the storage of x with the new storage
x.set_(x_set_mutation_result)
There are two things that make this difficult to do though:
(1) Functionalization: the functionalization rule for set_() will fully throw away the old FunctionalStorageImpl on the graph input. So if there are any mutations to that FunctionalStorageImpl later on in the graph, the current graph input won't know about it. Maybe we can have a given FunctionalTensorWrapper remember all previous storages that it had, and track mutations on all of them - although this feels pretty complicated.
(2) AOTAutograd now needs to know that we might have two graph outputs that correspond to a single "mutated input", which is annoying.
It's worth pointing out that this issue is probably extremely unlikely for anyone to run into - can we just detect it and error? This feels slightly easier than solving it, although not significantly easier. We would still need FunctionalTensorWrapper to keep track of mutations on any of its "previous" storages, so it can report this info back to AOTAutograd so we can raise an error.
cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng
[ghstack-poisoned]
Lots of stuff has been done, no need to think about it
The Doctor who flux arc was shit, and I have had to make up an entire personal headcanon that makes it so that the Doctor was never part of "division" holy fuck chris chibnall, how could you fuck shit up that badly.
Puts all traits in the globalvars file + CI Testing (#79642)
Fixes #76349
I didn't know that people needed to add any new traits to a global list so they can be easily read in View Variables, and was pretty shocked to find out many other people didn't know it was a thing. Let's make it a thing by testing it using a new CI Python Linter to check this. But oh no-
There were about 200+ missing traits. Alright, so let's do the following:
- Move trait defines to their own dedicated folder in the
_DEFINESfolder. - Split up the traits mega-file into different files, for better organization. One for the macros, one for the sources, and a few for the "trait declarations"
- Run the linter a load of times and add everything to the globalvars file, removing anything that's no longer used and figuring out where the best categorization of it is. also minor code improvements. also rename all of the ones that look weird. also fix list indentations
- Also alphabetize the lists because it's easy
- Move everything to a new
traits_by_typelist, while keeping the admin one the way it is for the time being while we figure out a better way to show that list to admins. - Profit
Mapping trait injectors will now work for any type of trait. You shouldn't add any trait via this injector though, but you're no longer limited to coders remembering to add it to that critical list you needed.
Lays the framework for a better view variables experience. This work is too lengthy to presently do, but hopefully we can get this done sooner rather than later. we will need a code-accessible way to view these traits for such a framework to be implemented, so let's just do that.
Future steps are to break down the mega-declarations file into a folder full of separate files by typepath, but that requires a lot of auditing. Does need to happen one day though, there's a lot of mob traits mingled with datum traits and auuugh we gotta do this later this PR is already massive.
there's probably ways to game this but this catches my mistakes so good luck to everyone else (it should work for 99% of everyone)
Nothing applicable to players. However, to mappers, the mapping trait injector should always be able to add any kind of trait (which is rather good for the times when you need it).
Fixes sending stuff to "Old" Chat (#79819)
This functionality was removed in #79479
(e1c6cfdce89c7dbcd507d0c44803f5407a042a96), and we should still be
supporting the old chat anyways because it contains a plethora of useful
BYOND information that we still can really leverage (such as the
built-in profiler and stuff like that) and it's going to be painful to
do that if you have to keep spamming fix-chat to see OOC/ASAY while
alternating every damn time.
It's ugly but we still need it. There's a reason why we still have it.
🆑 fix: "Old Chat" (AKA: The old-styled non-TGUI raw-HTMLesque chat that you might see when it prods you with the "Failed to load fancy chat!" issue) should now get all text messages as expected. /🆑
Bring Back Lost Lover +27656012591 Green River Springdale Do You Seek Love, Friendship London, England Paris, France Amsterdam, Netherlands Barcelona .
Welcome, I'm thrilled the stars have brought you here. I'm a successful Psychic Reader based in South Africa - here to guide you through life's most complex and difficult matters. Whatever you're going through, I'm here to help you find your way forward. From a young age I realized I was blessed with a gift that enabled me to see and sense things others could not. Let me do the same for you as I have for so many others since 1995. Contact me to schedule an appointment or phone call reading. PSYCHIC TRADITIONAL HEALER SPELL CASTER +27656012591 People have relied on psychics, tarot readers, mediums, fortune tellers, and astrologers to help guide them through life for centuries. When making an important decision or you have questions about life, love, or career it helps to get insights into the future or your destiny to keep you on the right path. A real psychic see things clearly from a more elevated place to provide answers and give you quality advice. Even if you just want to know the meaning of a crazy dream you had last night, the best psychic Is available to help you. contact +27656012591 websites https://za.pinterest.com/spelllovespells/
Create Join brotherhood World Today +27733587735 Illuminati World Of Famous in south Africa Luxembourg Macedonia, Malta, Moldova Bermuda Virgin Island Astatula Clermont Eustis Fruitland Park Groveland
We welcome you all in this society, the Illuminati become a member by filling out our form. Sign up with Agent Aarush Membership benefits. I will help you register. Services: Illuminati members, Join illuminati, Sign up today. fees $1300 Join Illuminati Official - Illuminati Society For You Join illuminati brotherhood and enjoy all the benefits like money, fame, new house, car. Join illuminati for money today illuminati membership society. Services: Love Spells, Lost Love Spells, bring back lost lover. contact +27733587735
Stops rebar crossbow crashing dreamseeker when fired at point blank. (NO GBP) (#79803)
Simply put, due to how "caseless" is an element added to the ammo when it hits something, but ammo is qdeleted upon hitting someone. If shot point blank without combat mode (for some reason) it tries to add caseless to an ammo that no longer exists. For some reason, the result of this is to just fucking crash DS instead of aborting the adding of the element. The ammo isnt reusable anymore, but I'll take that over crashing.
Removes a game-breaking bug. I hate gun ammo code so much.
🆑 fix: Stopped a DS crash when shooting a rebar crossbow in specific circumstances. /🆑
Co-authored-by: Jacquerel [email protected]
[Fleet] Fix inability to upgrade agents from 8.10.4 -> 8.11 (#170974)
Closes elastic/kibana#169825
This PR adds logic to Fleet's /api/agents/available_versions endpoint
that will ensure we periodically try to fetch from the live product
versions API at https://www.elastic.co/api/product_versions to make sure
we have eventual consistency in the list of available agent versions.
Currently, Kibana relies entirely on a static file generated at build time from the above API. If the API isn't up-to-date with the latest agent version (e.g. kibana completed its build before agent), then that build of Kibana will never "see" the corresponding build of agent.
This API endpoint is cached for two hours to prevent overfetching from this external API, and from constantly going out to disk to read from the agent versions file.
- Update unit tests
- Consider airgapped environments
In airgapped environments, we're going to try and fetch from the
product_versions API and that request is going to fail. What we've
seen happen in some environments is that these requests do not "fail
fast" and instead wait until a network timeout is reached.
I'd love to avoid that timeout case and somehow detect airgapped
environments and avoid calling this API at all. However, we don't have a
great deterministic way to know if someone is in an airgapped
environment. The best guess I think we can make is by checking whether
xpack.fleet.registryUrl is set to something other than
https://epr.elastic.co. Curious if anyone has thoughts on this.
- Set up Fleet Server + ES + Kibana
- Spin up a Fleet Server running Agent v8.11.0
- Enroll an agent running v8.10.4 (I used multipass)
- Verify the agent can be upgraded from the UI
Co-authored-by: Kibana Machine [email protected]
docs: changed some warning to more friendly notes (#4108)
changed some warning to more friendly notes
Closes #4107
Type of change
(Remember to title the PR according to the type of change)
- Documentation update
How Has This Been Tested
(Please describe the tests that you ran to verify your changes.)
-
sphinx-autobuild(read Developer Documentation for more details)
Checklist
- I added relevant documentation
- I followed the style guidelines of this project
- I did a self-review of my code
- I made corresponding changes to the documentation
- My changes generate no new warnings
- I filled out the contributor form (see text above)
- I have added relevant notes to the
CHANGELOG.mdfile (See https://keepachangelog.com/)
Add files via upload
Build a Web-side with Web 3.0 with blockchain and next.js , solidity sanity i.o. Sample twitter web-site used for social networking platform where people can express their thoughts in short posts which people can read and share! Read a News some information. This project consept is using for future coding technology it call as web 3.0. Today, we are going to make the web-site for tweet consept using Next JS in the frontend along with Html, Css , javascript. And back-end with sanity i.o. Tailwind Css is designsystem implementation in pure Css. It is also configurable. It Gives Developers Super power. It allows them to Build websites with a clean consistent UI. MetaMask is the trailblazing tool enabling user interactions and experience on Web3. It is currently available as a browser extension and as a mobile app on both Android and iOS devices. The purpose of this documentation is to illustrate how to build a dapp with MetaMask. Sanity i.o use Back-end Database. Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling. This Web-site very style and look cool color.
man this is a fucking pain I should honestly just learn coding at this point tbh
Create Malek
Once upon a time in the land of ImagiNATION, there existed a quaint little village called Desireville, where the air was always filled with the sweet scent of dreams and the streets were lined with the colorful aspirations of its inhabitants. In this village, there lived a young and ambitious inventor named Leo, who had a burning desire to create something truly remarkable.
Leo had always been fascinated by the stars and the mysteries of the universe. He spent countless nights gazing at the twinkling lights above, longing to unravel their secrets. One day, as he wandered through the village square, he stumbled upon an ancient book in the local library. The book was titled "The Wonders of the Cosmos" and contained detailed descriptions of a legendary artifact known as the "Wishful Star."
According to the book, the Wishful Star was said to possess the power to grant the deepest desires of those who sought it. Excited and inspired, Leo made it his mission to build a device that could lead him to this fabled star.
Armed with determination and a knack for invention, Leo toiled away in his workshop, fashioning gears, wires, and all manner of peculiar contraptions. Days turned into weeks, and weeks into months, until finally, Leo unveiled his masterpiece—a wondrous machine with shimmering crystals and pulsating energy—a Cosmic Compass, capable of pointing the way to the Wishful Star.
Equipped with his newfound invention, Leo embarked on a daring journey across the rolling hills and misty forests, braving the trials of the Enchanted Valley and the riddles of the Whispering Woods. Along the way, he encountered curious creatures and helpful companions, each with their own unique dreams and wishes.
After a series of perilous adventures, Leo reached the summit of Mount Lumina, where, guided by the Cosmic Compass, he laid eyes upon the elusive Wishful Star. It bathed the entire mountaintop in a mesmerizing glow, and whispers of unspoken desires filled the air.
As Leo approached the star, he realized that the true power of the Wishful Star lay not in granting wishes outright, but in awakening the courage and determination within individuals to pursue their aspirations. With a newfound understanding, Leo returned to Desireville, where he shared his story with the villagers, inspiring them to chase their dreams with renewed vigor.
And so, in the village of Desireville, each resident found the courage to pursue their heart's desires, knowing that the true magic lay not in the granting of wishes, but in the journey towards them.
updated onUpdate api to be based on stopwatch api
we'll do wide spanning impl later with a general class but the problem was that the detection for when things finish STINKS I mean like hot ass, like worst thing on planet earth when things stop / start / swap new movies it's awful and we did this ugly work- around where we had count variables and then we do delays as well in the rest of our app all because of this simple bug we even thought mobx as the problem but it was simple_animations, I'm so pissed I don't even want to do a PR
Makefile.lib: Lower kernel gzip compression to fastest
You're reading this - so you're trying to understand "JUST WHY OMG". That's already a good step.
First of all, this is a downstream kernel - always keep that in mind! Now, this kernel is targeting new very powerful Qualcomm platforms like SM8250 and the Sony Edo platform - which has a very fast UFS card.
Keep in mind that the bootloader sets the CPU at a frequency that is slightly faster than the "in the middle" ones, which is anyway not veeeery fast - but that's good, really. I agree.
So.. check this out: for Image.gz-dtb..... COMP_LEVEL SIZE 9 20116171 5 20220479 2 20940223 1 21231290
Remember again that we're loading from a UFS card and that we are loading ~1.1MB more out of a 20MB file. If you're smart enough you surely know already about RAM and CPU overhead of very high compression levels.
If you still disagree with what I just did, read this commit description another 20 times, or more, until you understand it. :)))
reduces timer on joining ert after death to 30 seconds (#4652)
reduces timer
Having to wait a full minute to join an ERT is annoying, it was better b4 when timer from ERT was a minute as well, but 30 second ERT means if u die just b4 ERT goes you cant join regardless.
if ppl are ghosting bc they want ert then they are stupid.
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 balance: Timer on attempting to join ERT after death is now 30 seconds down from 1 minute /🆑
DFB property changes. (#4590)
part 2 out of 4 This does a big touch up on defibrillation property in research
Well, to start off, max_level = 1 was removed. It appears warcrimes forgot to remove it since process proc has benefits explicitly for higher levels. I would call it a bug(oversight rather).
Second: Ghosts get notified when the chem starts to try and defib you, so you dont just wonder how did you stand up, and pretty neat too.
Third: The >6 level of defib to apply healing like with actual item defib is too high, so we move requirement down to >1 but make it heal much, much worse at levels lower than 5. eg it took 20 units to heal ~20 brute at level 3(you will literally perma lmao), at level 5, however, this will go at around 2.5 per life tick, level 8 will give 4 damage heal. This is a balance change(buff) But hardly so since its research, Research is already neglecting most of the time this property.
Fourth: removes one letter var, This whole file is entombed with them but Im not doing that for now.
Defib property is way too underused and crudely made. This fixes it, partially.
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 kiVts add: Ghosts get notified when they are being revived by DFB property balance: DFB property healing threshold lowered, You can create DFB property higher than one. /🆑
Co-authored-by: Zonespace [email protected]
Fixes body collision causing a stun, despite a successful block. (#79824)
Puts a block check into the throw_impact() of carbon mobs.
I'm touching on a lot of 'get around shields' stuns, and this has been a big one for the better part of a few years and potentially not even intentional. I would say it gained its largest popularity when it became weaponized with fireman carrying.
Despite seemingly rolling to block, blocking a body hitting you doesn't actually do anything at all. This reminds me a bit of energy bolas. So I fixed it? I think, there might be a better fix, I'm just replicating code present in xenomorph tackles. This shit sucks, please recommend a better fix if you know it.
🆑 fix: When you successfully block a body collision, it does something rather than nothing at all. /🆑
fix stupid "this forces us to do things the """right""" way" bullshit from python 3.11 (#79783)
This is likely not the best way to go about this, but i do not want us to capitulate to python3's nanny state, suffocating levels of propriety bullshit.
venv sucks and i fucking hate it.
MBS-13310: Add new empty artist credits to unreferenced_row_log (#3105)
When artists are merged, Data::ArtistCredit::merge_artists is called, which
inserts new artist credits: each appearance of the old artist is replaced by
the new one. If the old AC had no references, it will have had an entry in the
unreferenced_row_log table already; we should make sure to update that to
point to the new AC, if the new one also has no references.
Remember that because artist credits have MBIDs, we'd like to preserve them from deletion where possible: there's a 2-day delay before we cleanup empty ACs, allowing time for them to be re-used with their original MBIDs intact. This applies to redirected MBIDs too; so while inserting empty artist credits may seem silly, these empty ACs are in fact redirected to from a (now-deleted) empty AC which hadn't been cleaned up yet.
Massive Ruin Fixes + Removals PR (#2334)
This PR is made so I can stop getting angry at the ruins beyond saving that are still ingame. My criteria for a ruin being removed is if another ruin already does its niche better, if the ruin is outdated and/or the ruin is excessively small or unbalanced. For ruins that dont meet this criteria but are still outdated, they will be getting balance fixes and touch ups or a total remap.
This PR is a draft for now because I will need to update the PR changelog and description as I make changes and communicate with the maptainers on what stays and what goes.
Adds departmental RND lootdrop spawners for circuit imprinters, protolathes and techfabs. Excludes omnisci and basic boards from the drops. Fixed a space tile under a door and replaced the omnilathe with a medical lathe on dangerousresearch Fixed the whitesands saloon not spawning which may have caused some sandplanets to spawn without a ruin Fixed harmfactory's nonfunctional traps to now be as lethal as intended. Also changed the loot in the vault to better reflect the ruin's theme and difficulty (cargo techfab board instead of omnilathe, adv plasma cutter instead of combat medkit, less gold more cash, kept the cyberarm implant). Fixed provinggrounds magical SMES FINALLY by adding a terminal on the back. The map should finally function as intended. Fixed a few dirs on fire extinguisher cabinets and blast door assemblies in singularity_lab Removed mechtransport.dmm for being small and bad Removed some leftover gasthelizards.dmm cruft (VILE) Removed nucleardump for being an utter mess of an oldcode ruin Removed gondolaasteroid for being large and empty besides gondolas. better suited for a jungle planet IMO. Removed Jungle_Spider. Literally just a box with spiders and cloning equipment. Small, bad, hard to find, unjustified loot. Removed Golem_Hijack. Like jungle spider but it was free rnd, an AI core, a full BSRPED and three golem corpses. With no enemies or obstacles. Removed rockplanet_clock for being a tiny lootbox that doesnt fit with the lore. Also had a quantumn pad. Removed whitesands_surface_youreinsane. Its a silly little reference to an old event that unfortunately resulted in a subpar ruin. Could return as a wasteplanet greeble ruin, but it has to go for now.
Normally I'm all for remapping instead of removing ruins, but some ruins are very much beyond saving. Clearing out space for better ruins to take the spotlight is always nice. Some older ruins are fine but are missing certain things or have loot that worked fine in the past, but doesn't reflect the balance we want for ruins in the present.
I will be PR'ing ruins to replace the ones I remove.
🆑 add: departmental RND lootdrop spawners for imprinters, protolathes and techfabs fix: dangerous_research.dmm now no longer has a space tile under a door and a medical lathe instead of an omnilathe fix: whitesands_surface_camp_saloon can now spawn again after its remap into a functional ruin fix: harmfactory.dmm's traps now work and loot has been adjusted to fit the ruin better fix: provinggrounds.dmm now has a working SMES and power fix: singularity_lab fire extinguishers and a few poddoors now have correct dirs del: mechtransport.dmm and associated code del: gasthelizards areas del: nucleardump.dmm and associated code del: gondolaasteroid.dmm and associated code del: jungle_spider.dmm and associated code del: whitesands_golem_hijack.dmm and associated code del: rockplanet_clock.dmm and associated code del: whitesands_surface_youreinsane.dmm and associated code /🆑
Signed-off-by: zevo [email protected]
im so fucking dumb holy shit
Signed-off-by: Dominicentek [email protected]
Fix secret scrubbing log latency (#6034)
- fix: use custom implementation for secret scrubbing
This was a fun exercise in processing streams in go, and an absolutely massive nerd-snipe :(
Essentially, we need a custom transformer to handle precisely matching Reads on the underlying source with the output - we shouldn't hold output any longer than is absolutely neccessary.
To be able to do this at all in any reasonable way, we need a trie, and handle all the secrets at once, instead of doing multiple passes. Multiple passes won't work, since it's possible to accidentally trim too much at each step, which would be very sad.
e.g. imagine secrets (aaa, bbb, ccc, etc), and an input (cba)
In removing secret aaa, we would trim to cb, then we'd remove bbb to trim to c, then finally trim to nothing. However, this is overly enthusiastic, we could easily just trim to cb, if we knew about all the secrets at once.
So, we need a trie, and we need a custom implementation of one. This is because no off the shelf implementation seems to allow traversing the trie state-by-state. Thankfully, it's a pretty short implementation to implement one from scratch, and not too much harder to turn it into a radix tree (which lets us use quite a lot less memory).
With our trie, we can implement our custom transformer, which is an utter pain. Honestly, the comments should explain all the fun edge cases it's possible to hit. There's a lot of tests added as well, each of which was a real horrible thing I hit while implementing it.
I played around a bit with benchmarking, but ugh, it's a tiny bit slower than the original implementation (maybe by like ~25%?). It's not huge, but the latency problem is actually solved. Some potential things I did look into and gave up on:
- Only copy into dstBuf when dst is full (requires tons of extra conditionals, so slows everything down).
- Avoid copies at all costs by having "virtual buffer pointers" into src, that indicate future data to copy (not only is this slower, the logic becomes truly incomprehensible).
- Playing with off-the-shelf radix tree implementations, but they're so inconvenient to use for this specific use case, it'd be way more trouble than it'd be worth.
Any ideas welcome, but honestly, I've looked at enough flamegraphs today.
Signed-off-by: Justin Chadwell [email protected]
- test: avoid use of require.Eventually for secret scrubbing
Signed-off-by: Justin Chadwell [email protected]
Signed-off-by: Justin Chadwell [email protected]
someone commented birthday greeting, fuck yourself
simplify state reordering logic (#4817)
Context: I wrote the same function twice, differing only by state flattening, to get the DQ upgrade done. It's starting to cause trouble.
Description of the Change: Greatly simplified the state re-arrangement logic. There used to be a whole mess of things happening, but now things are much more straightforward.
simulatefirst puts things in our "standard" order, and this means that if any measured wires are not also operator wires, they are put to the end of our tape wires. Therefore, for each measured-only wire, we just have to stack azeros_like(state)to the last axis of our final state!simulatenever tried to transpose wires back to a different ordering, so that was always wasted work.StateMP.process_statealways receives the full state, and never needed to pad. No other device has done this optimization (the function used to literally justreturn statebefore DQ2 migration), andsimulatealready ensures that the final state has all wires in it - they just might be out of order. The only thing we might need fromprocess_stateis a transposition to the correct wire order. The inputtedwire_ordershould always berange(len(wires)), but whatever, we don't need to assume that.
I'll paint a picture for a normal scenario:
@qml.qnode(qml.device("default.qubit", wires=3))
def circuit(x):
qml.RX(x, 0)
qml.CNOT([0, 2])
return qml.state()What happens with this QNode?
- Device preprocessing sticks the device wires (
[0, 1, 2]) onto theStateMP simulatemaps the wires to our standard order. I'll demonstrate (withprobsso I can specify wires):
>>> qs = qml.tape.QuantumScript([qml.RX(1.1, 0), qml.CNOT([0, 2])], [qml.probs(wires=[0, 1, 2])])
>>> qs.map_to_standard_wires().circuit
[RX(1.1, wires=[0]), CNOT(wires=[0, 1]), probs(wires=[0, 2, 1])]- Operate on the 2-qubit state, then stack another
[[0, 0], [0, 0]]on the end of it (wire "1") StateMP(wires=[0, 1, 2]).process_state(state, wire_order=[0, 2, 1])transposes the result to the correct order
I also changed the torch tests to stop using a deprecated setter for default float types.
Benefits: Duplicate code is cleaned up, existing code is simplified, no unnecessary call to transpose.
Possible Drawbacks:
- Have to call
qml.math.stackfor every wire that was not operated on. Hopefully this is usually not a lot, and it's not that costly anyway - functions now do less than they used to (I see this as a perk - they now do exactly what they're supposed to)
Added new folder monday_morn_updates which is most developed version, changes to css, js(added click listener functionality throughout, modal functionality to confirm favouriting on p2, fully functional list generation on p3, clear feature that displays the carousel and credits), just waiting for list group menu items and cocktail feature to be integrated on p2 (Dan, Allan) and Nick and Patrick are free to adjust recipe card on p2 and local storage functionality on p3 to integrate their work.My next steps will be to address the improperly rendering title and blurb on right column p2, to add a modal to p1 to deal with the case of a search string that returns no results. Will then address missing functionality on p2. Will start on writing the readme no later than 2 and hope we can deploy no later than 4 in order to troubleshoot any deployment issues that arise. We can still make changes to repo after deployment and deployed page will reflect them. From 4 till 6.30 I'll be prepping my part in the presentation. We should probably have another working api key on hand in case the currently loaded one reaches its quota with all the application tests we are doing today. Wouldn't want it to fail just as we are trying to demo it to the class.
Handled the stupidest of the error whic is not even worth to mention anyways i hate my life
Even Further Heretic Adjustments: New minor things, Bug fixes, Heretic path adjustments and movement adjustments! (#20843)
- a whole lot of shit
yessir
- gun stuff
crazy
- haha
fuck guns
- my brain bursts
it hurts
- so much shit
im done
- fuck forgot this
god damn low memory mode
- removes backslashes
really linter
- oops
typos
Invisible touch - this time for real (#20742)
-
This was surprisingly easy
-
Well this might be funny
-
Hm
-
Oh boy it's working
-
I might be going insane
-
Checks moved
Adds garbage dumpster ruins (#79446)
Adds 4 small space ruins. Each is a dumpster in space containing hostile mobs to fight and items to bring back to the station. There's a decommissioned garbage truck pulling each dumpster which acts as a staging area before you take on the mobs inside. All the fights are in cramped dark areas with full pressure, air is breathable but sometimes has miasma in it so beware of getting sick. So you can drop your space suit and put on armour, but PKAs won't fire at full power and keeping a gas mask on is recommended. Also all the dumpsters look the same from the outside so you gotta crawl inside to know what's inside. And no you can't metagame it with mesons either.
Comes in the following flavours: Food Waste Full of trash from kitchens, and food. Some of the food is still edible. There's a lot of territorial rats. You can chop them up into meat if you want more food. The big prize is a big vat of cooking oil.
Medical Waste Spare organs, cyberorgans and almost a full set of old surgical gear. There's a syndicate agent here up to no good and he has a GUN. The gun blows up when the agent dies so you can't get it. There's a few corpses of different species in bodybags and some spare corpse parts so you can bring them back to the station and give them to the coroner. Also a single use eyestealer in a safe (the cool way to do surgery) and a bug from the old traitor objective that doesn't do jack but can probably still get you thrown in perma.
Construction Garbage Tools and construction materials here, including a cool hammer that fits in a tool belt and can function as a crowbar. There's also a drug lab with plenty of weird pills to eat, cigarettes to eat and an angry russian drug dealer who will stab you if he sees you. He has a badass lighter and a flamethrower you can take after you kill him. Setting fire to things in here is not recommended because of all the welding fuel.
Mall Trash Action figures, trading cards, Christmas crackers and other trash the local mall tossed out. Also a mothman used to live here but he got eaten by giant spiders so you can grab his stuff, including snacks and a civilian modsuit with no mods (wow). You can cut through the webs to kill the spiders or let them eat you too if you want.
More content for space explorers. More variety to the potential dangers of space, now u can get sick and die or get eaten by rats (this is hobo RP) Better environmental storytelling. Now instead of players left asking "what happens to the garbage when it goes into space" they can rest assured that there's busted ass garbage trucks in space. All their questions are answered. Loot that encourages working with people on the station. Raw food for the kitchen, rats for genetics, organs for the coroner, etc
🆑 add: 4 new space ruins /🆑
Changes to the lore of Knock (#79542)
This PR renames Knock to Lock, and changes most of the knowledge gain lore.
The Knock Lore, is based on the Knock Principle from Cultist Simulator, with the path description being copied from the wiki. Many other keywords and concepts are fully lifted from that game (Locksmith's Secret, Mother Of Ants, etc). In my vision, if a heretic path has to be based on a principle from cultist simulator, it should have its own spin, and also, the knowledge gain texts should tell a story. For example, Ash tells the story of a watchman burning down their city after being betrayed, and Cosmic is a love story between a knowledge seeker and a monster from the beyond.
So I have decided to reflavour Knock. I have changed the name to Lock, so at least it would feel similar, just like how Blade is akin to Edge. Many powers also block people or confuse their paths instead of opening new ways, and thus, I feel a path whose name implies that it both opens and closes would be more self describing.
I have changed most of its lore to be about the Locked Labyrinth, where knowledge seekers willingly trap themselves and submit themselves to servitude to find ultimate freedom by progressing through its trials. These are the Stewards, who are basically workers in an infinite and malicious hotel in their dreams. Consider them assistants if you will (this wasn't my intention when I wrote the lore, but thinking about it in retrospect, it honestly fits). In the implied story, the heretic joins their ranks, but keeps getting closer to the more corrupt members, along with parasitic spirits. Ultimately, they manage to open the Labyrinth's core, letting out the Stewards, allowing them to manifest in the forms of heretic summon creatures.
The side path spells and the lock knowledge ritual I have not touched, they were fine. Some items have been renamed and repathed.
I have kept the distinctive sound effect for using the Grasp, as its unique enough. Though if someone did have a nice sound effect for turning a lock and added some filters, I would add it.
DB Issue
I have renamed the achievement's define to MEDAL_LOCK_ASCENSION but kept the value as "Knock", as I don't know how trigger a change in the DB. If this is a blocking change, I'll try to figure out how to make a migration file.
Future improvements
I would also come back later with another PR, that hands out names to the eldritch beings spawned by the portal, based on the Stewards in the knowledge gain lore that I added, along with some new ones that fit the theme, and some jokey ones like Minotaur.
🆑 spellcheck: Renamed Knock to Locks, and changed most of the flavor text of knowledge gain, and renamed some items and knowledges from the path. /🆑
[SDK][CMLIB] Implement log transaction writes & Resuscitation
=== DOCUMENTATION REMARKS ===
This implements (also enables some parts of code been decayed for years) the transacted writing of the registry. Transacted writing (or writing into registry in a transactional way) is an operation that ensures the successfulness can be achieved by monitoring two main points. In CMLIB, such points are what we internally call them the primary and secondary sequences. A sequence is a numeric field that is incremented each time a writing operation (namely done with the FileWrite function and such) has successfully completed.
The primary sequence is incremented to suggest that the initial work of syncing the registry is in progress. During this phase, the base block header is written into the primary hive file and registry data is being written to said file in form of blocks. Afterwards the seconady sequence is increment to report completion of the transactional writing of the registry. This operation occurs in HvpWriteHive function (invoked by HvSyncHive for syncing). If the transactional writing fails or if the lazy flushing of the registry fails, LOG files come into play.
Like HvpWriteHive, LOGs are updated by the HvpWriteLog which writes dirty data (base block header included) to the LOG themselves. These files serve for recovery and emergency purposes in case the primary machine hive has been damaged due to previous forced interruption of writing stuff into the registry hive. With specific recovery algorithms, the data that's been gathered from a LOG will be applied to the primary hive, salvaging it. But if a LOG file is corrupt as well, then the system will perform resuscitation techniques by reconstructing the base block header to reasonable values, reset the registry signature and whatnot.
This work is an inspiration from PR #3932 by mrmks04 (aka Max Korostil). I have continued his work by doing some more tweaks and whatnot. In addition to that, the whole transaction writing code is documented.
=== IMPORTANT NOTES ===
HvpWriteLog -- Currently this function lacks the ability to grow the log file size since we pretty much lack the necessary code that deals with hive shrinking and log shrinking/growing as well. This part is not super critical for us so this shall be left as a TODO for future.
HvLoadHive -- Currently there's a hack that prevents us from refactoring this function in a proper way. That is, we should not be reading the whole and prepare the hive storage using HvpInitializeMemoryHive which is strictly used for HINIT_MEMORY but rather we must read the hive file block by block and deconstruct the read buffer from the file so that we can get the bins that we read from the file. With the hive bins we got the hive storage will be prepared based on such bins. If one of the bins is corrupt, self healing is applied in such scenario.
For this matter, if in any case the hive we'll be reading is corrupt we could potentially read corrupt data and lead the system into failure. So we have to perform header and data recovery as well before reading the whole hive.
Update README.md
In "Beauty and the Beast," Belle, this smart and kind gal, gets stuck in a magical castle because her dad's in a jam. At first, she's freaked out by the Beast who lives there, but then she sees he's not so bad and befriends his enchanted furniture friends. They fall in love, break the curse with some true love magic, and bam, Beast turns back into a prince, and the castle's back to normal.
[libc++] Reduce the compilation time required by SIMD tests (#72602)
Testing all the SIMD widths exhaustively is nice in theory, however in practice it leads to extremely slow tests. Given that
- our testing resources are finite and actually pretty costly
- we have thousands of other tests we also need to run
- the value of executing these SIMD tests for absolutely all supported SIMD widths is fairly small compared to cherry-picking a few relevant widths
I think it makes a lot of sense to reduce the exhaustiveness of these tests. I'm getting a ~4x speedup for the worst offender (reference_assignment.pass.cpp) after this patch.
I'd also like to make this a reminder to anyone seeing this PR that tests impact everyone's productivity. Slow unit tests contribute to making the CI slower as a whole, and that has a direct impact on everyone's ability to iterate quickly during PRs. Even though we have a pretty robust CI setup in place, we should remember that it doesn't come for free and should strive to keep our tests at a good bang for the buck ratio.
Broken Finding Next Slots In Purge
I hate my life
Further Prevention of Disposals Qdeletion (#79714)
Fixes the consequences of #79629 - Verdict is still out on what the root issue is
This has been an issue for the last two years and everything I go
bananas trying to get a consistent reproduction case to figure out the
root issue. After three session of picking, I think it's just a
consequence of certain thing in disposals code sleeping due to
addtimer() and whatnot so I'm just throwing in the towel and just
making it so we stop sending atoms to nullspace for no reason.
target_turf is typically always a present arg, but regardless we are
guaranteed to get a valid turf to send people to instead of the deleted
mob room. We still stack_trace() whenever this happens, so tracking
this issue doesn't change any more than the present status quo- we just
don't keep torturing mobs by sending them to the shadow realm.
One day we'll figure out why we keep getting null passed into
forceMove() like this but today is not that day. i know turfs
technically can't be deleted but it's just there as a safety since we
nullcheck anyways (which is the whole point of this fix). Let's just
stop screwing with players for the time being
also the code looks much better
🆑 fix: Safeties in the code have been added to prevent things in disposals going into nullspace whenever they get ejected from a pipe - you will just magically spawn at the turf that you were meant to be flung towards. /🆑
I HAVE FINALLY FUCKING FIXED IT HOLY FUCKING SHIT IT WORKS HOLY MOTHERFUCK
Damn I'm so fucking ugly (I forgot to disable the debugger)
Add files via upload
Hey fellow developers,
I'm excited to share the beginning of a new learning journey with all of you! 🌟 Today, I dove into the world of QR code generation using Node.js, and I can't wait to share my progress and insights with you.
Project Overview:
🔍 What is this project about? I've started working on a QR code generator using Node.js. QR codes have become an integral part of modern applications, and understanding how to generate them programmatically is a valuable skill.
🚀 Why Node.js? Node.js is known for its speed and scalability, making it a fantastic choice for building applications that require real-time functionality. It's also great for handling asynchronous operations, which is essential when working with QR code generation.
Tech Stack:
🔧 Node.js: I've chosen Node.js as the primary technology for this project due to its event-driven architecture and ease of use. If you're new to Node.js like me, it's a fantastic opportunity to learn and grow your skills.
📦 Additional Packages: I'll be using relevant npm packages to make the QR code generation process smoother. Feel free to suggest your favorite packages or share any tips you have!
Learning Goals:
🎓 What am I hoping to achieve? I aim to understand the fundamentals of QR code generation, explore the capabilities of Node.js in handling such tasks, and ultimately create a robust QR code generator that can be used in various applications.
🛣️ Milestones: I'll be documenting my progress and milestones along the way. From setting up the project to generating the first QR code, every step will be a learning experience.
How Can You Get Involved?
🤝 Join the Discussion: Feel free to join the conversation! Share your insights, ask questions, or suggest improvements. This project is as much about collaboration as it is about learning.
🚀 Contribute: If you're experienced with Node.js or QR code generation, your contributions are more than welcome! Let's make this project a collective effort.
Stay Tuned:
📅 What's next? I'll be posting regular updates on my progress, challenges faced, and lessons learned. Subscribe to this thread to stay in the loop and follow along on this exciting journey.
Thank you for being a part of this adventure! Let's code, learn, and grow together. 🌐💻
Made Last Updated live based on page refresh
This is such a hack on line 40 I actually hate myself for it. None of the other documented ways to do this actually worked with Astro. Thanks :)
Yeah, I did it. fetchMenu formats fixed and more.
- Fixed fetchmenu to properly format menuItems
- Added fetchmenu for lunch
- Added fetchmenu for dinner
- Connected fetchLunchMenu to Lunch menu button on UI
- Connected fetchDinnerMenu to Dinner menu button on UI
- (Previously connected fetchBreakfastMenu to Breakfast menu button on UI, don't know if I said that in a prior commit or not)
Extract storage manager related code from sled-agent (#4332)
This is a large PR. The changes are in many ways just moving code around, and at a cursory glance may appear to be a giant waste of time. To justify these changes and my rationale I will first present the goals I believe we should strive to meet in general sled-agent development. I'll then go into how I believe these goals can be realized via code patterns. I'll then discuss the concrete changes in this PR and how they implement the discussed patterns. Lastly, I'll list a few open questions about the implementation in the PR.
I want to emphasize that a lot of what I talk about below is already done in sled-agent, at least part way. We can pick the best patterns already in use and standardize on them to build a more coherent and yet decoupled architecture for easier testing and understanding.
This PR is an attempt to start making sled-agent easier to maintain. In order to make things easier to maintain, I believe we should attempt to realize a few key goals:
- Initial startup and control code should read linearly. You shouldn't have to jump around to follow the gist of what's going on.
- Tasks, like functions, should live at a certain abstraction level. It must be clear what state the task is managing and how it gets mutated.
- A developer must be able to come into the codebase and know where a given functionality should live and be able to clearly follow existing patterns such that their new code doesn't break or cross abstractions that make following the code harder in the future.
- Tests for individual abstractions and task driven code should be easy to write. You shouldn't need to spin up the whole sled-agent in order to test an algorithm or behavior.
- Hardware should be abstracted out, and much of the code shouldn't deal with hardware directly.
In my opinion, the most important pattern to follow for async rust
software
is what I call the "task/handle" pattern. This pattern helps code
maintenance
by explicitly managing state and making task driven code easier to test.
All
tasks that provide services to other tasks should follow this pattern.
In this
pattern, all state is contained in a type owned by the task and
inaccessible
directly to other tasks. The task has a corresponding handle which must
be
Send and Clone, and can be used to make requests of the task. The
handle
interacts with the task solely via message passing. Mutexes are never
used.
A few things fall directly out of this pattern:
- Code that manipulates state inside and outside the task can be synchronous
- We don't have to worry about mutex behavior with regards to cancellation, await points, etc...
- Testing becomes easier:
- We can test a bunch of the code without spawning a task in many cases. We just directly construct the state object and call functions, whether sync or async.
- When testing sequential operations that are fire and forget, we know when they have been processed by the task loop, because our next request will only run after those operations. This is a direct result of the fifo channel between handle and task. This is not possible with state shared outside the task via a mutex. We must poll that mutex protected state until it either changes to the value we expect or we get a timeout. If we expect no change, we must use a side-channel.
- We can write complex state handling algorithms, such as those in maghemite or bootstore, in a deterministic, synchronous style that allows property based testing and model checking in as straightforward a manner as possible.
- We can completely fake the task without changing any of the calling code except the constructor. The real handle can instead send messages to a fake task. Importantly, this strategy can also be used to abstract out hardware for unit tests and simulation.
Beyond all that though, the understanding of how state is mutated and
accessed
is clear. State is only mutated inside the task, and can only be
retrieved from
code that has a copy of the handle. There is no need for separate
_locked
methods, and no need to worry about order of locking for different bits
of task
state. This can make the task code itself much shorter and easier to
read as
demonstrated by the new StorageManager code in sled_storage. We can
also
maintain internal stats for the task, and all of this can be retrieved
from the
handle for reporting in omdb.
There is one common question/problem with this pattern. How do you choose a bounded channel size for handle to task messages?
This can be tricky, but in general, you want the channel to act unbounded, such that sends never fail. This makes the channels reliable, such that we never drop messages inside the process, and the caller doesn't have to choose what to do when overloaded. This simplifies things drastically for developers. However, you also don't want to make the channel actually unbounded, because that can lead to run-away memory growth and pathological behaviors, such that requests get slower over time until the system crashes.
After discussions with @jgallagher and reflections from @sunshowers and @davepacheco on RFD 400, the solution is to choose a large enough bound such that we should never hit it in practice unless we are truly overloaded. If we hit the bound it means that beyond that requests will start to build up and we will eventually topple over. So when we hit this bound, we just go ahead and panic.
Picking a channel bound is hard to do empirically, but practically, if requests are mostly mutating task local state, a bound of 1024 or even 8192 should be plenty. Tasks that must perform longer running ops can spawn helper tasks as necessary or include their own handles for replies rather than synchronously waiting. Memory for the queue can be kept small with boxing of large messages.
It should also be noted that mutexes also have queues that can build up and cause pathological slowness. The difference is that these queues are implicit and hard to track.
We have a bunch of managers (HardwareManager, StorageManager,
ServiceManager, InstanceManager) that interact with each other to
provide sled-agent services. However, much of that interaction is ad-
hoc with state shared between tasks via an Inner struct protected
by a mutex. It's hard to isolate each of these managers and test
them independently. By ensuring their API is well defined via a
Handle,
we can fake out different managers as needed for independent testing.
However, we can go even farther, without the need for dependency
injection
by having different managers announce their updates via [broadcast or
watch
With this strategy, we can drive tests for a task by using the handle to
both
trigger operations, and then wait for the outflow of messages that
should occur
rather than mocking out the handle API of another task directly and
checking
the interaction via the fake. This is especially useful for lower level
services
that others depend upon such as StorageManager, and we should do this
when we
can, rather than having tasks talk directly to each other. This strategy
leads
directly to the last pattern I really want to mention, the monitor
pattern.
Remember that a primary goal of these patterns is to make the sled-agent
easier
to read and discover what is happening at any given point in time. This
has to
happen with the inherent concurrency of all the separate behaviors
occurring
in the sled-agent such as monitoring for hardware and faults, or
handling user
requests from Nexus. If our low level managers announce updates via
channels
we can have high level Monitors that wait for those updates and then
dispatch
them to other subsystems or across clients to other sleds or services.
This
helps further decouple services for easier testing, and also allows us
to
understand all the asynchrony in the system in fewer spots. We can put
RAS code
in these monitors and use them as central points to maintain stats and
track the
overall load on the system.
How do the patterns above satisfy the goals? By decoupling tasks and interacting solely via message passing we make testing easier(goal 4). By separating out managers/ services into separate tasks and maintaining state locally we satisfy goals 2 and 5. By making the tasks clear in their responsibilities, and their APIs evident via their handles, we help satisfy goal 3. Goal 3 is also satisfied to a degree by the elimination of sharing state and the decoupling via monitors. Lastly, by combining all the patterns, we can spawn all our top level tasks and monitors in one place after initializing any global state. This allows the code to flow linearly.
Importantly, it's also easy to violate goal 3 by dropping some mutexes
into the
middle of a task and oversharing handles between subsystems. I believe
we can
prevent this, and also make testing and APIs clearer, by separating
subsystems
into their own rust packages and then adding monitors for them in the
sled-agent.
I took a first cut at this with the StorageManager, as that was the
subsystem I was
most familiar with.
Keeping in line with my stated goals and patterns, I abstracted the
storage
manager code into its own package called sled-storage. The
StorageManager
uses the task/handle pattern, and there is a monitor for it in
sled-agent
that takes notifications and updates nexus and the zone bundler. There
are also a
bunch of unit tests where none existed before. The bulk of the rest of
the code
changes fell out of this. In particular, now that we have a separate
sled-storage
package, all high level disk management code lives there. Construction
and
formatting of partitions still happens in sled-hardware, but anything
above the
zpool level occurs in sled-storage. This allows testing of real
storage code on
any illumos based system using file backed zpools. Importantly, the
key-management
code now lives at this abstraction level, rather than in
sled-hardware, which
makes more sense since encryption only operates on datasets in ZFS.
I'd like to do similar things to the other managers, and think that's a good way to continue cleaning up sled-agent.
The other large change in this code base is simplifying the startup of
the bootstrap agent such that all tasks that run for the lifetime of
the sled-agent process are spawned in long_running_tasks. There is a
struct called LongRunningTaskHandles that allows interaction with all
the
"managers" spawned here. This change also has the side effect of
removing the
wait_while_handling_hardware_updates concurrent future code, since we
have
a hardware monitor now running at the beginning of time and can never
miss
updates. This also has the effect of negating the need to start a
separate
hardware manager when the sled-agent starts up. Because we now know
which
tasks are long running, we don't have to save their tokio JoinHandles
to display
ownership and thus gain clonability.
- I'm not really a fan of the name
long_running_task_handles. Is there a better name for these? - Instead of calling
spawn_all_longrunning_tasksshould we just call the individual spawn functions directly inbootstrap/pre_server? Doing it this way would allow theServiceManagerto also live in the long running handles and remove some ordering issues. For instance, we wait for the bootdisk insidespawn_all_longrunning_tasksand we also upsert synthetic disks. Neither of these is really part of spawning tasks.
Updating: 11/20/2023 10:00:00 PM
- Added: The cocktail revolution - Works in Progress (https://worksinprogress.co/issue/the-cocktail-revolution/)
- Added: SearchArray: Making search relevance not so special (https://softwaredoug.com/blog/2023/11/20/search-relevance-less-special)
- Added: Long Term Refactors - Max Chernyak (https://max.engineer/long-term-refactors)
- Added: Exploring macOS private frameworks (https://www.jviotti.com/2023/11/20/exploring-macos-private-frameworks.html)
- Added: How to Effectively Set Up NextJS with a Component Library using Monorepos (https://dainemawer.com/articles/how-to-effectively-setup-nextjs-with-a-component-library-using-monorepos)
- Added: Tim Severien (https://tsev.dev/posts/2023-11-10-should-avif-be-the-dominant-image-format/)
- Added: The reciprocal Fibonacci constant (https://fredrikj.net/blog/2023/11/the-reciprocal-fibonacci-constant/)
- Added: Writing a Cloudflare worker with squint and bun (https://blog.michielborkent.nl/squint-cloudflare-bun.html)
- Added: Data-Driven Development is a Lie (https://grishaev.me/en/ddd-lie)
- Added: Back up your Bitwarden vault in a future-proof and secure way (https://davidisaksson.dev/posts/bitwarden-backup/)
- Added: Discount rates in venture backed startups (https://reactionwheel.net/2023/11/discount-rates-in-venture-backed-startups.html)
- Added: Erik Johannes Husom (https://erikjohannes.no/posts/20231119-the-future-of-social-media/)
- Added: Never again compare a startup to a vitamin (https://www.pathsensitive.com/2023/09/its-time-for-painkillers-vitamins-die.html)
- Added: UTC is not Your Saviour – Random Notes (https://blog.nytsoi.net/2022/03/13/utc)
- Added: C# Data Access: Complex Objects with Dapper (https://youtube.com/watch?v=n7mGEh4_06c)
- Added: 📨 Void Inbox (https://orchardlab.dev/posts/void-inbox/)
- Added: Reverse-engineering GPTs for fun and data (https://andrei.fyi/blog/reverse-engineering-gpts/)
- Added: The Creator's Curse: Why your latest project will eventually make you miserable | Peter Shallard (https://www.petershallard.com/the-creators-curse/)
- Added: The New CSS Math: rem() and mod() (https://danielcwilson.com/posts/mathematicss-rem-mod/)
- Added: Microsoft Canada - Calgary Automation and Integration Day (https://msit.events.teams.microsoft.com/event/5d41b1b3-e626-4de4-92db-65768d6f2ea6@72f988bf-86f1-41af-91ab-2d7cd011db47)
- Added: Radius a new open-source application platform for the cloud | BRK402 (https://youtube.com/watch?v=gaG77PiYv5w)
- Added: Migrating Page Navigation Apps from Xamarin Forms (https://platform.uno/blog/migrating-page-navigation-apps-from-xamarin-forms/)
Generation took: 00:09:07.3204785 Maintenance update - cleaning up homepage and feed
Add Weld for Java dependency injection
Weld is the reference implementation of "CDI: Contexts and Dependency Injection for the Java EE Platform."
This is in preparation for introducing the StringCalculator interface, which I'll use to inject different StringCalculator implementations into the Servlet.
This involved:
-
Adding implementation dependencies for:
- org.jboss.weld.servlet:weld-servlet-core
- io.smallrye:jandex (recommended for speeding up bean discovery)
-
Adding new strcalc/src/main/webapp files to add to the servlet WAR file, not needed until now, configured according to https://docs.jboss.org/weld/reference/5.1.2.Final/en-US/html_single/#tomcat:
- META-INF/context.xml
- WEB-INF/web.xml
-
Added strcalc/src/main/webapp/WEB-INF/beans.xml because Weld will skip initialization without it, with the warning: WELD-ENV-000028: Weld initialization skipped - no bean archive found
-
Updating the TestTomcat helper to find these new files and to enable Java Naming and Directory Interface (JNDI), required by Weld:
One silver lining was that adding JarScanner > JarScanFilter element to META-INF/context.xml rendered the custom TestTomcat logic to disable the JarScanner unnecessary.
Perhaps the other silver lining is that the TestTomcat now tracks whatever's in src/main/webapp. This should enable the TestTomcat configuration to remain in sync with the final WAR file.
And now for what I really came here to say: I hate Java. I really, really, really hate Java. Not so much the language itself, but the entire culture and ecosystem that has festered around it for 28 years.
If the question is:
- How can we make relatively straightforward tasks as complicated, verbose, and arcane as humanly possible?
The answer is invariably:
- Java.
Never in any other programming language, in any program, have I had the need to use a "dependency injection framework". Never. And I've been injecting dependencies like crazy for at least a decade and a half by now—starting in C++.
None of those other languages or frameworks made it impossible to wire my own object graph in whatever context at hand. Often this is within a test class a la JUnit, or a "describe" block a la Mocha, or a similar construct easily written in Go. (See my mbland/elistman project for copious examples of the latter.) Then I can wire up my production graph in main(), or in a function directly called from main(). Or, in Node.js, in the main server script before starting the server task.
In those other programming languages, if I want to start a local HTTP server injected with whatever implementations I want, I just do that. In a test, in the main implementation, it doesn't matter. Most standard libraries provide a HTTP server implementation, their interfaces and their contracts are straightforward, and they're usually well documented. At any rate, it's not that hard to figure out.
The Java ecosystem, in its infinte wisdom, presents a different story. It considers wresting direct responsibility for and control over your execution environment and object a graph a feature, not the revolting bug that it is. And somehow, a critical mass of programmers have not only learned to cope with the trauma, but actively dedicated themselves to perpetuating it.
And that brings us to the concept of "servlet containers" and "Context and Dependency Injection," a.k.a. "CDI".
Like I said, I just want an HTTP server that I can plug things into myself, usually via registering endpoint handlers at runtime. Granted, that's the same principle as the Servlet API, but this being Java, of course it's not that easy.
Let's look at the opening paragraph of https://tomcat.apache.org/:
The Apache Tomcat® software is an open source implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations and Jakarta Authentication specifications. These specifications are part of the Jakarta EE platform.
Outside of "software" and "open source implementation," what the hell do any of those words even mean? Here's my attempt at an improvement:
Apache Tomcat is a web server for deploying Java Servlets, web applications bound to an HTTP endpoint. Servlets implement the jakarta.servlet.http.HttpServlet interface for accepting HTTP request and response objects.
Was that so hard to say? And that first example is, sadly, genuinely representative of the entire Java documentation corpus. References to references to references, never ending up giving concrete, practical guidance on what should be straightforward steps to achieve a goal. Words, words, words, tales told by idiots, full of sound and fury, signifying practically nothing.
(I blame Sun Microsystems. I remember trying repeatedly to make heads or tails of some of their Solaris docs, and giving up every time. I think Amazon hired a bunch of their old writers for the higher-level AWS docs, which I've found equally useless. There are some great AWS docs, but I only found them after spending hours sniffing out rare breadcrumbs that led me to them. Once I knew where they were hiding, and how to get straight to them, life got much better.)
All I want to do is define an interface, a production implementation, and a test double, and plug it into my HTTP server. Instead, I need a graduate degree in trawling through enterprise bloatware documentation with a nearly imperceptible signal to noise ratio to perform this routine task:
- CDI: https://www.cdi-spec.org/
- Weld: https://docs.jboss.org/weld/reference/5.1.2.Final/en-US/html_single/
- JNDI: https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
And I refuse to learn about any @Interceptors or @Decorators or @Stereotype or any more META-INF/kill_me_now.xml files or @AnyOtherBullshitNotActuallyNecessaryForDependencyInjection.
If it weren't for web search and programmer forums, I still wouldn't
have made any progress. Sometimes even those resources couldn't help me;
check out the comment above tomcat.enableNaming(). I found matches for
"Failed to retrieve JNDI naming context for container". However, I
couldn't find any advice for when this appeared after stopping an
embeddded Tomcat. Somehow having waded through so much excess verbiage
referencing JNDI did I think to see if the Tomcat class had an
enableNaming() method. Even the Weld docs' example for embedded Tomcat
didn't mention this:
In fact, it recommends registering the Weld listener programmatically—which I'd normally prefer, if it worked:
ctx.addApplicationListener(Listener.class.getName())
That didn't end up working for me at all. It did nothing to eliminate sufficient complexity to get embedded Tomcat instance starting successfully. For that reason, I think the current TestTomcat implementation that reads the src/main/webapp configs is superior. It may be more complex than I find ideal, requiring access to those files to function, but at least it's consistent and functional.
The point of this tomcat.enableNaming() example is that, in the end, I
made an educated guess, and I got lucky. In other languages, I make an
educated guess, and the language or framework makes more sense. In Java,
I just got lucky this one time, and that's it. There's no deeper value
or insight to derive from the experience. I can merely move on from the
task at hand, surely to waste more time on the next one until I get
lucky again.
Java is the quintessential triumph of marketing hype over delivering actual technical value. Everytime I touch it I feel like I'm wasting at least 10x the time I should need to in order to get something straightforward done. It's just sick and wrong, and it generates immeasurable waste in terms of programmer time, business value, opportunity cost, and global warming.
OK, I feel better. That's all for now. (Until I eventually make this a proper blog post.)
Remove stupid debug shit where I put my goddamn API key in my stupid idiot code
FUCK YOU TYLER FIX MY SHIT ok thank you :) also give me free dsi games and make sure to generate more ai names for our game along with logos so I can use them for a playtest I'd like at least 5 of them but preferably closer to 10
--