mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-04-21 19:54:15 +01:00
088409bbe376a7adcd4d1fb747cf4a5e4f257c5b
2241 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
SmArtKar
|
d4ac95a0e1 |
Nobody expects the span inquisition: replaces most <span>s with macros (#86798)
## About The Pull Request 123 changed files and multiple crashes after writing broken regex, I replaced most remains of direct spans with macros. This cleans up the code and makes it easier to work with in general, see justification for the original PR. I also fixed a bunch of broken and/or unclosed spans here too. I intentionally avoided replacing spans with multiple classes (in most cases) and spans in the middle of strings as it would impact readability (in my opinion at least) and could be done later if required. ## Why It's Good For The Game Cleaner code, actually using our macros, fixes borked HTML in some places. See original PR. ## Changelog Nothing player-facing |
||
grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
san7890
|
a4328ae1f9 |
Audits tgui_input_text() for length issues (#86741)
Fixes #86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(
|
||
Ghom
|
5409570e01 |
Upgrades GODMODE from a flag to a trait. (#86596)
## About The Pull Request GODMODE has a lot of sources that toggle it. From admin-stuff to status effects, components, actions and mobs which are supposed to be invincible. It's better off as a trait than a flag, so we can manage these sources. ## Why It's Good For The Game See above. ## Changelog 🆑 admin: godmode is now a datum trait instead of a bitflag. This means the process for toggling it is a little different now. /🆑 |
||
Timberpoes
|
6808a082eb |
Assorted changes to job assignment code and logging. Runtime free, guaranteed or your money back. Price: $£0. (#85947)
## About The Previous Pull Request
#85308 reverted by #85929
~~Causes the round to not start when a player isn't eligible for any
jobs at a specific priority level due to runtimes trying to `pick()`
from an empty list aborting the entire job assignment stack.~~
(Fixed???? by
|
||
Y0SH1M4S73R
|
7b46cef07c |
Fixes runtimes caused by dreamluau's absence (#86171)
## About The Pull Request Currently, if dreamluau is absent (which it might be on linux instances that don't automatically download it), every `call_ext` call runtimes, crashing the calling proc. This fixes that by using a flag that skips calling `call_ext` if unset. ## Why It's Good For The Game Apparently this could really bork the garbage collection subsystem, so fixing it is a really good idea. ## Changelog Does this even count as a player-facing change? |
||
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
klorpa
|
e1bf793264 |
Spelling and Grammar Fixes (#86022)
## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game ## Changelog 🆑 spellcheck: fixed a few typos /🆑 |
||
Rhials
|
d87afa9433 |
ERTs can now be summoned as a set species (#85651)
## About The Pull Request This repurposes the redundant `mobtype` var on the ERT datum. Originally used to store the typepath for what mob the ERT would spawn (which was unchanged on any of the other datums), it is now null by default and can be modified in the summon_ert verb menu. If left blank, it will default to humans, but it can be set to any humanoid species.  ## Why It's Good For The Game As stated previously, mobtype was redundant, as it would either always spawn humans (human authority would immediately humanize the spawned mob) or be overridden by the preferences of the player being spawned. Rather than making it a hardcoded value and deleting the var, I've elected to repurpose it for further ERT customization. Moth ERT, Moth ERT, Moth ERT. ## Changelog 🆑 Rhials admin: You can now choose the humanoid species spawned by an ERT summon in the summon menu. /🆑 |
||
Time-Green
|
095f7e3b70 |
Death of mutant bodyparts AND external organs (#85137)
## About The Pull Request Removes mutant bodyparts and external organs from the game completely Digitgrade behaviour was mutant bodypart for no reason Cat ears now work with the bodyparts overlay system, same as all the other external organs (since all their behaviour is now just on /organ It doesn't remove all the /external types, but moves all behaviour to /organ. I'll follow up with a PR wiping all the /external organ types, but it's just conflict heaven so not this PR I've also streamlined a lot of duplicate/weird species regeneration code Melbert did the same PR as well but due to a lack of time (?) I have absorbed his PR to double nuke mutant bodyparts ## Why It's Good For The Game Frees us from the chain of unmodular code, and kills my greatest nemesis (after the shuttle meteor murder bug) ## Changelog 🆑 Time-Green and MrMelbert Refactor: External organ behaviour has been moved to /organ, ears now use the same system as the other organs Refactor: Mutant bodyparts are dead! This likely does not mean much to the average person but it's very dear to me code: Improves digitgrade handling in preference code /🆑 I have absorbed #85126, using Melberts code to improve and add some missing changes. Mainly improving the functioning of preferences and digitgrade legs. I didn't take over the hairstyle improvements. --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
Lucy
|
368ca25e6b |
Use yt-dlp by default instead of youtube-dl (#85953)
## About The Pull Request This replaces references to youtube-dl in the config, pre-compile script, and error messages with yt-dlp. also wow yt-dlp seems like gibberish after seeing it so much lol ## Why It's Good For The Game yt-dlp is more reliable and updated more frequently than youtube-dl, and works as a drop-in replacement for the purposes of Play-Internet-Sound. ## Changelog No player-facing changes |
||
John Willard
|
1880003270 |
Reworks silicon/ai access checking & fixes some ui_act's (#84964)
## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑 |
||
|
Rhials
|
00a0d0b890 |
Special radio channels now use bitflags instead of individual vars (#85150)
## About The Pull Request Radios/encryption keys now use a `RADIO_SPECIAL_XXXXX` bitflag for behaviors related to "special" radio channels (Binary, Centcom, Syndie). I decided to do this because I wanted to add a radio channel for pirates and hunters (hence the branch name), but it felt weird adding two more variables. The more I look at the changes I've made here the more I realize that the effort was probably not worth the utility but whatever. This also subtypes some varedited intercoms and makes them their own objects. ## Why It's Good For The Game Compresses a whopping three (3!) variables into a single one. Easier to scale (I guess?). I felt like adding a fourth/fifth variable and just moving on with the original project, but decided "lets do this the unnecessarily hard way instead". ## Changelog 🆑 Rhials code: Radios/encryption keys now use a single variable for "special" frequencies. Please report if you experience any strangeness with accessing/being unable to access the Centcom, Syndicate, or Cyborg radio. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
Kyle Spier-Swenson
|
4d1639b04c |
Revert "Assorted changes to job assignment code and logging." (#85929)
Reverts tgstation/tgstation#85308  |
||
|
Timberpoes
|
1eef540054 |
Assorted changes to job assignment code and logging. (#85308)
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
|
||
|
SmArtKar
|
67387a1d5c |
Fixes multiple admin verbs using incorrect search, updates them to TGUI (#85744)
## About The Pull Request Closes #85740 BYOND doesn't support this sort of type picking, these are the 3 last admin verbs to use it ## Changelog 🆑 fix: Fixed nuke toggle, smite and machine upgrade admin verbs using incorrect sorting admin: Updated nuke toggle, smite and machine upgrade admin verbs to use TGUI /🆑 |
||
|
Rhials
|
e220a57934 |
ERTs no longer humanize plasmamen (#85631)
## About The Pull Request This one's a bit complex, stay with me here. So, the ERT system has support for enforcing all ERT members to be human, or if they will be spawned as their selected species.  This addresses plasmamen by including plasmamen outfits that are equipped prior to the actual outfit they're given, added in #56987.  Despite this support, plasmamen never spawn as plasmamen, as they are missing the `ERT_SPAWN` changeflag. This is because as the body is created, the ERT spawning system human-ifies them to prevent them from exploding. This system existed in place prior to #56987, but it didn't work.  Fortunately(?) #58870 fixed it, but in doing so nullified the work done in #56987 as plasmamen could no longer be plasmamen when the `plasmaman_outfit` check was reached. They had already become human. If this reads a bit weirdly its because this was originally just going to be an issue report. I finished writing it and decided "well why not just fix it instead dorkus".  ## Why It's Good For The Game Fixes a problem caused by, ironically, a logic fix. ## Changelog 🆑 Rhials fix: Centcom ERT hiring standards have been expanded to include plasmamen, again. /🆑 |
||
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
jimmyl
|
55f11237eb |
fix hard restart (#85611)
fixes the third option in the restart verb |
||
Y0SH1M4S73R
|
619887cdbd |
[NO GBP] Actually makes the runtime logging suppression for lua states suppress logging runtimes (#85502)
## About The Pull Request I was so focused on the ui code that I forgot that I didn't make the `supress_runtimes` var do anything. ## Why It's Good For The Game Things should do what they were made to do. ## Changelog 🆑 admin: The "Suppress Runtime Logging" toggle in the lua editor actually does what it says /🆑 |
||
|
Y0SH1M4S73R
|
20361ace13 |
Fixes/improves the Lua UI Slightly (#85447)
## About The Pull Request A couple of fixes/updates watermelon asked for. Of particular note is the ability to suppress logging runtimes that the state was involved in causing. ## Why It's Good For The Game There were a few formatting issues caused by converting the UI to React Typescript. As for suppressing runtime logging, sometimes the runtimes being logged aren't important to the lua code being run, so it would make sense to toggle whether such runtimes should be saved to a state's log. ## Changelog 🆑 admin: The layout of the lua editor has been tweaked slightly. admin: In the lua editor, you can now toggle whether to log runtimes the viewed state is involved in. /🆑 |
||
|
Y0SH1M4S73R
|
d1ccb530b2 |
Replaces Auxlua with the byondapi-based Dreamluau (#84810)
## About The Pull Request Ever since byondapi went stable, I've been meaning to create a replacement lua library that uses it instead of the auxtools-based auxlua. After so many months, I've finally got the code just about into a position where it's ready for a PR. [Click here](https://hackmd.io/@aloZJicNQrmfYgykhfFwAQ/BySAS18u0) for a guide to rewriting auxlua scripts for dreamluau syntax. ## Why It's Good For The Game Code that runs on production servers should not depend on memory hacks that are liable to break any time Dream Daemon updates. ## Changelog 🆑 admin: Admin lua scripting uses a new library that (probably) will not break when BYOND updates. /🆑 ## TODO: - [x] Convert the lua editor ui to TS - [x] Include a guide for converting scripts from auxlua syntax to dreamluau syntax |
||
norsvenska
|
5f80128fa9 |
Corrects 200+ instances of "it's" where it should've been "its" instead (#85169)
## About The Pull Request it's - conjunction of "it" and "is" its - possessive form of "it" grammar is hard, and there were a lot of places where "it's" was used where it shouldn't have been. i went and painstakingly searched the entire repository for these instances, spending a few hours on it. i completely ignored the changelog archive, and i may have missed some outliers. most player-facing ones should be corrected, though ## Why It's Good For The Game proper grammar is good ## Changelog 🆑 spellcheck: Numerous instances of "it's" have been properly replaced with "its" /🆑 |
||
|
SmArtKar
|
dfb12f91d6 |
HUD traits now apply their corresponding hud automatically. Most clothing/item/etc sources of HUDs now only use traits (#84984)
## About The Pull Request Currently if you want to apply a HUD you usually add both its trait and the HUD itself. Only exceptions are things like simplemobs where you should avoid adding the hud trait since it adds security/med DB access and such, but there is no cases where you'd want to apply the trait and not apply the hud. Requested by Melbert about a week ago.  ## Why It's Good For The Game This makes working with HUDs significantly easier, as you no longer have to bother with manually adding/removing them. Also potentially removes an edge case where if your hud could get removed while keeping the trait. ## Changelog 🆑 refactor: HUD traits now apply their corresponding hud automatically /🆑 |
||
|
Kyle Spier-Swenson
|
45ca1717d0 |
Full revert of #79995 (tri-ai station trait). Partal revert of #81681 (human ai) (#84850)
#79995 removed the verb and secrets button for no reason. This means you can no longer decide to do tri-ai in the lobby, you have to do it next round or make players suffer thru another init cycle. **__In general systems that require things be decided the previous round are really fucking annoying and should be minimized to only specific things that absolutely have to for technical reason.__** This is not one of them. I do not have the time to redesign the station trait to make use of the existing admin code so this is a full revert instead. If the station trait is re-added, it should be done so without removing the secrets button or admin verb. #81681 had an undocumented and un-atmoized change, in that it removed a job related signal needlessly, that undocumented change has been reverted because this system used that signal. @Fikou @JohnFulpWillard (also cc @tralezab and @Ghommie as you merged the reverted prs) |
||
Yaroslav Nurkov
|
fa0d602da6 |
Toggle the ability for the dead to vote in-game + understandability for the dead whether voting is disabled. (#84352)
## About The Pull Request Adds a convenient switch to change the ability to vote dead (previously only in the config), and also turns off the button and adds a tooltip to let players know why they can't vote (previously, you could just click, since the button wasn't turned off, but the vote didn't count). https://github.com/tgstation/tgstation/assets/78199449/404aac9c-0b41-4c16-8ffd-2a435cf25e2c ## Why It's Good For The Game At the right moments, you can just stop considering the opinions of dead players. The dead players will be able to understand why they can't vote. ## Changelog 🆑 Vishenka0704 qol: With voting turned off for the dead, you can now understand why you can't vote (being dead). admin: Voting switch for the dead players /🆑 |
||
|
Rhials
|
6c30e75656 |
Admin narrations now let you pick a text formatting span to use in your message (#84723)
## About The Pull Request This adds a menu to all admin narrate verbs that allows you to select a span type for your message. This includes global, direct, world, subtle, and headset narrates. This includes (nearly) all forms of text span. Some were not included, like OOC announcements, centcom priority announcement headers, the span used for hyperlink text, stuff like that. They're mostly all there, but the stuff that probably shouldn't be showing up under a generic chat message has been excluded. There's well over 100 of these things, so pick whatever you want. Due to the way this works, you can close the spans in the message mid-string, in case you wanted to have multiple text formats in the message. You can also just format text the old-fashioned way if you really wanted.  **_Fun fact -- When using admin OOC spans, the reply will copy whatever your admin OOC color is._**  Yeah I'm sure you can tell I'm a super mature person by what the test messages I used here were. Laugh it up. Just know that I'm laughing too, like a grade schooler who just learned their first swear words. ## Why It's Good For The Game No more futzing about with copypastes and big long text files with the span formatting already written out. Now, you can just pick them from a list. Neato! This will increase adminbus immersion by a factor of at least 3-5% assuming all projections and the data we have been provided holds true. ## Changelog 🆑 Rhials admin: Narrate verbs will now allow you to pick what text formatting span you want to use before you send them, if any. /🆑 |
||
MrMelbert
|
69b673bba6 |
Adds more "curated" version of human randomization (for humonkeys, corpse spawners, and fresh characters) (#84443)
## About The Pull Request Basically, adds a version of `randomize_human` that's a tad more curated, IE, primarily picks results to create a more "coherent" result than full randomization. Shown here: Humans, Lizards, Felinids. Looks a bit boring, but that's the point.  Non-humans I left almost entirely untouched, as they generally form a more "coherent" mob from pure randomization already. ## Why It's Good For The Game Basically just aiming to perform a more "consistent" style for humonkeys and corpses. For monkeys, it doesn't make the most sense when they pop up with a giant red afro. For corpses, it's a bit hard to feel immersed in the ruins when they've all got pink and green mustaches. ## Changelog 🆑 Melbert add: Humonkeys and random corpse spawns now look more... human. /🆑 |
||
Watermelon914
|
0db2a23faf |
Adds a new power storage type: The Megacell. Drastically reduces power cell consumption/storage. [MDB Ignore] (#84079)
## About The Pull Request As the title says. A standard power cell now only stores 10 KJ and drains power similar to how it did before the refactor to all power appliances. The new standard megacell stock part stores 1 MJ (what cells store right now). APCs and SMESs have had their power cells replaced with these megacell stock parts instead. Megacells can only be used in APCs and SMESs. It shouldn't be possible to use megacells in any typical appliance. This shouldn't change anything about how much 'use' you can get out of a power cell in regular practice. Most should operate the same and you should still get the same amount of shots out of a laser gun, and we can look at expanding what can be switched over to megacells, e.g. if we want mechs to require significantly more power than a typical appliance. Thanks to Meyhazah for the megacell icon sprites. ## Why It's Good For The Game Power cell consumption is way too high ever since the power appliance refactor that converted most things to be in joules. It's a bit ridiculous for most of our machinery to drain the station's power supply this early on. The reason it's like this is because regular appliances (laser guns, borgs, lights) all have a cell type that is identical to the APC/SMES cell type. And it means that if we want to provide an easy way to charge these appliances without making it easy to charge APCs/SMESs through a power bug exploit, we need to introduce a new cell type to differentiate between what supplies power and regular appliances that use power. This is primarily what the megacell stock part does. This moves us back to what it was originally like before the power refactor, where recharging power cells wouldn't drain an exorbitant amount of energy. However, it maintains the goal of the original refactor which was to prevent people from cheesing power generation to produce an infinite amount of power, as the power that APCs and SMESs operate at is drastically different from the power that a regular appliance uses. ## Changelog 🆑 Watermelon, Mayhazah balance: Drastically reduces the power consumption and max charge of power cells balance: Added a new stock part called the battery, used primarily in the construction of APCs and SMESs. add: Suiciding with a cell/battery will shock you and potentially dust you/shock the people around you if the charge is great enough. /🆑 --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com> |
||
ArcaneMusic
|
472fd37257 |
Adds an admin secret to mass heal and revive everyone. (#84248)
## About The Pull Request Turns out, the only way to do this, if desired as an admin, is through SQL. And that's lame! So, this adds an admin secret to mass heal and revive everyone on the station with a mob. Not much else nuance to it really. ## Why It's Good For The Game Turns out we've been asking about it in bus for like, 3-4 years now? I was also asked about it in a round today, so here we go. |
||
Jacquerel
|
e8157f4dfc |
Items in your hands can catch fire (#83867)
## About The Pull Request Recently we allowed items held in your hands to catch fire if you catch fire. This makes sense but the code had a few oversights, then we reverted it. This PR reintroduces the feature, but with a few refinements. The basic feature is simple: If you are on fire then items you are holding will also catch fire, in the same vein as items you are wearing on your head or hands. There are also a few caveats we forgot about the first time we added this: - If your gloves cannot catch fire, your held items will not catch fire (because your hands aren't on fire). - If you are extinguished, your held items will also be extinguished. - Stopping, Dropping, and Rolling on top of any items will also extinguish those items. As part of this change, after an argument about whether or not this is an oversight in coding-general, I've made the proc `get_equipped_items` take a bitflag instead of a series of booleans as an argument and added a new one for "include held items", so that we need no longer argue about whether holding something counts as "equipping" it (in all other parts of the game than this proc, it does). This is what gives the PR most of its code footprint, don't be scared. ## Why It's Good For The Game Items you are holding in your hands _should_ catch fire if everything else on your person is on fire, and taking an item off of your body to put it in your hands shouldn't protect it from fire, because those things don't make intuitive sense. If we want an item to be able to catch fire when worn, then it should do so. This might expose some issues where we were improperly setting the flammability flags on items, but any weapon which will burn in your hands now would also have burned if you were wearing it on your belt or back, so making those issues more visible should be a bonus (we'll also stop them from burning on your back or belt). If you see someone holding a piece of paper that you really don't want them to read you can now set them on fire to stop them from reading it, whereas previously they would deftly hold the very flammable object out of reach of their flaming body. ## Changelog 🆑 balance: Items held in your hands can catch fire. balance: Items you are holding won't catch fire if your hands cannot catch fire. balance: When you stop being on fire so will items you are holding. balance: If you roll around on your burning items they will stop being on fire. /🆑 |
||
SyncIt21
|
b6369a47b4 |
Mouse drag & drop refactored attack chain (#83690)
## About The Pull Request
Mouse drag & drop has been refactored into its own attack chain. The
flowchart below summarizes it
Brief summary of each proc is as follows
**1. `atom/MouseDrop()`**
- It is now non overridable. No subtype should ever touch this proc
because it performs 2 basic checks
a) Measures the time between mouse down & mouse release. If its less
than `LENIENCY_TIME`(0.1 seconds) then the operation is not considered a
drag but a simple click
b) Measures the distance squared between the drag start & end point. If
its less than `LENIENCY_DISTANCE`(16 pixels screen space) then the drag
is considered too small and is discarded
- These 2 sanity checks for drag & drop are applied across all
operations without fail
**2. `atom/base_mouse_drop_handler()`**
- This is where atoms handle mouse drag & drop inside the world. Ideally
it is non overridable in most cases because it also performs 2 checks
- Is the dragged object & the drop target adjacent to the player?.
Screen elements always return true for this case
- Additional checks can be enforced by `can_perform_action()` done only
on the dragged object. It uses the combined flags of
`interaction_flags_mouse_drop` for both the dragged object & drop target
to determine if the operation is feasible.
We do this only on the dragged object because if both the dragged object
& drop target are adjacent to the player then `can_perform_action()`
will return the same results when done on either object so it makes no
difference.
Checks can be bypassed via the `IGNORE_MOUSE_DROP_CHECKS` which is used
by huds & screen elements or in case you want to implement your own
unique checks
**3. `atom/mouse_drop_dragged()`**
- Called on the object that is being dragged, drop target passed here as
well, subtypes do their stuff here
- `COMSIG_MOUSEDROP_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
**4. `atom/mouse_drop_receive()`**
- Called on the drop target that is receiving the dragged object,
subtypes do their stuff here
- `COMSIG_MOUSEDROPPED_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
## Why It's Good For The Game
Implements basic sanity checks across all drag & drop operations. Allows
us to reduce code like this
|
||
|
MrMelbert
|
d244c86ce6 |
Adds Character Loadout Tab to preferences (with just a small handful of items to start) (#83521)
## About The Pull Request Adds a Character Loadout Tab to the preference menu This tab lets you pick items to start the round with  This also has some additional mechanics, such as being able to recolor colorable items, rename certain items (such as plushies), set item skins (such as the pride pin)  ## Why It's Good For The Game This has been headcoder sanctioned for some time, just no one did it. So here we are. Allows players to add some additional customization to their characters. Keeps us from cluttering the quirks list with quirks that do nothing but grants items. ## Changelog 🆑 Melbert add: Character Loadouts del: Pride Pin quirk (it's in the Loadout menu now) /🆑 |
||
thegrb93
|
f2644ab9e8 |
Fix admin borg panel unable to install/remove upgrades (#83733)
## About The Pull Request Fixes the admin borg panel's upgrade functionality. Caused by not registering the signals for deletion and also by the upgrade code checking the robot's contents instead of upgrades list (since the borg panel spawns the item in the borg, it appears in the borg's contents, making the check think the borg already has it installed.) ## Why It's Good For The Game Easier testing new borg modules ## Changelog 🆑 fix: Fixes admin borg panel upgrade functions /🆑 |
||
Pickle-Coding
|
b34afb1432 |
Admin fix_air verb also fixes the turfs' temperatures. (#83549)
## About The Pull Request Makes the turfs' temperatures be set to their initial values when fix_air is used on them. ## Why It's Good For The Game Prevents the turfs from heating the air back up after an admin uses fix_air on a very hot room. ## Changelog 🆑 admin: fix_air will also fix the turfs' temperatures. /🆑 |
||
|
Watermelon914
|
dc2da9338a |
Removes logging each lua function called on the dm side of things. (#83483)
## About The Pull Request As the title says. This should significantly improve the performance of running lua scripts. ## Why It's Good For The Game There is a lot of performance overhead in logging each individual function called by a lua script as can be seen in the following screenshot: This is a test done on a local server where I run the `zombie_controller.lua` script that can be found on the auxlua-cookbook repository with a lot of AI zombies spawned in.   Logging these calls is not necessary as it doesn't provide any real information to anyone looking for bad actors. Lua scripts are already logged when ran and they can be examined to spot if the script being run is done so in bad faith. --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> |
||
Afevis
|
0308430832 |
Fixes logging runtime when admins trigger summon events (#83109)
Admin secrets panel passes a client to this proc, which only had
handling for being passed a mob.
```
[17:23:21] Runtime in code/modules/spells/spell_types/right_and_wrong.dm, line 250: undefined proc or verb /client/log message().
proc name: summon events (/proc/summon_events)
usr: ShizCalev/(Gratian Hunter)
usr.loc: (Engineering SMES (115,96,2))
src: null
call stack:
summon events(ShizCalev (/client))
/datum/secrets_menu (/datum/secrets_menu): ui act("events", /list (/list), /datum/tgui (/datum/tgui), /datum/ui_state/admin_state (/datum/ui_state/admin_state))
/datum/tgui (/datum/tgui): on act message("events", /list (/list), /datum/ui_state/admin_state (/datum/ui_state/admin_state))
/datum/callback/verb_callback (/datum/callback/verb_callback): InvokeAsync()
```
|
||
Jeremiah
|
e766f921f6 |
Code cleanup: Sorting (#83017)
## About The Pull Request 1. Removes code duplication 2. Fully documents `sortTim()` 3. Makes a define with default sortTim behavior, straight and to the point for 95% of cases 4. Migrates other sorts into the same file 5. Removes some redundancy where they're reassigning a variable using an in place sorter For the record, we only use timSort ## Why It's Good For The Game More documentation, easier to read, uses `length` over `len`, etc Should be no gameplay effect at all |
||
|
MrMelbert
|
0cc5cfb178 |
Random Name Generation refactor, generate random names based on languages (for species without name lists, like Felinids and Podpeople) (#83021)
## About The Pull Request This PR moves random name generation for species onto their languages. What does this mean? - For species with a predefined name list, such as Lizards and Moths, nothing. - For species without predefined name lists, such as Felinids, their names will now be randomly generated from their language's syllables.   (In the prefs menu:)  Why? - Well, we actually had some dead code that did this. All I did was fix it up and re-enable it. - Generates some pretty believable in-universe names for various languages that are lacking name lists. Obviously defined lists would be preferred, but until they are added, at least. - Moves some stuff off of species, which is always nice. - Also hopefully makes it a tad easier to work with name generation. There's now a standard framework for getting a random name for a mob, and for getting a random name based on a species. Misc: - Adds a generic `species_prototype` global, uses it in a lot of places in prefs code. - Makes `GLOB.species_list` init via the global defines - Deletes Language SS - Alphabetizes some instances of admin tooling using the list of all species IDs - Docs language stuff - Deletes random_skin_tone, it does pretty much nothin ## Changelog 🆑 Melbert refactor: Random Name Generation has been refactored. Report any instances of people having weird (or "Unknown") names. qol: Felinids, Slimepeople, Podpeople, and some other species without defined namelists now automatically generate names based on their primary language(s). qol: More non-human names can be generated in codewords (and other misc. areas) than just lizard names. /🆑 |
||
Mothblocks
|
bc4e7d3b4e | Remove data systems in favor of global datums (#82943) | ||
|
san7890
|
78e2ada35d |
Re-adds Possess Object to Right-Click Context Menu (#82912)
## About The Pull Request Fixes #82882 ## Why It's Good For The Game Corrects nonintentional regression in expected behavior by re-adding this verb back to the context menu. ## Changelog 🆑 admin: Possess Object is now back in the right-click context menu. /🆑 |
||
|
Jeremiah
|
c1a775efe1 |
Implements data systems (#82816)
## About The Pull Request Subsystems currently come in two different flavors: 1. Systems that process at intervals with the master controller 2. Global data containers that do not fire And I think they should be split up... This moves 4 non firing, non init subsytems -> datasystem ## Why It's Good For The Game Clarity in code |
||
Zephyr
|
907f9497d7 | Player Panel-age (#82757) | ||
|
Zephyr
|
abbee36f1d |
Hey what if admins were allowed to use the player panel (#82682)
Re-adds the player panel verb to the verb panel. |
||
|
Zephyr
|
9124a73b60 |
Put some admin jump verbs back into the context menu | sorts area jump list again (#82647)
## About The Pull Request See title. ## Why It's Good For The Game Some admins wanted all the jump verbs back, aswell as making them not AGhost you. Also make the Jump To Area verb use a sorted list again |
||
|
Zephyr
|
7f8752be14 | Admin Verb Datums MkIII | Now with functional command bar (#82511) | ||
|
san7890
|
c403a6eccc |
Wraps lowertext() to ensure proper stringification. (#82442)
## About The Pull Request Fixes #82440 This PR just creates a new macro, `LOWER_TEXT()` (yes the irony is not lost on me) to wrap around all calls of `lowertext()` and ensure that whatever we input into that proc will be stringified using the `"[]"` (or `tostring()` for the nerds) operator. very simple. I also added a linter to enforce this (and prevent all forms of regression) because I think that machines should do the menial work and we shouldn't expect maintainers to remember this, let me know if you disagree. if there is a time when it should be opted out for some reason, the linter does respect it if you wrap your input with the `UNLINT()` function. |
||
|
Watermelon914
|
ce23a59c36 |
Cleans up the SS13_base lua file and adds a new lua file for easily handling multiple signals on different objects. (#82458)
## About The Pull Request Cleaned up the SS13.register_signal and SS13.unregister_signal, removing the weird list shifting. Also adds a new lua file that can be included for the use of registering different signals on various datums and being able to clear them all in 1 function. Removed the make_easy_clear_function option when registering a signal via lua because I don't think it's used by anyone and it lacks any sort of versatility. Users can just create their own function for clearing signals from a datum. Also updates the documentation for HARDDELETES.md as COMSIG_PARENT_QDELETING was renamed to COMSIG_QDELETING ## Why It's Good For The Game New handler file makes registering signals in batches a lot easier if you want to clear them in one go without clearing unrelated callbacks on the same datum. The list shifting in SS13.register_signal had pretty significant performance problems, so removing that will make registering and unregistering signals faster. ## Changelog 🆑 admin: LUA - Adds a new library called handler_group. Include it in your files by doing require('handler_group') /🆑 --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> |
||
|
John Willard
|
5e9ce5ab99 |
New Battle Arcade (#81810)
## About The Pull Request Remakes Battle Arcade from just about the ground up, with exceptions taken for emagged stuff since I didn't really want to touch its behavior. The Battle Arcade now has stages that players can go through, unlocking a stage by beating 2 enemies and the boss of the previous one, but this must all be done in a row. You can choose to take a break between each battle and there's a good chance you'll sleep just fine but there's also a chance it can go wrong either through an ambush or robbery. The Inn lets you restore everything for 15 gold and you can buy a sword and armor, each level you unlock is a new sword and armor pair you can buy that's better than the last, it's 30 gold each but scales up as you progress through levels. They are really worth getting so it's best to try to not lose your money early in. The battle system is nearly the same as how it was before but I removed the poor combo system that plagued the old arcade as one big knowledge lock, now it's more just turn based. The game is built on permadeath so dying means you restart from the beginning, but if you are going to lose you can try to escape instead which costs you half of your gold. Getting to higher levels increases the difficulty of enemies but also increases the gaming exp rewards which could make this a better way to get exp if you can get good at it. Gaming EXP is used to increase chances of counterattacking but doesn't give any extra health to the player. I also removed the exploit of being able to screwdriver arcade cabinets because people would do that if they thought they were on the verge of losing to bypass the effects of loss. I instead replaced it with a new interaction that the Curator's display case key can be used to reset arcade cabinets (there's several keys on the chain so it made sense to me), which I added solely because I thought Curators would be the type of person to have run an actual arcade. This is some gameplay https://github.com/tgstation/tgstation/assets/53777086/499083f5-75cc-43b5-b457-017a012beede As a misc sidenote, I also split up the arcade file just like how Orion Trail was before, just for neat code organization. The Inn keeper is straight up just a photo of my localhost dude, he's not a player reference or anything it's not my actual character. I also have no idea how well balanced this is cause I suck at it lol. ## Why It's Good For The Game Battle Arcade is one of 3 last machines in my hackmd here to turn into TGUI https://hackmd.io/XLt5MoRvRxuhFbwtk4VAUA?view I've always thought the current version of battle arcade is quite lame and lacks any progression, like Orion Trail I thought that since I was moving this to TGUI, it would also be a perfect opportunity to revamp it and try to improve on where it failed before, especially since the alternative (NTOS Arcade) is also lame as hell and is even lamer than HTML battle arcade (spam mana, then spam health, then just spam attack, rinse and repeat). This will hopefully be more entertaining and give players sense that they are getting through a series of tasks rather than doing one same one again and again. ## Changelog 🆑 JohnFulpWillard, Zeek the Rat add: Battle Arcade has been completely overhauled in a new progression system, this time using TGUI. add: The Curator's keys can now reset arcade cabinets. balance: You now need to be literate to play arcade games, except for Mediborg's Amputation Adventure. fix: You can no longer screwdriver emagged arcade consoles. Accept your fate. fix: Silicons can no longer play Mediborg's Amputation Adventure. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
|
Jacquerel
|
f47733d0e3 |
Final Objective: Battle Royale (#82258)
## About The Pull Request Adds a new final objective option with a classic premise; the forced battle to the death. The concept is that the Syndicate will provide you with an implanter tool you can use on an arbitrary number of crew members. Once you have at least 6 (though there is no ceiling) you can activate the implants to start the Battle Royale and broadcast the perspectives of everyone you implanted live to the entertainment monitor. After activation these implants cause you to explode upon death. If at the end of 10 minutes, more than one person remains unexploded then all of the remaining implants will detonate simultaneously. Additionally, one of the station's departments (Medbay, Cargo, Science, or Engineering) will be chosen as the arena. If after 5 minutes pass you're not within that department (or if you leave it after that time has passed) then you will be killed. The Syndicate plan on both using the recorded footage to study Nanotrasen technology, and also to sell it as an underground blood sport, and so have employed a pirate broadcasting station to provide colour commentary. The implantation is silent, however it requires you and your target to be adjacent and stood still for one and a half seconds. Once implanted, it will occasionally itch and eventually signal to the implantee that something is up, so once you start implanting someone you're on a soft timer until you are given away. You can also implant yourself if you want to do that for some reason. Removing an implant from someone has a 70% chance of setting it off instantly, but it _is_ possible. If the implant is exposed to EMP, this value is randomised between 0 and 100%. You could also try doing surgery while the patient is wearing a bomb suit or something, that puzzle is for you to solve and I'm not going to tell you the answers. I'm sure you'll think of ones I haven't. ## Why It's Good For The Game Adds a somewhat more down-to-earth but still hopefully exciting and threatening option which should let people mess around with the sandbox. The mutual death element provides some roleplaying prompts; nothing actually _forces_ you to fight apart from fear of death and it may be possible to find other ways to survive, or perform some kind of solidarity behaviour with your fellow contestants. Maybe you'll try that but one of your fellow contestants just wants to be the last survivor anyway. Maybe you'll pretend you're setting up some kind of mutual survivorship thing in order to make sure you're the sole survivor. Gives some people to watch on the bar TV channel. The crew apparently love playing Deathmatch while dead so we might as well enable doing it while alive. Also I'm going to follow this up with a separate PR to remove the Space Dragon objective and it felt like it'd be a good idea to do one out one in ## Changelog 🆑 add: Adds a new Final Objective where you force your fellow crew to fight to the death on pain of... death. /🆑 |
