* spraycanning stuff now updates its sprites on the mob (#62726)
* spraycanning stuff now updates its sprites on the mob
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Removes the augment painter, moves the function to spraycan rightclicking. (#61814)
Right-clicking a robotic body part with a spraycan will open a radial menu and allow for coloring the body part just like the augment painter did. This costs five charge off the spraycan, meaning a single can will paint six augments.
The augment painter has been removed from the game files and from all maps.
* Removes the augment painter, moves the function to spraycan rightclicking.
* removes augment painter
Co-authored-by: zxaber <37497534+zxaber@users.noreply.github.com>
Co-authored-by: Kat <evesovereign@hotmail.co.uk>
* tgui Preferences Menu + total rewrite of the preferences backend
* nah, we dont need to ping those people
* trying to remove the funny stuff
* unmodularizing this
* prefs reset
* this may need to be reverted, who knows
* okay, this part
* perhaps
* EEEEEEEEE
* unsanitary
* E
* Stage 1 + loadout system
* more fixes
* E
* I mean, it launches?
* More fixes and reorganisation
* E
* customisation code is spaget.
* disable ERP prefs
* Update erp_preferences.dm
* Update erp_preferences.dm
* E
* Slowly getting there
* It may be time for help :)
* tri...colors... help
* preferences now pass preferences
* Update dna.dm
* Fuck this man
* missing savefile return, set_species works, removed dumb stuff from updateappearance
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/8199
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/8224
* https://github.com/tgstation/tgstation/pull/61519
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/8278
* e
* le butonAZARAK HELLO
* hhh
* Proper recognition where it's due, MrMelbert!
* EEEE
* examine block
* Better gen hit sounds from whitedream
* final loadout touches, more bug fixes im sure to come
* i said there would be bugfixes
* Update LoadoutManager.js
* Missing preferences in the html menu
* LIVE TESTING PHASE BABY
* Update LoadoutManager.js
* EEE
* LAUNCH TEST FIRE
* Update job.dm
* Update new_player.dm
* 50gb DAY ONE PATCH
* EEE
* Update preferences.dm
* buggle fixes
* Update examine.dm
* >LOOC starts on
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: jjpark-kb <55967837+jjpark-kb@users.noreply.github.com>
Co-authored-by: Gandalf <jzo123@hotmail.com>
Co-authored-by: Azarak <azarak10@gmail.com>
* Fix crayon text input (#61002)
The regex expression being used missed some symbols and screwed up spacing.
* Fix crayon text input
Co-authored-by: Tim <timothymtorres@gmail.com>
* Spraycans actually empty if used below 2 units while colouring lights. (#60395)
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Spraycans actually empty if used below 2 units while colouring lights.
Co-authored-by: DomitiusKnack <56321744+DomitiusKnack@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Crafting menu tells you which colour of crayon is needed (#56950)
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Crafting menu tells you which colour of crayon is needed
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Spraycans now consume charges in the right order when spraying graffiti. (#54929)
Spraycans now check the cost of placing down a new spray before performing the do_after countdown, then uses the charge immediately after the do_after is completed.
Spraycans should check and only use a charge AFTER their cooldown timer is complete.
* Spraycans now consume charges in the right order when spraying graffiti.
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
* Converting art component into element. (#54616)
* Only art is now an element. There have been some issues with beauty.
* Typo.
* Update art.dm
* Update art.dm
* Maintainer suggestions. Reversing order of switch(impress) for correct moodlets.
* Fixing some pre-existing oddities with art element.
* stating the right var.
* simplifying the component.
* Update art.dm
* lowercasing pronoun.
* Converting art component into element.
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Enforce preserving parent proc return values across ui_act call stacks (#53964)
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
* Enforce preserving parent proc return values across ui_act call stacks
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
* Bring back painting arbitrary objects with spray cans (#52936)
Brings back the behavior removed from #52186 with cleaner code.
Differences in the code:
No more explicit type checks in the spray paint code, other than a broad isobj.
Checking for dark colors is now based on luminosity, rather than unscientifically summing all the RGB components and checking an arbitrary number.
Removes the paintable component. This was used on one item, and its behavior is replicated in the spray can.
Instead of checking for windows specifically and changing opacity through there, atoms can now specify through init flags whether or not they allow dark colors. Windows set this flag.
Adds a COMSIG_OBJ_PAINTED signal. Windows use this signal to dynamically update opacity, just like how they did before.
This was a fun cosmetic feature that I'm not sure anyone had a problem with. The original reason for removal seemed to be because of code quality, and not because of negatives about the feature.
Makes canvasses unpaintable
* Bring back painting arbitrary objects with spray cans
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
* Personalized combat messages part 2 (#52890)
Adds more "personalized" combat messages for all participants in a fight: the attacker, the victim and the spectators
* Personalized combat messages part 2
* Update misc.dm
Co-authored-by: kingofkosmos <riki.sundberg@gmail.com>
Co-authored-by: Gandalf <jzo123@hotmail.com>
* Renames a few variables. Also reorders fallback order again.
Renames item_state to inhand_icon_state
Renames mob_overlay_icon to worn_icon
Renames mob_overlay_state to worn_icon_state
worn_icon_state/mob_overlay_state now never gets used for inhands.
* Fixes some comments
* Fixes map issue
* Restart lints
* Properly resolves conflicts
Adds the Families gamemode to the codebase. In this 1 hour showdown,
multiple criminal families are placed onto the station with their goal
to rack up the most points by the end of 1 hour. At which point, the
Space Cops hit up the station to crack down on the family activity. The
severity of the Space Cops is based on how much carnage and murder the
families have committed.
## Why It's Good For The Game
With an actual official medium/heavy RP server, and the codebase taking
a much harder swing towards heavier consequences for death, a more
player focused gamemode with a unique swing on teamwork, the concept of
what exactly is an antagonist, and trust/paranoia will do wonders to
help improve that atmosphere.
Previous tests went extremely well(when administrators weren't
intentionally sabotaging it by welderbombing families as the Head of
Security every single round immediately with no escalation), but
suffered from "this just isn't a gamemode for no RP servers like /tg/".
However, /tg/ is now an RP server.
Get ready to rep your family.
## Isn't this just Gang?
Heck no. Only thing similar is tagging turf and the fact criminal
groups are involved. This mode is completely different otherwise.
## Heck yeah, where do I sign up?
Ask a family member where their Signup Point is, and then simply click
on it with an open hand. You'll be signed up for the family instantly,
and given some sick threads and a spraycan for tagging.
## How do I rep my family?
Wear your gang's uniform or colors similar.
## What does it mean to roll with a crew?
Travel in a group of four or more for bonus points towards your gang.
However, you receive less for having eight or more, so be careful. Try
to spread your crews out!
## I'm an X, what do?
Gangster: Yeah, go do whatever. Wanna backstab your gang? Go for it.
You can switch sides at any time by clicking on an enemy gang's sign up
point. Wanna murder some snitch because they ratted you out to the
pigs? Do it. Wanna pressure the locals into supplying you with goods to
export? Emergent gameplay.
Civilians: Wanna join a gang? Go for it. Gangsters probably shouldn't
be arbitrarily murdering you, but if you're repping someone else's
colors, don't expect to be given a free pass. After all, uniforms are
the only way to really identify a gang member.
SPACE COP: Get rid of all the gangsters. Secure the station. Protect
the law. Uphold the law. Eat donuts.
## No huds? How can I tell if someone's part of my group?
Tough shit, man. I hope you like trust.
In short, this gamemode will be a fun exercise in how far the
playerbase can go in regards to trusting eachother and unifying to meet
a common goal for their group with no rules, gameplay mechanics, or
anything actively forcing them to work together.
## How do I know if someone is a gangster?
1. Are they wearing a gang uniform/color?
If yes, they're probably a gangster.
If no, they're probably a civvie.
2. Are they attacking gangsters?
If yes, they're probably a gangster.
If no, they're probably a civvie.
* Unicode support Part 2 -- copytext()
This is the transition of all copytext() calls to be unicode aware and also some nearby calls in the same functions. Most things are just replacing copytext() with copytext_char() as a terrible character limiter but a few others were slightly more involved.
I replaced a ton of
````
var/something = sanitize(input())
something = copytext(something, 1, MAX_MESSAGE_LEN)
````
with a single stripped_input() call. stripped_input() already calls html_encode(), trim(), and some other sanitization so there shouldn't be any major issues there.
This is still VERY rough btw; DNA is a mess, the status displays are complete ass, there's a copytext() in code\datums\shuttles.dm that I'm not sure what to do with, and I didn't touch anything in the tools folder. I haven't tested this much at all yet, I only got it to compile earlier this morning. There's also likely to be weird bugs until I get around to fixing length(), findtext(), and the rest of the string procs.
* Makes the code functional
* Assume color hex strings are always # followed by ascii.
Properly encodes and decodes the stuff in mob_helpers.dm which fixes some issues there.
* Removes ninjaspeak since it's unused
* update_icon() improvements
Fixes some update_icon() calls to properly call parent and use update_overlays() and update_icon_state().
The rest of obj/item fuck it
* Suggested fixes, also passes the linter
* I always forget . = ..() is faster than return ..() FOR SOME FUCKING REASON
* Actually this is better
* Signilzes datum/action to update its icon when its connected item does.
About The Pull Request
Does exactly what it says on the tin.
text2ascii accepts text strings with length higher than one character as first arg, so we need to check against that beforehand.
Why It's Good For The Game
Fixing a (likely unreported) mild issue with the game.
Changelog
cl
fix: non-alphanumeric graffiti decals will no longer display as "letter".
/cl
About The Pull Request
Non-taggers' graffiti counts as bad art. Taggers' graffiti counts as good art, not great art.
Makes the art defines global defines and removes some magic numbers.
Re-orders the switch statement for art to go ascending instead of descending, because otherwise if something is at BAD_ART it will register as good instead, if it's at GOOD_ART it will register as great, etc., which defeats the purpose of having defines.
Why It's Good For The Game
The tagger component: Because there isn't really much bad art in the game ,and graffiti is as obvious a candidate as any, and gives the janitor an actual excuse to remove it besides being a dick. If you don't want the potential for a bad moodlet, don't examine the art. You have to go out of your way to do so anyway.
Very slightly nerfing tagger graffiti: Because "what a thought-provoking piece of art" is kind of much for graffiti.
The other component: Because there's no point in having defines if people are just going to put magic numbers everywhere anyway. (I left the impressiveness numbers for statues, etc. alone, because those can take damage, dropping their quality. But if something can't take damage, just use the define.)
Changelog
cl
tweak: Graffiti by a non-tagger counts as bad art.
/cl
About The Pull Request
Converts every single usage of playsound's vary parameter to use the boolean define instead of 1 or 0. I'm tired of people copypasting the incorrect usage.
Also changes a couple of places where a list was picked from instead of using get_sfx internal calls
This was done via regex:
(playsound\(.+,.+,.+, ?)1( ?\)| ?,.+\)) to match 1
(playsound\(.+,.+,.+, ?)0( ?\)| ?,.+\)) to match 0
full sed commands:
/(playsound\(.+,.+,.+, ?)1( ?\)| ?,.+\))/\1TRUE\2/ 1 to TRUE
/(playsound\(.+,.+,.+, ?)0( ?\)| ?,.+\))/\1FALSE\2/ 0 to FALSE
I'm not very good with regex and these could probably be optimized, but they worked.
Why It's Good For The Game
Code usability
About The Pull Request
Adds 'notice' span class to all visible_messages which had no span class, making all those black messages blue.
Why It's Good For The Game
This should help differentiate action-messages from talking-messages in the chat. More actions will be blue, thus black talking-messages should pop out more.
About The Pull Request
Completely removes item_color and the clusterfuck of bad programming it caused.
In places where item_color was used for entirely unique purposes it was split off and renamed to a new var on that typepath only, or refactored so it wasn't needed
In places where item_color was used as a dye color, it was converted to the new dye_color var
In places where item_color was used as the worn overlay it was removed and instead now icon_state is always used as the clothing overlay.
A new mob_overlay_icon var was added for manually setting where the mob overlay icon path is for specific items.
Moved some mob overlay files relating to clothing to their own directory as well for organization purposes.
Totally refactors washing machines, instead of the horrible abortion that was iterating through the typepath it now uses a registry of dye results.
Some bonus functionality to come out of this:
the washing machine now supports arbitrary dye colors.
Why It's Good For The Game
It's been 4 years since the "this should be deprecated soonish" comment was added, and this var is a shitpile of confusion if you just trace the usage of it.
Changelog
cl
add: Washing machines now support arbitrary dye color
add: Washing machines now dye nearly every item.
refactor: lots of backend changes to clothing overlays, report any issues
/cl
