* Refactors sheet crafting to better support directional construction (#74572)
## About The Pull Request
0426f7ddba/code/game/objects/items/stacks/stack.dm (L449)
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Refactors sheet crafting to better support directional construction
* fex
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/20636
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Removing verbs from the simple_rotation component (#71740)
## About The Pull Request
Likely the most trival issue from the [Dev Cycles
Initiative](https://github.com/orgs/tgstation/projects/11) project:
Closes https://github.com/tgstation/dev-cycles-initiative/issues/20
## Why It's Good For The Game
On the face of how useful they may seem, these verbs are basically
surclassed by the more accessible click shortcuts, while also being an
additional cost, which I cannot readily quantify on my subpar hardware,
but likely to be but a smidge compared to loading the nukie outpost and
wizard shuttle everytime rather than on demand, for example.
## Changelog
🆑
del: Removed object rotation related verbs, overwhelmingly overshadowed
by the click shortcuts anyway.
/🆑
* Removing verbs from the simple_rotation component
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Removes canuserrotate from simple rotation's screentip (#70002)
Removes canuserrotate from rotation context
Removes the check on whether the user can rotate a chair or not, in the screentip context message.
We shouldn't check to see if a person can or can't rotate a chair or not, they will instead get the feedback when they try to rotate it if they fail, but it's better if the screentip let them know it's a mechanic that exists.
* Removes canuserrotate from simple rotation's screentip
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Add Alt RMB and Ctrl RMB screentips (used for Simple Rotation) (#69726)
* Add Alt RMB and Ctrl RMB to screentips
* Add Ctrl and Alt RMB screentips to defines
* Add Alt RMB and Ctrl RMB screentips (used for Simple Rotation)
Co-authored-by: Tim <timothymtorres@gmail.com>
* Adjust balloon alerts for the rotate component (#64801)
Adjusts the failure balloon alerts to have a !, which is standard.
Remove the balloon alert for rotating/flipping things, as the visual feedback is already there: it's the thing getting rotated/flipped. Plus it's too long.
* Adjust balloon alerts for the rotate component
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Renames RemoveComponent, fixes a dumb runtime in Destroy (#60653)
* Renames RemoveComponent, as its purpose was unclear. Fixes up some dumb uses, and properly docs its status as a helper proc for transfering components
* Renames RemoveComponent, fixes a dumb runtime in Destroy
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Food refactor part 1: Bread destruction and processable element (#53047)
* Food refactor part 1: Bread destruction and processable element
Co-authored-by: Qustinnus <Floydje123@hotmail.com>
* Adds SIGNAL_HANDLER and SIGNAL_HANDLER_DOES_SLEEP to prevent signal callbacks from blocking (#52761)
Adds SIGNAL_HANDLER, a macro that sets SHOULD_NOT_SLEEP(TRUE). This should ideally be required on all new signal callbacks.
Adds BLOCKING_SIGNAL_HANDLER, a macro that does nothing except symbolize "this is an older signal that didn't necessitate a code rewrite". It should not be allowed for new work.
This comes from discussion around #52735, which yields by calling input, and (though it sets the return type beforehand) will not properly return the flag to prevent attack from slapping.
To fix 60% of the yielding cases, WrapAdminProcCall no longer waits for another admin's proc call to finish. I'm not an admin, so I don't know how many behinds this has saved, but if this is problematic for admins I can just make it so that it lets you do it anyway. I'm not sure what the point of this babysitting was anyway.
Requested by @optimumtact.
Changelog
cl
admin: Calling a proc while another admin is calling one will no longer wait for the first to finish. You will simply just have to call it again.
/cl
* Adds SIGNAL_HANDLER and SIGNAL_HANDLER_DOES_SLEEP to prevent signal callbacks from blocking
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
About The Pull Request
This PR adds signals for all basic tool acts.
Replaced signals places where it's appropriate.
Why It's Good For The Game
It's kinda dirty how we used to do attackby and then check for tool behaviour. Since we now have stuff like plumbing and possibly that one laser PR, we need signals that directly relate to tool behaviour.
Changelog
cl
code: Added signals for all basic tool acts.
/cl
* 1/4 done? maybe?
* more
* stuff
* incremental stuff
* stuff
* stuff & things
* mostly done but not yet
* stuffing
* stuffing 2: electric boogaloo
* Git Commit and the Kingdom of the Crystal Skull
* make it actually compile
* found more stuff
* fixes
* fix AI laws appearing out of order
* fix windows
* should be the remaining stuff
* this time for real
* i guess it should compile too
* fix sechuds
one of three things.
1. They don't use RegisterWithParent or UnregisterFromParent to unregister
and register signals
2. They use callbacks which refer to a source object, which is usually deleted
on transfer, or lost in some manner, or simply makes no sense at all to be
transferred
3. the component was never designed to be transferred at all
TransferComponents gave no shits about any of this and just blindly transferred
all components, if they were actually capable of it or not.
I only noticed this because it was causing chairs to break as they would not register signals
and verbs correctly for rotation after being picked up and then placed down, and a player
reported that issue via ahelp.
Luckily we caught it before the rot got anywhere, only chairs and the shuttle subystem
tend to use this proc (Shuttle uses it on turfs), can you imagine if everything was using
this LMAO
Which is good because it's more dangerous than a loaded gun
I have added a can_transfer var, that is true when a component is valid to
actually transfer, which means the dev has actually thought about what happens when
you take the parent object away and swap it for another and all the crazy that is entailed
by this
I have done my best to audit what components are actually
transferable, but things are basically a hot mess (Thanks @Cyberboss )
The following components required edits:
Forensics:
did not register/deregister the clean_act signal properly, did not checkblood on new parent
Rotation:
did not use RegisterWithParent or UnregisterFromParent, turned out
to not be transferable anyway due to having callbacks that can be
passed in to the parent with unknown sources that we can't feasibly
reuse (i.e if you're transferred from a chair to a bed, your old rotation
call backs are no longer valid). Turns out the use case it was for (just chairs)
didn't need it anyway, so I just made it non valid for transfer.
Wet Floor:
Honestly this one is just a hot mess, it should be a subtype of the slippery
component with the extra wet turf handling.
As it is it basically manages a slippery component on top of it's own extra
functionality, so that's a major code smell.
I added registration/unregistration of the signals, and made it's pretransfer
remove the slippery component and the posttransfer add it back (via update_flags)
Components that seem transferable without issues
mirage_border
orbiter
decal
spill
storage (I hope to earth)
