Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space Piano will NOT play G# (steps to fix included) #704

Closed
sararar opened this issue Jun 2, 2013 · 1 comment
Closed

Space Piano will NOT play G# (steps to fix included) #704

sararar opened this issue Jun 2, 2013 · 1 comment
Labels
Bug Correct Functionality Sound Oh god my ears, they bleed, did you normalise the volume?

Comments

@sararar
Copy link
Contributor

sararar commented Jun 2, 2013

Revision:

Server:
Yogstation

Problem Description:
The note G# does not work when put into the space piano.

What did you expect to happen?
I expected the piano to play the Ab file of the same octave. (For those not musically inclined, A flat and G sharp are the same note. The sound files for this game only uses naturals and flats)

What happened instead?
When the piano was meant to play G#, it didn't play anything.

Why is this bad/What are the consequences?
If you want to code a song that uses G#, you have to put Ab instead, which is just annoying since any “proper” As in the piece are likely to need to be natural or sharp. Or, you can code the song properly and have missing notes that just make it sound wrong.

Steps to reproduce the problem:

  1. Paste “C#5,D#5,E#5,F#5,G#5,A#5,B#5,C6” into the space piano. (Lower the tempo for easier listening)
  2. Hit play, and hear all the notes play except G#. (Can use www.onlinepianist.com/virtual_piano/ to confirm correct notes are being played)
  3. Wonder why it didn’t play G#.

Possibly related stuff:
The .dm file contains this bit of code to handle converting G#

else if(acc == "#") // mass convert all sharps to flats, octave jump already handled
    acc = "b"
    note++

If you read that you can see that if I put in, say, A#, it’s going to play the next higher note as a flat: Bb. However the notes are numbered 1-7 with G being 7. This means if you put in G#, the space piano will try to play note 8 as a flat, when there is no note 8.

This can be fixed by changing the code as follows:

else if(acc == "#" && (note == 7)) //G#
    note = 1
    acc = "b"
else if(acc == "#") // mass convert all sharps to flats, octave jump already handled
    acc = "b"
    note++

The appropriate .dm file is found at code/game/objects/structures/musician.dm
I’ve tested this change and it works exactly the way it’s supposed to.

Anything else?
Please, please use my—or another—fix since I love coding songs for the space piano <3
I would make a pull request but I'm not entirely sure how or if I even can, so hopefully someone will spot this and correct the code :)

sararar added a commit to sararar/-tg-station that referenced this issue Jun 20, 2013
…e piano. tested and works.

Signed-off-by: sararar <sarajfarr@gmail.com>
Giacom added a commit that referenced this issue Jun 22, 2013
@sararar
Copy link
Contributor Author

sararar commented Jun 27, 2013

Resolved. this can be closed now <3

@sararar sararar closed this as completed Jun 27, 2013
LemonInTheDark pushed a commit to LemonInTheDark/tgstation that referenced this issue Dec 12, 2021
…not just moldy messes. (tgstation#704)

* Food decomposition can mold stuff into different items, and not just moldy messes. (tgstation#61233)

Originally the component only allowed food to decompose into the generic moldy mess. This PR changes the component so that what item the component decomposes something into can be changed per attached object. I've added a few examples; bread types > moldy bread, pizza slice types > moldy pizza slices, dead mice > moldy dead mice (they need a sprite still, I'll get to that later. Kinda catbrained rn.)

edit:
Makes sure that none of this moldy food touches cytology unnecessarily.

Rotten eggs have been added (decomposed eggs), along with rotten boiled eggs. The only way to determine if an egg is good or not requires using a container of water on the egg. If it floats, it's rotten! They also do not produce ants when they decompose, so chickens no longer get eaten alive by swarms of ants for producing all these eggs.

fixes tgstation#61188

* Food decomposition can mold stuff into different items, and not just moldy messes.

Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
LemonInTheDark pushed a commit to LemonInTheDark/tgstation that referenced this issue Mar 12, 2023
…nother when looking EAST or WEST (tgstation#66607) (tgstation#704)

So, for over 5 years, left legs have been displaying over right legs. Never noticed it? Don't blame you.
Here's a nice picture provided by tgstation#20603 (Bodypart sprites render with incorrect layering), that clearly displays the issue that was happening:

It still happened to this day.
Notice how the two directions don't look the same? That's because the left leg is always displaying above the right one.

Obviously, that's no good, and I was like "oh, that's a rendering issue, so there's nothing I can do about it, it's an issue with BYOND".

Until it struck me.

"What if we used a mask that would cut out the parts of the right leg, from the left leg, so that it doesn't actually look as if it's above it?"

Here I am, after about 25 hours of work, 15 of which of very painful debugging due to BYOND's icon documentation sucking ass.

So, how does it work?

Basically, we create a mask of a left leg (that'll be explained later down the line), more specifically, a cutout of JUST the WEST dir of the left leg, with every other dir being just white squares. We then cache that mask in a static list on the right leg, so we don't generate it every single time, as that can be expensive. All that happens in update_body_parts(), where I've made it so legs are handled separately, to avoid having to generate limb icons twice in a row, due to it being expensive. In that, when we generate_limb_icon() a right leg, we apply the proper left leg mask if necessary.

Now, why masking the right leg, if the issue was the left leg?
Because, see, when you actually amputated someone, and gave them a leg again, it would end up being that new leg that would be displayed below the other leg. So I fixed that, by making it so that bodyparts would be sorted correctly, before the end of update_body_parts(). Which means that right legs ended up displaying above left legs, which meant that I had to change everything I had written to work on right legs rather than left legs.

I spent so much time looking up BYOND documentation for MapColors() and filters and all icon and image vars and procs, I decided to make a helper proc called generate_icon_alpha_mask(), because honestly it would've saved me at least half a day of pure code debugging if I had it before working on this refactor.

I tried to put as much documentation down as I could, because this shit messes with your brain if you spend too long looking at it. icon and image are two truly awful classes to work with, and I don't look forward to messing with them more in the future.

Anyway. It's nice, because it requires no other effort from anyone, no matter what the shape of the leg is actually like. It's all handled dynamically, and only one per type of leg, meaning that it's not actually too expensive either, which is very nice. Especially since it's very downstreams-friendly from being done this way.


It fixes tgstation#20603 (Bodypart sprites render with incorrect layering), an issue that has been around for over half a decade, as well as probably many more issues that I just didn't bother sifting through.

Plus, it just looks so much better.

Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Correct Functionality Sound Oh god my ears, they bleed, did you normalise the volume?
Projects
None yet
Development

No branches or pull requests

1 participant