Commit Graph
20 Commits
Author SHA1 Message Date
SmArtKarandGitHub 431bf75d53 Color Code Audition: Human rendering hates me (#89702)
## About The Pull Request

This trainwreck of a PR is (hopefully) a final solution to all rendering
jank stemming from the new filter-based coloring system. I went over
every single instance of RESET_COLOR, either adding KEEP_APART or
rewriting them entirely so they render properly. I've also fixed blood
rendering issues by utilizing alpha filters and adding an abstract
"holder" appearance for worn items, which holds blood overlays on worn
clothing as to avoid coloring it. I've also fixed horrible
inconsistencies with atmos pipe coloring as a result (of getting sucked
down that rabbit hole) and converted all uses of COLOR_VERY_LIGHT_GRAY
in atmos code to ATMOS_COLOR_OMNI to avoid confusion.

MODsuit modules still get colored into MOD unit's color, need to
refactor their rendering for this.

Closes #88989
Closes #87526
Closes #89837

## Changelog
🆑
refactor: Audited all remaining coloring code - among noticeable
changes, blood should no longer get colored or "leak out" of item
bounds, atmos pipes no longer color weirdly and repairbots are white
again.
/🆑
2025-03-24 15:05:33 +01:00
7d3004bc79 Removes caps from many improper items (#86759)
## About The Pull Request

Removes caps from many improper items.
For example - Heated Rebar Crossbow -> heated rebar crossbow

I've kept a lot of items untouched because for some reason or another it
felt nicer to me that they be, uh, capsed. For example Hat of the
Honkmother, anything that has 'weight' to it.

There's also some minor name changes that I think fit better, such as
Rebar Storage Quiver -> rebar quiver. I mean, we already know it's for
storage. That's the whole point of quivers.
## Why It's Good For The Game

This is one of my biggest pet peeves, Randomly Capitalized Items For No
Reason. It looks sloppy, awkward, and half-assed. This PR brings a lot
of the worst offenders in line. if your name isn't a proper noun it
almost never should have caps.
## Changelog
🆑
spellcheck: Removes caps from many improper items
/🆑

---------

Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com>
2024-09-21 00:09:34 +02:00
JeremiahandGitHub 8e3f635b98 Alt click refactor (#82656)
## About The Pull Request
Rewrites how alt click works. 
Based heavily on #82625. What a cool concept, it flows nicely with
#82533.

Fixes #81242 
(tm bugs fixed)
Fixes #82668

<details><summary>More info for devs</summary>

Handy regex used for alt click s&r:
`AltClick\((.*).*\)(\n\t.*\.\.\(\))?`
`click_alt($1)` (yes I am aware this only copies the first arg. there
are no other args!)

### Obj reskins
No reason for obj reskin to check on every single alt click for every
object. It applies to only a few items.
- Moved to obj/item
- Made into signal
- Added screentips

### Ventcrawling
Every single atmospherics machine checked for ventcrawling capability on
alt click despite only 3 objects needing that functionality. This has
been moved down to those individual items.
</details>

## Why It's Good For The Game
For players: 
- Alt clicking should work more logically, not causing double actions
like eject disk and open item window
- Added context menus for reskinnable items
- Removed adjacency restriction on loot panel

For devs:
- Makes alt click interactions easier to work with, no more click chain
nonsense and redundant guard clauses.
- OOP hell reduced
- Pascal Case reduced
- Glorious snake case

## Changelog
🆑
add: The lootpanel now works at range.
add: Screentips for reskinnable items.
fix: Alt click interactions have been refactored, which may lead to
unintentional changes to gameplay. Report any issues, please.
/🆑
2024-04-16 17:48:03 -06:00
orangesandGitHub 46d6daf524 Fix set_light colour parameters for ethereal disco ball (#81326)
🆑 optimumtact, whomst didn't write this CL entry.
fix: Fixed the colorful lights of the ethereal disco ball.
/🆑
2024-02-08 00:51:50 +01:00
jimmylandGitHub 549b83b78d ethereal disco ball altclick sanity (#81268)
## About The Pull Request

im getting tired of writing this but you may no longer altclick to
unanchor or anchor when crit or at range or otherwise

## Why It's Good For The Game

bug bad

## Changelog
🆑
fix: you may no longer altclick ethereal disco balls while unconscious
to anchor/unanchor
/🆑
2024-02-05 12:12:51 -05:00
YesterdaysPromiseandGitHub 71a1fee2f1 Explodes device.dmi (#80025)
## About The Pull Request

I woke up today and thought 'what would be easy thing to do today so I
can say I've done something?'. Then I remembered I saw several gangtool
usages the time I split radio up, and I could remedy those. 7 hours
later, device.dmi is split in a folder of its own, and I've also given
unique sprites to door remotes and landing desginators.


## Why It's Good For The Game

The device.dmi was kind of a mess.

## Changelog

🆑
/🆑
2023-12-09 13:31:50 +01:00
41f20bc3ce [MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request

Hello friends, I've been on a bit of a lighting kick recently, and I
decided I clearly do not have enough things to work on as it is.
This pr adds angle support to static lights, and a concepting/debug tool
for playing with lights on a map.

Let's start from first principles yeah?

### Why Angled Lights?

Mappers, since they can't actually see a light's effect in editor, tend
to go off gut.
That gut is based more off what "makes sense" then how things actually
work
This means they'll overplace light sources, and also they tend to treat
lights, particularly light "bars" (the bigger ones) as directional.
So you'll have two lights on either sides of a pillar, lights inside a
room with lights outside pointing out, etc.


![image](https://user-images.githubusercontent.com/58055496/228785032-63b86120-ea4c-4e52-b4e8-40a4b61e5bbc.png)

This has annoying side effects. A lot of our map is overlit, to the
point that knocking out a light does.... pretty much nothing.
I find this sad, and would like to work to prevent it. I think dark and
dim, while it does not suit the normal game, is amazing for vibes, and I
want it to be easier to see that.

Angled lights bring how lights work more in line with how mappers expect
lights work, and avoids bleedover into rooms that shouldn't be bled
into, working towards that goal of mine.

### How Angled Lights?

This is more complex then you'd first think so we'll go step by step


![image](https://user-images.githubusercontent.com/58055496/228786117-d937b408-9bc2-4066-9aee-aae21b047151.png)

Oh before we start, some catchup from the last time I touched lighting
code.
Instead of doing a lighting falloff calculation for each lighting corner
(a block that represents the resolution of our lights) in view we
instead generate cached lightsheets. These precalculate and store all
possible falloffs for x and y distances from a source.

This is very useful for angle work, since it makes it almost totally
free.
 
Atoms get 2 new values. light_angle and light_dir
Light angle is the angle the light uses, and light_dir is a cardinal
direction it displays in

We take these values, and inside sheetbuilding do some optional angle
work. getting the center angle, the angle of a pair of coords, and then
the delta between them.
This is then multiplied against the standard falloff formula, and job
done.

We do need some extra fenangling to make this all work nicely tho.

We currently use a pixel turf var stored on the light source to do
distance calculations.
This is the turf we pretend the light source is on for visuals, most
often used to make wall lights work nice.
The trouble is it's not very granular, and doesn't always have the
effect you might want.

So, instead of generating and storing a pixel turf to do our distance
calculations against, we store x and y offset variables.
We use them to expand our working range and sheet size to ensure things
visually make sense, and then offset any positions by them.

I've added a way for sources to have opinions on their offsets too, and
am using them for wall lights.
This ensures the angle calculations don't make the wall behind a light
fulldark, which would be silly.

### Debug Tool?

In the interest of helping with that core problem, lights being complex
to display, I've added a prototyping tool to the game.
It's locked behind mapping verbs, and works about like this.

Once the verb is activated, it iterates over all the sources in the
world (except turfs because those are kinda silly), outlining and
"freezing" them, preventing any future changes.
Then, it adds 3 buttons to the owners of a light source.

![image](https://user-images.githubusercontent.com/58055496/228776539-4b1d82af-1244-4ed6-8754-7f07e3e47cda.png)
The first button toggles the light on and off, as desired.
The third allows you to move the source around, with a little targeting
icon replacing your mouse
The second tho, that's more interesting.

The second button opens a debug menu for that light

![image](https://user-images.githubusercontent.com/58055496/228777811-ae620588-f08a-4b50-93a0-beea593aea77.png)
There's a lot here, let's go through it.

Bit on the left is a list of templates, which allow you to sample
existing light types (No I have no idea why the background is fullwhite,
need to work on that pre merge)
You can choose one by clicking it, and hitting the upload button.

This replaces your existing lighting values with the template's,
alongside replacing its icon and icon state so it looks right.
There are three types as of now, mostly for categorization. Bar, which
are the larger typically stronger lights, Bulb, which are well, bulbs,
and Misc which could be expanded, but currently just contains floor
lights.

Alongside that you can manually edit the power, range, color and angle
of the focused light.
I also have support for changing the direction of the light source,
since anything that uses directional lighting would also tie light dir
to it.
This isn't *always* done tho, so I should maybe find a way to edit light
dir too.

My hope is this tool will allow for better concepting of a room's
lights, and easier changing of individual object's light values to suit
the right visuals.

### Lemon No Why What

Ok so I applied angle lights to bars and bulbs, which means I am
changing the lighting of pretty much every map in the codebase.
I'm gonna uh, go check my work.

Alongside this I intend to give lighting some depth. So if there's room
to make a space warmer, or highlight light colors from other sources, I
will do that.

(Images as examples)

![image](https://user-images.githubusercontent.com/58055496/228786801-111b6493-c040-4199-ab99-ac1c914d034c.png)

I also want to work on that other goal of mine, making breaking lights
matter. So I'll be doing what I can to ensure you only need to break one
light to make a meaningful change in the scene.

This is semi complicated by one light source not ever actually reaching
fullbright on its own, but we do what we must because we can.


![image](https://user-images.githubusercontent.com/58055496/228786483-b7ad6ecd-874f-4d90-b5ca-6ef78cb70d2b.png)

I'm as I hope you know biased towards darker spaces, I think contrast
has vibes.
In particular I do not think strong lights really suit maintenance. 

Most of what is used there are bulbs, so I'm planning on replacing most
uses with low power bulbs, to keep light impacts to rooms, alongside
reducing the amount of lights placed in the main tunnels


![image](https://user-images.githubusercontent.com/58055496/228786594-c6d7610c-611e-478b-bcba-173ebf4c4b12.png)

**If you take issue with this methodology please do so NOW**, I don't
want to have to do another pass over things.
Oh also I'm saving station maps for last since ruins are less likely to
get touched in mapping march and all.

### Misc + Finishing Thoughts

Light templates support mirroring vars off typepaths using a subtype,
which means all the templates added here do not require updating if the
source type changes somehow. I'd like to expand the template list at
some point, perhaps in future.

I've opened this as a draft to make my intentions to make my changes to
lights known, and to serve as motivation for all the map changes I need
to do.

### Farish Future

I'm unhappy with how we currently configure lights. I would like a
system that more directly matches the idea of drawing falloff curves,
along with allowing for different falloffs for different colors,
alongside extending the idea to angle falloff.
This would make out of engine lighting easier, allow for nicer looking
lights (red to pink, blue to purple, etc), and improve accessibility by
artists.

This is slightly far off, because I have other obligations and it's
kinda complicated, but I'd like to mention it cause it's one of my many
pipedreams.

## Changelog
🆑
add: Added angle lighting, applies it to most wall lights!
add: Adds a lighting prototyping tool, mappers go try it out (it's
locked behind the mapping verb)
/🆑

---------

Co-authored-by: MMMiracles <lolaccount1@hotmail.com>
2023-07-19 04:39:55 +00:00
4d6a8bc537 515 Compatibility (#71161)
Makes the code compatible with 515.1594+

Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword

And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.

@tgstation/commit-access Since the .proc/stuff is pretty big change.

Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
2022-11-15 03:50:11 +00:00
tralezabandGitHub 6c01cc2c01 every case of initialize that should have mapload, does (#61623)
## About The Pull Request

stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it

for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload

![](https://media.discordapp.net/attachments/823293417186000909/875122648605147146/image0.gif)

## Regex used:

procs without args, not even regex

`/Initialize()`

procs with args
`\/Initialize\((?!mapload)((.)*\w)?`

cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
2021-09-24 17:56:50 -04:00
Watermelon914andGitHub 375a20e49b Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.

Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.

(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
2021-06-14 13:03:53 -07:00
TemporalOroborosandGitHub e4079c87b8 update_appearance (#55468)
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
2021-02-19 12:06:18 -03:00
LemonInTheDarkandGitHub 5c22a0cfc1 Converts many proc overrides to properly use list/modifiers, lots of other smaller things (#56847)
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.
2021-02-16 09:18:46 -05:00
4b6500fb67 Makes all anchored changes use setAnchored(), COMSIG_MOVABLE_SETANCHORED now only sent if an AM's anchored var has changed for more reliable usage. (#52254)
* Converts everything to use setAnchored() + other fixes

* Fixed singulo debug

* singulo again

* forgot to move the vv_edit proc

* caught that this time :)

* changes

* Update code/game/atoms_movable.dm

Co-authored-by: Rohesie <rohesie@gmail.com>

Co-authored-by: Rohesie <rohesie@gmail.com>
2020-07-21 02:20:26 -03:00
MrPersonandEmmett Gaines e22560a346 update_icon() improvements (#48669)
* 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.
2020-01-11 23:46:43 -05:00
Unknown dcbbfa81f6 reee 2018-12-23 17:49:11 +01:00
QustinnusandGitHub 30f22b5f1a yeet 2018-12-23 17:42:40 +01:00
QustinnusandGitHub 954ba5c76b wtf did i fuck up 2018-12-18 23:40:30 +01:00
8092369539 Update code/game/objects/items/etherealdiscoball.dm
Co-Authored-By: Qustinnus <Floydje123@hotmail.com>
2018-12-18 22:36:56 +01:00
Unknown a46e1881c4 done 2018-12-16 18:58:36 +01:00
Unknown 7f586323cc discomode 2018-12-16 18:11:47 +01:00