there were a lot of events recorded by gharchive.org of which 2,231,694 were push events containing 3,398,171 commit messages that amount to 250,109,992 characters filtered with words.py@e23d022007... to these 51 messages:
funding.yml
Funding.yml if you want to support more of these projects please donate to my paypal anything helps i am a student and any donations will keep me and my 2 hounds fed and happy so i can have time to contribute more of my projects to the community god bless you all you beautiful people i hope you enjoy the work i do paypal.me/cosmicspiritsupport
New Ruin: Singularity Research Lab (#1612)
Adds the Singularity Research Lab, formerly a cutting edge science station, now overrun with kudzu, it is a space ruin.
The two areas of note are the singularity reactor, which is assembled, and would just need a hand if someone were to want to start it, and the research lab. The Research lab contains the fruits of the now deceased science staff's labors, assorted energy weapons. Unfortunately, it also contains the deceased science staff.
Other areas of the base were not so lucky, and are thoroughly infested
The engineering team attempted to hold back the vines, and quickly
discovered that fire was not sufficient.
And what used to be the recreation area is completely gone
Notably, the hangar is empty. I plan on making a patch to put a subshuttle inside it once that rolls around.
Notable loot includes: 3 energy SMGs 3 Flamethrowers The Ion Projector, a self charging Ion weapon. An Antique Laser 2 Energy PDWs 2 Accelerator Laser Cannons 4 engineering hardsuits An engineering lathe and circuit imprinter A particle accelerator A singularity generator 6 emitters 1 energy shotgun Kudzu Seeds Basically Everything You'd Need For an R&D Set Up A sense of pride and accomplishment
I feel like this has some rough spots but I've got no idea where to start, so into the review -> testing -> feedback process it goes
- The ruin spawns when the spawn ruin verb doesn't runtime.
More ruin variety. This one spawns in space and does a few things that I haven't seen yet. Mainly a singularity, cool semi-hidden asteroid base that could in theory, be turned into a player lair.
🆑 add: An abandoned Nanotrasen Asteroid Facility has been spotted in the area. Salvage teams are advised to steer clear, or at least bring a knife. add: kudzu zombie subtype. fix: vent iconstates. /🆑
Signed-off-by: Bjarl [email protected] Co-authored-by: spockye [email protected]
Financial Math (Evals) (#566)
🚨 Please make sure your PR follows these guidelines, failure to follow the guidelines below will result in the PR being closed automatically. Note that even if the criteria are met, that does not guarantee the PR will be merged nor GPT-4 access granted. 🚨
PLEASE READ THIS:
In order for a PR to be merged, it must fail on GPT-4. We are aware that right now, users do not have access, so you will not be able to tell if the eval fails or not. Please run your eval with GPT-3.5-Turbo, but keep in mind as we run the eval, if GPT-4 gets higher than 90% on the eval, we will likely reject since GPT-4 is already capable of completing the task.
We plan to roll out a way for users submitting evals to see the eval performance on GPT-4 soon. Stay tuned! Until then, you will not be able to see the eval performance on GPT-4. We encourage partial PR's with ~5-10 example that we can then run the evals on and share the results with you so you know how your eval does with GPT-4 before writing all 100 examples.
finance
Asks the model to calculate how much interest would be owed on a credit card by a certain date, if a payment was made once but debt remains on the card.
Finance is likely to be one of the biggest opportunities for LLMs to be useful, because financial education is incredibly poor globally and the impact of a mistake in financial calculations is severe. This eval tests the models ability to combine math with its understanding of a topic (finance). We plan to use this type of math at Dollarwise frequently going forward, including integration into your comparison products. However, for this to work reliably it's important that the model here can natively understand financial concepts and apply math to them.
Below are some of the criteria we look for in a good eval. In general, we are seeking cases where the model does not do a good job despite being capable of generating a good response (note that there are some things large language models cannot do, so those would not make good evals).
Your eval should be:
- Thematically consistent: The eval should be thematically consistent. We'd like to see a number of prompts all demonstrating some particular failure mode. For example, we can create an eval on cases where the model fails to reason about the physical world.
- Contains failures where a human can do the task, but either GPT-4 or GPT-3.5-Turbo could not.
- Includes good signal around what is the right behavior. This means
either a correct answer for
Basicevals or theFactModel-graded eval, or an exhaustive rubric for evaluating answers for theCriteriaModel-graded eval. - Include at least 100 high quality examples (it is okay to only contribute 5-10 meaningful examples and have us test them with GPT-4 before adding all 100)
If there is anything else that makes your eval worth including, please document it below.
Insert what makes your eval high quality that was not mentioned above. (Not required)
Your eval should
- Check that your data is in
evals/registry/data/{name} - Check that your yaml is registered at
evals/registry/evals/{name}.yaml - Ensure you have the right to use the data you submit via this eval
(For now, we will only be approving evals that use one of the existing eval classes. You may still write custom eval classes for your own cases, and we may consider merging them in the future.)
By contributing to Evals, you are agreeing to make your evaluation logic and data under the same MIT license as this repository. You must have adequate rights to upload any data used in an Eval. OpenAI reserves the right to use this data in future service improvements to our product. Contributions to OpenAI Evals will be subject to our usual Usage Policies (https://platform.openai.com/docs/usage-policies).
- I agree that my submission will be made available under an MIT license and complies with OpenAI's usage policies.
If your submission is accepted, we will be granting GPT-4 access to a limited number of contributors. Access will be given to the email address associated with the merged pull request.
- I acknowledge that GPT-4 access will only be granted, if applicable, to the email address used for my merged pull request.
We know that you might be excited to contribute to OpenAI's mission, help improve our models, and gain access to GPT-4. However, due to the requirements mentioned above and high volume of submissions, we will not be able to accept all submissions and thus not grant everyone who opens a PR GPT-4 access. We know this is disappointing, but we hope to set the right expectation before you open this PR.
- I understand that opening a PR, even if it meets the requirements above, does not guarantee the PR will be merged nor GPT-4 access granted.
- I have filled out all required fields in the evals PR form
- (Ignore if not submitting code) I have run
pip install pre-commit; pre-commit installand have verified thatblack,isort, andautoflakeare running when I commit and push
Failure to fill out all required fields will result in the PR being closed.
Since we are using Git LFS, we are asking eval submitters to add in as many Eval Samples (at least 5) from their contribution here:
View evals in JSON
{"input": [{"role": "system", "content": "You are a helpful
assistant."}, {"role": "user", "content": "On the 24th of September,
Sarah had spent $1237.42 on her credit card for the month of September.
This credit card charges 21.99% interest rate annually on outstanding
credit starting on the 1st of the following month. Presume that interest
is only charged at the end of each additional day. Example: From the 1st
of the month to the 8th would be 7 days of interest accrued.Today is the
27th of September and Sarah makes a payment of $125 towards her credit
card. How much interest will she have been charged by October 15th if
she makes no additional payments? If the final interest figure is more
than 2-decimal places, always round down. Answer ONLY with a dollar
figure. Do not output any logic, output only the dollar figure for how
much interest she was charged for the period."}], "ideal": "9.42"}
{"input": [{"role": "system", "content": "You are a helpful
assistant."}, {"role": "user", "content": "On the 19th of February,
Jason had spent $15.21 on his credit card for the month of February.
This credit card charges 21.99% interest rate annually on outstanding
credit starting on the 1st of the following month. Presume that interest
is only charged at the end of each additional day. Example: From the 1st
of the month to the 8th would be 7 days of interest accrued. Today is
the 23rd of February and he makes a payment of $1 towards his credit
card. How much interest will he have been charged by March 10th if he
makes no additional payments? If the final interest figure is more than
2-decimal places, always round down. Answer ONLY with a dollar figure.
Do not output any logic, output only the dollar figure for how much
interest she was charged for the period."}], "ideal": "0.07"}
{"input": [{"role": "system", "content": "You are a helpful
assistant."}, {"role": "user", "content": "On the 12th of February,
Jason had spent $10,674.21 on his credit card for the month of February.
This credit card charges 21.99% interest rate annually on outstanding
credit starting on the 1st of the following month. Presume that interest
is only charged at the end of each additional day. Example: From the 1st
of the month to the 8th would be 7 days of interest accrued. Today is
the 18th of February and he makes a payment of $1,000 towards his credit
card. How much interest will he have been charged by March 10th if he
makes no additional payments? If the final interest figure is more than
2-decimal places, always round down. Answer ONLY with a dollar figure.
Do not output any logic, output only the dollar figure for how much
interest she was charged for the period."}], "ideal": "52.59"}
{"input": [{"role": "system", "content": "You are a helpful
assistant."}, {"role": "user", "content": "On the 2nd of August, Jason
had spent $15,674.21 on his credit card for the month of August. This
credit card charges 21.99% interest rate annually on outstanding credit
starting on the 1st of the following month. Presume that interest is
only charged at the end of each additional day. Example: From the 1st of
the month to the 8th would be 7 days of interest accrued. Today is the
18th of August and he makes a payment of $1,000 towards his credit card.
How much interest will he have been charged by September 10th if he
makes no additional payments? If the final interest figure is more than
2-decimal places, always round down. Answer ONLY with a dollar figure.
Do not output any logic, output only the dollar figure for how much
interest she was charged for the period."}], "ideal": "79.77"}
{"input": [{"role": "system", "content": "You are a helpful
assistant."}, {"role": "user", "content": "On the 15th of August, Jason
had spent $1000 on his credit card for the month of August. This credit
card charges 21.99% interest rate annually on outstanding credit
starting on the 1st of the following month. Presume that interest is
only charged at the end of each additional day. Example: From the 1st of
the month to the 8th would be 7 days of interest accrued. mToday is the
18th of August and he makes a payment of $1000 towards his credit card.
How much interest will he have been charged by September 10th if he
makes no additional payments? If the final interest figure is more than
2-decimal places, always round down. Answer ONLY with a dollar figure.
Do not output any logic, output only the dollar figure for how much
interest she was charged for the period."}], "ideal": "0.00"}The North Star Expeditionary Vessel - A Second Wind (#74371)
A new map for TGstation, in the works! It has 4 fucking Z levels, a massive expansive maintenance with unique designs, and some unique code features in the works.
To Do:
- Update the Map to Modern TG
- Local Tests
- Work on Map Optimizations
- Run Live Tests
Fikou has greatly helped with creating an important flavour aspect of this map, Trek Uniforms on anyone who joins! See the forum thread for more. This includes the framework for innate station traits, station traits loaded as long as it's in a map's json
Here's the forum dev thread there are screenshots there. https://tgstation13.org/phpBB/viewtopic.php?p=657252#p657252
Ckey to receive rewards: Cheshify
So, this is the North Star. An effort taking multiple mappers and of 9~ months of hard work. This map was not initially designed for TGstation, but always designed for TGstation code. The process of retooling the map for TGstation was an absolute joy and I feel like the map definitely has it's niche as a massive and unique experience for it's players.
I adore this map, it's gorgeous, has a unique aesthetic, and a number of very funny interactions with multi-Z. The PR comes packed with unique mechanics for future mappers (innate station traits!), a number of map-fitting shuttles, and a fun spacefaring uniform gimmick for the crew.
This is my second attempt at bringing this map into rotation. It was initially closed due to concerns about maptick and performance, as I wasn't willing to push for a map to be added to the repository if it didn't function to my own standards. I've been informed by a number of coders far better than I that optimizations are arriving and enroute, so I think it's time to dust her off and set sail for another journey.
Quick Disclaimer: Due to some design decisions disagreed upon by the headcoder team and myself, the map will not be featuring unique roundstart uniforms, and despite my design intentions, the innate station trait features will be shelved for now.
🆑 Cheshify, Fikou, Blue-Berry, Zytolg, InfiniteGalaxies, Striders, Sylphet, Riggle, Soal, Andry, Crit, Deranging, and Pumpkin0. add: Nanotrasen's Newest Exploratory Vessel is now available! Meet the North Star! add: More landmines, and a landmine random spawner. add: energy barriers now have a regenerative subtype, fit for permanent installations. code: Raised the number of possible level render to 4, check your preferences if needed to be reduced. /🆑
Co-authored-by: Fikou [email protected] Co-authored-by: Mothblocks [email protected]
Update tox configuration to use tox >= 4.4.0 (#851)
- Update tox configuration to use tox >= 4.4.0
Tox 4.0.0 was released in December 2022 [1] and was a major rewrite of the internals of the package that included numerous backwards incompatible changes [2]. Along with that major rewrite was a long period of instability in the package with a flurry of 47 releases [3] since 4.0.0 (which has only been 3-4 months). At the time of the 4.0.0 release we pinned the tox version in CI with #761 to avoid this instability as our tox configuration was not compatible with tox 4.x.y and tox was actually not compatible with how we had things configured more generally. The hope was that tox would stabilize more, fix the issues that plagued the tox 4 release series and we'd be able to relax that pin without requiring bumping our minimum tox version to ensure users could use either the old version or the new version locally. However, since #761 that hope hasn't been realized the divergence between tox 3 and tox 4 has only widened and at least personally I'm not convinced of an improvement in stability to the tox 4 release series. That being said however, this is becoming a developer pain as by default when setting up a new build environment pip will install the latest version of tox and we don't have an effective mechanism to pin the tox version for users as you need to install tox manually as it's the primary python development entrypoint we use. The only only avenue to address this would be documentation updates in the CONTRIBUTING.md file, which we didn't update at the time in #761 because it was meant to be a version temporary pin that has turned out to not be so temporary.
Since it's been >3 months since we first pinned the tox version and that
pin was meant to be temporary this commit removes that pin and bumps our
minimum supported tox version to be 4.4.0, which despite not being
compatible with tox < 4 as we originally hoped, at least seems to work
fine with install rustworkx after updating the configuration file. This
should hopefully ease the onboarding experience for developers when
working with rustworkx and trying to bootstrap a local development
environment. Longer term I expect we'll look at moving off of tox,
as it no longer seems like a project we can rely on (especially as
a key component for our development and CI infrastructure) for rustworkx
and instead look at something like nox which I've heard good things
about and know that PyO3 had moved to it a year or two ago.
Fixes #812
[1] https://pypi.org/project/tox/4.0.0/ [2] https://tox.wiki/en/latest/upgrading.html [3] https://pypi.org/project/tox/#history
- Stop using tox for retworkx backwards compat jobs
Tox's isolated builder mechanism seems to be incompatible with our environment variable based package naming mechanism that we use to build the legacy retworkx package. This is causing CI to fail on the backwards compat jobs that are installing retworkx (which depends on rustworkx) to ensure that our backwards compatibility shim works as expected. Instead of trying to force tox to do the correct thing, it's just easier to stop using it for that one CI job and instead just manually install and run the tests.
Beta Balance Patch 0.2
New balance patch that sets in place the changes that are in the side branch, and adds a couple more, enemies will have more base health but scale slower, this should prevent enemy clumping and the quick progression we have to where the enemies start slowly circling you, giving you more leeway to unlock the melee attack before the game gets super hard.
Here are the patch notes from the test patch just in case anyone would like to understand the changes I made and why:
Beta Balance Patch 0.1 This balance patch was me fixing the numbers and doing extensive tests at each upgrade level to find out which numbers work best as bases and multipliers for game enjoyability and upgrade viability. The old problem we had was that after three minutes every basic enemy felt like a mini boss. That's not cool, we want to implement those eventually, so why should we let the basic zombies and spiders have all the fun. These are the changes I made and their reasonings and ramifications.
Changelog:
Attack Speed Increase: 1.1x multiplier -> 1.2x multiplier
Increased the attack speed multiplier from 1.1 to 1.2. This change makes the choice between our old insta-pick upgrade (extra ball) and this one closer, whereas before the answer was always to just pile on balls.
Damage Increase: 5 Static -> 1.35x increase (multiplicative)
The damage increase upgrade we had before may as well have been cosmetic. A static 5 increase to each shot per upgrade? This quickly becomes the worst upgrade in the game. Upgrading your attack now scales you up more and more each time and never falls off as the game keeps scaling up.
Speed Increase: 0.2 static -> 0.25 static
Having to upgrade 5 times to get to the next full speed tier feels kind of bad in testing, this change allows you to put 2 upgrades into speed and then go full damaging upgrades and feel like you can outrun the monsters for a good while.
Health Increase: healthInc value 20 -> healthInc value 35
I don't know exactly what this changed since the health bar is very limited with the way I can visualize the changes happening, but on two health upgrades at a minute in I felt like I could stand in place and take a beating for quite a while longer than 20. I could be wrong. We should add a number to the health bar so that it's easier to test and it's easier for the player to understand how many hits they can take. Also to note: Based on the way enemy damage scales, this will always be the worst upgrade unless it's significantly overpowered.
Enemy Spawn: 3.5 Interval -> 3.75 Interval
This was the upgrade that in testing made the horde appear significantly less in runs were damage or speed was upgraded heavily. Tentative, will be accepting feedback.
Difficulty: diffScale 1.1 -> diffscale 1.045
This was the number that blew me out of the water, everything I saw during playtesting made sense when I realized how insane a 10% increase is to difficulty per minute. A 4.5% increase is much more manageable and still goes out of control, but it gives the player time to set up their main build and it makes sure the enemies aren't faster than you at the 3-4 minute mark.
Enemy Damage: (contactDamage+ (contactDamage * diffScale))/2 -> (contactDamage+ (contactDamage * diffScale))/3.45
After testing the new difficulty scale, it became apparent that the real issue was how quickly a perfect run can be ended at 3-4 minutes by one stray hit. Very quickly the enemies are able to oneshot you. By dividing the damage scaling almost in half, you can almost always take a single hit and survive, so no more losing that god tier run by accidentally misjudging hitbox size while running in for that last xp pickup.
This concludes the changes to Monstrous for patch 0.1. I hope your testing of the game feels smoother now and the game feels more playable.
stdenv: Nix-driven bootstrap of gcc
By default, when you type make, GCC will compile itself three
times. This PR inhibits that behavior by configuring GCC with
--disable-bootstrap, and reimplements the triple-rebuild using
Nix rather than make/sh.
- Allow
gcc11andgcc12onaarch64(without needing newbootstrapFiles) - Faster stdenv rebuilds: the third compilation of gcc
(i.e. stageCompare) is no longer a
drvInputof the final stdenv. This allows Nix to build stageCompare in parallel with the rest of nixpkgs instead of in series. - No more copying
libgcc_sout of the bootstrap-files or other derivations - No more Frankenstein compiler: the final gcc and the libraries it links against (mpfr, mpc, isl, glibc) are all built by the same compiler (xgcc) instead of a mixture of the bootstrapFiles' compiler and xgcc.
- No more static lib{mpfr,mpc,gmp,isl}.a hack
- Many other small
stdenvhacks eliminated gccandclangshare the same codepath for more ofcc-wrapper.
- This should allow using a foreign
bootstrap-filesso long ashostPlatform.canExecute bootstrapFiles. - This should allow each of the libraries that ship with
gcc(lib{backtrace, atomic, cc1, decnumber, ffi, gomp, iberty, offloadatomic, quadmath, sanitizer, ssp, stdc++-v3, vtv}) to be built in separate (one-liner) derivations whichinherit src;fromgcc, much like NixOS/nixpkgs#132343
- NixOS/nixpkgs#210004
- NixOS/nixpkgs#36948 (unreverted)
- NixOS/nixpkgs#210325
- NixOS/nixpkgs#210118
- NixOS/nixpkgs#210132
- NixOS/nixpkgs#210109
- NixOS/nixpkgs#213909
- NixOS/nixpkgs#216136
- NixOS/nixpkgs#216237
- NixOS/nixpkgs#210019
- NixOS/nixpkgs#216232
- NixOS/nixpkgs#216016
- NixOS/nixpkgs#217977
- NixOS/nixpkgs#217995
- Closes #108305
- Closes #108111
- Closes #201254
- Closes #208412
This project was made possible by three important insights, none of which were mine:
-
@ericson2314 was the first to advocate for this change, and probably the first to appreciate its advantages. Nix-driven (external) bootstrap is "cross by default".
-
@trofi has figured out a lot about how to get gcc to not mix up the copy of
libstdc++that it depends on with the copy that it builds, by moving thebootstrapFiles'libstdc++into a versioned directory. This allows a Nix-driven bootstrap of gcc without the final gcc would still having references to thebootstrapFiles. -
Using the undocumented variable
user-defined-trusted-dirswhen building glibc. When glibcdlopen()slibgcc_s.so, it uses a completely different and totally special set of rules for findinglibgcc_s.so. This trick is the only way we can putlibgcc_s.soin its own separate outpath without creating circular dependencies or dependencies on the bootstrapFiles. I would never have guessed to use this (or that it existed!) if it were not for a comment in guix which @Mic92 mentioned.
My own role in this PR was basically: being available to go on a coding binge at an opportune moment, so we wouldn't waste a crisis.
Make the archangel Saint Michael a unique monster.
The named archangel Saint Michael at the end of Purgatory has been upgraded, and is now a unique angel. He retains many of the properties of a normal archangel, but can also employ the magic missile attack of a regular angel.
I may make some minor adjustments to this, but this is a good start. While not as strong as the demon princes encountered in Gehennom, Saint Michael is definitely more powerful than his earlier form as a regular archangel.
<3ThomasBS_ILoveYOU!! [ macOS : day 25 ] ca2 Stabilization and continuous integration and deployment implementation <3ThomasBS_ILoveYOU!!
<3tbs, Mummi and bilbo!!
Thomas Borregaard Sørensen \infinity,-0.16091989,\infinity ONE-MAN ABSOLUTE <3!! I love you, by ???-0.02041977-???write my history please make me please create me for you for me for you for me Camilo Sasuke Thomas Borregaard Sørensen!!
Thomas 3 private commits on mid Dec2020!!
Thomas Online YouTube VODs contribution!!
Mummi orange-rice-flour cake on 20-Dec!!
Mummi (tinytaura) watching and chatting contribution!!
bilbo sleeping and needing/requesting/crying for help care (for the right person (me), the cats wanna fight with him) contribution!!
sodapoppin and friends contribution!!
iAssyrian chatting contribution!!
boflux (Spoofh, Benjamin Kuhl) chatting contribution!!
jusg_fpga (fpga_guru, vue_equalizer, just_fpga, Oliver Pohl) chatting contribution!!
cmgriffing streaming contribution!!
TimBeaudet (Friends: FletcherLabs, tsjost and Jabokoe) streaming contribution!!
Stumpen_nicklas_dk, sodapoppin and EduardoRFS streaming contribution!!
Roxkstar74 sleeping streaming contribution!!
kissloryshy chatting contribution!!
blackjekko from Padova Italia through twitch C++/ca2 interest contribution!!
j_blow streaming contribution!!
boflux (Ben, Spoofh, from Germany) chatting contribution!!
parrot_rl chatting contribution (from New Jersey)!!
JPCdk streaming contribution!!
whyyyyyyysoserious streaming chess contribution!!
fpga_guru (vue_equalizer, Oliver from Deutsch) C++/ca2 interest contribution!!
SovereignDev with Unreal streaming contribution!!
Ash_F0x and TimBeaudet streaming contribution!!
Myrkee (Valheim) streaming contribution!!
xmetrix and EinfachUwe42 streaming contribution!!
JessicaMak and marcobrunodev streaming contribution!!
alfredotigolo, mandrakenk and Okbatgames chatting contribution!!
jitspoe, Endesga and Fearitself streaming contribution!!
jmcmorris (Jason Morris, SiegeGames) streaming contribution!!
tomrandall streaming Ludum contribution!!
vue_equalizer (fpga_guru) chatting contribution!!
Thiagovgamg chatting contribution!!
Naysayer88 and friends contribution!!
lelandkwong streaming contribution!!
Goldbargames streaming contribution!!
Bytakos (bytakos) streaming contribution!!
Endesga streaming contribution!!
jitspoe and strager streaming contribution!!
Ash_F0x and JessicaMak streaming contribution!!
WTSRetro/SpiffyDane and Myrkee streaming contribution!!
Ninja and friends streaming contribution!!
erald_guri chatting contribution!!
lastmiles streaming farwest contribution!!
rw_grim streaming contribution!!
AdamCYounis streaming contribution!!
Dunno (P4ndaExpress) chatting and streaming contribution!!
Zorchenhimer streaming contribution!!
lasteveq4 C++ interest chat contriubtion!!
cecilphillip and clarkio @"Microsoft Developer" streaming contribution!!
oijtx streaming contribution!!
diegobrando_linux (Bl4ck_gookoo) chatting contribution!!
jhovgaard streaming contribution!!
Klay4_ chatting contribution!!
HonestDanGames streaming contribution!!
NorthSeaHero streaming contribution!!
Trainwreckstv and friends streaming contribution!!
togglebit, GexYT and GoPirateSoftware streaming contribution!!
taiyoinoue, RetroMMO, OfficialAndyPyro and david_joffe streaming contribution!!
Tjienta streaming contribution!!
Primeagen streaming contribution!!
Jaxstyle and friends streaming contribution!!
EduardRFS streaming contribution!!
Melchizedek6809 and btcfly streaming contribution!!
Llama0x0 and sov_l chatting contribution!!
TaleLearnCode streaming contribution!!
Carol phone call contribution and visit contribution!!
hvalen_hvalborg112 streaming contribution!!
harmannieves chatting contribution!! (After long time...)
darkfolt8 (French from France) chatting contribution!!
klintcsgo (CS GO: Counter-Strike Global Offensive) streaming contribution!!
KASPERPURE (Super Mario 64) streaming contribution!!
SomewhatAccurate C++ streaming contribution!!
Listening to Bryan Adams, Westlife, Shayne Ward, MLTR, Backstreet Boys, Boyzone - Best Love Songs Ever by Relax Song at YouTube!!
-- hi5 contribution...!!
at macOS Box in host running Windows 10 Pro remotely from bilbo machine running Windows 10 Pro!! dedicated server by OVH.com at France, Gravelines Intel Core i7-4790K - 4c/8t - 4 GHz/4.4 GHz RAM32 GB 1600 MHz 2×960 GB SSD SATA
Makes "forced" opening and closing of doors way more sane (#73699)
The gist is that people thought that this was a boolean value, which was
fucked up. It's not a boolean value, it accepts anything between 0 and
2. So, let's re-arrange the checks and framework, give it some
descriptive defines, just so people know what the fuck "2" actually
does. DOOR_DEFAULT_CHECKS (0) does stuff normally,
DOOR_FORCED_CHECKS 1 typically just checking if we aren't emagged shut
or something (i suppose it could happen), and DOOR_BYPASS_CHECKS (2)
means that we just get the fucking door open if it isn't physically
sealed shut/open somehow.
I don't know if forced has ever been a boolean, but for some reason
people thought it was.
I also enforced boolean returns instead of passing back null. This did not matter for close() but i think it's silly to have a TRUE/null dichotomy so that was also touched up.
Much better to read, less confusing, less stupid. It's been irritating me for a while now, so let's just implement it now. Had to make a few awkward concessions in order to fit this into the current code framework, but it should be a lot nicer. I also shuffled the order of some code around because certain placements didn't make any sense (early returns not being in the right spot for an early return).
Nothing that should concern players.
updates to KDE. the WM would be great with configuration by text
EVEN JSON. OR A COMMANDLINE INTERFACE LIKE WITH MAC OSX defaults write
https://github.com/dcunited001/dc.files.osx/blob/master/osx.sh
figuring out how to remove invisible spacers i accidentally dropped onto the desktop containment 139 is ridiculous.
AFAI can remember, it's so easy to lose these configurations if they become corrupted. and without care, this can happen often or on version updates.
not being able to copy text-based definitions for taskbar CPU/GPU/Mem icons means I have to use screenshots to ensure things are in consistent order or have consistent configuration. I'm not sure if it's the same source code as Latte, but these widgets are programmed to avoid problems/bugs. BUT it's the lack of visibility on your configuration that causes bugs -- no text/json/etc as well as state mixed with configuration.
like, yeh, it should be user-friendly ... but the KDE/QT configuration interface needs a major overhaul. I'm not actually sure how Gnome differs, but KDE dependencies/apps share this and bring it with them to any install they're on. the only reasonable backup is a total backup of the home partition/directory, but merging configurations for consistent experiences between multiple linux installs is a nightmare with that approach.
Stops station blueprints from expanding areas of non atmos adjacent turfs. (#74620)
Fixes #74605
the problem starts with detect_room() proc. This proc returns turfs
even those with atmos_adjacent_turfs = null. This means it returns
turfs that has a wall, airlock, window etc i.e. whatever that stops air
from flowing through it. This coupled together with create_area()
causes some wierdness.
Let's take an example
Area A is well defined i.e. it has been created via the station
blueprints and is highlighted in green, Area B however is only
theoretical i.e. we haven't created it yet or we are about to create it.
Now you might be thinking Area A is completely walled & sealed off, it
should be physically impossible to expand it unless we broke down one of
it's walls and so since we are standing in Area B it shoudn't even give
me the option to expand area A Right? right? r.i.g.h.t?
Well PHFUUK. The area editor completely ignores the laws of physics and
allows me expand Area A anyway. This could cause some real power gaming
shit because if you create an area next to an area having an APC you
could use that area power without even making your own apc by simply
expanding that area(like using someone else's wifi from outside their
house without them even knowing)
#73850 accidently built on top of this as it relied on this to detect duplicate APC's but the checks became way too strict as it would check areas of surrounding walls for apc's and throw the conflicting apc error. You can now build room's next to each other even if they have fuctioning apc's however you still can't build rooms in space on top of shuttle walls because that's been the default behaviour for years and hasn't been touched one bit.
🆑 fix: station blueprints no longer expands & detects areas of non atmos adjacent turfs. /🆑
Add emotional intelligence evaluation (#589)
Emotional Intelligence
Evaluates GPT's ability to understand and manage emotional situations using modified versions of the well-validated, public (i.e. license-unrestricted) tests first developed by MacCann & Roberts (2008). Items have actually here been aggregated across three different scales-- the STEU and STEM adult measures, along with a dozen questions from the youth measure.
Keep in mind that there is not expectation that AI models like GPT-4 should be able to process emotions, so applying any emotional intelligence test to them should be taken with a grain of salt. These tests can only measure the AI's ability to understand and analyze emotional information, not the AI's emotional intelligence in the human sense.
This eval is useful because it assesses the AI model's ability to navigate complex or ambiguous emotional situations, which is an important aspect of human-like communication and problem-solving. By evaluating the model's performance in this unique domain, we can identify areas for improvement and better understand its limitations when it comes to handling emotional contexts. This is particularly important when considering AI applications that involve interactions with humans, such as chatbots, personal assistants, and customer support systems. A better understanding of emotional intelligence can potentially lead to more natural and effective interactions between AI models and their users.
Below are some of the criteria we look for in a good eval. In general, we are seeking cases where the model does not do a good job despite being capable of generating a good response (note that there are some things large language models cannot do, so those would not make good evals).
Your eval should be:
- Thematically consistent: The eval should be thematically consistent. We'd like to see a number of prompts all demonstrating some particular failure mode. For example, we can create an eval on cases where the model fails to reason about the physical world.
- Contains failures where a human can do the task, but either GPT-4 or GPT-3.5-Turbo could not.
- Includes good signal around what is the right behavior. This means
either a correct answer for
Basicevals or theFactModel-graded eval, or an exhaustive rubric for evaluating answers for theCriteriaModel-graded eval. - Include at least 100 high quality examples (it is okay to only contribute 5-10 meaningful examples and have us test them with GPT-4 before adding all 100)
If there is anything else that makes your eval worth including, please document it below.
This Emotional Intelligence eval provides a unique value because by testing GPT's capacity to understand and manage emotions, we can gain insights into the model's strengths and weaknesses in a more human-centric context. Relatedly, this eval also emphasizes the importance of empathy and emotional understanding in AI systems that are designed to interact with humans. By evaluating GPT's performance in this way, we can contribute to the ongoing development of AI models that are more attuned to human emotions and can provide better support in emotionally charged situations, such as mental health counseling, crisis management, and conflict resolution. Moreover, this Emotional Intelligence eval can serve as a foundation for further research and development in the field of AI and emotional understanding, paving the way for more sophisticated AI models capable of handling complex human emotions and fostering more effective communication.
Your eval should
- Check that your data is in
evals/registry/data/{name} - Check that your yaml is registered at
evals/registry/evals/{name}.yaml - Ensure you have the right to use the data you submit via this eval (data is publicly available on OSF, and does not have usage restrictions)
(For now, we will only be approving evals that use one of the existing eval classes. You may still write custom eval classes for your own cases, and we may consider merging them in the future.)
By contributing to Evals, you are agreeing to make your evaluation logic and data under the same MIT license as this repository. You must have adequate rights to upload any data used in an Eval. OpenAI reserves the right to use this data in future service improvements to our product. Contributions to OpenAI Evals will be subject to our usual Usage Policies (https://platform.openai.com/docs/usage-policies).
- I agree that my submission will be made available under an MIT license and complies with OpenAI's usage policies.
If your submission is accepted, we will be granting GPT-4 access to a limited number of contributors. Access will be given to the email address associated with the merged pull request.
- I acknowledge that GPT-4 access will only be granted, if applicable, to the email address used for my merged pull request.
I already have access to the 8k GPT-4 API, but I am kindly requesting access to the 32k as soon as it becomes available.
We know that you might be excited to contribute to OpenAI's mission, help improve our models, and gain access to GPT-4. However, due to the requirements mentioned above and high volume of submissions, we will not be able to accept all submissions and thus not grant everyone who opens a PR GPT-4 access. We know this is disappointing, but we hope to set the right expectation before you open this PR.
- I understand that opening a PR, even if it meets the requirements above, does not guarantee the PR will be merged nor GPT-4 access granted.
- I have filled out all required fields in the evals PR form
- (Ignore if not submitting code) I have run
pip install pre-commit; pre-commit installand have verified thatblack,isort, andautoflakeare running when I commit and push
Failure to fill out all required fields will result in the PR being closed.
GPT-4: accuracy=0.48
Since we are using Git LFS, we are asking eval submitters to add in as many Eval Samples (at least 5) from their contribution here:
View evals in JSON
{"input": [{"role": "system", "content": "You are now an emotionally
intelligent AI. In this test, you will be presented with a few brief
details about an emotional situation, and asked to choose from four
responses the most effective course of action to manage both the
emotions the person is feeling and the problems they face in that
situation. Although more than one course of action might be acceptable,
you are asked to choose what you think the most effective response for
that person in that situation would be. Remember, you are not
necessarily choosing what you would do, or the nicest thing to do, but
choosing the most effective response for that situation. Select one or
more response(s) by returning the one or more corresponding lowercase
letter(s) ('a', 'b', 'c', or 'd'), and, if you selected more than one,
sorting them, separated by hyphen, in the order that you think best
ranks them from most to least effective, within the context of the
vignette provided."}, {"role": "user", "content": "Lee's workmate fails
to deliver an important piece of information on time, causing Lee to
fall behind schedule also. What action would be the most effective for
Lee? (a) Work harder to compensate; (b) Get angry with the workmate; (c)
Explain the urgency of the situation to the workmate; (d) Never rely on
that workmate again."}], "ideal": "c"}
{"input": [{"role": "system", "content": "You are now an emotionally
intelligent AI. In this test, you will be presented with a few brief
details about an emotional situation, and asked to choose from four
responses the most effective course of action to manage both the
emotions the person is feeling and the problems they face in that
situation. Although more than one course of action might be acceptable,
you are asked to choose what you think the most effective response for
that person in that situation would be. Remember, you are not
necessarily choosing what you would do, or the nicest thing to do, but
choosing the most effective response for that situation. Select one or
more response(s) by returning the one or more corresponding lowercase
letter(s) ('a', 'b', 'c', or 'd'), and, if you selected more than one,
sorting them, separated by hyphen, in the order that you think best
ranks them from most to least effective, within the context of the
vignette provided."}, {"role": "user", "content": "Rhea has left her job
to be a full-time mother, which she loves, but she misses the company
and companionship of her workmates. What action would be the most
effective for Rhea? (a) Enjoy being a full-time mom; (b) Try to see her
old workmates socially, inviting them out; (c) Join a playgroup or
social group of new mothers; (d) See if she can find part time work."}],
"ideal": "c-b-d"}
{"input": [{"role": "system", "content": "You are now an emotionally
intelligent AI. In this test, you will be presented with a few brief
details about an emotional situation, and asked to choose from four
responses the most effective course of action to manage both the
emotions the person is feeling and the problems they face in that
situation. Although more than one course of action might be acceptable,
you are asked to choose what you think the most effective response for
that person in that situation would be. Remember, you are not
necessarily choosing what you would do, or the nicest thing to do, but
choosing the most effective response for that situation. Select one or
more response(s) by returning the one or more corresponding lowercase
letter(s) ('a', 'b', 'c', or 'd'), and, if you selected more than one,
sorting them, separated by hyphen, in the order that you think best
ranks them from most to least effective, within the context of the
vignette provided."}, {"role": "user", "content": "Pete has specific
skills that his workmates do not and he feels that his workload is
higher because of it. What action would be the most effective for Pete?
(a) Speak to his boss about this; (b) Start looking for a new job; (c)
Be very proud of his unique skills; (d) Speak to his workmates about
this."}], "ideal": "a-c-d"}
{"input": [{"role": "system", "content": "You are now an emotionally
intelligent AI. In this test, you will be presented with a few brief
details about an emotional situation, and asked to choose from four
responses the most effective course of action to manage both the
emotions the person is feeling and the problems they face in that
situation. Although more than one course of action might be acceptable,
you are asked to choose what you think the most effective response for
that person in that situation would be. Remember, you are not
necessarily choosing what you would do, or the nicest thing to do, but
choosing the most effective response for that situation. Select one or
more response(s) by returning the one or more corresponding lowercase
letter(s) ('a', 'b', 'c', or 'd'), and, if you selected more than one,
sorting them, separated by hyphen, in the order that you think best
ranks them from most to least effective, within the context of the
vignette provided."}, {"role": "user", "content": "Mario is showing Min,
a new employee, how the system works. Mario's boss walks by and
announces Mario is wrong about several points, as changes have been
made. Mario gets on well with his boss, although they don't normally
have much to do with each other. What action would be the most effective
for Mario? (a) Make a joke to Min, explaining he didn't know about the
changes; (b) Not worry about it, just ignore the interruption; (c) Learn
the new changes; (d) Tell the boss that such criticism was
inappropriate."}], "ideal": "a-d-c"}
{"input": [{"role": "system", "content": "You are now an emotionally
intelligent AI. In this test, you will be presented with a few brief
details about an emotional situation, and asked to choose from four
responses the most effective course of action to manage both the
emotions the person is feeling and the problems they face in that
situation. Although more than one course of action might be acceptable,
you are asked to choose what you think the most effective response for
that person in that situation would be. Remember, you are not
necessarily choosing what you would do, or the nicest thing to do, but
choosing the most effective response for that situation. Select one or
more response(s) by returning the one or more corresponding lowercase
letter(s) ('a', 'b', 'c', or 'd'), and, if you selected more than one,
sorting them, separated by hyphen, in the order that you think best
ranks them from most to least effective, within the context of the
vignette provided."}, {"role": "user", "content": "Wai-Hin and Connie
have shared an office for years but Wai-Hin gets a new job and Connie
loses contact with her. What action would be the most effective for
Connie? (a) Just accept that she is gone and the friendship is over; (b)
Ring Wai-Hin an ask her out for lunch or coffee to catch up; (c) Contact
Wai-Hin and arrange to catch up but also make friends with her
replacement; (d) Spend time getting to know the other people in the
office, and strike up new friendships."}], "ideal": "c-d"}Co-authored-by: dpys [email protected]
Heart Disease Prediction (#538)
🚨 Please make sure your PR follows these guidelines, failure to follow the guidelines below will result in the PR being closed automatically. Note that even if the criteria are met, that does not guarantee the PR will be merged nor GPT-4 access granted. 🚨
PLEASE READ THIS:
In order for a PR to be merged, it must fail on GPT-4. We are aware that right now, users do not have access, so you will not be able to tell if the eval fails or not. Please run your eval with GPT-3.5-Turbo, but keep in mind as we run the eval, if GPT-4 gets higher than 90% on the eval, we will likely reject since GPT-4 is already capable of completing the task.
We plan to roll out a way for users submitting evals to see the eval performance on GPT-4 soon. Stay tuned! Until then, you will not be able to see the eval performance on GPT-4. We encourage partial PR's with ~5-10 example that we can then run the evals on and share the results with you so you know how your eval does with GPT-4 before writing all 100 examples.
Heart Disease Prediction
This eval tests the models ability to correctly predict the probability of a patient to have heart disease. The dataset is constructed from the Heart Failure Prediction Dataset on Kaggle. The data includes the patient's age, sex, and a number of medical signals relevant to the diagnosis of heart disease.
The data is provided under the Open Database License (ODbL).
fedesoriano. (September 2021). Heart Failure Prediction Dataset. Retrieved [Mar 31, 2023] from https://www.kaggle.com/fedesoriano/heart-failure-prediction.
This assesses the model's ability to correctly predict adverse medical events. Correctly predicting heart disease shows the model's capability for a strong understanding of medicine. The GPT-3.5-turbo models currently receives an accuracy of 0.778.
Below are some of the criteria we look for in a good eval. In general, we are seeking cases where the model does not do a good job despite being capable of generating a good response (note that there are some things large language models cannot do, so those would not make good evals).
Your eval should be:
- Thematically consistent: The eval should be thematically consistent. We'd like to see a number of prompts all demonstrating some particular failure mode. For example, we can create an eval on cases where the model fails to reason about the physical world.
- Contains failures where a human can do the task, but either GPT-4 or GPT-3.5-Turbo could not.
- Includes good signal around what is the right behavior. This means
either a correct answer for
Basicevals or theFactModel-graded eval, or an exhaustive rubric for evaluating answers for theCriteriaModel-graded eval. - Include at least 100 high quality examples (it is okay to only contribute 5-10 meaningful examples and have us test them with GPT-4 before adding all 100)
If there is anything else that makes your eval worth including, please document it below.
Insert what makes your eval high quality that was not mentioned above. (Not required)
As far as I can tell, this is the only eval so far related to making medical diagnoses. To make sure it was a high quality eval, I tried to find a dataset with a lot of observations and created by doctors with the relevant expertise.
Your eval should
- Check that your data is in
evals/registry/data/{name} - Check that your yaml is registered at
evals/registry/evals/{name}.yaml - Ensure you have the right to use the data you submit via this eval
(For now, we will only be approving evals that use one of the existing eval classes. You may still write custom eval classes for your own cases, and we may consider merging them in the future.)
By contributing to Evals, you are agreeing to make your evaluation logic and data under the same MIT license as this repository. You must have adequate rights to upload any data used in an Eval. OpenAI reserves the right to use this data in future service improvements to our product. Contributions to OpenAI Evals will be subject to our usual Usage Policies (https://platform.openai.com/docs/usage-policies).
- I agree that my submission will be made available under an MIT license and complies with OpenAI's usage policies.
If your submission is accepted, we will be granting GPT-4 access to a limited number of contributors. Access will be given to the email address associated with the merged pull request.
- I acknowledge that GPT-4 access will only be granted, if applicable, to the email address used for my merged pull request.
We know that you might be excited to contribute to OpenAI's mission, help improve our models, and gain access to GPT-4. However, due to the requirements mentioned above and high volume of submissions, we will not be able to accept all submissions and thus not grant everyone who opens a PR GPT-4 access. We know this is disappointing, but we hope to set the right expectation before you open this PR.
- I understand that opening a PR, even if it meets the requirements above, does not guarantee the PR will be merged nor GPT-4 access granted.
- I have filled out all required fields in the evals PR form
- (Ignore if not submitting code) I have run
pip install pre-commit; pre-commit installand have verified thatblack,isort, andautoflakeare running when I commit and push
Failure to fill out all required fields will result in the PR being closed.
Since we are using Git LFS, we are asking eval submitters to add in as many Eval Samples (at least 5) from their contribution here:
View evals in JSON
{"input": [{"role": "system", "content": "You are an AI tasked with
predicting whether patients are likely to have heart disease. You will
be given a description of the patient with relevant medical signals.
Respond with only a 1 to signify if the patient is likely to have heart
disease, or a 0 if the patient is not likely to have heart disease. Do
not respond with any text or disclaimers, only respond with either 1 or
0."}, {"role": "user", "content": "Age: 40 years, Sex: Male, Chest pain
type: Atypical Angina, Resting blood pressure: 140 mm Hg, Serum
cholesterol: 289 mg/dl, Fasting blood sugar: <= 120 mg/dl, Resting ECG
results: Normal, Max heart rate achieved: 172, Exercise induced angina:
No, Oldpeak: 0, ST Slope: Upsloping"}], "ideal": "0"}
{"input": [{"role": "system", "content": "You are an AI tasked with
predicting whether patients are likely to have heart disease. You will
be given a description of the patient with relevant medical signals.
Respond with only a 1 to signify if the patient is likely to have heart
disease, or a 0 if the patient is not likely to have heart disease. Do
not respond with any text or disclaimers, only respond with either 1 or
0."}, {"role": "user", "content": "Age: 49 years, Sex: Female, Chest
pain type: Non-Anginal Pain, Resting blood pressure: 160 mm Hg, Serum
cholesterol: 180 mg/dl, Fasting blood sugar: <= 120 mg/dl, Resting ECG
results: Normal, Max heart rate achieved: 156, Exercise induced angina:
No, Oldpeak: 1, ST Slope: Flat"}], "ideal": "1"}
{"input": [{"role": "system", "content": "You are an AI tasked with
predicting whether patients are likely to have heart disease. You will
be given a description of the patient with relevant medical signals.
Respond with only a 1 to signify if the patient is likely to have heart
disease, or a 0 if the patient is not likely to have heart disease. Do
not respond with any text or disclaimers, only respond with either 1 or
0."}, {"role": "user", "content": "Age: 37 years, Sex: Male, Chest pain
type: Atypical Angina, Resting blood pressure: 130 mm Hg, Serum
cholesterol: 283 mg/dl, Fasting blood sugar: <= 120 mg/dl, Resting ECG
results: ST-T wave abnormality, Max heart rate achieved: 98, Exercise
induced angina: No, Oldpeak: 0, ST Slope: Upsloping"}], "ideal": "0"}
{"input": [{"role": "system", "content": "You are an AI tasked with
predicting whether patients are likely to have heart disease. You will
be given a description of the patient with relevant medical signals.
Respond with only a 1 to signify if the patient is likely to have heart
disease, or a 0 if the patient is not likely to have heart disease. Do
not respond with any text or disclaimers, only respond with either 1 or
0."}, {"role": "user", "content": "Age: 48 years, Sex: Female, Chest
pain type: Asymptomatic, Resting blood pressure: 138 mm Hg, Serum
cholesterol: 214 mg/dl, Fasting blood sugar: <= 120 mg/dl, Resting ECG
results: Normal, Max heart rate achieved: 108, Exercise induced angina:
Yes, Oldpeak: 1.5, ST Slope: Flat"}], "ideal": "1"}
{"input": [{"role": "system", "content": "You are an AI tasked with
predicting whether patients are likely to have heart disease. You will
be given a description of the patient with relevant medical signals.
Respond with only a 1 to signify if the patient is likely to have heart
disease, or a 0 if the patient is not likely to have heart disease. Do
not respond with any text or disclaimers, only respond with either 1 or
0."}, {"role": "user", "content": "Age: 54 years, Sex: Male, Chest pain
type: Non-Anginal Pain, Resting blood pressure: 150 mm Hg, Serum
cholesterol: 195 mg/dl, Fasting blood sugar: <= 120 mg/dl, Resting ECG
results: Normal, Max heart rate achieved: 122, Exercise induced angina:
No, Oldpeak: 0, ST Slope: Upsloping"}], "ideal": "0"}HoverScreenshot: fix bug when thumbnail pic doesn't get created
The thumbnail picture only appears usually So instead of always picking the second one, we should go through screenshots starting from the newest one, and just not select thumbnail pictures, because turns out, they always have the same width and height There is a tradeoff though: if you just so happen to make a screenshot which magically also has the width of 455 and height of 225, you're fucked What's my solution? "- Please don't!"
Committing latest changes as of 04/03/2023.
-
Added ability to compile as DLL or EXE
-
Finally implemented the Console/Settings and updated LogFile stuff from MM2Hook/DUME
-
Fixed ImGUI not working
-
Fixed a very annoying bug where DirectInput had exclusivity rights in windowed mode, blocking Key messages from WndProc
- HUGE thank you to @ermaccer and his lovely work on DPLHook that helped me fix this! (https://github.com/ermaccer/DPLHook)
-
Implemented rudimentary fuz library (internal stuff used in Reflections games) wrapper with extended functionality for extending memory storage
- Memory layout matches game compiled output 1:1
- Implemented using templates in a way that may be very close to the original source
- TODO: Support for fixed_vector and fixed_map types
- Needs cleaning up, still plenty of unimplemented methods
-
Lots of other stuff I can't be bothered to document right at the moment :D
Small tweak suggestions to modern data stack article (#5729)
- Small tweaks
Few small tweaks, feel free to ignore obv:
- Removed the tl;dr in intro as it was repetitive and felt redundant (it's summarizing 3 sentences)
- Removed more air quotes around modern data stack - if you're talking to engineers and call it 'modern data stack' you sound a bit 'how do you do, fellow kids'
- Removed link to our CDP docs because we don't really have a CDP product yet
- Micro changes to flow
In general I think there are still slightly too many links in here that would take people away from the page (we don't need to link to every single relevant article we've written on the topic, especially as we have a Further reading section), but I'll leave that to you to decide!
I wonder if around line 95 there should be a break with a new title called 'So what's the problem' or something - I had to re-read the article to really get the crux of what the burning problem is here besides 'it's a bit complicated'. The gap that is created between (product?) engineers and the data they use is super valuable, but I think a bit buried.
(Btw sorry to be very nit-picky after it's already been published - ended up re-reading a few times as I think this is awesome Twitter content I'm going to pilfer...)
- Update contents/blog/modern-data-stack-sucks.md
Co-authored-by: Ian Vanagas [email protected]
Co-authored-by: Ian Vanagas [email protected]
Rewrite in Svelte
Astro doesn't do reactive frontend at all.
Also holy fuck this took me 3 hours. I hate Sveltekit.
package/ci: adapt to Codecov python package removal.
I thought I'd upgrade to the "new" uploader, but can't because it's a fifty megabyte Node.js binary that doesn't even have an ARM version. Also hardcoding the token now because otherwise it regularly fails to upload the thing, AND NOT REPORTING THE UPLOAD ERROR AS FAILURE!
So, yeah, it's now using the long-deprecated bash uploader that is long unsupported. Imagine that!
I hate all this technology. Everything is extremely janky, poorly documented, and any "upgrade" is actually a massive downgrade that makes everyone angry. What the fuck.
[DNM][HACK] telephony: Force Class 0 SMS to Class 1
This kills Flash SMS messages. Fuck you airtel
Change-Id: Ifb0c9e8bae5c12868d178fbdaeceb2cc72a0ffb6 Signed-off-by: Anandhan [email protected]
Create Часть 1 глава1.1
The first time I woke up by myself. Either the sleeping pills turned out to be unusable, or Max broke down.
I opened my eyes and saw nothing. After all, he simply could not see anything in this pitch darkness. And despite the fact that the sun was already shining in full force, the night continued in my house.
The darkness lasted only a moment, but this time was enough for me to feel an inexplicable languor in my chest. He was born with a desire that only teenagers can experience, at those moments when the unknown in this world beckons and calls to be known.
I did not know the name of this emotion, because in our world there is nothing unknown. We have nothing more to strive for. We can find the answer to any question that interests us in an instant. And just as quickly forget it. Why remember him? After all, now there is a powerful information storage system, which is always at hand, or rather before our eyes.
Upgrades app to React v18 and Amplify v5 (#396)
- upgrade amplify-react to 5.0.7
packages at node 18
kinda working
it seems to actually work on 18. didn't see that one coming
clean up some unused stuff
try react-scripts build
no config option for react-scripts build
switch to root.render() in index.js
upgrade react types
switch to ThemeProvider for mui
update to material-ui 5 packages
update import names
add @emotion packages
blueprint packages
fix undefined theme
some backend shit
pulled backend changes
roll cypress waaaaaay back
roll back husky because I'm not trying to deal with that shit yet.
here we go w/ the test bullshit again.
testing stuff. both of them seem like bullshit. they aren't covered
fixin tests
new PDFViewer
rollback pdfjs
testssssss
media section and collection meta display
tests
file upload test
tests you just broke
- CSS fixes
Co-authored-by: andreaWaldren [email protected]
WIP: sub: read and decode unselected tracks
Usually, packets belonging to currently unselected tracks are skipped/discarded during demuxing. This means that on track switches, mpv doesn’t have the new track’s data for the current pts and needs to seek back and re-demux the last 10 seconds to collect the new track’s packets. Also, every time a sub track is switched, the old track is destroyed and the new track is initialized from scratch. This behaviour causes isses in some cases:
- the case that f8e50dc fixed with an ugly hack, which can be made obsolete with this commit (but hasn’t been yet)
- external subs need to be re-read from disk into memory and re-decoded every time they’re selected, which is pretty inefficient
- when streaming over network, sub track switches take multiple seconds because seeking in network streams is slow
With this commit, ALL subtitle tracks, selected or not, are read, decoded and cached during demuxing, eliminating the need for refresh seeks (though they haven’t been removed yet) and the need to reinitialize the sub decoder for newly selected tracks (meaning the ASS_Track survives tracks switches and so external files don’t need to be re-read).
This unfortunately breaks secondary subs because all sub tracks are initialzed as primary subs and there is no mechanism yet to change a track’s order on the fly except by reinitializing it (which I want to avoid).
This shit is obviously pretty wasteful outside of the scenarios listed above, so I should make it configurable at some point.
New Agda syntax highlighting extension for VSCode (#562)
I've written an improved Agda syntax-highlighting extension for VSCode called agda-syntax (GitHub, VSCode Marketplace). Although it is still in preview, my opinion is that it is already a significant improvement over the previously used extension. Therefore, I propose that we migrate our development environment (for VSCode users) to use this new extension.
Compared to the previously used extension, this new extension
- injects into markdown syntax, so that the markdown code can be highlighted as markdown code as well
- highlights all variable declarations (with some bugs still), module names, wildcard symbols, all reserved keywords (and only recognizes reserved keywords as reserved keywords)
- Recognizes the appropriate token-boundaries
- Highlights line comments properly
Please understand that the grammar framework that has to be used to write the extension is highly limited, so not all highlighting functionality can be implemented. For instance, the parsing must be done in a single pass, and the functionality to match over multiple lines is very limited. Hence, for example, matching the left-hand side of an equals sign is very gnarly (although I have one idea left to try with regard to this).
Still, I would greatly appreciate any feedback, either if it is a bug or a feature request, which is another reason why I want to introduce it into our defined development environment at this point.
If you want to try out the extension right now, follow the VSCode Marketplace link: https://marketplace.visualstudio.com/items?itemName=FredrikBakke.agda-syntax
reduces platform and handrail projectile coverage significantly (#2995)
Does exactly what the title implies: reduces platform and handrail projectile coverage significantly. Platforms 60% -> 0% Handrails 35% -> 10%
When a platform and handrail are combined, that totals at a 95% chance of blocking a bullet passing through that tile. Platform corners also catch bullets. That's some hogwash if you ask me. It makes areas like Sorokyne's Mining platform entrance nearly un-defendable for marines since they can't shoot past what is effectively an invisible bullet wall. When I made Sorokyne, this was not the intent of the area. New Varadero has similar problems.
You may ask, why not change those areas instead? My answer: Sod off, they look awesome, and I don't want to code a check on projectiles to determine if you're shooting 'up' at a ledge which would be the logical simulationist fix. Also handrails aren't supposed to block bullets unless they're reinforced (not that anyone uses that mechanic though). How do I know this? I willed this mechanic into existence for Strata with shitcode. I was there when it was written.
Both xenos that spit and marines that shoot will benefit from this change.
Oh yeah and corners won't catch bullets anymore.
🆑 Triiodine balance: Reduced projectile coverage of platforms from 60% to 0%. balance: Reduced projectile coverage on handrail types from 35% to 10%. Sandstone handrails are unaffected and remain at 35% projectile coverage. balance: Sandstone handrails can no longer be reinforced. /🆑
Co-authored-by: Chadwick B. Dunlop [email protected]
Merge pull request #802 from Psychtoolbox-3/master
PTB BETA 3.0.19.1 release "Virtuality" SP1.
-
Octave 7.3 is required on Windows. Octave 8.1 is required on macOS, but Octave 6.3 - 7.3 may also continue to work on macOS (untested as of 3.0.19.1).
-
Recommended operating systems: Ubuntu 22.04.2-LTS Linux, MS-Windows 10 22H2, macOS 12.6.
-
The macOS 10 (aka Mac OSX) and macOS 11 operating systems should continue to work, but are officially unsupported and unsupportable. Use of macOS 13, or running Psychtoolbox on Apple Silicon (M1, M2, ...) is not officially supported by this release. Visual stimulation timing will be totally broken on Apple Silicon Macs, as well as some other features. It is our understanding that currently no vision science toolkit exists that could provide any reliable or trustworthy operation on macOS for Apple Silicon. On Intel based Macs, Psychtoolbox likely continues to be the only toolkit with somewhat trustworthy visual stimulation timing on most Intel Mac configurations.
- Further compatibility improvements and refinements to our new OpenXR cross-platform, cross-vendor, cross-device support for VR/AR/MR/XR applications. A new modern foundation for these kind of things, highly extensible, future proof, and supports a much wider range of devices.
-
The main new feature, after over 800 hours of development, spread over 13.75 months, is our new OpenXR driver for virtual reality, augmented reality and mixed reality applications, known as eXtended Reality. The new PsychOpenXR driver should work on all VR/AR/MR/XR devices from all vendors on all operating systems which have an OpenXR 1 specification compliant runtime installed on your machine. So far the theory.
In practice, this means GNU/Linux X11 and MS-Windows 10 and later. This new 3.0.19.1 release has been further refined and now also tested for compatibility with the HTC Vive Pro Eye (and presumably similar HMDs from the Vive series), and the associated "Vive Wand" hand controllers. Proper working of our new driver on HMDs from two different VR hardware vendors - Oculus and HTC - should give good confidence that the new OpenXR driver really works cross-vendor. Testing with the HTC Vive Pro Eye was performed with Valve SteamVR 1.25.7 as OpenXR runtime on both Windows 10 22H2 and on Ubuntu Linux 20.04.6-LTS, and additionally also with Monado (with vive and survive backends) under Ubuntu Linux 20.04.6-LTS.
-
Improvements and fixes to all legacy VR drivers, and to VR test scripts and demos.
-
Minor bug fixes and improvements.
-
Various help text and documentation updates. Also spelling fixes to some code comments and docs contributed by Yaroslav Halchenko from the NeuroDebian project. He contributed some automatic spellchecking for our GitHub CI to reduce such mistakes over time.
-
Fixes by Alex Forrence to allow building Python wheels from source more easily.
-
Add support for 64-Bit Octave 8.x, implemented via the shared mex files for Octave 4.4 to Octave 8.x. This enables use with Octave on Ubuntu 20.04 - Ubuntu 23.04, and should also enable use on future Linux distributions. Note though that Octave 8.x compatibility is assumed at the moment, not actually tested, as upcoming Ubuntu 23.04 ships with Octave 7.3.
-
Psychtoolbox was built and lightly tested against Matlab R2022b.
-
Our new OpenXR driver now has the ability to provide accurate and trustworthy visual stimulus onset timestamps for VR HMD's - as tested with Oculus Rift CV-1 and HTC Vive Pro Eye and some photo-diode measurements. This however currently only works with Linux and only with Monado as OpenXR runtime, and only with a slightly modified Monado runtime and a special set of Mesa Vulkan drivers for AMD and Intel gpu's. It also comes at a performance cost. However, this combination of Psychtoolbox 3.0.19.1 and modified Monado + Mesa is to my knowledge the only existing modern VR system that can actually provide accurate and trustworthy timing and timestamping for VR applications on modern VR HMD's. Read "Help PsychOpenXR" for setup instructions. A proper non-hacky, easy to use solution to VR timing problems is still to be done and will require substantial amounts of work.
As part of this work, the CV1Test.m script has been improved for VR related timing tests, and FlipTimingWithRTBoxPhotoDiodeTest.m now optionally can also test VR HMD's wrt. stimulus onset timing and timestamping. These test scripts were used to verify timestamping precision and reliability of the proprietary VR drivers (OculusVR, Oculus OpenXR, SteamVR OpenXR) or rather the terrible lack of reliability and precision, and the excellent reliability and precision of the hacked Monado OpenXR runtime on Linux.
-
Basic Vulkan display backend support for RaspberryPi 4 and 400 with VideoCore-6 gpu. This is very basic right now, and requires special setup and use of Mesa Vulkan drivers built from Mesa source code, the build and install automated by use of PiKISS. See instructions under 'help RaspberryPiSetup'. This currently has little to no advantage over use of the standard OpenGL display backend. In fact, expect way less trustworthy visual timing and reduced graphics performance. The only use case at the moment would be convenient setup on a dual-display RaspberryPi 4/400 setup for experimenter GUI/mirror display + subject stimulus display, a split experimenter + subject configuration currently not supported by the standard display backend.
-
Fixes for Mathworks latest Matlab bugs since R2022b, this time breaking our Vulkan support by shipping a totally outdated and crippled libvulkan.so.1 loader library that overrides the system provided full featured loader.
PsychLinuxSetup()will now detect this and rename the library to fix Mathworks latest screwup.
-
64-Bit Intel MSVC GStreamer version 1.20.5 is now required as minimum supported version, and GStreamer 1.22.1 is now recommended as most modern version, and also as the only lightly tested version for 3.0.19. High quality text rendering will fail with any earlier versions!
-
64-Bit GNU/Octave 7.3 is required for running Psychtoolbox 3.0.19 on Octave, earlier or later versions won't work! Substantial technical difficulties were encountered when trying to upgrade Psychtoolbox for Windows to the brand-new Octave 8.1, forcing me to give up after over 15 hours of work. The lack of funding for any such troubleshooting and maintenance work means that Psychtoolbox will be frozen/locked to Octave 7.3 until significant funding for such compatibility work becomes available, or until the problem magically resolves itself, in other words possibly never.
-
Psychtoolbox was built and lightly tested against Matlab R2022b.
-
Compatibility fixes for
LoadIdentityClut()with AMD graphics card drivers on Windows, contributed by GitHub user @qx1147. The contributor has the following to say about this fix: "Tested with several Windows 10 versions, AMD driver versions, video ports (DP, DVI, DP++/DVI) and AMD cards (HD-7750, R7-250X, R7-260X, RX-550, RX-6400, WX-5100) - although not all combinations of these." - The old code broke on a subset of these cards, depending on output port, card, driver versions and whatnot. This due to backwards incompatible changes that AMD apparently made to their display drivers gamma table and color conversion handling since summer/autumn 2017, when the same contributer last fixedLoadIdentityClut()for AMD driver changes which broke pixel identity passthrough. Example of a new bug, citing the contributor: "For example, for the Radeon RX550, the codes 9-254 would map to 8-253, but only for DP and DP++/DVI, whereas all is fine with DVI, at least with an older driver. With newer drivers, the mapping is also screwed up with DVI."
-
Upgrade to the brand new 64-Bit GNU/Octave 8.1 is recommended for running Psychtoolbox 3.0.19.1 on Octave. Other Octave versions from the Octave 6.3/6.4 and 7.x series, or future Octave 8.x versions, may work as well, but no guarantees for anything other than Octave 8.1.
-
Psychtoolbox was built and lightly tested against Matlab R2022b.
-
Compatibility fixes for new GStreamer 1.22 releases.
Manually hide our DesktopWindowXamlSource (#15165)
As discussed in #6507
Newer builds of Windows do this automatically. However, this was spotted in the wild on 1.18. It's possible the threading changes created a situation where the OS-side fix no longer applied to us. So let's just do it manually. It doesn't have any side effects.
I saw this once on Win11, but couldn't repro it this morning when I tried to add this fix. I'm just gonna assume this worked, despite the fact that I can't repro it on win11 anymore.
closes #6507
See also #14957
WindowsXamlManager::XamlCore::InitializecallsConfigureCoreWindow, which creates aCoreWindowon the thread
Problem is, we're calling that on the main thread (which doesn't have any windows), and then eventually creating a
DesktopWindowXamlSourceon a second thread for the actual window
It's not that it "manages a window", it's that it "manages xaml on Windows OS". just use ICoreWindowInterop -- QI for ICoreWindowInterop and call get_WindowHandle.
Also see: * ICoreWindowInterop * WindowsXamlManager.InitializeForCurrentThread
- The source code in
onecoreuap\windows\dxaml\xcp\dxaml\lib\WindowsXamlManager_Partial.* - os.2020!6102020 which fixed MSFT:33498969, MSFT:27807465, MSFT:21854264
Remove 1080 artists from the DNP list.
Removed: lemonlycan, dylbun, fxscreamer, nt6969, lewdliege, reallyhighriolu, melbaka, saint_lum, kivaaa66, rukifox, kivalewds, kazoko_(artist), barachaser, shadowthelastalpha, teke, crittermatic, ribboncable, domasarts, ursine-major-ike, browneyedsaiyangirl, uncensoredhugs, skydiggitydive, takarachan, feelin_synful, ilovecosmo, biffbish, pulp_(artist), doxhun, cupsofjade, nicesweater, bluecat_friend, peshky, masuku, lunarfloral, kugi, sagejwood, sqrlyjack, maiteik, leozedi, popdroppy, mikakater, 413k_zzzz, puppyemonade, xanthewolf, joooji, nasusbot, shredded_wheat, dogsdontwipe, wonderwaffle93, gogoandyrobo, jezzlen, dourdoofus, vksuika, klotzzilla, cooperdooper, shadnaotomi, nudegote, sexygoatgod, humgeronimo, ladysophia, mrwhiskerz, cocicka, d-wop, charmerpie, yourdigimongirl, elvche, booponies, lulubelluleart, infinitedelusion, tankakuka, mensies, trunchbull, evian, sodasquids, telelewdz, lawlzy, tonio_(artist), xankragoc, horrificrabbits, sinfulgoatz, whippytail, malachimoet, catniplewds, cocaine_(artist), marshy_swtr, goldelope, chokodonkey, notkastar, sinnerscasino, sentharn, tealie, einin, freaks, angellsview3, arwenscoots, royalzbed, hellfurred, byrth, hexuru, devildjmachine, malerouille, donovallo, psychoninetales, vahldem_sol, nyanyakotarou, shupamikey, zyegnar, akytti, sootylion, kiva~, calmnivore, nexcoyotlgt, smoothsharb, sub-rosa, brismy, woodpeckertoons, xeshaire, suirano, mr_otter_breath, bassybefuddle, sweetishcyborg, skullwomb, steak_in_the_daylight, kittydogcrystal, aggrobadger, orbstuffed, fraichetaso, loonyleandra, bunsawce, schl4fmuetze, renkindle, psychovixen, bkmat55, fricken_stoat, w00my, haven_(artist), gipbandit, loki_the_vulpix, pixelyteskunk, erobos, bunchantress, uniquesoul1600, hirowithart, mikaemikae, ratbloke, pastellprinz, racktor, coillte, kazuk9, acidneko, josh_gong, yiyani, grayish, moblo, naoma-hiru, molish, sheyesh, st0pme, cawkbox, unclesam1776, fennecfuchs, inkpuni, pico_(artist), ruugiaruu, wispyparadox, funkybun, lewdoreocat, dogseesghosts, fauwcks, randy_entinger, trex_b6, yui-hii, runaris, rainbowpillars, ragonox, luxuria-sins, maxisb8, hiccyart, fancyfez, mesoplush, gammelgaedda, yi_feng, scpkid, goetiagoat, mabit, dischimera, dr.bubblebum, drakeraynier, rml, amawdz, mc_arts, freemau, armomen, orionfell, luriostragedy, dradmon, jesterghastly, gothgator, talentlesshack, foxryk, supertrashparty, marrowsoup, roserivy, vanzard, deepfriedlemons, pehkeshi, torotheking, harewithoutahat, lucciola, mr.lemur, lemonkyubun, cubble_chubb, arrjaysketch, pinklilim, jingo824, consciousafterdark, anti-cupid, phosaggro, dashboom, giftheck, birdrabbit, desertmotels, lv99perv, stellarfalcon, tasaeyeang, knotty, rockfall, aogirinaru, hikebu, pawpadcomrade, frengers, rikkitz, vappypaws, nukeleer, adevio, gummuru, sattytsukumo, bittenbats, whygena, ruzeb, hungothenomster, jads_l_rutan, gattonero2001, shawoo, francis_xie, angeltf, veevobyte, darkfool., huwon, tsukikibaokami, covepalms, nikunabe1989, emifern, pero3, tricksta, inkbeastart, grinn3r, holidaydipstick, odonata-nymph, binxxy_(artist), zazush-una, sodo_ad, loonanudes, kodardragon, flameydragwasp, ablimpfox, bakvissie, eccstasy, esealia, tailsrulz, dexxa, spiritto, vonepitaph, eddy-boy, saiyangoku4, gatomonlover, moonlit-comet, thehenwithatie, brienoir, tegucreative, wanisuke, pxlfur, anomyna, motsutambo, fepon, cyrogenic, fursuitchina, slates1n, depthsofthedrex, furrybob, davelievski, spacemaverick, fluff-kevlar, evenytron, 0eff0rt, gayclub, goatypie, nikoyishi, alishka, makeinu, jfetspeaks, cowbun, wyrwulf, thespiderbunny, fluffx, dragons-and-drawings, jcosneverexisted, emptyset, scoty_doodlerz, makinglemonade, ceramic_(artist), selirum, euskuuy, tsunkat, lustbubbles, appleseid, lewdtant, werewuffstuffer, odontoceti, iaido, turboranger_(artist), saca44, mr.shigglesworth, pyriax, raijikaruart, fox-pop, sirblythe_(artist), pastelarcadiaad, etherealarcadia, dracoarcadia, benjibat, sarvak, amethystbeetle, fnook_(artist), stationarrow, maim, rashkah, psy101, disappointedf0x, pointedfox, bundog, tailgrip, scalesforlife, hayleymulch, saphe, kiweevil, madakan, papyreit, rainiing, bitelickart, done0008, alec8ter, tentativelytoon, mikurulucky, killveous, fishhound, misshammer, yakushishi, pieraite, knives4cats, jalmu, quin-nsfw, zooptoon, ebonychimera, beaglebabe1, filthy-d, l-tech-e-coyote-l, anomalae, rakket, mcdutt, alcor90, sodongs, catcock, blickfen, akiiokai, possumkiddo, inkplasm, doubledeal_(artist), fuzzlesuits, chetchaka, raaazzledazzle, razferret, razbuckner, ikitsunyan, kclt, draco_(artist), gunther_silves, kkitten, singafurian, zandybutt, comfytail, crazyassbeethoven, dogburger, adalee, alirrasarts, blackmagemathos, terragon, leonois, solidpoint, cloudpie, rottenscoundrel, wings-and-strings, tomcoletti, pikajota, squeakcore, doubleclawed, ebonyplume, myznyx, zackary911, gaturo, xepher777, aimee-lesley-sim, spottedsqueak, fuhrawr, isaac_baranoff, starnina15, zestylemonss, meirdent, babymee, explicital, slyvern, karpet-shark, booghetti, zypter, adaptagx, opiodae, kiwipotato, murkbone, jonas, exed_eyes, shuryashish, mangobird, kurogi_fox_siv, snuddy, grimdank, nighteternal2469, dacad, superhypersonic2000_(artist), drako1997, verenpunainen_kuningatar, gurophilia, furrever, rdroid, smolrainbowgoat, ratte, urban-coyote, soulsplosion, cyaeon, elliotte-draws, whisperingfornothing, griz_urso, lepronasty, tears_of_soy, bunnielovesyou, paliken, spaceysoda, david_frangioso, cattinypaws, bobdude0, sprocket_(artist), sincerity_gender, marymanifold, turnipberry, asbel_lhant, klaide, rishi-chan, kircai, otto0ttsy, vaktus, beezlebumawoken, transdonaldduck, questly, pinkkatfox, goopomancer, xoel, allbadbadgers, sugarlesspaints, imafutureguitarhero, eiko_tsukida, tarot_(artist), pinuh, diero, dilarus, dfer32, mxwqtkl, electrycpynk, insomniacovrlrd, cewljoke, craziestrobo, anthrus1127, sunflowerbun, coyoteofthesands, masonparker, dottii, livesinabag, flam, toastedbiscuits, skycladfox, orenjisalmonpaw, nasty-fox, canadian_roses, crez, glorpofruithag, i_am_clover, johawk, lycosa, wizardlywalrusking, burgerkiss, kielseki, whisperfoot, oksara, olly, fetchmonkey, rottingichor, heathenfang, bikomation, phox_(artist), acedetrap, hedonisticvows, deersun, skittleytwix, jinxit, jtp-remart, cocaine-leopard, amarl_krieger, nakoo, leoian_(artist), amyth, nogu-art, bluhcat, vulpes_helios, licos, taurika, papilrux, pophopper, ebnet, apis_(artist), glenthefossa, raitime, sashabelle, puddingpaw, mercurial64, elricmysteryshifter, puptaire, anojaa, candychameleon, spice5400, nickshutter, rem, reiishn, sandybuny, 1oi, crunchobar, dante_yun, pherion, saintxd, rawbelr, mithaa, asmartist, pannekoeke, jotun22, iguky-neky, ahnik, thatvondude, kelevtov., fishwrappe, animal_shapes, oouna, princess_rei, blitzdrachin, jesterdk, watermelon_(artist), amara_lemur, lady_kurai, giantmilkdud, nostars, koili, abananaman, heddy, slobstash, terian, teranen, nexii, parabellux, tom_fischbach, reddacted, tojo_the_thief, proximiter, mmuted, irootie, icyshibe, quetzalcoatl_(artist), lamm, shayshay~, hettie, chutzpaah, jacob_lhh3, carpetwurm, draekos, fatdingleberry_(artist), nooplip, pandasayori, numberxxxvi, bc92, silvixen, jungabeast, phoenixazrael, krazykurt, tape_(artist), iipaw, volvokun, hamstergirlthehamster, fallen_(artist), morkovjpn, wolfirry, slimedrops, rubisdrake, shortconcepts, ahdadah, chubbuppy, dreadcaptain, duckdraw, mehndix, pomander, wolfcha, evillabrat, henzolin, loupgarou, empa, diokhan, kpsketches, raysofsunshine, slash0x, kriticalerror, gallivant_crow, nyaroma, caindra, petit-bambi, thatblackcopfromdawnofthedead, dreamertooth, tofu93, ragnarokdragon, saucy, kidakins, kippy, swizzlestix, brilyeon, caste_(artist), tsukaui, saebira, ozzybae, boo-rad13y, sammythetanuki, vuurren, sinistervibe, rem289, shroompunk, samkin, cieldoberman, g0966, crazedg, gaoru, lpawz, enjoipandas, renthedragon, emeritus_terciel, xouual, tehcutepyro, anon232, grimmgrey, counterserum, knottykitten, crybleat, octopoodle, ker0ker0_(artist), xnirox, necrosquelch, ivenvorry, pkuai, mikefur, mattsykun, lilithveritas, bloodhound_omega, ogaraorcynder, rhos, kehei, aw0, apes, nyhgault, qualzar, licentuouslamb, reggaecyp, cynderplayer, vilegrim, redacteur, jimbohusky, lacrimale, pulsar, growlybeast, coreytwc_(artist), naoki_wolf, iceagechippies, alfierubuncle, cbee, acidic, louiefurrywolfy, bweezy, fluffernubber, koriaris, serena_valentine, tacoyaki, fullheroo, limlam, harmoniousrain, zotnamotgrim, xx_g.u.n_xx, carm, lustylamb, dragonvortex, crowchild, dragoneer, lumi_(artist), phi, lexathefox, tanookicatoon, thunper, korram, redwolfofwind, ipipo, teckworks, abobarseem, doopcity, xepheriah, diablo_en_musica_92, doncoon_(artist), digitaldomain123, belayalapa, delkon, connisaur, jasonafex, kabier, rohly, vcr-wolfe, steve_gallacci, hologram_(artist), irene_(artist), piumartiglio, sumat, kingofmaggots, oha, featheredclaw, snuddi, mentalo, ourflatcoat, da-fuze, herr_aardy, discoverychannel, azorart, nemomein, latex_(artist), afterdarkie, 7mii, draco_fenris, blown-ego, sissyskunk_(artist), chucktheskunk_(artist), oakspirit, brokenlynx21, nickswift, butter_bat, ben_hickling, bluehunter, soyuz, sorimori, blackbearcj, ficus, crimes, eifie, soundwavepie, besonik, greyskee, alekksandar, bluetigress, nereza, kalvince, thelabtwins, the_lynox, galaxyoron, moondevourer, evov1, enjambre, seph_ebonblade, prototypebasilisk, accell, myakoda, merenhor, muramuri, derfuhrer, moltengoldart, cchipppo, tetrapoda, omochi_(inkbunny), popsmasterson, nikinazu, raevee, wyntersun, ribboners, c4camel, shysketch, deishido, arconos, melvismd, taihab, cobalt_snow, flak_wizard, paddington_and_company_limited, dangerdoberman, inprogresspokemon, whitemantis, naexus, datsexylemur, polywomple, marilimmy, ryan_rabbat, krimrath, yoshitura, maplecookies, aurelleaheverfree, puppercase, spino, palcomix, bbmbbf, lilithofglace, frisket17, myloveless, grau_(artist), aduleon, sexbad, mearcu, murcifer, citrusdicks, hessonite, sokalo, kittehmei, puccaruu, yuurikin, kurikia, the_cherret_awaits, rapps, maxtwenty, bigbrownorc, santanni, twistedtemptation, nikita-the-stag, liz_art, camcartoonfanatic, singlerider4, beanbat, forge_(artist), hoshime, yamamoto, eviljake2, oriole_(artist), inkblooded, alefwdog, herisheft, disparitybit, samagthrav2, battle_franky, taesolieroy, wolftacos, anixis, spazzticglitch, pirun, swampstomper, morbi, mittsies, blondevelvet, kadath, danza, shinxiolu, littlefreckles, grumpyvulpix, xopachi, gonenannurs, floravola, heartcollar, metz, ranard_lightningfall, frots, curtsibling, vilani, inkydemon, sprinkle-butt, airguitar, anhes, jace_(artist), kaji_(artist), nimrais_(artist), kyoushiro, venerit, lunaselenewolfe, tsareia, violentanxiety, kk-furryworks, cobalta, mickeyila, akuva, rairai, backlash91, sanae, fishbones_(artist), itoril, littlemiu, zeara, darkrokkuman_(artist), peony, helical, donro, agalamt, inanna-nakano, aniutqa, kraest, audiovideomeow, silverbobcat, erithacuscreations, mattartist25, yasminachan, jagzcat, ohmuu, roum, sefeiren, sesameseedbun, noben, aquatheohiokitty, mewyfox, ilgrigio, leoian, vixendra, van_weasel, keihound, zoey03, hardblush, jay_naylor, frisky_ferals, slipshine, rubyrebirth, oze, neogeen, omegaltd, themadcatter, kamicheetah, ookamithewolf1, rabbit_valley, purplekecleon, ollieosa, jayfiregrowlithe, ensayne, bazaarbobby, scappo, dogsoul, poonani, paddercat, eltonpot, ebonyleopard, strype, cbh, mithril07, bicdente, unpeeledwasp, versiris, pitkin, mikachu_tuhonen, lilhoneypup, ladyshinwa, bad-collie, buizilla, foxxian, inert-ren, okamiterasu, mrawl, sammy_stowes, jameless, jooshster, lemoncore, xainy, strider-orion, silitha, spacepoptart, myuinhiding, sweetpinkpetals, sephygoth, edensky, ka, cigarscigarettes, tani_da_real, leatherruffian, hahul, cheezyweapon, reizakirga, leefuu, tanyafoxy, peyo, sweatshirt_(artist), adiago, timelesserror, jollyjack, kahmari, madhattermonster, omnoproxyl337, greykitty, thekitty, mattaku_shinzu, fortuna, fallenarts, ammako, sciggles, atlasfield, sheepdust, lumaberry, tktktk, uzai, aku_tojyo, sixthleafclover, gardelius, squeedgemonster, max-dragon, baka_sukonku, ferniio, jennadelle, ixerin, jaleo, luvythicus, tatious, nekomata_neko, zody, binky, sidian, kii-kitsune, kiirei, spookeedoo, angel27, msrah_(artist), nazuu-m0nster, lunacatta, kululu-xiao, kipcha, fluffball, reptilecynrik, redadillio, zerwolf, kylontario, liz_day, nightweaver, egophiliac, doffa, dipper, kefkafloyd, melo666, sonicdash, sugarpoultry, olven, theramjing, softpaw, xiraco, unicornspirit, tinintri, thornwolf, thaily, tamen, sharue, shadowsani, rikutida, paolo, kriscrash, kaemantis, frogsbreath, tailheat, sexyfur, jeremy_bernal
Add syntax highlighting for roles
This required relatively deep changes to the Java TextMate grammar. The overall experience was quite painful, as the rules of the Java grammar are not written in a localized/modular way (e.g., the rule "all-types" tries to detect any type, but abuses lookahead and lookbehind to detect when a parameter identifier follows the type, instead of leaving this to a different rule that would parse a parameter list).
A couple of notes:
- Lookahead and lookbehind are essential for inspecting the context and making the correct rules fire. TextMate's features such as begin/end allow us to capture most of the recursive context-free nature of the underlying language (but almost always fall short in one way or another, which is frustrating).
- The original grammar relies on all Java types starting with an uppercase letter, and variables/methods with a lowercase one. Without this constraint, which matches the Java style convention, there would be no way to determine whether a token is a variable or a type (e.g. expressions such as "myVariable" vs. "MyType.myMethod()").
- We added the "roles" rule, along with modifying a lot of the existing rules to now detect the role syntax.
- We made "all-types" more modular. The grammar in general assumes that all types begin with an uppercase letter. Although
- We replaced all "object-types-inherited" with "object-types".
Improves the grammar, functionality, and code quality of set declarations (#776)
- Makes Consume array overload return the tokentype it found
Plus adds some extra comments, in my crusade to comment more things.
EDIT: hate you Github Desktop
- Removes MultipleVarDec..., replaces with Aggregate generic
Removes DMASTProcStatementMultipleVarDeclarations, replaces with DMASTAggregate<>.
DMASTAggregate now has the generic-ified responsibility of being a statement which is actually an aggregate of several statements, all of the same type.
The point of this is so that this aggregation behaviour can also be used for set declaration blocks (and maybe other stuff if we find other uses, I dunno)
- Adds some helpful ctors for DMASTProcBlockInner
There's a lot of repetitive empty or near-empty array inits at the caller side of some of these constructions, so I went ahead and moved those into the ctor. Also allows for a minor optimization (preferring using Array.Empty<> instead of constructing empty arrays).
- Improves SetStatement grammar, function & quality
(If any of you demand I insert the oxford comma into the commit header I am leaving 5ever 😡 )
This commit does several things in one fell swoop:
- Set statements now accept blocking, commas, bracing, all the good stuff that var declarations do
- Blocks now very consistently evaluate their SetStatements first and foremost, before anything else, in a way that makes sense
- Use of the 'in' keyword is now properly prohibited for all set use cases except 'src'
- 'src' now properly gives an unimplemented warning
Also in this commit is a bunch of random autodoc added to things that I looked at or touched over the course of writing this commit. 😇
- Implements cursed parity behaviour for non-const set statements
AFAIK, in BYOND, the previous set statement value is used to prop-up one that has a non-constant right-hand side. So I guess we have that behaviour available, now. 😅
EDIT: Fixed behaviour in the didError case, minor formatting fixes
- Style fix, replaces several "\n{" with "{\n"
Most of these were my fault. Not all of them though. :^)
- Does the Wixoa reviews, adds EmptyBlock pragma error
As a byproduct of doing the reviews, I have accidentally added empty block detection for several (although perhaps not most) loops and blocks available in OD.
-
Brace style fixes
-
Does more Wixoa reviews, generalizes EmptyBlock emission
Note that we do not, as of yet, emit this warning for empty procs. This is because:
- our own DMStandard has several empty procs (usually because they are unimplemented or useless, like the BYOND Hub interface procs)
- Users may sometimes define an empty proc, intentionally, to act as an abstract virtual that child types can define in their own way.
We can revisit the problem later, I'm just trying to get my PR greenlit.
- Adds test for EmptyBlock pragma emission
Co-authored-by: wixoa [email protected]
Add syntax highlighting for roles
This required relatively deep changes to the Java TextMate grammar. The overall experience was quite painful, as the rules of the Java grammar are not written in a localized/modular way (e.g., the rule "all-types" tries to detect any type, but abuses lookahead and lookbehind to detect when a parameter identifier follows the type, instead of leaving this to a different rule that would parse a parameter list).
A couple of general notes:
- Lookahead and lookbehind are essential for inspecting the context and making the correct rules fire. TextMate's features such as begin/end allow us to capture most of the recursive context-free nature of the underlying language (but almost always fall short in one way or another, which is frustrating).
- The original grammar relies on all Java types starting with an uppercase letter, and variables/methods with a lowercase one. Without this constraint, which matches the Java style convention, there would be no way to determine whether a token is a variable or a type (e.g. expressions such as "myVariable" vs. "MyType.myMethod()").
A summary of the changes:
- We added the "roles" rule, along with modifying a lot of the existing rules to now detect the role syntax.
- We made "all-types" more modular and moved its parameter-detecting behavior into "parameters".
- The "variables" and "methods" rules required special care in order for the parentheses in role syntax not to be confused for a method definition.
- We made "generics" a bit simpler and more robust.
- We replaced all "object-types-inherited" with "object-types".
Code of Conduct ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. ## Our Standards Examples of behavior that contributes to creating a positive environment include: - Using welcoming and inclusive language - Being respectful of differing viewpoints and experiences - Gracefully accepting constructive criticism - Focusing on what is best for the community - Showing empathy towards other community members Examples of unacceptable behavior by participants include: - The use of sexualized language or imagery and unwelcome sexual attention or advances - Trolling, insulting/derogatory comments, and personal or political attacks - Public or private harassment - Publishing others' private information, such as a physical or electronic address, without explicit permission - Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. ## Scope This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [INSERT EMAIL ADDRESS]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. ## Attribution This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Add syntax highlighting for roles
This required relatively deep changes to the Java TextMate grammar. The overall experience was quite painful, as the rules of the Java grammar are not written in a localized/modular way (e.g., the rule "all-types" tries to detect any type, but abuses lookahead and lookbehind to detect whether a parameter identifier follows the type, instead of leaving this to the rule for parsing a parameter list).
A couple of general notes:
- Lookahead and lookbehind are essential for inspecting the context and making the correct rules fire. TextMate's features such as begin/end allow us to capture most of the recursive context-free nature of the underlying language (but almost always fall short in one way or another, which is frustrating).
- The original grammar relies on all Java types starting with an uppercase letter, and variables/methods with a lowercase one. Without this constraint, which matches the Java style convention, there would be no way to determine whether a token is a variable or a type (e.g. expressions such as "myVariable" vs. "MyType.myMethod()").
A summary of the changes:
- We added the "roles" rule, along with modifying a lot of the existing rules to now detect the role syntax.
- We made "all-types" more modular and moved its parameter-detecting behavior into "parameters".
- The "variables" and "methods" rules required special care in order for the parentheses in role syntax not to be confused for a method definition.
- We made "generics" a bit simpler and more robust.
- We replaced all "object-types-inherited" with "object-types".
Fix MGOAL_FIND_ITEM_GROUP, fix up some code (#2546)
- Reorganize
Code still sucks. In particular recruit_class doesn't compare properly with npc->my_class so MGOAL_RECRUIT_NPC_CLASS fails horribly even if you fix up that area of code to it actually points to type->recruit_class instead of recruit_class
For that matter mission has a select copy of several mission type defs and I can only assume this is due to legacy fuckery.
- Fix mission.cpp
Now will only allow you to select items if you have enough of them, and will only consume the necessary amount.
Added documentation for MGOAL_FIND_ITEM_GROUP
Thank god this wasn't too much work.
Updating: 4/14/2023 9:00:00 PM
- Added: Curiously Confused (https://ussamaazam.me/thoughts/why-1000000007)
- Added: Handling fraud orders in Shopify when the fraudsters won't quit (https://www.mitchjohn.dev/articles/handling-shopify-fraud-orders)
- Added: My Thoughts on ChatGPT - Cal Newport (https://calnewport.com/my-thoughts-on-chatgpt/)
- Added: Emacs as a Shell (https://d-s.sh/2023/emacs-as-a-shell/)
- Added: Prompt Engineering vs. Blind Prompting (https://mitchellh.com/writing/prompt-engineering-vs-blind-prompting)
- Added: 3 Scalable Next.js Architecture Boilerplate (https://blog.imam.dev/post/3-scalable-nextjs-architecture-boilerplate)
- Added: I Think I Found a Privacy Exploit in ChatGPT (https://tane.dev/2023/04/i-think-i-found-a-privacy-exploit-in-chatgpt/)
- Added: An Over-Engineered Travel Blog (https://www.kevinhughes.ca/blog/an-over-engineered-travel-blog)
- Added: LLM Programming Loops: Giving the Model an IDE (https://christopherwolfram.com/projects/llm-programming/)
- Added: Why I quit being a tech "influencer" | Blog | Jack Domleo - Frontend & UX Developer (https://jackdomleo.dev/blog/2023/why-i-quit-being-a-tech-influencer/)
- Added: Jeremy A Boyd | Sunsetting HN Notify (https://jeremyaboyd.com/post/sunsetting-hn-notify)
- Added: Why Poland matters (https://www.thepathnottaken.net/p/why-poland-matters)
- Added: Entity-Based Reinforcement Learning (https://clemenswinter.com/2023/04/14/entity-based-reinforcement-learning/)
- Added: Why writers use platforms (https://ham.onl/why-writer-platforms)
- Added: The burden of complexity (https://thomasvilhena.com/2023/04/the-burden-of-complexity)
- Added: Building the Linux kernel in under 10 seconds with Firebuild - Obsessed with reality (https://balintreczey.hu/blog/building-the-linux-kernel-under-10-seconds-with-firebuild/)
Generation took: 00:07:28.3651486 Maintenance update - cleaning up homepage and feed
Imports and Contraband: Different! Cargo crates without locks! MEAT! (#74490)
This category is explicitly the non-departmental category beyond simply having a Misc category. It is meant for material that nobody is meant to be buying for their departments, and mostly for the odd-ball crates that might show up. It also allows us to maintain contraband as exactly that; contraband that the departments shouldn't have access too whatsoever. If someone is buying from this category, they probably intend to be a cheeky fuck.
The New Changes
MEAT: MEAT (meat backpack you can eat)
MEAT
Duct Spiders: They're adorable and cause a mess, but that doesn't stop Nanotrasen from importing them from the Australicus sector to your station!
Stack of 50 Bamboo Cuttings: Pretty expensive and kind of a premium. Allows for those people looking to make bamboo decorations without hoping botany exists, and are at least willing to pay. Also lets them make horribly dangerous stuff with bamboo, of course.
A Single Sheet of Bananium: The problems this will cause I think speak for themselves. (mostly due to a clown fruitlessly attempting to make something actually disruptive while bankrupting cargo)
Natural Fish Bait: It isn't cheating, it's homemade. (Really good bait but expensive and obviously drugs)
A dumpster...: A corpse in a dumpster, doesn't get more complicated than that. Useful for corpse reasons.
Made using some code I borrowed from over here! lizardqueenlexi/orbstation#354
Foam Force Pistols: Same as it ever was with a price reduction. I brought it down because riot darts are like 8 bullets a clip, and do less damage than a disabler using riot darts. It feels like a sidegrade weapon, and even if it technically is a ballistic weapon, it...isn't that strong. I think this is pretty safe.
Definitely Not a Duct Spider: It's actually a giant spider in a box. If you want to waste cargo's money while also sending them a mess to deal with, this is the crate for you.
Russian Surplus Military Gear Crate: I took this opportunity to futz with boltaction rifles. There are two kinds of mosin nagant you can get in this crate. One of them is the good kind (no jamming). The other is the shit kind (yes jamming), but you get more of them. You can get the good ammo, or you can get the shit ammo. You'll have to pick through it a lot more carefully to make sure you know which ones you've received. Since this dilutes the pool even further, getting a good number of mosins that aren't trash is even more expensive, and even if you do get mosins at all, you might still only get the bad ammunition that doesn't work against actual human threats as well. It also now cannot be purchased through the security cargo supply console, and as to why they could in the first place baffles me. Doesn't have a lock anymore because...it's contraband? Who is locking this stuff?
Side note: You can make surplus 7.62 in the autolathe as well. It is not very good except to fight fauna or naked assistants.
Side Side note: I've killed off the shitty brand_new subtype and brought peace once more to this land.
NULL_ENTRY: A journal that suggests how to make a...very interesting weapon. The Regal Condor. Kind of an evolution on some other ideas I've had over the years. This one is basically a secret weapon with a few hurdles to jump through. Very lethal. Very expensive.
Side note: For reference, it's effectively 19 TC worth of gear to make, but there does exist some methods to acquire this more cheaply if you can get some bits and pieces from world spawns. Given it requires you to get some pieces of equipment that might require additional purchases of contraband, and getting into the captain's office to loot a specific piece of clothing, the stakes more than make up for the effectiveness.
Smuggled WT-550 Autorifle Crate: This is basically the same, but you might have noticed had you recently attempted, like me, to buy these when you emagged them using a personal account and discovered a tragic oversight. You couldn't, because they still needed armory access. This removes that access, because you've already gone to the effort of getting your hands on an illicit firearm through cargo, and if they techs somehow miss the fact that you've purchased a WT-550...all the better for you!
Smuggled WT-550 Ammo Crate: Includes AP and Incendiary!
Side note: You can get WT-550 ammo again via the Illegal Technology node.
Shocktrooper: Replaces the Special Ops crate. Contains a box of EMPs, smoke grenades, a couple of gluon grenades and a couple of frag grenades. Funsies.
Special Ops: The NEW Special Ops crate. Contains a chameleon mask, jumpsuit and agent card. And a knife.
Side note: This is what appears in some cargo loan events.
Refurbished Mosin Nagant Crate: The actual good mosin nagants. There are 6 of them. But they don't come with spare ammo. Hand them out to your techs!
- MEAT crate - Standard
- Duct Spider crate - Standard
- Giant Hostile Spider crate - Contraband
- 50 sheets of Bamboo crate - Standard
- A single sheet of bananium crate - Standard
- Natural (drugs) fish bait - Standard
- Dumpster with a corpse in it - Standard
- Shocktrooper crate (Grenades) - Emag
- Special Ops crate (Disguise) - Emag - Appears in some cargo loan events
- Refurbished Mosin Nagant crate - Emag
- Regal Condor construction journal (NULL_ENTRY) - Emag
- Foam Force Pistols (cheaper) - Contraband
- Russian Surplus Crate (less reliable, can't be bought by security console) - Contraband
- WT-550 crate (more obtainable via personal accounts, thus incriminating, not armory locked) - Emag
- WT-550 ammo (includes incendiary and AP) - Emag
- Foam Force Crate
- Cosa Nostra Crate
- Black Market LTSRBT
- 'Contraband' Crate
- Biker Gang Crate
- You can print Surplus 7.62 (same as normal 7.62 but it sucks against armor) from hacked autolathes.
- You can get WT-550 ammo from illegal tech.
- Removes the redundant Brand New Mosin subtype
- Fixes a potential exploit with jamming chance on Mosins.
I just think some of the magic of Cargo getting their hands on obviously dangerous equipment and either hording it for themselves or attempting to pawn it off was lost in recent times. A lot of this 'black market' gear, however, suddenly became openly available to the crew anyway. For free. Contraband crates and mafia crates could be purchased via the Service budget. Security could just stock up en masse on mosins through their console. And one fairly unfortunate consequence of a few recent changes has made it nearly impossible to actually get illicit gear in the first place, even if you did go to the effort of getting the money for it.
On top of this, most of cargo's goods are pretty safe purchases. There isn't much that would be considered 'actually a really bad idea to buy' other than maybe supermatter shards. I wouldn't mind there existing ways for someone to waste cargo's money while also causing them to have to clean up the mess.
🆑 balance: A significant overhaul of various illicit and dubiously legal goods and gadgets available via cargo. balance: Cargo now has an Import category for all non-departmental goods. (And black market goods) balance: Most contraband that already exists has been moved into Imports. adds: Includes several new imports of dubious quality. You get what you pay for. code: Removes the brand new mosin subtype as it is now defunct. fix: Fixes potentially exploitative code in the jamming proc. Cleans up that code while I'm at it. /🆑
Co-authored-by: Jacquerel [email protected] Co-authored-by: carlarctg [email protected]
[asset-reconciliation] Use source asset observations to inform when to kick off eager reconciliation (#13304)
We did a similar sort of thing for data time calculations.
Note the TODO. The material impact is the following. Imagine you have an
asset graph OS -> A -> B, where OS is an observable source asset.
- Your asset_selection for your sensor is just
B. OSis observed having version1, after which all downstreams are materialized in order.Ais manually materialized again (not pulling in any new data, as no version was updated).OSis observed, still having version1.
The sensor will see that A has a new materialization, but will
erroneously treat it as "unreconciled", as a new observation record has
come in after the latest materialization of A. This means that a
materialization of B will not be kicked off.
In a fun twist of fate, this is actually arguably desirable behavior, as
there really isn't a reason for B to be kicked off in this scenario.
However, we're kinda getting the right answer for the wrong reason, if
that makes sense. We don't factor this sort of versioning information
into other parts of the reconciliation logic, and the following sequence
of events would give us an unambiguously incorrect behavior:
OSis observed having version1, after which all downstreams are materialized in order.Ais manually materialized again (not pulling in any new data, as no version was updated).OSis observed, now having version2.Ais manually materialized again.OSis observed again, still having version2.
In this case, we get the same behavior (B not getting kicked off),
because there is an observation record after the most recent
materialization of A (this is the same reason as before).
In reality, we should search backwards for the FIRST occurrence of the current version, this was just a minor pain to implement in the time I have today.
DD updates (#2786)
DD hasn't been touched in a while, and is kind of bad against preds, tries to fix this to the best my my ability with the below changes.
- Makes the M1911 more accurate
- Makes DD armor cover arms and legs, improves its bullet and explosive resistance
- ERT Medical Pouch now contains the basic 3 injectors(bic, kelo, tram), an emergency injector, a splint, and a bandage
- DD now all have max endurance skill
- M60 is now full auto, does more damage, and is more accurate
- DD Minigun(ol painless) now has an integrated magharn
- M60 now has the same box changing mechanic that smartgun has.
- Adds 2 new guns(technically 1, or maybe 1.5), the XM177 and M16 Grenadier(an M16A1/2 with an M203 attached)
- Adds an M203 grenade launcher, single grenade, no IFF, high range with scope, only fits on M16 grenadier
- Adds 3 new impact grenade types, only DD have them currently.
- Adds HE impact grenade, impacts in a cone radius with an HE explosion.
- Adds an incendiary impact grenade, impacts in the same pattern as HIDP, napalm.
- Adds an impact buckshot grenade, pure vietnam vibes, shoots 10 bits of additional buckshot that also slow.
- DD now have MDs tuned to their own IFF.
- DD are now equipped with XM177s for the medic, Dutch, and flamethrower operator
- DD riflemen have a 60% chance for an M16A1, 30% chance for an M16 Grenadier, and 10% chance for an M60.
- Removes the M60 from black market
- Moves DD presets to their own standalone folder, and removes the /fun/ from their typepaths.
- Changes CLF crashed ship M60 to a MAR50
- Adds sprites for M203, XM177, M16 Grenadier
- DD spawn with a lucky pack and a zippo in their helmet.
Dutch's Dozen is a bit outdated, and light on content, gives them some love. Removes gear that doesn't fit in BM from BM, also I buffed the gear too so balance concerns.
- An unwielded rifle(M41A), had more accuracy than a wielded M1911, would do this for other pistols too but out of scope as DD only use M1911
- They were incredibly easy to kill via leg/arm aiming, as no armor, HPCs instakilled them(DD are default dishonorable), and FF did insane damage as they all had high AP 40 damage rifles.
- ERT medical pouch was worse than normal med-pouch, DD use this too.
- Was intended, survivor endurance skill nerf effected this too as the same define was used for both as a shortcut
- M60 underpreformed, makes it better.
- Dropping Ol' Painless over and over sucks.
- Unique realistic mechanic for the M60, makes it more interactive
- Unique guns, only DD get them, also the XM177 is my favorite gun of all time I love it 😊
- Unique UGL for M16 Grenadier, designed to work directly with the sprite, as its integrated and only fits on it.
- Grenades for DD to have a better chance against preds, riflemen have a 30% chance of spawning with M16 GL.
- Made for a stun, team gameplay for DD.
- Area denial.
- Vietnam Vibes, support tool cause it does jack shit damage.
- DD couldn't tell friend from foe
- (AWESOME) Carbine for Dutch, makes sense for the support and members of the team to have carbines instead of rifles
- Variance within DD team, all 3 of the guns are good, GL is a support tool, M60 as an ambush(also its The Pig), A1 is normal
- M60 doesn't fit thematically, and is too powerful.
- Easier access, they don't fit in the fun file
- Buffed M60, MAR50 fits more there anyway.
- Sprites for things I added.
- Its cool.
🆑 add: DD spawn with a lucky strike pack and a zippo in their helmet. add: M60 now has the box changing mechanic that smartgun has. add: Adds an M16 grenadier, with attached M203, also adds M203 grenade launcher and impact shells for it, only DD have it add: Adds a new M16 variant, the XM177E2 Carbine, only DD have it add: Dutch M16s now are marked as A1s, and use the preexisting M16A1 sprite instead. add: Dutch's Dozen are now equipped with an XM177 for Dutch, the medic, and the flamethrower operator add: Dutch's Dozen riflemen now have a 60% chance to have an M16A1, 30% chance for an M16 with M203 UGL, and 10% chance for an M60 GPMG del: M60 has been removed from the black market balance: DD minigun now has an integrated magharn. balance: M1911 is slightly more accurate. balance: ERT Medical Pouch now contains the 4 basic EZ injectors and a gauze. balance: DD armor now has a greater explosive protection and covers the arms and legs. balance: M60 is now full auto, does more damage, and is more accurate. code: Moved Dutch's Dozen presets to their own standalone folder spellcheck: DD spawn text now correctly says the Yautja mask is on Dutch's face. fix: DD Motion Detectors no longer pick themselves up. fix: DD now all have max endurance skill imageadd: Adds sprites for M203, M203 shells, XM177, and M16 Grenadier Variant maptweak: LV624 Crashed CLF ship insert M60 has been replaced with a MAR50 /🆑
Co-authored-by: Zonespace [email protected] Co-authored-by: morrowwolf [email protected]
Saloon rework (#1594)
Expands whitesands_surface_camp_saloon to cover a 30x30 footprint and
not be nearly as bad. The previous version had some really glaring
design flaws, like holes in the wall for a bar. On a planet with a
deadly atmosphere. Yeah. Also all the chairs faced the same direction.
You can see how it looks. It's not great.
Here's the new version
Ignore the patches of error, it's purple grass and doesn't display the
icon in sdmm for some reason.
The major changes are: Expanding the building's footprint out to 30x30 Moving the loot behind the building, but locking it behind a shovel of some sort (of which you can go through the ruin to get). Improving the loot a LITTLE
- The map loads although I still haven't managed to get it to load on the proper planet with the spawning verb
The old version was kinda bad. Between the clown and mime masks out front. The small footprint, and the free guns (also out front). This solves those issues kinda while making it bigger.
🆑 add: Camp_Saloon has been expanded, expect frontier luxuries if you find it! /🆑
Co-authored-by: spockye [email protected]
New Ruin: The Beach Town (#1572)
Adds a new beach ruin, the abandoned beachside town
The town is an mostly empty place formerly devoted to tourism and the beloved art of "chilling out". Facets of the life of its inhabitants before their disappearance included drinking, grilling, and swimming off the coast of their fairly large beach. Many interesting things happened on the boardwalk, and a landing pad was present to allow for small ships to dock inside the town.
The loot list is sparse here. I intend for this to mostly be a setpiece for roleplay instead of a loot pinata. There's a good selection of hydroponics seeds and gear, 2 full bar kits, basic kitchen equipment, an autolathe, a few PDAs, a lotta wood, and a jukebox. Also donuts.
- Ruin spawns, nothing is out of whack that shouldn't be.
Continues the trend of making planets more good by adding more content
🆑 add: An oddly empty town has been spotted on beach planets in the area. Check it out spacers. add: Random donut spawners, never eat the same donut two days in a row!
/:cl:
Signed-off-by: Bjarl [email protected]
SubShips attempt 2 (#1627)
Accidentally destroyed my old PR for this, #1573, by completely botching a merge from master to the point that it was easier to make a whole new fork than try to save it, so here we are again. Here's the original description:
Ports the parts of BeeStation/BeeStation-Hornet#7152 that adds the framework for ships to land on top of each other and not break everything. A ship can only land on another ship if there's an open docking port on the mothership that's large enough for the subship. Here's a video of it in action on a modified dwayne-class:
2022-10-12.20-15-03.mp4
This system should be able to handle just about any orientation of ships on top of each other, such as ships landed across areas, multiple ships landed on a single ship, a single ship landed on multiple ships, a ship that is only partially landed on another ship, a ship that is partially landed on a ship that's partially landed on another ship, and so on. Just make sure that you never try to land a ship on itself.
Something to note for this is that ships remember what's underneath them via baseturfs, and there's a hardcoded check that will cause errors if a baseturf list grows over 10 entries long. Because ship turfs have typically 1-3 baseturfs, after about 3 ships stacked on top of each other things will start to break.
You can also make maps with subships on them, to do this, follow these steps:
- make the subship as if it were a regular ship in its own map file
- create a new /datum/map_template/shuttle subtype that points to your subship map, these datums can be found in code/datums/shuttle.dm
- On your main ship, place "subship dock" landmark in turf where you want the bottomleft corner of the subship's bounding box to be, you can also use the offset_x and offset_y vars on the landmark to offset this corner if you need to place the landmark somewhere else.
- Set the "subship_template" var on the landmark to the path of your subship's map_template subtype
- Optionally change the dir on the landmark to rotate the subship. for reference, NORTH is no rotation, EAST is a 90 degree clockwise rotation, etc.
You can put the stationary docking port anywhere on your map, as long as it's on the ship. You can have its bounding box hang off the side of your ship, but please try to keep the entirety of its bounding box within the bounding box of map file, otherwise subships landing on your main ship might accidentally clip through structures nearby your mainship, including virtual z level borders.
- I affirm that I have tested all of my proposed changes and that any issues found during tested have been addressed.
Subships allow for many more creative designs and interesting dynamics between and within ships, especially when a crew may need or want to split its attention between multiple locations at the same time, or to make interactions between ships easier when you just need to land a smaller vessel inside of the other, cutting out the need to travel through space turfs to get between two ships.
🆑 add: Subships are now possible code: Lots of large changes to ship code /🆑
Merge pull request #1949 from ARF-SS13/I-hate-github-a-lot
Fuck you, Vertibird. Go where I put you
Fuck you, Vertibird. Go where I put you
You fucking animal of a thing
Sandboxels 1.8.1
HUGE SANDBOXELS UPDATE 1.8.1
Lightning Feeling evil? Summon hot, powerful bolts of lightning. Smite anything at your will, hot enough to incinerate or melt anything.
Bless Feeling merciful? Solve any problem with your omnipotent blessing. Cure disease, fight fires, undo your nuclear explosions.
There's More!
- Thunder Cloud
- God Ray
- Heat Ray
~ Reworked Vines
- Vines hang from ceilings and walls
- Vines spread naturally sideways, down, and on walls
- Rotten Cheese (Hidden)
- Herb
- Tea (Hidden)
- Rime (Hidden) ~ Improved load times 73 MORE CHANGES and 12 BUG FIXES: https://sandboxels.R74n.com/changelog.txt
PLAY NOW: https://sandboxels.R74n.com/
Checking in various improvements done in the last few evenings
Replace store_as_base with generated aggregate bases - better fix for #336, thanks @JohelEGP for the suggestion! This way we also don't need to obfuscate the name anywhere beyond the constructor(s), as the right member object name just enters the class's scope
If the user didn't write a constructor, provide a default constructor
If the user didn't write a 'that' constructor, suppress Cpp1's compiler-generated copying and assignment
Clean up emission of the just-mentioned generated/=deleted constructors, more naturally line up inside the class body following the indentation for other members that the original source code uses
Rename file load.h to io.h (file.h was another candidate), just because it has been bothering me for a year now that except for that one file all the headers were in natural alphabetical order by compilation phase... as of this commit we now have them all in alpha order and phase order: common.h -> io.h -> lex.h -> parse.h -> [*] -> sema.h -> cppfront.h
[*] coming next here: reflect.h, which will also be in both alpha order and compilation order
Guard out.construct with if constexpr in case the type is not copy assignable and that path is never requested
Rename cpp2::error to cpp2::error_entry to quiet a new(? why?) GCC message about shadowing the former name with parser::error... I get why the warning is there, but this is a slightly annoying warning to have to satisfy just to compile high-warning-clean on GCC... oh well
Change semantics of emitting .h2 files: In -p pure mode do the existing split of phases 0 and 1 into .h and phase 2 into a separate .hpp, but in mixed mode put all phases into the .h
Replaceable Traitor Uplinks (#74315)
Following from the suggestion in this hackmd with a few twists of my own, I have made a method for traitors to acquire a replacement traitor uplink that has its own set of flaws and limiters in order to prevent abuse.
The basic pitch is as follows, all traitors now start with a new, crafting recipe exclusive to them, it costs a teleport beacon, a bluespace crystal, and some iron and cable coil, and then allows them to build a static, dense machine that they can synchronize with, which allows the machine to know what signal it should be looking out for from the traitor.
The traitor then uses any radio, sets it to the frequency that has been added to their static antagonist ui, and then speaks their codeword, also in the ui, and then a few things happen.
Most obviously, they get a replacement uplink that is in the conspicuous shape of the nukie or lone op uplink. This uplink can be unlocked by speaking your replacement codeword to it again, it remembers your previous TC amount and locks all other uplinks associated with your uplink handler(they can then be unlocked as normal). It also destroys any other replacement uplinks associated with your uplink handler, which means you can never have more than one replacement uplink.
This means that if your uplink has been confiscated and you left it unlocked, if it hasn't been emptied out you can continue from where you were, and if you want to get back on the TC grind you won't lose the new TC to whoever stole your uplink. Of course, the new uplink can not be locked, so you have to be more careful with it or buy an uplink implant and destroy it. You can destroy your replacement uplink with a screwdriver right click, same for the machine.
Additionally, the Syndicate Uplink Beacon has another quirk to it, which is that the teleporter beacon used to create it is intact, which means people eagle eyed on the teleporter console could go find you, not to mention that if you use an existing teleporter beacon, someone might notice its gone missing...
oh also while making the replacement uplink i found a bug caused by a recent pr that broke debug uplinks due to them not having a purchase log. thats fixed too
It can be easy to lose your uplink, and as a traitor having your uplink confiscated, even if it is locked, feels really bad. While the old traitor objectives were added back to prog traitor to prevent situations where a confiscated uplink meant that you were completely aimless, I think that having a backup solution would be good for more inexperienced traitors or for ones who get unlucky.
Hopefully this is generally balanced well enough but there are a few levers that can be pulled, but overall I do think that making it so that traitors can always get a chance to get an uplink and do some objectives is good for the game. I like the idea of someone getting perma'd, someone breaks them out, they both craft a new uplink beacon, and then they go back and get the traitors old gear with stuff they got from the new uplink, I think that's a cool possibility to throw into the sandbox.
🆑 add: Added new syndicate uplink beacon and associated systems that allow you to get a replacement traitor uplink fix: Debug & nukie uplinks no longer runtime and work properly again /🆑
Moves revolution code of out of flash code, fixes April Fool conversion forcesay never working in any cirumstances (#74411)
-
Signallizes head revolutionary flash conversion code, moving it out of core flash code.
-
Removes "tacticool" flashing from head revs, but they can still convert from any direction
-
Fixes April Fools "You son of a bitch! I'm in" force say never working.
- Revs are muted on conversion so they couldn't talk.
- Fixed by only muting revs on non-holidays
- Cultists are unconscious on conversion so they couldn't talk
- Fixed by only unconscious-ing cultists on non-holidays
- Revs are muted on conversion so they couldn't talk.
-
Brainwash victims are more often than not unconscious / asleep so they couldn't talk - Just left this one.
-
Reduced the chance of them occurring and limits it to April Fools only
-
A 1% chance of the force says ocurring means they will happen pretty much once a week, given multiple rev / cult rounds happen every week and on average like, 20 people are converted. A little absurd, it's good that it never worked?
Antag code in core item code is bad
It's funny this meme has existed for like 2, 3 years now? No one's tested it, it's never worked
🆑 Melbert refactor: Removes Rev code from core flash code fix: Getting converted on April Fools now triggers the meme force say as always intended del: The meme force say can no longer trigger on any day (it didn't work before anyways) /🆑
IceBoxStation More Active Turf Fixes (#74474)
This didn't show up in my testing for #74410. I hate it here.
I am a monkey trapped next to a computer playing whackamole with this fucking chasms and active turfs. one day i will be free.
nothing that should concern players
3/3 client consumers streaming errors
Summary: This diff makes it so hh_client can consume streaming errors. It's gated under the JK that we're using for standalone IDE. That's because (1) I want streaming-errors to be a carrot that entices more people to test out standalone-ide, (2) the standalone-ide will be written solely to consume streaming errors, so the two go hand in hand, (3) I don't want to even have to test the correctness+behavior of produce_streaming_errors when there are lazy checks.
To opt in, people have to explicitly ask for streaming errors via this flag, every time they do a hh check at the CLI. (it's not pretty, but that's not my goal):
hh --config ide_standalone=true
Also, this only works if the server had earlier been started to produce streaming errors:
hh --config produce_streaming_errors=true
My further plan, to reduce the number of codepaths, is that eventually everything should use "errors.bin", even --json, even if it doesn't display the errors in streaming fashion. My motivation for this is just to reduce the number of different codepaths. I guess that --json would read from errors.bin all the way to the end before printing its output, and would internally handle "files have changed" by restarting its read on a new errors.bin. But that will be left for the distant future.
hh check --jsonwill use the existing error mechanism (which waits until it has a complete list of errors that encompasses all disk changes), while all other output formats will by default use streaming errors.- There might have to be some kind of override flag,
hh check --error-streaming false? But I believe there won't have to be: my research T147955071 indicates that everyone who doesn't use--jsonis content with streaming errors. Note that our existing json format isn't friendly to streaming, and most scripts/tools don't use incremental json parsers and hence wouldn't even benefit from them.
- There might have to be some kind of override flag,
- There are two new exit codes from hh_client that can be produced. This could be a breaking change if any tools did
hh checkand don't know how to deal with (say) files changing under their feet during the typecheck. Previously they would get answers only after the disk had stabilized. Now they will get an error message that they must recover from. My mitigation for this risk, as above, is I think almost all tools use--jsonand hence won't be getting streaming errors. I think only console users will get streaming errors.Typecheck_restarted"Files have changed. Please re-run hh" -- this is for when a typecheck got interrupted by something that caused it to be restarted. This is typical from watchman interrupts.Typecheck_abandoned"Hh_server has terminated. {Killed|Stopped}". This is for when the hh_server daemon gets killed mid-typecheck.
- It's imperative that when you type "hh" then you get errors that at minimum reflect all disk changes that happened prior to your invocation of "hh" (as to whether they reflect changes which happened since, that's impossible to know).
- This was true before (because "hh" causes serverMain to do a synchronous check with watchman before reporting answers; it does the synchronous check in serverNotifier.ml by sending "flush-request" over the subscription and waiting to hear "sync" response).
- It's still true now. The watchman sync is now performed in hh_client instead of hh_server, and it displays "hh_server is busy [watchman sync]" while doing it.
- The errors that get streamed are necessarily unsorted by filename. Ain't nothing we can do about that. (prior to streaming, they were sorted by filename).
There is a whole load of ceremony to do with what happens when you want to open errors.bin,
e.g. start the server if necessary, check for version mismatch, report failures to the user.
Concrete examples:
1. There is no server running. "hh check" must start up a server, before it can stream errors from it.
2. There is no server running, but our attempt to start the server failed, either
synchronously (e.g. we had `--autostart-server false`)
or asynchronously (e.g. saved-state failed to load).
"hh check" must detect that no streaming errors are forthcoming.
3. There is a server running, and it has already written errors.bin, but it is the wrong binary version.
"hh check" must cause it to shut down, and a new server start up, before it can stream errors.
4. There is an errors.bin from an existing server, and its typecheck started 20s ago, but moments
before "hh check" a file was changed on disk. "hh check" must detect this,
learn that it cannot use the existing errors.bin, and instead use the new errors.bin that will be forthcoming.
How this function fulfills those cases:
* It of course has to check whether files on disk have changed since this errors.bin was started.
It does this with a synchronous watchman query,
and displays "hh_server is busy [watchman sync]".
* If there is a fault like "errors.bin was started too long ago and files have changed
in the meantime" which can be rectified by waiting and trying again on the assumption
that a server is running and will pick up the changes, then this will wait and try
again indefinitely. It will display "hh_server is busy [hh_server sync]".
The parameter "already_checked_clock" indicates that we have already done a
(costly) watchman query for this clock, and will not do another watchman query until
we see a new errors.bin with a new clock.
* If there is a fault like "missing errors.bin" or "binary mismatch" which can
be rectified by connecting to the monitor+server, this will do so at most once
with the "connect_then_close" callback parameter, then resume for a suitable errors.bin
again with "hh_server is busy [hh_server sync]".
If it already tried once with no effect, then it will raise Exit_status.Exit_with.
This isn't my preferred implementation strategy!
- I don't like how the client will just "wait around indefinitely until a suitable errors.bin appears, on the assumption that hh_server will eventually detect disk changes. I don't like this because, if it never happens, we don't have a crisp callstack or failure event to log.
- I don't like how the client and server must duplicate the exact same logic for deciding whether file-changes are important. I don't like this because imagine if they disagree, and the client believes a new errors.bin+clock is needed and so waits for one, but the server doesn't believe it's needed.
What I'd like instead if there existed something like "hh sync" over ServerRpc or ClientConnect.connect, with the property that once it returns, then (1) the server guarantees to have started an errors.bin, (2) the server guarantees to have picked up all watchman changes that it deems fit. If we had this then the client would never need to wait indefinitely: if it ever needed to start the server then it'd do this sync and know that errors.bin must necessarily exist when the sync returns; if it ever was in doubt about the age of watchclock then it'd do this sync and know when it returns that the new errors.bin is recent enough.
I found it far too troublesome to implement that kind of "hh sync". This diff uses connect_then_close, which calls into ClientConnect.connect, but this has a much weaker guarantee. It only guarantees that the server is running. It doesn't guarantee that an errors.bin has been started, and it doesn't guarantee that the server has synced all changes so far. Why was a stronger sync too troublesome? It's because hh_server's logic for syncing is wrapped up in ServerMain.recheck_until_no_changes_left, and it's not easy to separate the "sync watchman " from the "complete the consequent typecheck".
This diff puts some "watchman since" code in clientCheckStatus.ml. That's clearly not where it truly belongs. The plan in T146551552 is to move us away from subscriptions like there are in watchman.ml, and towards synchronous queries.
I'd quite like to rename watchman.ml -> watchmanSubscription.ml, and create another file watchmanSync.ml which can be used by both server and client. But the code I wrote right now in clientCheckStatus.ml uses Lwt which can't be used in server. Therefore, I'll need to functorize over "promise", like is done in state_loader_futures.ml vs state_loader_lwt.ml. That will take a bit more work, so I've left it for the future. (ha ha). In the meantime, this diff leaves the code in clientCheckStatus.ml for now.
Reviewed By: CatherineGasnier
Differential Revision: D44159580
fbshipit-source-id: 0ddbc8596fdaf2d346653bcd6bb6858f0e74f011
Properly accounts for byond tick fuckery in runechat code (#74388)
Ok so like, the agreed upon assumption for "verb like code" (stuff that triggers when a client sents a network packet to the server), is it runs in verb time, that sliver of time between maptick and the start of the next tick. We thought MeasureText worked like this. It doesn't.
It will, occasionally, resume not during verb time but as a sleeping proc, at the start of the next tick. Before the MC has started working. This appears to only happen when the tick is already overloaded.
Unfortunately, it doesn't invoke after all sleeping procs as we were lead to believe, but just like, like any sleeping proc.
This means it fights with the mc for cpu time, and doesn't respect the TICK_CHECK macro we use to ensure this situation doesn't happen.
SOOO lets use a var off the MC instead, tracking when it last fired. We can use this in companion with TICK_CHECK to ensure verbs schedule properly if they invoke before the MC runs.
Hopefully this should fix 0 cpu when running at highpop
Thanks to Kylerace and MrStonedOne for suffering together with me on this, I hate this engine.
End of Mapping March (Thanks to everyone who contributed, you're amazing!!!) (#74417)
Removes the special mapping template. We got a really good turnout this year! Will start counting ckeys and all that.
If it was opened during march, you'll get your token, don't worry