* offical to official (#78762)
## About The Pull Request
Fixes "offical" to "official" in several locations - admin fax panel,
admin newscaster, art patron text, a photocopier template, and a corgi
tail pin item description. Adds this common misspelling to the
check_grep.sh ci tool.
## Why It's Good For The Game
I have corrected the typo manually every single time I have sent a fax
from Central Command.
## Changelog
🆑
spellcheck: "offical" has been officially corrected to "official" in
several official locations.
/🆑
* offical to official
---------
Co-authored-by: Isratosh <Isratosh@hotmail.com>
* Progress bars & cleaning particles will centre on the tile occupied by large icon objects (#77940)
## About The Pull Request
Do_after bars always draw based on the top-left corner of the targetted
atom, for atoms with sprites that are larger than 32x32 this gives them
a weird offset instead of being centred, which bugs me.
I have tried my best to figure out a way to reverse this which does not
interfere with atoms which use pixel_x/pixel_y to visually appear to be
on a different tile.
## Why It's Good For The Game
Before:
he hates how you missed him completely 😦
After:
now you're cleaning his feet 🙂
## Changelog
🆑
image: progress bars and cleaning particles are now centered on the tile
occupied by the target, if it is a big sprite
/🆑
* Progress bars & cleaning particles will centre on the tile occupied by large icon objects
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Sets a saner length limit to ID assignments and paintings' titles. (#76723)
* Sets a saner length limit to ID assignments and paintings' titles.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* [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.
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
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.
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
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)
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.
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
**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>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool
* Update north_star.dmm
* Revert "Update north_star.dmm"
This reverts commit bb5b8b5a549f7edc3e23a369a147ed96bab41991.
* Updatepaths
* Update nukie_base.dmm
* Newer version of northstar with the penguins
* Update northstar_cryo.dmm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Standardize Welder Fuel Usage (#76021)
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
* Standardize Welder Fuel Usage
---------
Co-authored-by: Couls <coul422@gmail.com>
The Canvas UI now shows a grid while the user is painting. (#75604)
A grid is shown while the user is holding a painting tool on an editable
canvas. This is achieved by drawing empty rectangles after the filled
ones are placed whenever the canvas is updated and if requirements are
met.
It's by no mean perfect, especially since the strokeStyle is a mere
"#888888" hexcolor, the contrast may get low around colors of similar
lightness. But I don't think I've much the strength to seek out a
fancier solution to a peeve that's hardly a botherance anyway while the
canvas is still mostly white.
I've also had a maintainer suggest me to make a toggle to
disable/enable. I talked a bit how that'd be a bit more complex to
integrate but not much so frankly, although switching hands or putting
away the tool already works for that. That said, I'm willing to do it if
player feedback suggests such toggle should be integrated.
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Adds a eye-dropper right-click function to the painting canvas. (#75571)
## About The Pull Request
Having used the painting UI to kill some time during long rounds for a
decent chunk of the past year, the need of a quicker and less tedious
way to fix a misclick or mistake like drawing over the wrong pixel has
become clear to me, as well as getting some feedback on the palette
component I made last year.
As the title suggests, this PR adds an eye-dropper function to the
canvas. Right-Click a pixel on the canvas, and the painting tool will
copy its color. Simple as, works on both finished and unfinished
paintings.
As a bonus, you can also right-click one of those selectable
white/colored squares on the color scheme near the bottom of the UI (if
using spraycan/palette) to change its color without having to go back to
main game window and a radial menu.
EDIT: With the tooltip added to the UI, I can say it's ready.
## Why It's Good For The Game
This PR aims to add better options to change colors on the go and
improve the user experience on the painting UI.
## Changelog
🆑
qol: Adds a eye-dropper-like right-click function to the painting canvas
UI. Right-Click a pixel on the canvas while holding a painting tool to
have it copy its color.
qol: Also adds a right-click function to the color palette at the bottom
of the UI to allow users to set its colors without having to alternate
between the game window and the UI.
qol: Lastly, a tooltip has been added near the top-left corner of the
same UI to let players know of these features.
/🆑
* Adds a eye-dropper right-click function to the painting canvas.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Fixes 'Paintings leaving their frames #74707' (#75558)
## About The Pull Request
See the title and the relative bug report. Yes, this is a webedit.
The relative lines were removed by #74538. The author of that PR had
apparently read the typepath wrong and therefore thought it was
redundant (they were adding the TRAIT_KEEP_TOGETHER to canvases).
## Why It's Good For The Game
This will close#74707. Bugfix.
## Changelog
🆑
fix: Fixed large paintings looking pretty off while flipped E/W.
/🆑
* Fixes 'Paintings leaving their frames #74707'
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Makes a whole bunch of wooden objects flammable (#74827)
## About The Pull Request
This whole PR started because I realized that baseball bats are not
actually flammable which I found weird, then I looked at a whole bunch
of other stuff that really should be flammable but also isn't.
## Why It's Good For The Game
Makes wooden objects behave slightly more consistently? Honestly, most
of these seem like oversights to me.
## Changelog
🆑
balance: The following structures are now flammable: Picture frame,
fermenting barrel, drying rack, sandals, painting frames, paintings,
spirit board, notice board, dresser, displaycase chassis, wooden
barricade
balance: The following items are now flammable: Baseball bat, rolling
pin, mortar, coffee condiments display, sandals, wooden hatchet, gohei,
popsicle stick, rifle stock
/🆑
* Makes a whole bunch of wooden objects flammable
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
* Fixed Normal sized paintings not appearing on the ground (#74538)
* Fixed Normal sized paintings not appearing on the ground
---------
Co-authored-by: Squishy <linkoisin@gmail.com>
* Painting don't get finalized when naming is cancelled. (#74178)
* Painting don't get finalized when naming is cancelled.
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Buff scythes, goats, and plantbgone vs PLANT biotypes (#72889)
This buffs scythes, goats, and plantbgone vs PLANT biotypes:
- Scythes now deal x1.5 damage to venus flytraps (3 hits to kill)
- Scythes now target the flower bud vines
- Goats now target flower bud vines and deal 15 damage to PLANT biotypes
- Goats have a eating sound whenever they bite PLANT biotypes
- Plantbgone now does 2 dmg per unit to PLANT biotypes (10 dmg per
spray)
- Plantbgone now has a 75% chance to remove weeds and deals large damage
to flower buds
- Weed control crates now come with a pair of leather gloves
- Golems are immune to thorn effects
- Any kind of thick glove material will prevent thorn effects when
attacking
- Flower buds will now take x4 damage from fire and sharp weapons
(unless they have fire trait)
- Regular scythes are now a sharp object
Also this fixes a few runtimes with spacevines and nulls. The bane
element now accepts `mob_biotypes` bitflags as an argument.
Before my changes:
- Plant-b-gone was doing 0.4 dmg per unit to PLANT biotypes (2 dmg per
spray)
- Scythes took 5 hits to kill venus flytraps
- Goats only affected podpeople
- Flower bud vines were being ignored by weed killing code
- Plantbgone only had a 50% chance to remove weeds (and this was very
inconsistent due to RNG)
- Botanical gloves and thick gloves didn't protect from thorns
- Golems were getting pierced by thorns despite having pierce immunity
- Flower buds were not taking the x4 damage like they should have been
- Regular scythes were not a sharp object, but other scythes
(chaplain's, megafauna loot) were sharp
This makes the weed killer crate more effective since people were
complaining about it being worthless vs vines and flower buds. These
changes give people more options to respond to threats vs plants.
🆑
add: Add a pair of leather gloves to weed control crate
balance: Mobs with the PLANT biotypes (venus flytraps, pod people,
killer tomatoes) are now much weaker vs scythes, goats, and plantbgone.
balance: Plantbgone is now more effective at destroying weeds.
balance: Regular scythes are now a sharp object
fix: Fixed scythes, goats, and plantbgone not affecting flower bud
vines.
fix: Thick and botanical gloves not protecting from thorns
fix: Golems not having pierce immunity from thorns
fix: Runtime where vines tried to spread into null turf
fix: Runtime where null vines that were destroyed were trying to spread
to nearby turfs
soundadd: Add eat food sound when goats eat plants
code: Improved goat targeting code
code: The bane element now accepts `mob_biotypes` bitflags as an
argument.
/🆑
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
Chisel and Statue Improvements (#72638)
## About The Pull Request
Resolves#72607Resolves#65701
Chisels and statues had quite a few bugs and they lacked any kind of
feedback system to inform the user on it's proper usage. My improvements
do the following:
- Chisels now give balloon alerts when selecting a target, cancelling,
or sculpting
- Chisels used on carving blocks that were interrupted will now continue
- Fixed abstract statues not letting people use the radial menu
- Fixed chisel targets to have no range requirement (so you can use
binoculars, cameras, etc.)
- Refactor a lot of the chisel and statue code to be more robust
- Add sculpting sounds when chisels are used on carving blocks
## Why It's Good For The Game
Less bugs and now people can now sculpt easier.
## Changelog
🆑
soundadd: Chisels now make sculpting sounds when used on carving blocks
qol: Chisels now give balloon alerts when selecting a target,
cancelling, or sculpting
qol: Chisels used on carving blocks that were interrupted will now
continue
fix: Fix chisel targets to have no range requirement (so you can use
binoculars, cameras, etc.)
fix: Fix standard mineral blocks (uranium, diamond, plasma, etc.) not
letting people use the radial menu to craft abstract statues properly.
This does not work with custom mineral blocks. (pizza, glass, etc.)
code: Change chisel and statue code to be more readable
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* fixes chisels (#72632)
## About The Pull Request
chisels used to only work when clicking on away stuff
mothblocks broke them and made them only work on close stuff
fixes that
## Why It's Good For The Game
yippe
## Changelog
🆑
qol: fixes chisels
/🆑
* fixes chisels
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Adds a helper for base_pixel sets in typepaths that ensures the offset is autoapplied to pixel_x/y (#72309)
## About The Pull Request
This was an issue on wallening and I figured I should fix it at the root
Look ma I'm upstreaming
* Adds a helper for base_pixel sets in typepaths that ensures the offset is autoapplied to pixel_x/y
* update modular
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* AI Universal Standard canvas will now show it's canvas size on the item name (#70868)
## About The Pull Request
This PR adds the canvas size to the name of the AI canvas from "canvas
(AI Universal Standard)" to "canvas (24x24) (AI Universal Standard),
making it consistent with other types of canvases which has their own
size on their name.
## Why It's Good For The Game
Consistency, every other canvases has their size on their name except
for this one.
Also makes it easier to distinguish the difference between this and the
other canvases.
## Changelog
🆑
spellcheck: AI Universal Standard canvas will now specify it's size on
the item name.
/🆑
* AI Universal Standard canvas will now show it's canvas size on the item name
Co-authored-by: Hardly3D <66234359+Hardly3D@users.noreply.github.com>
* Adds a QM statue, as all other heads have one. (#70744)
* Adds a QM statue, bringing it on par with every other head of staff.
* Adds a QM statue, as all other heads have one.
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
* Fixes 118(give or take) cases of mapload not being passed to initilaize (#69107)
fixes 114 cases of mapload not being passed to initilaize
* Fixes 118(give or take) cases of mapload not being passed to initilaize
* Fixes a lot (give or take) cases of mapload not being passed to initilaize
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Fixes statue simplemob teleport not working and 3 other spells not appearing (#67105)
* Fixes statue simplemob not being able to teleport, and their 3 spells they're supposed to have.
* Also repaths statues to netherworld mobs, to reduce copy paste code.
* Fixes statue simplemob teleport not working and 3 other spells not appearing
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
* Parallax but better: Smooth movement cleanup (#66567)
* Alright, so I'm optimizing parallax code so I can justify making it do a
bit more work
To that end, lets make the checks it does each process event based.
There's two. One is for a difference in view, which is an easy fix since
I added a view setter like a year back now.
The second is something planets do when you change your z level.
This gets more complicated, because we're "owned" by a client.
So the only real pattern we can use to hook into the client's mob's
movement is something like connect_loc_behalf.
So, I've made connect_mob_behalf. Fuck you.
This saves a proc call and some redundant logic
* Fixes random parallax stuttering
Ok so this is kinda a weird one but hear me out.
Parallax has this concept of "direction" that some areas use, mostly
the shuttle transit ones. Set when you move into a new area.
So of course it has a setter. If you pass it a direction that it doesn't
already have, it'll start up the movement animation, and disable normal
parallax for a bit to give it some time to get going.
This var is typically set to 0.
The problem is we were setting /area/space's direction to null in
shuttle movement code, because of a forgotten proc arg.
Null is of course different then 0, so this would trigger a halt in
parallax processing.
This causes a lot of strange stutters in parallax, mostly when you're
moving between nearspace and space. It looks really bad, and I'm a bit
suprised none noticed.
I've fixed it, and added a default arg to the setter to prevent this
class of issue in future. Things look a good bit nicer this way
* Adds animation back to parallax
Ok so like, I know this was removed and "none could tell" and whatever,
and in fairness this animation method is a bit crummy.
What we really want to do is eliminate "halts" and "jumps" in the
parallax moveemnt. So it should be smooth.
As it is on live now, this just isn't what happens, you get jumping
between offsets. Looks frankly, horrible. Especially on the station.
Just what I've done won't be enough however, because what we need to do
is match our parallax scroll speed with our current glide speed. I need
to figure out how to do this well, and I have a feeling it will involve
some system of managing glide sources.
Anyway for now the animation looks really nice for ghosts with default
(high) settings, since they share the same delay.
I've done some refactoring to how old animation code worked pre (4b04f9012d). Two major
changes tho.
First, instead of doing all the animate checks each time we loop over a
layer, we only do the layer dependant ones. This saves a good bit of
time.
Second, we animate movement on absolute layers too. They're staying in
the same position, but they still move on the screen, so we do the same
gental leaning. This has a very nice visual effect.
Oh and I cleaned up some of the code slightly.
* Parallax but better: Smooth movement cleanup
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Removes over/underlays on special planes from statues. (#66003)
* Removes over/underlays on special planes from statues.
* alright
* Removes over/underlays on special planes from statues.
Co-authored-by: AnturK <AnturK@users.noreply.github.com>
* Changes the values of the pen colour variable from color name to hexadecimal (#65553)
About The Pull Request
See the title. Hexadecimal values are better than color names for programming since they can be sanitized and are more easily converted to RGB(A) or HSV. Color names aren't really meant to be used in some functions and methods about colors.
TL;DR: color names don't work with the Color common package in the TGUI folder.
Why It's Good For The Game
This will remove the need of a hacky bandaid from /obj/item/canvas/proc/get_paint_tool_color that only covers about half the pen colors anyway.
Changelog
cl
fix: Fixed certain pens breaking painting on a canvas because of their peculiar colors.
/cl
* Changes the values of the pen colour variable from color name to hexadecimal.
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Becoming the patron of a painting now lets you select a different, persistent appearance for the frame it's in. (#65305)
* Painting frame selection for patrons, painting json version update.
* Becoming the patron of a painting now lets you select a different, persistent appearance for the frame it's in.
* fix unit test
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: John Doe <gamingskeleton3@gmail.com>
* Painting improvement: Added a palette component for spraycans and palette items. (#65577)
* Painting improvement: Added a palette component for spraycans and palettes.
* Painting improvement: Added a palette component for spraycans and palette items.
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Change hydroponics tray and chem dispenser AltClick behavior to be used by RMB (#64939)
* Change hydroponics tray and chem dispenser AltClick behavior to be used by RMB
Co-authored-by: Tim <timothymtorres@gmail.com>
* Refactors pay stands + custom vendors (#63889)
I am disgruntled by the way pay stations work. They're not intuitive, they're a pain to build and have no interface. Basically: They don't get made, and the potential is lost.
Pay stands => Holopay
Summoned by right clicking your ID
Disappears if the card is out of range.
New TGUI window that offers more customization
Other bundled fixes:
Custom vendors become more user friendly
Code improvement
Lots of documentation + refactoring
New bundled number input will likely take place of animated number in tgui input number
Why It's Good For The Game
More RP opportunity for players, plus bug fixes. It's now much easier for players to start their own in game business selling substances clown shoes.
Changelog
cl
code: Created a new input component that accepts only integers. More usage to come.
refactor: Pay stands are now holographic. It's 2562! Create one by right-clicking your ID.
del: Circuit boards for pay stands.
refactor: Pay stands now have their own TGUI.
fix: Custom vendors now alert you when someone makes a purchase.
fix: Custom vendors now place items in your hand when you make a purchase.
/cl
* Refactors pay stands + custom vendors
* I edited these maps in a text editor
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
