there were a lot of events recorded by gharchive.org of which 2,344,527 were push events containing 3,536,906 commit messages that amount to 291,492,839 characters filtered with words.py@e23d022007... to these 45 messages:
Gun kits don't need cable coil or tools, halved crafting time (#78419)
Crafting R&D guns from gun kits no longer requires tools or cable coil. The decloner and energy crossbow still need reagents.
Halved R&D gun crafting time. 20->10 seconds.
These changes were made a long, long while ago and honestly while I understand gun kits I don't understand why it was made So. Annoying. To make the fucking guns once you got everything ready. It makes it a total annoyance. You spent 40 minutes getting all the tech for it, you shouldn't have to also get tools and cables and wait 20 seconds standing still.
Anyone who has played ingame like any time after that change can attest how underused any R&D gun is now. X-ray laser guns still DESTROY blobs but people don't even THINK about them because of the dumb annoying recipe (alongside RnD being a pain now).
Simply put this just. Makes life easier for security officers. And reduces tool dependency.
🆑 qol: Crafting R&D guns from gun kits no longer requires tools or cable coil. The decloner and energy crossbow still need reagents. qol: Halved R&D gun crafting time. 20->10 seconds. /🆑
Rounded supermatter delamination times to 5 seconds, restored old mood messages (#78335)
Makes the supermatter delaminate in 15 seconds instead of 13 and 5 seconds instead of 3 if a sliver has been taken from it, mainly to please perfectionists (me and some others who commented on the PR) as well as giving people at least a chance to escape delam round removal.
I don't like it when flavorful text is replaced by bland and not-as-funny alternatives. Also, how the hell is it gamey for staff to know the engineers are in charge of the power? It's honestly more gamey for them to know what a resonance cascade or supermatter delamination is, so I'd say you've done the opposite of what the goal was with the message changes on top of making them less fun in general. I disapprove.
Oh, yeah, and the SM now reports the times correctly due to it reporting them every 5 seconds, meaning people would only see the 10 second announcement. Now there is going to be a 15 second announcement as well.
Watering down messages to be bland is just, like, less fun, ya know? I didn't see a single person in support of the message changes apart from the PR author, everyone else was just complaining about them, including myself.
Also, several people mentioned the fact it could just be 15 instead of 13 for a nice round number, including myself. I also made the sliver delamination time 5 seconds instead of 3 seconds because you pretty much can't get out in time, especially if the game is laggy. 3 - 5 people being round removed because of one traitor objective with no chance to escape it is just bad gameplay.
Oh, and, bugfix good, I suppose.
🆑 balance: Supermatter now takes 15 seconds to delaminate normally and 5 if a sliver has been taken from it. Gives a little more time to escape in the case of the sliver and also evens out the times to please perfectionists. fix: Supermatter now accurately reports it's detonation time. spellcheck: Supermatter mood descriptions have been reverted back to their old, more flavorful selves. /🆑
The Food Sortening, Extra Pain-In-My-Ass Edition (#17393)
- The Food Sortening, Extra Pain-In-My-Ass Edition
Sorts all food sprites and cuts down the MONOLITH snacks.dm and food.dmi. This was an absolute pain in my ass. No front-facing changes.
Planning to add more shit down the line. Makes everyone's lives easier.
-
changelol
-
finally
-
inhands
-
merge conflict
-
this really "ticked" me off HAHAHAHAHS
-
fixes
-
make megalinter happy
SO much new shit fr just read the description
New active items! Dusty D6, Dusty D4, Dusty D100, D11, Blood Meridian, House of Leaves New passive items: Lil Ari, Faded Note, Fuck That Noise!, a whole bunch of new X10 Shitposts (which I don't really count as items since they're jokes sorta)
New Boss: Despair! (WIP)
New trinkets: Blank White Card, YES!, Floppy Disk, Plastic Key
New pickup: Toy Chests!
New consumables: Zap, Misprinted Justice (finally!), Bank Error In Your Favor, Time Wizard, Quicklove, Starlight, Pale Box, Lucky Flower
New pill effects: Free Crack, Uppers!, Downers!, Psychedelics
New grid entity: Radioactive barrel! (WIP)
New enemy: Oozer (Ashpit)! Innies (Hoard) have been fixed!
Book Of Virtues wisps for many active items!
New challenge: MyBasement.lua!
xfs: reserve less log space when recovering log intent items
Wengang Wang reports that a customer's system was running a number of truncate operations on a filesystem with a very small log. Contention on the reserve heads lead to other threads stalling on smaller updates (e.g. mtime updates) long enough to result in the node being rebooted on account of the lack of responsivenes. The node failed to recover because log recovery of an EFI became stuck waiting for a grant of reserve space. From Wengang's report:
"For the file deletion, log bytes are reserved basing on xfs_mount->tr_itruncate which is:
tr_logres = 175488,
tr_logcount = 2,
tr_logflags = XFS_TRANS_PERM_LOG_RES,
"You see it's a permanent log reservation with two log operations (two transactions in rolling mode). After calculation (xlog_calc_unit_res() adds space for various log headers), the final log space needed per transaction changes from 175488 to 180208 bytes. So the total log space needed is 360416 bytes (180208 * 2). [That quantity] of log space (360416 bytes) needs to be reserved for both run time inode removing (xfs_inactive_truncate()) and EFI recover (xfs_efi_item_recover())."
In other words, runtime pre-reserves 360K of space in anticipation of running a chain of two transactions in which each transaction gets a 180K reservation.
Now that we've allocated the transaction, we delete the bmap mapping, log an EFI to free the space, and roll the transaction as part of finishing the deferops chain. Rolling creates a new xfs_trans which shares its ticket with the old transaction. Next, xfs_trans_roll calls __xfs_trans_commit with regrant == true, which calls xlog_cil_commit with the same regrant parameter.
xlog_cil_commit calls xfs_log_ticket_regrant, which decrements t_cnt and subtracts t_curr_res from the reservation and write heads.
If the filesystem is fresh and the first transaction only used (say) 20K, then t_curr_res will be 160K, and we give that much reservation back to the reservation head. Or if the file is really fragmented and the first transaction actually uses 170K, then t_curr_res will be 10K, and that's what we give back to the reservation.
Having done that, we're now headed into the second transaction with an EFI and 180K of reservation. Other threads apparently consumed all the reservation for smaller transactions, such as timestamp updates.
Now let's say the first transaction gets written to disk and we crash without ever completing the second transaction. Now we remount the fs, log recovery finds the unfinished EFI, and calls xfs_efi_recover to finish the EFI. However, xfs_efi_recover starts a new tr_itruncate tranasction, which asks for 360K log reservation. This is a lot more than the 180K that we had reserved at the time of the crash. If the first EFI to be recovered is also pinning the tail of the log, we will be unable to free any space in the log, and recovery livelocks.
Wengang confirmed this:
"Now we have the second transaction which has 180208 log bytes reserved too. The second transaction is supposed to process intents including extent freeing. With my hacking patch, I blocked the extent freeing 5 hours. So in that 5 hours, 180208 (NOT 360416) log bytes are reserved.
"With my test case, other transactions (update timestamps) then happen. As my hacking patch pins the journal tail, those timestamp-updating transactions finally use up (almost) all the left available log space (in memory in on disk). And finally the on disk (and in memory) available log space goes down near to 180208 bytes. Those 180208 bytes are reserved by [the] second (extent-free) transaction [in the chain]."
Wengang and I noticed that EFI recovery starts a transaction, completes one step of the chain, and commits the transaction without completing any other steps of the chain. Those subsequent steps are completed by xlog_finish_defer_ops, which allocates yet another transaction to finish the rest of the chain. That transaction gets the same tr_logres as the head transaction, but with tr_logcount = 1 to force regranting with every roll to avoid livelocks.
In other words, we already figured this out in commit 929b92f64048d ("xfs: xfs_defer_capture should absorb remaining transaction reservation"), but should have applied that logic to each intent item's recovery function. For Wengang's case, the xfs_trans_alloc call in the EFI recovery function should only be asking for a single transaction's worth of log reservation -- 180K, not 360K.
Quoting Wengang again:
"With log recovery, during EFI recovery, we use tr_itruncate again to reserve two transactions that needs 360416 log bytes. Reserving 360416 bytes fails [stalls] because we now only have about 180208 available.
"Actually during the EFI recover, we only need one transaction to free the extents just like the 2nd transaction at RUNTIME. So it only needs to reserve 180208 rather than 360416 bytes. We have (a bit) more than 180208 available log bytes on disk, so [if we decrease the reservation to 180K] the reservation goes and the recovery [finishes]. That is to say: we can fix the log recover part to fix the issue. We can introduce a new xfs_trans_res xfs_mount->tr_ext_free
{ tr_logres = 175488, tr_logcount = 0, tr_logflags = 0, }
"and use tr_ext_free instead of tr_itruncate in EFI recover."
However, I don't think it quite makes sense to create an entirely new transaction reservation type to handle single-stepping during log recovery. Instead, we should copy the transaction reservation information in the xfs_mount, change tr_logcount to 1, and pass that into xfs_trans_alloc. We know this won't risk changing the min log size computation since we always ask for a fraction of the reservation for all known transaction types.
This looks like it's been lurking in the codebase since commit 3d3c8b5222b92, which changed the xfs_trans_reserve call in xlog_recover_process_efi to use the tr_logcount in tr_itruncate. That changed the EFI recovery transaction from making a non-XFS_TRANS_PERM_LOG_RES request for one transaction's worth of log space to a XFS_TRANS_PERM_LOG_RES request for two transactions worth.
Fixes: 3d3c8b5222b92 ("xfs: refactor xfs_trans_reserve() interface") Complements: 929b92f64048d ("xfs: xfs_defer_capture should absorb remaining transaction reservation") Suggested-by: Wengang Wang [email protected] Cc: Srikanth C S [email protected] [djwong: apply the same transformation to all log intent recovery] Signed-off-by: Darrick J. Wong [email protected] Reviewed-by: Dave Chinner [email protected]
App Menus!
Been wanting to set this up for a long time now! It's actually really nice to set up the defaults. TypeScript really helps with this especially too.
https://www.electronjs.org/docs/latest/api/accelerator (I thought this was to do with the menus, but this is instead the keyboard shortcuts standalone, themselves) https://www.electronjs.org/docs/latest/api/menu#examples (Big help here, this is great actually!) https://www.electronjs.org/docs/latest/api/menu-item (Related to the last part, it's the actual class instance that is built after using the templates. It's the instances which hold the menu metadata and options themselves on there) https://www.youtube.com/watch?v=4aIanHYViOM (A great big help for this too, thank you!)
Been listening to some of the albums in this playlist last night and today during this session. I've felt like I'm in a creative stagnation for music writing recently, so I'm trying to go back to older songs, and try out new stuff to get my ideas reset a little bit again. These first two bands are sick, I really like the both two albums this playlist starts with 🔥 (This is much heavier than what I listen to normally, but I think it's what I've been looking for maybe? looked up 'ambient metal' the other day, and found this and other gems, because of that. I think I looked up black metal/progressive black metal to find this one though hehe) https://www.youtube.com/watch?v=rk_BTrL6rwI&list=PL9FMwl2Y6WAdiuvoMqGrVdktDPuFts51Q&index=1 https://www.youtube.com/watch?v=BHDAKPW4lgk&list=PL9FMwl2Y6WAdiuvoMqGrVdktDPuFts51Q&index=2
I'm very surprised and sad about the departure of Salvatore from Thank You Scientist; just heard today he's leaving the band. Sounds like he heavily misses his family though, so I totally feel for him in his choice to do that. I'd rather him be honest like that and make that call, than to deal with not doing what he truly wants do/has to. I'm glad I found Thank You Scientist when I did, I hope they keep going, I'd love to see them live someday!
just so we all know: my family or friends of my family do not represent all of India or Indian culture, whatsoever, especially my overseas relatives. None of this has or ever will. It's always been about individual motivations. No one can own an entire country's history or culture, and anyone who attempted to say they were right about me because they are related to or of the same origins as me are just liars whom should not be trusted with financial or political boons of any kind, and such a thing should serve a valuable lesson to future organizations. That said, and I will address this elsewhere in detail, I do understand how some corporate and political leaders could not say "no" to some of the people involved, because you feared looking rascist. Anyway, I'm sure we can all agree had you found a way to say "no" behind closed doors months or years ago, this would have ended and would never have caused you as much trouble or pain. That said, it's been extremely validating to me and my reasons to keep distance from parts of my family. The largest lesson I learned is that I should protect my direct relatives - particularly my mother and father - from getting tied into these things again as it will be taken out of their control by their overseas relatives. I'm sorry for all the trouble they have caused you, particularly political and corporate leaders. I wish the best of luck to the upcoming negotiations and hope they go as smoothly as the recent ones this weekend.
You can do revival surgery on Ian (#78288)
Allows you to perform revival surgery on any mob which is organic or
looks humanoid.
This means yes: Corgis, Goliaths, Syndicate mobs not those because
they spawn human corpses and delete themselves.
No: Slimes, Ghosts, General Beepsky.
Splits revival surgery into a subtype used for "mobs" and a subtype for "mobs with brains" as the former don't have any brains to damage.
Additionally by special request, Ian can now wear an eyepatch and will automatically put one on if he is brought back from death.
Currently you revive dead pets either by creating a magical reagent out of holy water or by buying a mining item which also brainwashes them, however reasonably our skilled medical team should be able to put a dog back together and now can. When you fuck up one of the stages of Tend Wounds on a kitten and stab it to death with your scalpel, now you can fix it. Expands the possibilities of vetinerary roleplay.
🆑 add: Many kinds of mobs can now be brought back to life through revival surgery. add: Dogs can wear eyepatches. /🆑
[MIRROR] Added the Hippocrates bust to medbay heirlooms [MDB IGNORE] (#23881)
- Added the Hippocrates bust to medbay heirlooms (#78121)
Remade from #77961 because coders dont like bloat in prs
Added the Hippocrates bust to medbay heirlooms. Paramedics don't get one.
You can now swear the Hippocratic oath with these busts! It'll give you pacifism but nothing else. The process is reversible.
There's a very small chance that the Hippocrates bust was once wielded by a certain German doctor. This chance is increased for coroner heirlooms.
Added the Hippocrates bust to medbay heirlooms. Paramedics don't get one.
I got this idea and I just couldn't get it out of my head, it's too funny. Paramedics don't get one because they're powergamers and laugh at the Oath, and also it doesn't feel like a paramedic thing.
You can now swear the Hippocratic oath with these busts! It'll give you pacifism but nothing else. The process is reversible.
This is just a little fun thing you can choose to do, i think it'd be cute to see doctors swearing the oath in medbay. Plus it's reversible which can be even funnier depending on the occassion.
There's a very small chance that the Hippocrates bust was once wielded by a certain German doctor. This chance is increased for coroner heirlooms.
We DO already have precedent for references with the entrenching tool after all. The buff isn't all that special in reality, getting a medical hud while in your hand is... basically irrelevant for the roles that literally spawn with a med hud? It's just for accuracy and rule of cool's sake.
🆑 add: Added the Hippocrates bust to medbay heirlooms. Paramedics don't get one. add: You can now swear the Hippocratic oath with these busts! It'll give you pacifism but nothing else. The process is reversible. add: There's a very small chance that the Hippocrates bust was once wielded by a certain German doctor. This chance is increased for coroner heirlooms. /🆑
Co-authored-by: Arturlang <24881678+Arturlang@ users.noreply.github.com>
- Added the Hippocrates bust to medbay heirlooms
Co-authored-by: carlarctg [email protected] Co-authored-by: Arturlang <24881678+Arturlang@ users.noreply.github.com>
Resub of Assignment 3 Unit 2 - Incomplete
I give up trying to fix this shit. I can't make fucking triangles to save my fucking life :)
modularize source code
suckie time has ended, use standard src/ file hierarchy.
pd: Since I plan to read a bit more about linux battery life and
improvements, I'm cleaning up a bit my enviroment. I realize that, on my
older projects, I don't remember much about the WIP
features/fixes/improvs I was working on at that time (mainly lack of
explicit and descriptive code [suckless habit]). I found myself very
comfy on a modular programing enviroment in my experience with
wallust. There was
good days, but even better are comming c:
windows: ignore empty PATH elements
When looking up an executable via the _which function, Git GUI
imitates the execlp() strategy where the environment variable PATH
is interpreted as a list of paths in which to search.
For historical reasons, stemming from the olden times when it was uncommon to download a lot of files from the internet into the current directory, empty elements in this list are treated as if the current directory had been specified.
Nowadays, of course, this treatment is highly dangerous as the current
directory often contains files that have just been downloaded and not
yet been inspected by the user. Unix/Linux users are essentially
expected to be very, very careful to simply not add empty PATH
elements, i.e. not to make use of that feature.
On Windows, however, it is quite common for PATH to contain empty
elements by mistake, e.g. as an unintended left-over entry when an
application was installed from the Windows Store and then uninstalled
manually.
While it would probably make most sense to safe-guard not only Windows
users, it seems to be common practice to ignore these empty PATH
elements only on Windows, but not on other platforms.
Sadly, this practice is followed inconsistently between different software projects, where projects with few, if any, Windows-based contributors tend to be less consistent or even "blissful" about it. Here is a non-exhaustive list:
Cygwin:
It specifically "eats" empty paths when converting path lists to
POSIX: https://github.com/cygwin/cygwin/commit/753702223c7d
I.e. it follows the common practice.
PowerShell:
It specifically ignores empty paths when searching the `PATH`.
The reason for this is apparently so self-evident that it is not
even mentioned here:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables#path-information
I.e. it follows the common practice.
CMD:
Oh my, CMD. Let's just forget about it, nobody in their right
(security) mind takes CMD as inspiration. It is so unsafe by
default that we even planned on dropping `Git CMD` from Git for
Windows altogether, and only walked back on that plan when we
found a super ugly hack, just to keep Git's users secure by
default:
https://github.com/git-for-windows/MINGW-packages/commit/82172388bb51
So CMD chooses to hide behind the battle cry "Works as
Designed!" that all too often leaves users vulnerable. CMD is
probably the most prominent project whose lead you want to avoid
following in matters of security.
Win32 API (CreateProcess())
Just like CMD, `CreateProcess()` adheres to the original design
of the path lookup in the name of backward compatibility (see
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
for details):
If the file name does not contain a directory path, the
system searches for the executable file in the following
sequence:
1. The directory from which the application loaded.
2. The current directory for the parent process.
[...]
I.e. the Win32 API itself chooses backwards compatibility over
users' safety.
Git LFS:
There have been not one, not two, but three security advisories
about Git LFS executing executables from the current directory by
mistake. As part of one of them, a change was introduced to stop
treating empty `PATH` elements as equivalent to `.`:
https://github.com/git-lfs/git-lfs/commit/7cd7bb0a1f0d
I.e. it follows the common practice.
Go:
Go does not follow the common practice, and you can think about
that what you want:
https://github.com/golang/go/blob/go1.19.3/src/os/exec/lp_windows.go#L114-L135
https://github.com/golang/go/blob/go1.19.3/src/path/filepath/path_windows.go#L108-L137
Git Credential Manager:
It tries to imitate Git LFS, but unfortunately misses the empty
`PATH` element handling. As of time of writing, this is in the
process of being fixed:
https://github.com/GitCredentialManager/git-credential-manager/pull/968
So now that we have established that it is a common practice to ignore
empty PATH elements on Windows, let's assess this commit's change
using Schneier's Five-Step Process
(https://www.schneier.com/crypto-gram/archives/2002/0415.html#1):
Step 1: What problem does it solve?
It prevents an entire class of Remote Code Execution exploits via
Git GUI's `Clone` functionality.
Step 2: How well does it solve that problem?
Very well. It prevents the attack vector of luring an unsuspecting
victim into cloning an executable into the worktree root directory
that Git GUI immediately executes.
Step 3: What other security problems does it cause?
Maybe non-security problems: If a project (ab-)uses the unsafe
`PATH` lookup. That would not only be unsafe, though, but
fragile in the first place because it would break when running
in a subdirectory. Therefore I would consider this a scenario
not worth keeping working.
Step 4: What are the costs of this measure?
Almost nil, except for the time writing up this commit message
;-)
Step 5: Given the answers to steps two through four, is the security measure worth the costs?
Yes. Keeping Git's users Secure By Default is worth it. It's a
tiny price to pay compared to the damages even a single
successful exploit can cost.
So let's follow that common practice in Git GUI, too.
Signed-off-by: Johannes Schindelin [email protected] Signed-off-by: Pratyush Yadav [email protected]
/shrug
I remember I coded the first few versions using "returns of dereferences" the beginning of this year the first week I created this repository
N' now I'm getting praised for that "ET technology" again
Personally I only see it as I broke my code myself trying to make it better b' it turned out it had been the thing n' since it's github so we can check on the original #.c/#.h files
[cli][frameworks][fs-detectors][next] detect framework versions (#9009)
This PR:
- updates
packages/frameworksto have most supported frameworks specify which dependency version should reflect the overall framework version - updates
packages/fs-detectorsto allow framework detection that returns the fullFrameworkrecord instead of just the slug - updates
packages/nextto return the detected Next.js version in the build result - updates
packages/clito leverage these changes so thatvc buildcan addframework: { version: string; }toconfig.jsonoutput
The result is that Build Output API and supported frameworks will return their framework version in the build result of vc build when possible, which is used by the build container when creating the deployment. The dashboard later retrieves this value to display in richer deployment outputs.
Supports:
With the related build container updates, we get to see Next.js version in the build output. You'll see this with BOA+Prebuilt or a normal deploy:
I went through all the supported frameworks and figured out how to best determine their versions. For most of them, we can check a known dependency's installed version number.
We can get most of the way only checking npm. For a handful, we'd have to support Go/Ruby/Rust/Whatever dependencies.
I started with a more complex method signature to allow for later expansion without changing the signature. It looked like this, in practice:
async getVersion(dependencies: DependencyMap) => depedencies['next']
However, after checking all currently supported frameworks, I don't think this will end up being necessary. It also has the constraint that all dependencies have to be gathered and presented to the function even though it only needs to check for one or two. That's not a huge deal if we have them already where we need them, but we don't. We could use a variant here where this function does its own lookups, but this seemed unnecessary and would beg for duplication and small variances that could cause bugs.
Further, if we only look at package.json, we're going to either see a specific version of a version range. To be precise, we have to look at the installed version of the package. That means checking one of the various types of lockfiles that can exist or poking into node_modules.
If we poke into node_modules to detect the installed version, we introduce another point where Yarn 3 (default mode) will not be supported. If we read lockfiles, we have to potentially parse npm, pnpm, and yarn lockfiles.
If we use npm ls <package-name>, that also fails in Yarn 3 (default mode). We could accept that and go forward anyway, which would look like:
const args = `ls ${packageName} --depth=0 --json`.split(' ');
const { stdout } = await execa('npm', args, { cwd });
const regex = new RegExp(String.raw`${packageName}@([\.\d]+)`);
const matches = stdout.match(regex);
if (matches) {
return matches[1];
}
But it turns out there's a --json option! That's what I ended up using, for now.
We could explore the lockfile route more, but after some initial digging, it' non-trivial. There are 3 main lockfiles we'd want to check for (npm, pnpm, and yarn) and there are different lockfile versions that put necessary data in different places. I looked for existing tools that parse this, but I didn't find any. We could certainly go down this path, but the effort doesn't seem worth it when npm ls gets us really close.
Now that we know how to determine version per framework, we can vary configuration by version. In a future PR, we could allow a given value to vary by version number:
name: (version) => {
if (semver.gt(version, '9.8.7')) {
return 'some-framework-2''
}
return 'some-framework';
}
However, it may still be easier to differentiate significant versions by adding multiple entries in the list.
Desouls Hivelord (#78213)
Replaces the sprite of the hivelord with a new one, in my continuing quest to annihilate the old asteroid mob sprites. A (never completed) asteroid mob resprite was actually my first PR, this one is my 200th. I am also planning on fucking with basic mob versions of these mobs some time but the sprites can be atomised out.
In addition to replacing the old-ass MSPaint sprites, this PR also adds a short death animation effect to the hivelord brood (from hivelords or legions) which looks nicer than them just vanishing instantly upon death.
Look at this video for an example of the animation: https://www.youtube.com/watch?v=cKaskN5-y2A
Looks nicer.
🆑 image: Hivelords have a new sprite. image: Hivelord and Legion brood have a death animation. /🆑
[TEST-MERGE FIRST] Wound refactor number two: Full synthetic support (#78124)
Heavily refactors wounds AGAIN.
The primary thing this PR does is completely change how wounds are generated and added - while the normal "hit a guy til they bleed" stuff works about the same, asking for a specific type of wound, say, like how vending machines try to apply a compound fracture sometimes, isnt going to work if we ever get any non-organic wounds, which the previous refactor allowed.
With this PR, however...
- You can now ask for a specific type of wound via get_corresponding_wound_type(), which takes wound types, a limb, wound series, etc. and will try to give you a wound fitting those specifications - but also, a wound that can be applied to a limb.
- This will allow for a vending machine to apply a compound fracture to a human, but a collapsed superstructure (assuming my synth wounds go in) to a robot
There are now new "series types" and "wound specific types" that allow us to designate what series are "mainline" and randomly generatable, and what are "alternate types" and must be generated manually - you can see the documentation in wounds.dm.
The behavior of limping and interaction delays has been abstracted to datum/wound from bone wounds to allow just, general ease of development
Pregen data now allows for series-specific wound penalties. Example: You could set a burn wound's series wound penalty to 40, which would make wound progression in the burn category easier - but it would not make it any easier to get a slashing wound. As it stands wound penalties are for wounds globally
Scar files are now picked in a "priority" list, where the wound checks to see if the limb has a biostate before moving down in said list. Example: Wounds will check for flesh first, if it finds it - it will use the flesh scar list. Failing that, they then check bone - if it uses that, it will use the bone scar list. This allows for significantly more modular scars that dont even need much proc editing when a new wound type is added
Misc changes: most initial() usage has been replaced by singleton datums, wound_type is now wound_types and thus wounds can accept multiple wound types, wounds can now accept multiple tool behaviors for treatment, wounds now have a picking weight so we can make certain wounds rarer flatly,
This PR also allows for wounds to override lower severity wounds on generation, allowing eswords to jump to avulsions - but in spirit of refactoring, this has been disabled by default (see pregen data's competition_mode var).
Code quality is good!
Also, all the changes above allow wounds to be a MUCH more modular system, which is one of its biggest problems right now - everything is kinda hardcoded and static, making creative work within wounds harder to do.
🆑 refactor: Refactored wounds yet again fix: Wounds are now picked from the most severe down again, meaning eswords can jump to avulsions fix: Scar descs are now properly applied /🆑
levels: various QOL fixes.
Generally there should be nothing necessary to finish a level that requires any of:
- straferunning;
- extremely sensitive timing that could softlock you if you're on keyboard, lagging in multiplayer or have motor issues;
- checking only for a sound cue that something has happened;
- remembering how to distinguish two visually nearly identical areas; or
- backtracking to a previous area on the map that you had previously been given no reason to revisit.
I haven't caught all of them by any stretch of the imagination but it's a start.
Also some regular minor fixes.
E1M9
- Fixed some textures around the big blue-trimmed lift and removed an extraneous use line that triggered a faraway lift for no reason.
- The red key bridge lowerable section is now textured differently from the rest of the bridge.
E3M5
- Teleporter platform to get back up to the catwalk from the northeastern blood maze is now clearly marked as having a switch, as it is a mandatory progression rather than a secret.
E4M8
- Got rid of some fake contrasts on the noodles at the start.
- Added a radsuit for the northwest switch. While it is possible to avoid damage even without straferun, unless you've got a tic counter display and can time it to the damage interval this is basically RNG.
- The water flat on top of the lowering wall in the east was very, very noticeable. The switch is now stepped on instead of hit. (Not too sure if the secret isn't too obscure now...)
- Removed asymmetrical doortrak on the slime bridge on the southeastern piston switch.
- The linedefs of said slime bridge pit are flipped so a deathmatch opponent trying to grab the berserk in there is not magically immune to rocket blasts. (see #996)
- Realigned the four pistons by the gate to the starship. They also reveal moving parts when activated - not nearly as good as the crushers on the original DI, but better than nothing.
- Made the southern walls use PLAT1 to make it more obvious that those walls will lower later (with the added bonus that they match the four pistons).
- The southern light bronze area now has a strip to guide the player towards the switch in case they lose track of their direction while fighting monsters and forget to explore inside that area, as well as to better distinguish it from the southeast.
- The gate threshold to the southern light bronze area now matches that of the pre-opened southeast.
- There is now actually a threshold where you can tell where the starport ends and the ship begins.
- The two light bronze areas are a bit too similar-looking. Added a few health boosts so the player can spot/be attacked by them and know this is an unexplored area.
Map11
- The lift going down into the yellow key room requires a switch that is out of sight from the lift itself, which is not clearly marked as a lift to begin with. The only real way to realize what's going on if you don't already know about the lift is to locate the sound and immediately turn to investigate before the lift comes back up. I thought this was annoying when I first did my big overhaul of this map, but ultimately left the basic mechanism alone out of an abundance of caution; however, with the recent discussion of accessibility in the proposed changes to the documentation I'm revisiting this. That upper switch now lowers a wall to reveal the lift which is triggered by a walk line.
- The lower far switch on that same lift was actually literally impossible to make on keyboard and no straferun (and no vanilla wallbounce exploit), even if I change it to a regular lift instead of fast. This is completely unacceptable for something necessary to progression (rather than an obscure secret). The lower switches are now permanent repeatable floor-lowerers, while the line crossing from the lift into the lower chamber is a permanent repeatable floor-raiser, with the line crossing into the lift from above being a simple lift line.
- Retextured the stairs out of the water in the eastern branch so it's not an unreadable mess of criss-crossing grey lines.
- Realigned the new skull switch texture in the skull room.
Map19
- One of the stealth worms was stuck in a burning barrel.
- Removed monster block flag on line 2083.
- Unmerged and remerged a few identical sectors to better match the intended sound travel.
- Flagged line 281 as a monster blocker. This allows the player to always be able to make the jump onto that bottom stair without being blocked by the octaminator.
- That octaminator is now a pain bringer in easy mode. The far end of that platform path is well outside the maximum vertical autoaim range in vanilla, which means that to actually hit the octaminator without up/down aiming you'd have to be on one of the later platforms - i.e., confined to a relatively narrow area with no cover against an opponent that has seeker missiles. The best way to solve this is to charge towards the octaminator as fast and as soon as possible with the SSG, minigun, or ripsaw+prayer to RNGsus that you'll get a good painlock. This is not the kind of tactic the sort of person who needs to play on easy will think to do, or could do while also being ready to sidestep if the octaminator fires at the wrong time.
- 347 and 249 are now also monster blockers, and the worms in that slime pit have been moved to the platform just behind the combat slug since they're awakened early on and that's where you'll first encounter them anyway.
- Replaced the teleport pad in the vertical platforming sequence with a lift, to minimize disorientation and going the wrong way. (In retrospect I probably could have just made the teleport destination face the pit you came in from, but the lift worked aesthetically better anyway.)
- A good chunk of that entire platforming area has been moved 8 units to the west so that things would align with the flat grid.
- Lines 307 and 309 are now also monster blockers. The worm that would be trapped between them is now moved further down the route and marked ambush.
Map20
- Removed the useless, misleading skull switch texture on the bars at the start.
- The door leading into the blue key arena needs no blue key; the door leading out needs a blue key. Both are marked with blue-light trim. Removed the blue lights on the first one.
- The lowering wall leading to the teleporter now uses a pipe texture.
- The door leading out of the giant quadruped arena now has a bright flickering light.
- Yellow key is another case of effectively-randomly-mandatory damage. Added a path.
- Same with the lava tunnel on the red key route.
Map25
- The silver lift near the river and shack is now activated by SW1GSTON switch right on the wall at eye level, rather than counterintuitively and invisibly recessed into additional sectors.
- The painlord ambush lift is now accessible after the encounter. A small health refill has been added there for easy and medium.
pseudo: Fix to work with glibc 2.38
This adds a horrible hack to get pseudo working with glibc 2.38. We can't drop _GNU_SOURCE to something like _DEFAULT_SOURCE since we need the defines the gnu options bring in. That leaves using internal glibc defines to disable the c23 versions of strtol/fscanf and friends. Which would break pseudo build with 2.38 from running on hosts with older glibc.
We'll probably need to come up with something better but this gets glibc 2.38 and working and avoids autobuilder failures.
(From OE-Core rev: 909fd25c2ebd25f5d3bc560e26f9df6862e033d0)
Signed-off-by: Richard Purdie [email protected] (cherry picked from commit 596fb699d470d7779bfa694e04908929ffeabcf7) Signed-off-by: Steve Sakoman [email protected]
aider: Add option for users to input a URL and fetch data from it.
USER: Add proper description and tags to the github repo
ASSISTANT: As an AI, I don't have the ability to directly interact with GitHub to add a description and tags to your repository. However, I can guide you on how to do it.
-
Adding a Description to Your Repository
- Go to your GitHub repository.
- Click on the "Edit" button near the repository name.
- In the "Description" field, enter a brief summary of your project. For example, "A Streamlit web application for exploring and manipulating CSV datasets."
- Click "Save".
-
Adding Tags (Topics) to Your Repository
- Under your repository name, click the "Manage topics" link.
- In the "Topics" field, enter topics that are relevant to your project. These could include "python", "streamlit", "data-visualization", "csv", "data-analysis", etc.
- Press ^C KeyboardInterrupt
USER: Can I host this project in github
ASSISTANT: Yes, you can host the code for this project on GitHub. Here are the steps to do so:
-
Create a new repository on GitHub.
- Go to your GitHub account.
- Click on the '+' icon in the upper right corner and select 'New repository'.
- Name your repository and provide a description.
- Choose whether to make your repository public or private.
- Initialize the repository with a README if you want.
- Click 'Create repository'.
-
Push your local project to the GitHub repository.
- Open Terminal or Command Prompt on your computer.
- Navigate to the project directory.
- Initialize the local directory as a Git repository:
git init - Add the files in your new local repository. This stages them for the first commit:
git add . - Commit the files that you've staged in your local repository:
git commit -m 'First commit' - In the Command prompt, add the URL for the remote repository where your local repository will be pushed:
git remote add origin remote repository URL - Push the changes in your local repository to GitHub:
git push -u origin master
Now your project is hosted on GitHub.
However, if you want to host the application itself (i.e., make it accessible as a web app), you'll need to use a platform like Heroku, AWS, or Google Cloud Platform. GitHub itself does not host web applications, it only hosts the code for projects.
USER: Can I use github pages to host streamlit apps
ASSISTANT: No, unfortunately, you cannot use GitHub Pages to host Streamlit apps. GitHub Pages is designed to host static websites, i.e., websites that consist of fixed content. Streamlit apps, on the other hand, are dynamic and require a server to run Python code, which GitHub Pages does not support.
To host a Streamlit app, you would need to use a service that supports running Python applications. Some popular options include:
-
Heroku: A platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud. It supports Python and is free for small applications.
-
Streamlit Sharing: A platform provided by Streamlit itself for hosting Streamlit apps. It's free but currently in beta and requires an invitation.
-
AWS (Amazon Web Services): A secure cloud services platform, offering compute power, database storage, content delivery and other functionality. It's not free, but it's very flexible and powerful.
-
Google Cloud Platform: Similar to AWS, it provides a variety of cloud services on Google infrastructure. It's also not free, but offers a wide range of services and is quite flexible.
Remember, deploying a Streamlit app on these platforms usually involves providing a requirements.txt file that lists all of the Python libraries that your app needs to run, and possibly also providing some configuration files.
USER: What other features can I add to this streamlit app
ASSISTANT: There are many features you could add to your Streamlit app to enhance its functionality and user experience. Here are a few suggestions:
-
User Authentication: Implement a login system to control access to your app. This could be useful if you want to restrict access to certain users or track user activity.
-
Data Upload from URL: In addition to uploading files, allow users to input a URL from which the app can fetch and load data.
-
More Data Transformations: Add more options for users to manipulate the data. This could include more complex operations like normalization, standardization, encoding categorical variables, handling missing values, etc.
-
Machine Learning Models: Allow users to apply machine learning models to the data. You could provide a selection of pre-trained models for common tasks, or allow users to train their own models on the data.
-
Interactive Visualizations: Use libraries like Plotly or Bokeh to create interactive plots that users can zoom, pan, and hover to get more detailed information.
-
Real-time Data: If applicable, you could add functionality to handle real-time data streams.
-
Exporting Results: Allow users to export the results of their data analysis, either by downloading files or by sending the results to an email address.
-
User Feedback: Implement a system for users to provide feedback on the app, report issues, or request new features.
Remember, the features you choose to add should depend on the needs of your users and the purpose of your app. Always consider the user experience when adding new features.
USER: Data Upload from URL: In addition to uploading files, allow users to input a URL from which the app can fetch and load data.
ASSISTANT: To implement the feature of data upload from a URL, we need to modify the translate_app.py file. We will add a new option for the user to input a URL, and then use the pandas.read_csv() function to fetch and load the data from the URL.
Here are the changes to make in the translate_app.py file:
This change will add a new option for the user to input a URL from which the app will fetch and load data. If the URL does not point to a valid CSV file, an error message will be displayed.
Remove balancer.fi from blocklist (#13609)
Balancer has recovered control of balancer.fi after a social engineering attack at our registrar allowed hackers to take over the account.
We have confirmed that correct IPs have propigated. If possible, please leave web.balancer.fi on the blocklist as we do not use it, and it seems like this name was used as part of the recent attack.
We have a war room open that we contacted via the seal-911 chat and I have been speaking to Tay. You can find me that way if you have questions.
Thank you
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. :)))
Signed-off-by: TogoFire [email protected] Change-Id: Icef2de24b839ae4b5a51bf90ae0ab9a4d816f329
Skrem's Quick Ballistic Glanceover (#2354)
If maintainers want me to shorten the changelog, I can, I tend to start there so I know what to talk about up here.
What started as a PR meant to buff up rubber rounds ended up turning into a general passover I gave to much of the syntax and presentation of ballistics. PR doesn't actually change that much function-wise, but it changes a lot of lines due to a lot of changed pathing to better establish consistency within ballistic code as well as overviewing a lot of descriptions, names, and inherit moments.
Functionally, less-lethals and sniper rounds have been changed the most by this PR. To a lesser extent, .38 special and shotgun rounds have been tweaked. Finally, the PR stamps out a missing sprite bug with the WT-550 magazines, buffs up the surplus rifle (yeah, that old thing), tinkers with some projectile speeds, makes match rounds slightly better, and goes over A LOT of descriptions. I apologize for the massive wall of text that's to follow.
Will take a look at energy weapons when I feel like it (might kill disablers, I don't like mapping though).
The pellet changes are actually just systemizing what was supposed to be intentional design according to code comments, it just hadn't reached every single pellet-based shotgun projectile. The improvised shell buff is to make it not a potential complete whiff because RNG mechanics are generally bad and not fun to play with.
Several implementations of less-lethal (rubber) ammunition on shiptest are strictly worse than their standard alternatives. While this isn't a PvP server, it feels very not-fun meta-wise to POTENTIALLY arm for SOME insubordination and still fire what may as well be a round that bleeds someone out (as they'll cause bleeding anyway). Increasing the stamina damage on each of these makes it so they actually have a vague trade-off (maybe stamina damage can do something like slow simplemobs in the future, I don't know, I'd love to do it but simplemob code makes me screech).
To make them not directly better in PvP and not the staple of taking down the Super Scary Syndicate Shocktrooper Guy, they've had their negative AP doubled. Not as good against combatants, but still perfectly adept, if not better at general riot control against civilians. Makes sense and puts them in their niche a little better.
The .38 special round relatively has more "power" and "velocity" compared to the 9mm round, though it does not quite reach the levels that .45 automatic or 10mm does in the IRL server. Furthermore, .38 special was specifically designed not to over-penetrate targets so as to minimize the chance of collateral damage in police work. These are the ultimate justifications behind giving it the worst AP out of all the pistol calibers (-30, instead of -20) while still raising its damage to 25.
This should make the Winchester a better staple for taking out weaker enemies such as legions or unarmored hermits, but it'll perform worse against goliaths, frontiersmen, and the like. All-in-all, a more "early-game" caliber, if you will, which is kinda what it's always been.
Match rounds don't really exist as far as I've seen. That being said, they're meant to be of higher quality, so their getting slightly higher AP and speed makes sense, even if they're mostly just a meme round.
The speed increase of DMR/sniper rounds is primarily meant to differentiate them better from AR rounds beyond having 20 more AP. Assault rifles so far have pretty much dominated with better magazine size, fire rate, and the exact same force as the DMR calibers, just doing less damage against armored targets (doesn't matter too much when you can just vomit rounds). I'd like to buff up the DMR damage even more (sniper is fine), but I'd rather get some feedback on changing them to 35 baseline before doing so.
The speed decrease on shotguns is meant to cement them as CQC weapons. Slugs are heavy. Shotguns are meant for close range. It's not much, but it's thematically a good way to keep them in their lane, not that they're even that problematic, hence only the slight change.
Having a big-ass bullet that does 70 damage with 50 AP hit you is already a middle finger. Making it potentially knock off an arm or a leg is another middle finger. Being hardstunned for ten seconds after is the icing on the cake. Changed it to a knockdown because we hate ranged tasers.
This thing is a joke. I haven't even seen it on the server, but I'd rather make it vaguely competitive considering 10mm isn't super deadly and only otherwise exists on the stechkin or the one Inteq SMG that you never see (Colossus-only).
It's still clunky and terrible, but it should be less comedic and more of a potential option if you have NOTHING else (will never happen).
Top-loading magazine fits into a standard assault rifle? No. Doesn't make sense. Someone should probably just kill this gun, it's stupid and looks stupid last I checked.
Don't think I've seen anyone use this weapon, I've only printed out their magazines to dump AP rounds into my NT-SVG carbine. Noticed they were invisible then. Someone increased their capacity to 30 without a care for how its update_icon works. Not cool. Anyway, fixes are good. Moving on.
Something very important when maintaining code is generally keeping consistency in how things are not only presented, but how they're stored as well. While I'd love to do EVEN more in the method of refactoring to better align how so much of gun code works, this was something I wanted to keep as a one-day project, so I mostly tinkered with pathing, inherits, and groupings.
In the avenue of spelling and description changes, that's just 1) Cleaning up errors that PR authors and maintainers missed and 2) Making things more concise and just... better. Some of the SolGov descriptions were a real headache to look at, and not because of the frequent spelling and syntax errors.
Whoever misspelled and caused an entire series of items to be /obj/item/gun/ballistic/automatic/assualt may wish to avoid any crows for the next three months.
Perfectly willing to adjust or reel back some of my descriptions if someone can offer something better than what I've written out if there's some soul they REALLY want to keep.
🆑 tweak: The NT 'Boarder' ARG now loads standard P-16 magazines, rather than the M-90gl toploaders. balance: .38 special does 25 damage up from 20. AP has been reduced to -30 from -20. balance: Standardizes pellet projectiles to lose 10% damage of both types per tile across the board. Improvised pellets no longer have a hardcapped 1-8 tile range. balance: Less-lethal rounds now do 50% more stamina than the force of their lethal counterparts, with 25% the normal force and double the negative AP. If the round had positive or zero AP, it was subtracted by 20. balance: Shotgun slugs do 40 damage, down from 60, but have zero AP, rather than -10. FRAG-12 and meteor slugs have had their damage adjusted to reflect their relative force. balance: Surplus rifle fire_delay has been cut to 1 second from 3. balance: .50 BMG knocks down instead of hardstunning. balance: Any DMR, match, or sniper round now travels slightly faster than other bullets. Shotgun slugs and pellets now travel slightly slower than other bullets. balance: Match rounds have had their AP slightly increased. fix: Fixed WT-550 magazines not displaying properly. spellcheck: Went over (almost) every single ballistic description, including the guns themselves, magazines, ballistic casings, and speed loaders/stripper clips to not only have better consistency and readability, but also be more clear on the general effectiveness of each caliber. spellcheck: Assualt is gone. code: Repaths/renames most ballistic ammo pathing to maintain consistency or take advantage of inherits, when possible. /🆑
Polymorph belt blacklists several biotypes instead of allowing only organics [MDB IGNORE] (#23620)
- Polymorph belt blacklists several biotypes instead of allowing only organics (#78229)
Title; this makes the belt able to morph into more mobs, but less problematic/abusable mobs hopefully. It still only functions on basic/simple_animals, however.
Headslugs get a
MOB_UNDEAD bioflag to prevent morphing into them
completely. Though catching a sentient ling slug and morphing everyone
into it is funny, it's only funny the first 5 times someone does it.
(disclaimer: this is an approximation, i did not actually see a
polymorph belt in-game because i currently play miner and like 10 games
a week tops)
Arguably, this isn't ideal, but it's the closest we get unless we rename
MOB_EPIC or something into MOB_SPECIAL and let that one be the go-to
bioflag for mobs we don't want fun things happen to.MOB_EPIC is now MOB_SPECIAL. Headslugs get that.
I think the alternative methow could use whatever the gold cores use to
determine what to spawn but that would shift the mobs available for the
belt even more and I can't be assed to figure out how much of a shift
that would be. Dragons or slimes or lavaland mobs would be out, for
example. Don't really vibe with that.
Fixes headslug's description bit that discerns a sentient slug from an AI one showing up on a dead slug. It can't move while it's dead, no matter its mind/AI.
Also adds simple dmdoc comments to the defines to help discern a few of them more easily. Non-quip text suggestions welcome.
- Resolves #77756
- Resolves #78227
More mobs available for the funny belt but less fun mobs should allow
for more stable use of the damn thing. Arguably, some of the mobs that
have been found to be incompatible with the belt are simply lacking a
MOB_ORGANIC flag, some of them with no apparent reason. However,
blacklisting potentially problematic biotypes should be easier to design
the unwanted mobs around.
Also consistency, less all-ling stations, code clarity. Whatever.
🆑 balance: polymorph belt now blacklists mobs that are undead, humanoid, robotic or spiritual (in nature, not religiously), as well as megafauna balance: however, this means that it works with more mobs that it should logically work with, like slimes/bugs/lightgeists etc fix: fixed headslug shenanigans with the polymorph belt hopefully for good this time fix: fixed headslug description mentioning its movement despite the slug being dead /🆑
- Polymorph belt blacklists several biotypes instead of allowing only organics
Co-authored-by: Sealed101 [email protected]
Home Shorts Subscriptions You Your channel History Your videos Watch Later Show more Subscriptions Healing Sleep Tones Lovemotives Meditation Music WION Deep House Nation Alien Records Spirit Science Clash With Bao Show 201 more Explore Trending Music Gaming News Sport More from YouTube YouTube Premium YouTube Studio YouTube Music YouTube Kids Settings Report history Help Send feedback AboutPressCopyrightContact usCreatorAdvertiseDevelopers TermsPrivacyPolicy & SafetyHow YouTube worksTest new features © 2023 Google LLC 1:14:39 Now playing Creepy and Scary TikToks That will Change Your Reality | DRE_OG LIVE Dre_OG Reacts 43K views Streamed 6 hours ago 38:25 Now playing Donald & Stormi | Help! I'm In A Secret Relationship | Full Episode | Series 1 Episode 8 MTV UK 9.7K views 3 weeks ago 35:02 Now playing J Bay Explodes💥 Biggest Swell in History!! Next Offshore Adventure 273K views 5 days ago 1:47:49 Now playing SCARY And CREEPY Tik Toks That You Should Not Watch Before Bed! Wright7x 30K views 8 hours ago 32:17 Now playing These TikTokers Became Horrible Criminals... DEONDRE 68 views 11 hours ago Shorts Something is going down today! 9/23/23 #shorts 14K views Ancient wars of Mahabharata and the Bhagavad Gita by Billy Carson 44K views 1 Cent Burgers 🍔🤢🚮❌ 88K views What Really Happened To Young M.A! 34K views Pinocchio Predicted THIS Back In 1940 🏝️😲 40K views Unexplained Mysteries of the Natural World Most Amazing Elite 8.7K views 6 days ago Catfish NOT Looking For Love 🤔 Catfish: The TV Show MTV Catfish 84K views 3 weeks ago Autonomous AI Agents - why YOU should be building them... and HOW. Wes Roth 126K views 4 weeks ago Breaking news WATCH | Road closures, flooding and power outages as heavy downpours pummel Western Cape News24 5.4K views 2 hours ago Reports of torrential rains in the Western Cape eNCA 57K views 18 hours ago SA Weather Service warn of severe weather conditions in large parts of the Western Cape SABC News 5.4K views 2 hours ago TikTok's That Will Give You Chills (Pt. 19) JimmyDeeTV 6.7K views 12 hours ago What Is 3-MMC? The Party Drug With "No Comedown" | High Society VICE 517K views 3 days ago Her Revenge Brings Paternity Into Question (Triple Episode) | Paternity Court Paternity Court 93K views 21 hours ago creepiest tik toks you shouldn't watch alone Connor Reacts 132 views 13 hours ago Web Design for Beginners | FREE COURSE Envato Tuts+ 2.9M views 1 year ago Purified Radio 370 Nora En Pure 1.7K views 2 hours ago Sweet Oldies 2.0 ft Clint L Sip N Chill 1M views 2 years ago Thoth - Enki and The Halls Of Amenti by Billy Carson Billy Carson 4biddenknowledge 32K views Streamed 9 hours ago Prime Crime: Stepdad Turned Husband Killed with His Own Kitchen Knife Law&Crime Network 250K views 1 day ago remotely control any PC with a shortcut file?! Loi Liang Yang 59K views 10 days ago Meddling Mothers And Paternity Mysteries (Triple Episode) | MGM Presents Courts MGM Presents Courts 167K views 2 weeks ago [JUDY JUSTICE] Judge Judy [Episode 5578] Best Amazing Cases Season 2023 Full Episode HD HIEU PAPER 4.3K views 20 hours ago
Push it to the limit, Working camra class, it turns my code was ass. Push it to the limit YEAH. The tutorial was shit, i had to grab some code from GIT. Push it to the limit. I need some sleep
Trait trampolines: declare _flat_index as uint32
This is to silence GCC when it decides to make warnings based on bad assumptions about the values that an argument may take.
Or at least, that is what I think is going on. Original issue was reported by @gwikland. I have not been able to create a minimal reproducer, which is why this lacks a test.
The seemingly stochastic nature of the issue does terrify me -- making me doubt myself and wondering if the warning is actually based on a concrete usage rather than GCC assuming something to be possible. However, based on an inspection of the generated code and my previous experience of a similarly stupid error (see #204) I've thoroughly convinced myself that no, GCC really is just deciding to be dumb.
GameOverScreen is in ze game ( and poggers ) ( i had to fix bugs fuck you @olarif )
module: unload module fix recovery bootloop
- fuck you init
Defang type inference.
So far the prelude and some of the libraries work but I haven't updated the tests or the examples. I'm going to keep working in this state as I add expressions-in-types.
My goal here is to make the type inference pass simpler so that we can modify it more easily, particularly adding expressions in types. I also want the type inference process to be more legible to users. It should be easy to reason about what type inference can do and we should be able to provide feedback about what it did.
The main principle I'm trying out is that type inference should be (1) local and (2) feed-forward. "Local" means I don't want inference variables spanning multiple expressions. "Feed-forward" means that type information should flow in the same direction as ordinary data - you get the type of an expression, given the types of its free variables, by looking at the types of its subexpressions. You don't figure out the type of a binder based on its occurrences.
Here are the main changes to type inference. "Fully known" means "contains no inference variables, including in the definitions and types of its free variables".
- All variables have fully-known types, and let-bound variables have fully-known definitions too.
- Each UExpr is either processed "top-down" (i.e. checking it against a
fully-known type) or "bottom-up" (inferring a fully-known type). There's no
"partial checking" where you check a term against, say
?a -> ?bwhere?aand?bare inference variables. - Inference variables only exist for the duration of a single (n-ary) function application.
- Lambda-like binders (including
forbinders) must either be explicitly annotated or their type must be evident from the top-down type we're checking against. The latter case lets us still write things likeeach xs \x. x + xwithout annotating thexbinder. The\xbehaves more like aletbinder than a lambda binder in this context. This is also the reason we can't adopt truly brutalist type inference and do everything bottom-up.
Some things are better now:
- ~1000 loc removed
- "cheap reduction" is now well-typed because there are no inference variables in either the term we're reducing or its environment.
- We now tend to ask "are these types equal?" rather than "what would these variables need to be for these types to be equal?". The latter question doesn't work so well when we move beyond syntactic equality and start talking about equivalence relations.
- We can now reliably use features that require fully-known types, like dot method resolution.
Other things look worse but I think they're actually better:
- To support inference, functions should appear last in an argument list. For
example, we should prefer
eachto its flipped version,map(I actually deletedmapfrom the prelude). This is so that we see the table argument first, which tells us the element type, which tells us the type of the binder of the per-element function. But function arguments should go last anyway, for syntactic reasons. And even before this change, if you put a function argument first, it might type check but you wouldn't be able to use type-dispatch features (like dot method resolution). This just forces us to be more consistent. - No more defaults. I got rid of these because they require non-local
inference. But I think they were confusing anyway for exactly that reason.
Now you have to be explicit, writing
n = 10 :: Natorn : Nat = 10(we should standardize on one or the other) instead ofn = 10. for i.now usually requries an annotatedi. But I think it ends up being more readable. And for the very common case where you're just usingito index into a single table, it's better to useeachanyway.
Other things are actually bad
Nothing. Sometimes we now have to writeNothing :: Maybe Nat. (We should be able to write it asNothing(a=Nat)but that doesn't work yet.)0 + xwill fail now. You can writex + 0just fine, because the type of0is obtained from the type ofxbut if you want to write it in the other order you have to write(0::Nat) + xor something. It's frustrating because+is such an obviously symmetric operator. There's a similar thing withcase, where the order of the cases influences whether inference succeeds or fails (it wasn't perfect before either - the order could still influence whether dot-notation would work).
I'm not sure how to fix these. "Backwards" type inference is just really useful
in handling polymorphic constants like 0 and Nothing. (In my opinion this is
the only place it's useful.) I'm tempted to just say that we should get in the
habit of annotating these constants or supplying explicit type arguments. Maybe
Nothing should take its type argument explicitly so by default so you write
Nothing(Nat) or Nothing(_) if you're sure you're in top-down checking mode.
Then you can at least avoid the redundant Maybe in Nothing :: Maybe Nat.
URP? (No.) Gap sculpture. Point light.
- Quite a bit of stuff in this one including an attempt to move to the URP pipeline and then backing away because it seemed worse or at the very least seemed as bad as the default. Codrin recommended it briefly and I believe it's cool, but I suspect I've sunk enough effort into the default engine that unless URP had been just amazing by default I don't think I want to go back to square one. I can try again later if I want to again. I did a big ol' discard changes to get rid of it successfully.
- I moved the current iteration of the exhibiting room onto an actual space on the island, put in a point light, and a cube, and had it cast a shadow into the corner, which creates quite a nice form in the interaction between the shadow and the corner's structure. In doing it I realized I think I do want a "physical" representative of the light, so I put the light inside a small luminous sphere (to symbolize point lighting) and I do think that helps make the scene more legible.
- Also made a series of poles with their spacing reducing by half each time to see when the shadows no longer render - though it's very (utterly) related to the angle of the sun and I suppose I now realize I should make sure they have the perfect perpendicular angle. The point being yeah when is it all shadow and no light? I had been thinking about making a version of that with holes in the wall of the room
- I think the performance took a hit from the point light? That classic thing where it stutters because you even look near to where a point light is? I will put triggers to switch the light on and off for that reason - should help as there are more lights. Only one would be on at any given time.
Removes debug species from magic mirror (#78541)
Tallboys strike again Fixes #78538 Removes "Tall Boys" from the magic mirror, again. Also gives the two fucked up monkey species names and removes them from the magic mirror. When the magic mirror was looping through available species it was finding these monkey subtypes with fucked up limbs, noting that they were not forbidden, then adding them to the assoc list. Because all of them were called "monkey" it would overwrite "monkey" with "monkey who has human arms and torso" which is... not what you wanted to turn into.
Additionally I made external organ feature name fall back to the species default if not provided because I kept getting a runtime on monkey tail insertion (nobody has a monkey tail feature in their prefs or DNA) which I originally thought was the cause of this bug, until I fixed it and learned that actually it was something much stupider.
Add files via upload
Features:
- Project Showcase: Browse through a curated selection of my web development projects, complete with descriptions and live demos.
- About Me: Learn more about me, my background, and my skills as a web developer.
- Contact: Get in touch with me through various contact methods provided on the portfolio.
- Responsive Design: This portfolio is built using React.js and is designed to be responsive, ensuring a seamless experience across different devices and screen sizes.
- React.js
- HTML/CSS -JQuery
- JavaScript Getting Started:
To run this portfolio project locally, follow these steps:
- Clone this repository to your local machine.
- Install the necessary dependencies using
npm installoryarn install. - Start the development server with
npm startoryarn start. - Open your web browser and navigate to
http://localhost:3000to view the portfolio.
Contributing I welcome contributions, bug reports, and feature requests. If you'd like to contribute to this project, please follow the contributing guidelines. License: This project is open-source and available under the MIT License. Acknowledgments I'd like to thank [List any individuals or resources you want to acknowledge] for their inspiration and support during the development of this portfolio. Feel free to explore, provide feedback, and reach out to me if you have any questions or suggestions. Thank you for visiting my React.js Portfolio!
Juiced the IndexNavbar and made the home extention cooler. IF you don't like this commit message go fuck yourself
Polymorphic Inverter tweaks (#77675)
Fixes #77649
You can no longer use the belt to turn into any kind of carbon mob, sorry gamers it was a cool dream but it leads to too many problems. Also I made space dragon "there's an alive guy in my stomach" code now work on signals instead of on Life tick which is slightly more efficient and also resolves an issue with the funny belt.
Too much room for weird edge cases as a result of doing this (messing with monkey DNA, producing infinite xeno organs, blocking legit xeno queens from being created) which had no graceful solution. Moving stuff off Life if it can be event based is nice.
🆑 fix: Turning into a space dragon with the polymorphic inverter will no longer leave you existing in two places balance: You can no longer use the belt to transform into monkeys or xenomorphs, for technical reasons. /🆑
Settler Quirk: Tame the Outdoors! Have trouble with tall shelves... (#77654)
Adds the Settler quirk. This gives you bonuses to taming animals and fishing, as well as making you gain hunger slower than others.
However, you are quite a bit slower than most people, and have trouble with vaulting objects. You do, however, suffer significantly less from equipment slowdown. (to the point that it is almost zero)
Settler riders are faster on their mounts than others if they're at least sane. They start to slow down if they're less sane.
You are also shorter than most people.
Typical Settler encounters the typical Spacer
I wanted to add a lightweight quirk that was kind of the 'opposite' of Spacer, but a little more focused on interacting with elements of the game world that would enjoy some attention. So, I thought 'what about an outdoorsman quirk?'
So, I based it around being from people who lived out on the rim, under unideal circumstances (and probably heavier gravity than Earth), and taming the land. The slower movespeed encourages finding an animal to tame that you can ride, and the bonuses to taming should help make that a bit easier. The other additions just made sense for someone living it a bit rough in the wilderness.
Having a bunch of settlers taming cows and riding around on them all shift just kind of sounds hilarious to me.
🆑 add: Settler quirk! Conqueror the great outdoors....in space. Just make sure nobody asks you to get anything from the top shelf. /🆑
Co-authored-by: san7890 [email protected] Co-authored-by: Ghom [email protected]
xfs: logging the on disk inode LSN can make it go backwards
commit 32baa63d82ee3f5ab3bd51bae6bf7d1c15aed8c7 upstream.
When we log an inode, we format the "log inode" core and set an LSN in that inode core. We do that via xfs_inode_item_format_core(), which calls:
xfs_inode_to_log_dinode(ip, dic, ip->i_itemp->ili_item.li_lsn);
to format the log inode. It writes the LSN from the inode item into the log inode, and if recovery decides the inode item needs to be replayed, it recovers the log inode LSN field and writes it into the on disk inode LSN field.
Now this might seem like a reasonable thing to do, but it is wrong on multiple levels. Firstly, if the item is not yet in the AIL, item->li_lsn is zero. i.e. the first time the inode it is logged and formatted, the LSN we write into the log inode will be zero. If we only log it once, recovery will run and can write this zero LSN into the inode.
This means that the next time the inode is logged and log recovery runs, it will always replay changes to the inode regardless of whether the inode is newer on disk than the version in the log and that violates the entire purpose of recording the LSN in the inode at writeback time (i.e. to stop it going backwards in time on disk during recovery).
Secondly, if we commit the CIL to the journal so the inode item moves to the AIL, and then relog the inode, the LSN that gets stamped into the log inode will be the LSN of the inode's current location in the AIL, not it's age on disk. And it's not the LSN that will be associated with the current change. That means when log recovery replays this inode item, the LSN that ends up on disk is the LSN for the previous changes in the log, not the current changes being replayed. IOWs, after recovery the LSN on disk is not in sync with the LSN of the modifications that were replayed into the inode. This, again, violates the recovery ordering semantics that on-disk writeback LSNs provide.
Hence the inode LSN in the log dinode is -always- invalid.
Thirdly, recovery actually has the LSN of the log transaction it is replaying right at hand - it uses it to determine if it should replay the inode by comparing it to the on-disk inode's LSN. But it doesn't use that LSN to stamp the LSN into the inode which will be written back when the transaction is fully replayed. It uses the one in the log dinode, which we know is always going to be incorrect.
Looking back at the change history, the inode logging was broken by commit 93f958f9c41f ("xfs: cull unnecessary icdinode fields") way back in 2016 by a stupid idiot who thought he knew how this code worked. i.e. me. That commit replaced an in memory di_lsn field that was updated only at inode writeback time from the inode item.li_lsn value - and hence always contained the same LSN that appeared in the on-disk inode - with a read of the inode item LSN at inode format time. CLearly these are not the same thing.
Before 93f958f9c41f, the log recovery behaviour was irrelevant, because the LSN in the log inode always matched the on-disk LSN at the time the inode was logged, hence recovery of the transaction would never make the on-disk LSN in the inode go backwards or get out of sync.
A symptom of the problem is this, caught from a failure of generic/482. Before log recovery, the inode has been allocated but never used:
xfs_db> inode 393388 xfs_db> p core.magic = 0x494e core.mode = 0 .... v3.crc = 0x99126961 (correct) v3.change_count = 0 v3.lsn = 0 v3.flags2 = 0 v3.cowextsize = 0 v3.crtime.sec = Thu Jan 1 10:00:00 1970 v3.crtime.nsec = 0
After log recovery:
xfs_db> p core.magic = 0x494e core.mode = 020444 .... v3.crc = 0x23e68f23 (correct) v3.change_count = 2 v3.lsn = 0 v3.flags2 = 0 v3.cowextsize = 0 v3.crtime.sec = Thu Jul 22 17:03:03 2021 v3.crtime.nsec = 751000000 ...
You can see that the LSN of the on-disk inode is 0, even though it clearly has been written to disk. I point out this inode, because the generic/482 failure occurred because several adjacent inodes in this specific inode cluster were not replayed correctly and still appeared to be zero on disk when all the other metadata (inobt, finobt, directories, etc) indicated they should be allocated and written back.
The fix for this is two-fold. The first is that we need to either revert the LSN changes in 93f958f9c41f or stop logging the inode LSN altogether. If we do the former, log recovery does not need to change but we add 8 bytes of memory per inode to store what is largely a write-only inode field. If we do the latter, log recovery needs to stamp the on-disk inode in the same manner that inode writeback does.
I prefer the latter, because we shouldn't really be trying to log and replay changes to the on disk LSN as the on-disk value is the canonical source of the on-disk version of the inode. It also matches the way we recover buffer items - we create a buf_log_item that carries the current recovery transaction LSN that gets stamped into the buffer by the write verifier when it gets written back when the transaction is fully recovered.
However, this might break log recovery on older kernels even more, so I'm going to simply ignore the logged value in recovery and stamp the on-disk inode with the LSN of the transaction being recovered that will trigger writeback on transaction recovery completion. This will ensure that the on-disk inode LSN always reflects the LSN of the last change that was written to disk, regardless of whether it comes from log recovery or runtime writeback.
Fixes: 93f958f9c41f ("xfs: cull unnecessary icdinode fields") Signed-off-by: Dave Chinner [email protected] Reviewed-by: Darrick J. Wong [email protected] Signed-off-by: Darrick J. Wong [email protected] Signed-off-by: Amir Goldstein [email protected] Acked-by: Darrick J. Wong [email protected] Signed-off-by: Greg Kroah-Hartman [email protected]
Add Postpone API (#27238)
This adds an experimental unstable_postpone(reason) API.
Currently we don't have a way to model effectively an Infinite Promise. I.e. something that suspends but never resolves. The reason this is useful is because you might have something else that unblocks it later. E.g. by updating in place later, or by client rendering.
On the client this works to model as an Infinite Promise (in fact, that's what this implementation does). However, in Fizz and Flight that doesn't work because the stream needs to end at some point. We don't have any way of knowing that we're suspended on infinite promises. It's not enough to tag the promises because you could await those and thus creating new promises. The only way we really have to signal this through a series of indirections like async functions, is by throwing. It's not 100% safe because these values can be caught but it's the best we can do.
Effectively postpone(reason) behaves like a built-in Catch
Boundary. It's like
raise(Postpone, reason) except it's built-in so it needs to be able to
be encoded and caught by Suspense boundaries.
In Flight and Fizz these behave pretty much the same as errors. Flight just forwards it to retrigger on the client. In Fizz they just trigger client rendering which itself might just postpone again or fill in the value. The difference is how they get logged.
In Flight and Fizz they log to onPostpone(reason) instead of
onError(error). This log is meant to help find deopts on the server
like finding places where you fall back to client rendering. The reason
that you pass in is for that purpose to help the reason for any deopts.
I do track the stack trace in DEV but I don't currently expose it to
onPostpone. This seems like a limitation. It might be better to expose
the Postpone object which is an Error object but that's more of an
implementation detail. I could also pass it as a second argument.
On the client after hydration they don't get passed to
onRecoverableError. There's no global onPostpone API to capture
postponed things on the client just like there's no onError. At that
point it's just assumed to be intentional. It doesn't have any digest
or reason passed to the client since it's not logged.
There are some hacky solutions that currently just tries to reuse as much of the existing code as possible but should be more properly implemented.
- Fiber is currently just converting it to a fake Promise object so that it behaves like an infinite Promise.
- Fizz is encoding the magic digest string
"POSTPONE"in the HTML so we know to ignore it but it should probably just be something neater that doesn't share namespace with digests.
Next I plan on using this in the /static entry points for additional
features.
Why "postpone"? It's basically a synonym to "defer" but we plan on using "defer" for other purposes and it's overloaded anyway.
add try_insert to entity commands (#9844)
-
I spoke with some users in the ECS channel of bevy discord today and they suggested that I implement a fallible form of .insert for components.
-
In my opinion, it would be nice to have a fallible .insert like .try_insert (or to just make insert be fallible!) because it was causing a lot of panics in my game. In my game, I am spawning terrain chunks and despawning them in the Update loop. However, this was causing bevy_xpbd to panic because it was trying to .insert some physics components on my chunks and a race condition meant that its check to see if the entity exists would pass but then the next execution step it would not exist and would do an .insert and then panic. This means that there is no way to avoid a panic with conditionals.
Luckily, bevy_xpbd does not care about inserting these components if the entity is being deleted and so if there were a .try_insert, like this PR provides it could use that instead in order to NOT panic.
( My interim solution for my own game has been to run the entity despawn events in the Last schedule but really this is just a hack and I should not be expected to manage the scheduling of despawns like this - it should just be easy and simple. IF it just so happened that bevy_xpbd ran .inserts in the Last schedule also, this would be an untenable soln overall )
- Describe the solution used to achieve the objective above.
Add a new command named TryInsert (entitycommands.try_insert) which functions exactly like .insert except if the entity does not exist it will not panic. Instead, it will log to info. This way, crates that are attaching components in ways which they do not mind that the entity no longer exists can just use try_insert instead of insert.
In my opinion, NOT panicing should really be the default and having an .insert that does panic should be the odd edgecase but removing the panic! from .insert seems a bit above my paygrade -- although i would love to see it. My other thought is it would be good for .insert to return an Option AND not panic but it seems it uses an event bus right now so that seems to be impossible w the current architecture.
Several common 'household' reagents can be used as improvised medicine treatment. Updated first aid analyzer information. (#77746)
Several common 'household' reagents can be used as improvised medicine treatment.
Drinking tea will help mend (non-bone) wounds over time.
Flour and corn starch may be splashed onto wounds to help dry them up, though they'll have a negative effect on burn wounds.
Added a new reagent, saltwater, made by combining table salt with water.
Table salt and saltwater can be splashed onto wounds as well, reducing bleeding and improving sanitization and disinfection significantly. However, the coarse undiluted salt will irritate the wounds, reducing clot rate and flesh healing, and both of the reagents will increase a burn wound's infestation rate.
Altered Table Salt's recipe to just need sodium and chloride. Changed the recipe of Pentetic Acid and Heparin to need table salt (sodium x chloride) and thus slightly altered the total output of those reagents (pentacid went from 5u per reaction to 4u, heparin 4u->3u)
Saline-Glucose Solution now needs 2u of saltwater and 1u of sugar, meaning the overall recipe should be completely unchanged in practice. Contact me on discord if any issues arise from these chemical changes!
First aid analyzers now give easy-to-understand direct information, with the specific recommended treatments bolded in the analysis text. They also have a 'unique' extra bit of info, telling you about improvised ways to remedy your wound.
Wounds have a very poor amount of interaction with the rest of the game and have not had much added to them post-merge, especially in 'improvised' ways to help Not Die to a wound while you crawl your way to a emergency medkit or medbay. I researched info on this and found some interesting ideas - some of them I'll have to leave for later because this PR kept growing out of scope (Improvised bone gel, ice on wounds which turned into wound temperature mechanics, crutches, a 'suture item' component refactor...)
As for what this actually does to benefit the game, it allows more dynamic wound Gameplay as people use first aid analyzers to get information on treatment when medbay blows up, helps them stabilize by splashing flour onto themselves before looking for some actual treatment, helps traitors realize how they can self-treat many crippling wounds (at risk, of course). It expands treatment options to things beside medkits and medbay, but always does so in ways that have downsides that make them not ideal as treatment, and more beneficial as stabilizing before seeking true professional help. This thus significantly increases the rather shallow depth of wounds as a system to interact with.
Several common 'household' reagents can be used as improvised medicine treatment.
From what I could tell by looking at several sources for each 'realistic' treatment, these are indeed semi-reasonable things that are done to wounds by some people as household treatment.
It goes without saying that you should not do any of these things in real life without consulting a doctor unless your blood is also spilling out by the gallon into the floor. All these 'realistic treatments' have drastic downsides and are meant for the short-term only. Except the tea.
Drinking tea will help mend (non-bone) wounds over time.
Tea is healthy, we all know that.
Flour and corn starch may be splashed onto wounds to help dry them up, though they'll have a negative effect on burn wounds.
Flour and apparently starch dries wounds up but risks infection. That's not a thing for blood wounds yet but oh well.
Table salt and saltwater can be splashed onto wounds as well, reducing bleeding and improving sanitization and disinfection significantly. However, the coarse undiluted salt will irritate the wounds, reducing clot rate and flesh healing, and both of the reagents will increase a burn wound's infestation rate.
Salt kills bacteria via osmosis, but it also kills your own cells, and some bacteria like salt.
Added a new reagent, saltwater, made by combining table salt with water.
Altered Table Salt's recipe to just need sodium and chloride. Changed the recipe of Pentetic Acid and Heparin to need table salt (sodium x chloride) and thus slightly altered the total output of those reagents (pentacid went from 5u per reaction to 4u, heparin 4u->3u)
Saline-Glucose Solution now needs 2u of saltwater and 1u of sugar, meaning the overall recipe should be completely unchanged in practice. Contact me on discord if any issues arise from these chemical changes!
I wish I hadn't had to mess with reagents like this, but I needed to because just adding mixing salt and water caused the saline glucose recipe to basically split itself into half saltwater half glucose.
I removed the water requirement for table salt (Why did it even have that, salt ain't wet bro?), made saline-glucose need 2u saltwater and 1u sugar, and altered relevant recipes so they didn't also cause unwanted table salt to react from their sodium and chloride ingredients.
A happy side-effect is that saline glucose solution is even easier to make now as an improvised chem by mixing salt, water, and sugar, which fits pretty perfectly (especially as a temporary blood substitute)
First aid analyzers now give easy-to-understand direct information, with the specific recommended treatments bolded in the analysis text. They also have a 'unique' extra bit of info, telling you about improvised ways to remedy your wound.
You might notice that as the wounds get more serious the text gets more direct and concise and reluctantly hands out more and more improvised treatment options, so that's fun. As for the improvised section itself, it helps people be actually aware of these ways to help treat themselves rather than delegating it to hyper-gamer knowledge.
The bolded treatment bit is pretty neat and means your eyes can inmediately focus on what you can do to save yourself - very useful if you have a weeping avulsion and no bandages.
🆑 add: Several common 'household' reagents can be used as improvised medicine treatment. add: Drinking tea will help mend (non-bone) wounds over time. add: Flour and corn starch may be splashed onto wounds to help dry them up, though they'll have a negative effect on burn wounds. add: Added a new reagent, saltwater, made by combining table salt with water. add: Table salt and saltwater can be splashed onto wounds as well, reducing bleeding and improving sanitization and disinfection significantly. However, the coarse undiluted salt will irritate the wounds, reducing clot rate and flesh healing, and both of the reagents will increase a burn wound's infestation rate. add: Altered Table Salt's recipe to just need sodium and chloride. Changed the recipe of Pentetic Acid and Heparin to need table salt (sodium x chloride) and thus slightly altered the total output of those reagents (pentacid went from 5u per reaction to 4u, heparin 4u->3u) add: Saline-Glucose Solution now needs 2u of saltwater and 1u of sugar, meaning the overall recipe should be completely unchanged in practice. Contact me on discord if any issues arise from these chemical changes! qol: First aid analyzers now give easy-to-understand direct information, with the specific recommended treatments bolded in the analysis text. They also have a 'unique' extra bit of info, telling you about improvised ways to remedy your wound. /🆑
Co-authored-by: san7890 [email protected] Co-authored-by: MrMelbert [email protected]
Merge branch 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull openat2 support from Al Viro: "This is the openat2() series from Aleksa Sarai.
I'm afraid that the rest of namei stuff will have to wait - it got zero review the last time I'd posted #work.namei, and there had been a leak in the posted series I'd caught only last weekend. I was going to repost it on Monday, but the window opened and the odds of getting any review during that... Oh, well.
Anyway, openat2 part should be ready; that did get sane amount of review and public testing, so here it comes"
From Aleksa's description of the series: "For a very long time, extending openat(2) with new features has been incredibly frustrating. This stems from the fact that openat(2) is possibly the most famous counter-example to the mantra "don't silently accept garbage from userspace" -- it doesn't check whether unknown flags are present[1].
This means that (generally) the addition of new flags to openat(2) has been fraught with backwards-compatibility issues (O_TMPFILE has to be defined as __O_TMPFILE|O_DIRECTORY|[O_RDWR or O_WRONLY] to ensure old kernels gave errors, since it's insecure to silently ignore the flag[2]). All new security-related flags therefore have a tough road to being added to openat(2).
Furthermore, the need for some sort of control over VFS's path resolution (to avoid malicious paths resulting in inadvertent breakouts) has been a very long-standing desire of many userspace applications.
This patchset is a revival of Al Viro's old AT_NO_JUMPS[3] patchset (which was a variant of David Drysdale's O_BENEATH patchset[4] which was a spin-off of the Capsicum project[5]) with a few additions and changes made based on the previous discussion within [6] as well as others I felt were useful.
In line with the conclusions of the original discussion of AT_NO_JUMPS, the flag has been split up into separate flags. However, instead of being an openat(2) flag it is provided through a new syscall openat2(2) which provides several other improvements to the openat(2) interface (see the patch description for more details). The following new LOOKUP_* flags are added:
LOOKUP_NO_XDEV:
Blocks all mountpoint crossings (upwards, downwards, or through
absolute links). Absolute pathnames alone in openat(2) do not
trigger this. Magic-link traversal which implies a vfsmount jump is
also blocked (though magic-link jumps on the same vfsmount are
permitted).
LOOKUP_NO_MAGICLINKS:
Blocks resolution through /proc/$pid/fd-style links. This is done
by blocking the usage of nd_jump_link() during resolution in a
filesystem. The term "magic-links" is used to match with the only
reference to these links in Documentation/, but I'm happy to change
the name.
It should be noted that this is different to the scope of
~LOOKUP_FOLLOW in that it applies to all path components. However,
you can do openat2(NO_FOLLOW|NO_MAGICLINKS) on a magic-link and it
will *not* fail (assuming that no parent component was a
magic-link), and you will have an fd for the magic-link.
In order to correctly detect magic-links, the introduction of a new
LOOKUP_MAGICLINK_JUMPED state flag was required.
LOOKUP_BENEATH:
Disallows escapes to outside the starting dirfd's
tree, using techniques such as ".." or absolute links. Absolute
paths in openat(2) are also disallowed.
Conceptually this flag is to ensure you "stay below" a certain
point in the filesystem tree -- but this requires some additional
to protect against various races that would allow escape using
"..".
Currently LOOKUP_BENEATH implies LOOKUP_NO_MAGICLINKS, because it
can trivially beam you around the filesystem (breaking the
protection). In future, there might be similar safety checks done
as in LOOKUP_IN_ROOT, but that requires more discussion.
In addition, two new flags are added that expand on the above ideas:
LOOKUP_NO_SYMLINKS:
Does what it says on the tin. No symlink resolution is allowed at
all, including magic-links. Just as with LOOKUP_NO_MAGICLINKS this
can still be used with NOFOLLOW to open an fd for the symlink as
long as no parent path had a symlink component.
LOOKUP_IN_ROOT:
This is an extension of LOOKUP_BENEATH that, rather than blocking
attempts to move past the root, forces all such movements to be
scoped to the starting point. This provides chroot(2)-like
protection but without the cost of a chroot(2) for each filesystem
operation, as well as being safe against race attacks that
chroot(2) is not.
If a race is detected (as with LOOKUP_BENEATH) then an error is
generated, and similar to LOOKUP_BENEATH it is not permitted to
cross magic-links with LOOKUP_IN_ROOT.
The primary need for this is from container runtimes, which
currently need to do symlink scoping in userspace[7] when opening
paths in a potentially malicious container.
There is a long list of CVEs that could have bene mitigated by
having RESOLVE_THIS_ROOT (such as CVE-2017-1002101,
CVE-2017-1002102, CVE-2018-15664, and CVE-2019-5736, just to name a
few).
In order to make all of the above more usable, I'm working on libpathrs[8] which is a C-friendly library for safe path resolution. It features a userspace-emulated backend if the kernel doesn't support openat2(2). Hopefully we can get userspace to switch to using it, and thus get openat2(2) support for free once it's ready.
Future work would include implementing things like RESOLVE_NO_AUTOMOUNT and possibly a RESOLVE_NO_REMOTE (to allow programs to be sure they don't hit DoSes though stale NFS handles)"
- 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Documentation: path-lookup: include new LOOKUP flags selftests: add openat2(2) selftests open: introduce openat2(2) syscall namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution namei: LOOKUP_IN_ROOT: chroot-like scoped resolution namei: LOOKUP_BENEATH: O_BENEATH-like scoped resolution namei: LOOKUP_NO_XDEV: block mountpoint crossing namei: LOOKUP_NO_MAGICLINKS: block magic-link resolution namei: LOOKUP_NO_SYMLINKS: block symlink resolution namei: allow set_root() to produce errors namei: allow nd_jump_link() to produce errors nsfs: clean-up ns_get_path() signature to return int namei: only return -ECHILD from follow_dotdot_rcu()
Merge branch 'flutterflow' of https://github.com/Aiden2244/vusic into flutterflow because fuck you that's why
gdb/testsuite: add test for core file with a 0 pid
This patch contains a test for this commit:
commit c820c52a914cc9d7c63cb41ad396f4ddffff2196 Date: Fri Aug 6 19:45:58 2010 +0000
* thread.c (add_thread_silent): Use null_ptid instead of
minus_one_ptid while getting rid of stale inferior_ptid.
This is another test that has been carried in the Fedora GDB tree for some time, and I thought that it would be worth merging to master. I don't believe there is any test like this currently in the testsuite.
The original issue was reported in this thread:
https://inbox.sourceware.org/gdb-patches/[email protected]/
The problem was that when GDB was used to open a vmcore (core file) image generated by the Linux kernel GDB would (sometimes) crash with an assertion failure:
thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
To understand what's going on we need some background; a vmcore file represents each processor core in the same way that a standard application core file represents threads. Thus, we might say, a vmcore file represents cores as threads.
When writing a vmcore file, the kernel will store the pid of the process currently running on that core as the thread's lwpid.
However, if a core is idle, with no process currently running on it, then the lwpid for that thread is stored as 0 in the vmcore file. If multiple cores are idle then multiple threads will have a lwpid of 0.
Back in 2010, the original issue reported tried to change the kernel's behaviour in this thread:
https://lkml.org/lkml/2010/8/3/75
This change was rejected by the kernel team, the current behaviour (lwpid of 0) was considered correct. I've checked the source of a recent kernel. The code mentioned in the lkml.org posting has moved, it's now in the function crash_save_cpu in the file kernel/kexec_core.c, but the general behaviour is unchanged, an idle core will have an lwpid of 0, so I think GDB still needs to be able to handle this case.
When GDB loads a vmcore file (which is handled just like any other core file) the sections are processed in core_open to generate the threads for the core file. The processing is done by calling add_to_thread_list, a function which looks for sections named .reg/NN where NN is the lwpid of the thread, GDB then builds a ptid_t for the new thread and calls add_thread.
Remember, in our case the lwpid is 0. Now for the first thread this is fine, if a little weird, 0 isn't usually a valid lwpid, but that's OK, GDB creates a thread with lwpid of 0 and carries on.
When we find the next thread (core) with lwpid of 0, we attempt to create another thread with an lwpid of 0. This of course clashes with the previously created thread, they have the same ptid_t, so GDB tries to delete the first thread.
And it was within this thread delete code that we triggered a bug which would then cause GDB to assert -- when deleting we tried to switch to a thread with minus_one_ptid, this resulted in a call to find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the find_inferior_pid call fails and returns NULL, which then triggered an assert in switch_to_thread.
The actual details of the why the assert triggered are really not important. What's important (I think) is that a vmcore file might have this interesting lwpid of 0 characteristic, which isn't something we see in "normal" application core files, and it is this that I think we should be testing.
Now, you might be thinking: isn't deleting the first thread the wrong thing to do? If the vmcore file has two threads that represent two cores, and both have an lwpid of 0 (indicating both cores are idle), then surely GDB should still represent this as two threads? You're not wrong. This was mentioned by Pedro in the original GDB mailing list thread here:
https://inbox.sourceware.org/gdb-patches/[email protected]/
This is indeed a problem, and this problem is still present in GDB today. I plan to try and address this in a later commit, however, this first commit is about getting a test in place to confirm that GDB at a minimum doesn't crash when loading such a vmcore file.
And so, finally, what's in this commit?
This commit contains a new test. The test doesn't actually contain a vmcore file. Instead I've created a standard application core file that contains two threads, and then manually edited the core file to set the lwpid of each thread to 0.
To further reduce the size of the core file (as it will be stored in git), I've zeroed all of the LOAD-able segments in the core file. This test really doesn't care about that part of the core file, we only really care about loading the register's, this is enough to confirm that the GDB doesn't crash.
Obviously as the core file is pre-generated, this test is architecture specific. There are already a few tests in gdb.arch/ that include pre-generate core files. Just as those existing tests do, I've compressed the core file with bzip2, which reduces it to just 750 bytes. I have structured the test so that if/when this patch is merged I can add some additional core files for other architectures, however, these are not included in this commit.
The test simply expands the core file, and then loads it into GDB. One interesting thing to note is that GDB reports the core file loading like this:
(gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core [New process 1] [New process 1] Failed to read a valid object file image from memory. Core was generated by `./segv-mt'. Program terminated with signal SIGSEGV, Segmentation fault. The current thread has terminated (gdb)
There's two interesting things here: first, the repeated "New process 1" message. This is caused because linux_core_pid_to_str reports anything with an lwpid of 0 as a process, rather than an LWP. And second, the "The current thread has terminated" message. This is because the first thread in the core file is the current thread, but when GDB loads the second thread (which also has lwpid 0) this causes the first thread to be deleted, as a result GDB thinks that the current (first) thread has terminated.
As I said previously, both of these problems are a result of the lwpid 0 aliasing, which is not being fixed in this commit -- this commit is just confirming that GDB doesn't crash when loading this core file.
Reviewed-By: Kevin Buettner [email protected]
Armor improvements (#1251)
-
the fixes
-
FUCK YOU
-
few more improvements
-
bring em back
-
fuck you
BSP 5.0
Changes in v5.0 - Colin Phipps, 8/2000:
Based on BSP v3.0, this version brings together a number of enhancements to BSP that have been floating around by various people.
There is no significant difference, in terms of the nodes produced, between this version and BSP v3.0. In fact on my computer (FreeBSD 4.1-STABLE, PII), the output is byte-for-byte identical with BSP v3.0. This is not true for the binary DOS and Win32 versions I'm distributing though, because they are linked against a different math library, but they are still effectively identical to BSP v3.0 I believe.
So what changes are there you ask? Well...
- better UNIX support, from Udo Monk and Andre Majorel
- big endian support, from Oliver Kraus
- from myself:
- major clean-up of the source code, splitting some stuff out into separate files so there is less mixing of unrelated code.
- vastly more memory-efficient when working on large multi-level WADs
- more flexibility about input and output
- can read from and write to pipes on UNIX systems
- output file can be the same as the input file
- Win32 version
2000/08/27
Fixed up a large number of memory leaks. Basically BSP was designed to do one level only, and the multi-level support was an afterthought. It did multiple levels, but memory-wise it assumed it needn't bother to free one level's stuff before moving on the the next. Since it's easy to fix, I fixed it. It's now practical to use it for multi-level PWADs. Builds doom.wad in < 1.5megs now (as compared to 15megs before).
Added big endian support. Imported the extra code from the xwadtools version. I rely on autoconf to detect if the machine is big endian. No adverse affects on x86 - I also verified that it compiles if WORDS_BIGENDIAN is defined. Can't do a real test myself though.
2000/08/26
Support for pipes and stuff was today's business. Added the isatty() test from the yadex version of BSP that supresses the spinning progress thingy when stdout is redirected.
Added support for input being from a pipe. I'm writing for UNIX damnit, so it ought to be usable like other UNIX programs! :-)
For input pipes, it just reads to a temp file, then reads back from the temp file. For output I was less sure what to do: there are 3 senarios:
- output to a file that either doesn't exist, or can be overwritten in any case.
- output to a file which we only want overwritten once the build is complete and sucessful (e.g. writing the output back to the input filename)
- output to a pipe
For (3), we need to write to a temp file then copy to the pipe, because we have to be able to fseek(3) on the output file to write a Doom WAD. For (2), we need to write to a temp file then copy to the output when we're done.
In the end, I went for an easy compromise. If the output file already exists (includes the case of a pipe), then we write the WAD to a temporary file, then copy it to the real output file once we're done. That copes with (2) and (3) fine.
2000/08/25
Made a makefile to built the test wads. I copied the test WADs to another machine, and ran original DOS BSP 3.0 on them, then made a note of the MD5 sums of the resulting files. Using these I can check that my version is still producing identical results to the original v3.0.
2000/08/23
Checked in the BSP 3.0 source. Immediately ditched the existing makefiles and created GNU autoconf/automake ones - much less messy.
First major problem to overcome was the crude existing build system - all the .c files were #include'd into bsp.c, which was kinda ugly. And whoever wrote this had an obsession with labelling everything "static" even though there was only one source file. Fun.
Misc mapping fixes and QoL additions (#78176)
fix: #78135 fix: #78059
This PR remaps Birdshot's disposals room, makes several small fixes on Icebox and Metastation, adds cell timers to isolation cells where such cells are present (they don't open the door, effectively just an in-game timer) (in-cell flashes are now controlled with the timer, where applicable); and adds translator glove modules to the stacks of "accessibility" modules found in most security, medical, and engineering storage rooms. (adds these stacks in their entirety to Northstar).
Specific changes are as follows: Birdshot
- Adds a roll of package paper to the cargo office
- Translator module [med,sec]
- Accessibility modules [eng]
- Recycler remap
Delta
- Translator module [med,sec,eng]
- Isolation cell timer
Icebox
- Translator module [med,sec,eng]
- Remove duplicate hand labeler on the rack near brig cells
- Adds a hand labeler to armory desk in gear room
- Isolation cell timer
Meta
- Translator module [med,sec,eng]
- Isolation cell timer
- Mends a broken corpse disposal pipe from aux surgery to the morgue
Northstar
- Accessibility modules [med,sec,eng]
- Nudges the binoculars off of the mass driver controls in ordnance
- Fixes the SM starting out hotwired (Rewires the SM room)
Tram
- Translator module [med,sec,eng]
- Isolation cell timers
Bug fixes with respect to Birdshot's recycler, Meta's corpse disposal, Northstar starting out hotwired, and Icebox's duplicated hand labeler.
Nudging Northstar's ordnance binoculars should make it a bit easier to find the mass driver controls.
Adding some packaging paper to Birdshot to make the techs' lives a little easier with a little less round-start fuss.
Adding a hand labeler to Icebox's gear room brings it in line with other maps in terms of rounds-start gear and locker labeling potential.
For players with characters running the Mute/Signer quirks, stock MODsuits are a pain to use. Suit gauntlets will replace their translator gloves. Unless they're able to get a suit put together ahead of time, they'll be stuck doing the retract gauntlets > send radio message > Extend Gauntlets shuffle. Adding a translator glove module to the stack of similar items (plasma fixation module / therma regulator) should alleviate that issue some.
Getting abandoned in an isolation cell sucks, and setting timers on your phone or some such is a hassle. Adding cell timers to isolation cells should go some way to alleviating those frustrations.
Screenshots/Videos
Disposal Room Remap
Cargo Packing Paper
Engineering Accessibility Modules
Medbay Translator
Security Translator
Engineering Translator
Medbay Translator
Security Translator
Isolation Cell Timer
Engineering Translator
Medbay Translator
Security Translator
Isolation Cell Timer
Gear Room Hand Labeler
Engineering Translator
Medbay Translator
Security Translator
Isolation Cell Timer
Engineering Accessibility Modules
Medbay Accessibility Modules
Security Accessibility Modules
Supermatter Rewiring
Ordnance Binoculars
Engineering Translator
Medbay Translator
Security Translator
Isolation Cell Timer
🆑 qol: [Deltastation, Icebox, Metastation, Tramstation] Adds cell timers to isolation cells. (they do not auto-open the doors) qol: [Birdshot, Deltastation, Icebox, Metastation, Northstar, Tramstation] Adds translator glove modules to the stacks of "accessibility" (e.g. plasma fixation / thermal regulator) modules found in security, medical, and engineering storage rooms. qol: [Birdshot] Adds a roll of packaging paper to the cargo office. qol: [Icebox] Adds a hand labeler to security's gear room. qol: [Northstar] Nudges the set of binoculars covering the mass driver controls in ordnance over a few inches. fix: [Birdshot] Remaps the janitor's closet such that the recycling machine will now work. fix: [Icebox] Removes a duplicated hand labeler from the rack near security's brig cells. fix: [Metastation] Patches a broken corpse disposal pipe running from aux surgery to the morgue. fix: [Northstar] Fixes the SM being hotwired at round-start (partially rewires the SM room, moves the APC to the North wall). /🆑