Instead of paintings lasting 1000 shifts before being deleted
Now the system will store up to 1000 paintings, and remove the one at the top of the list (the earliest/oldest one) first when the maximum number of paintings is exceeded.
Additionally, examining a painting that has been stored will move it to the bottom of the list, effectively renewing its lease in the system.
This should make it so that paintings aren't just arbitrarily being removed for being old, and, the paintings that actually get looked at should stick around.
adds what is effectively a rebalanced sword.
instead of being in sword family it's in two handed, and allows some tricks.
Like most two handed weapons it gains a damage boost if wield. At 0.3 sharpness it will be as powerful as machete of similar material. Minus the cleave effect. If held with something in your other hand it does 0.1 sharpness, a third of the machete.
Also the parry ability ONLY works if wielded. So you can't use it with a shield or a second parry item. You can't even parry if you have a gun or pen in the other hand.
so pros
can parry
cons
needs an empty hand to parry
if used one handed is 1/3 as powerful as stock gear
starts out as steel and needs mats to upgrade
So, I am not sure how much this will help or hurt.
We have noticed that, there is a lot of lag that happens under heavy radio use, and Ascian noted that the playsound proc was seriously overloaded during those times.
Notably, presently every radio in the game uses playsound to play the radio sound any time anything sends a radio message, even if the radio in question doesn't have the channel the message was sent to.
And if you are unaware, playsound figures out who's in range of every source of sound and their distance from its source to adjust the sounds so that it sounds like it's coming from the right place in the world.
Problem is, if the server's decently busy, that's possibly a hundred things doing that work every time any message comes over a radio.
I thought it would be better if, since the radio systems are ALREADY doing the work of figuring out who can see the radio message, that playsound doesn't actually need to do that work again for tons of different sources.
ADDITIONALLY, the thing to determine if the sound should be played based on preferences is also a part of playsound, meaning that it STILL RUNS PLAYSOUND EVEN IF THE PREFERENCE IS OFF
So! I used byond's direct sound thing which, I THINK just makes your client play the sound and ought to use next to no extra server resources for it.
The only downside is that we lose pitch shifting on the radio sounds, and we lose the sense of 'audio presence' for the sounds in the world.
In short, this means that the radio sound will just, always sound the same no matter where it is in relation to your character. If you receive a radio message, the sound will play on your client.
The sound should also only ever play once for you per message, rather than stacking like it does when lots of people/radios are in the same place.
ASSUMING THIS WORKS HOW I THINK IT DOES, this should reduce a lot of computer work for playsound on busy shifts. (And ideally, increase performance)
This change does also use and respect the same preference that already exists for radio sounds, so there will be no change in how that works.
The item bank doesn't store what such things are made out of, and so, such things will not be correct when retrieved.
This does not block things from being stored when made from the common crafting menu though, since those things spawn a defined item type instead of setting up material properties.
a primitive shield, perfect for the next knights at castle mystic event.
it's much less cool, there's no metal ones. but it's literally the only low tech shield in our code right.
No really all other shields are made of plastic like the riot shield, or energy like halo jackles.
anyway it has 10 lower block chance than the explo shield and 20 less than riot. It's planks off wood and a bucket tied together
This undoes my fix for the corporate sofas specifically. Their object subtyping is awful, but there is enough redundant code in there to make the layers work correctly for them anyway.
Sofas used to have really weird subtypes, now they correctly inherit from either the base (middle), left, right, or corner, which solves the issue with layers on the non-red corner sofas (which red sofas were exempt from due to them being the base object type).
