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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MIRROR] Fix pride pin reskinning #2382

Merged
merged 2 commits into from
May 8, 2024
Merged

Conversation

NovaBot13
Copy link
Collaborator

Original PR: tgstation/tgstation#82920

About The Pull Request

Edit: Since writing, this pr has been updated to address failing CI based on code-general suggestions, invalidating the previous descriptions. The previous descriptions has been included as spoilers for posterity

Right, so, this has gone from just a simple pride pin fix to realizing CI fails with it to doing a more complex lasting fix based on suggestions.

Recap time. Objects get reskinning set up if they have unique_reskin set when Initialize(...) runs.
https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/game/objects/items.dm#L267-L269
Because pride pins use a global list, we set it in Initialize(...)... After we call the parent.
https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/modules/clothing/under/accessories/badges.dm#L196-L198
Obviously this fails.

However, moving this before Initialize(...), while fixing the issue, causes CI to fail due to calling register_context() twice.
Why? Well, it's simple. We automatically call register_context() if we have unique_reskin set, as seen above, but we also call it on accessory Initialize(...) due to it having its own context.
https://github.com/tgstation/tgstation/blob/0c562fd74299f8ce92a81c0a932b8ec4862189af/code/modules/clothing/under/accessories/_accessories.dm#L29-L31
This causes it to try register the same thing twice, which doesn't break things, but it sure as hell isn't clean.

So talking about this with San in code general, we decided to try go with the following:
We add two new procs, setup_reskinning() and check_setup_reskinning(), and handle all this fuckery within those.
This lets subtypes override them with their own new checks or differences in setup.
Then we override setup_reskinning() for /obj/item/clothing/under and /obj/item/clothing/accessory to not register context again, and do the same for /obj/item/clothing/accessory/pride but while also setting unique_reskin.

This fixes it.

Previous implementation for posterity

Back from my short code break, time to fix some of the things I've been annoyed by.

Firstly, I noticed pride pins could no longer be reskinned since the alt-click refactor.
Looking into it, this seems to be because we now only register this on Initialize(...) if unique_reskin has been set:
https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/game/objects/items.dm#L267-L269
While due to using a global list we don't set this in the item definition, but in Initialize(...) :
https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/modules/clothing/under/accessories/badges.dm#L196-L198
Where we call the parent proc before setting unique_reskin, and thus not registering our ability to reskin.

So all we do is set this to our global list before we call the parent proc.

/obj/item/clothing/accessory/pride/Initialize(mapload)
	unique_reskin = GLOB.pride_pin_reskins // Set before parent proc checks for it.
	. = ..()

This fixes it.

Why It's Good For The Game

Fixes pride pin reskinning.
Theoretically makes it easier to avoid this happening in the future, and allows setup_reskinning() to be manually called in the case of values being edited post-initialize.

Previous pitch for posterity

Fixes pride pin reskinning.

Changelog

馃啈
fix: Pride pins can be reskinned again with alt-click.
/:cl:

00-Steven and others added 2 commits May 8, 2024 17:19
## About The Pull Request

**Edit: Since writing, this pr has been updated to address failing CI
based on code-general suggestions, invalidating the previous
descriptions. The previous descriptions has been included as spoilers
for posterity**

Right, so, this has gone from just a simple pride pin fix to realizing
CI fails with it to doing a more complex lasting fix based on
suggestions.

Recap time. Objects get reskinning set up if they have `unique_reskin`
set when `Initialize(...)` runs.

https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/game/objects/items.dm#L267-L269
Because pride pins use a global list, we set it in `Initialize(...)`...
After we call the parent.

https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/modules/clothing/under/accessories/badges.dm#L196-L198
Obviously this fails.

However, moving this *before* `Initialize(...)`, while fixing the issue,
causes CI to fail due to calling `register_context()` twice.
Why? Well, it's simple. We automatically call `register_context()` if we
have `unique_reskin` set, as seen above, but we *also* call it on
accessory `Initialize(...)` due to it having its own context.

https://github.com/tgstation/tgstation/blob/0c562fd74299f8ce92a81c0a932b8ec4862189af/code/modules/clothing/under/accessories/_accessories.dm#L29-L31
This causes it to try register the same thing twice, which doesn't
_break_ things, but it sure as hell isn't clean.

So talking about this with San in code general, we decided to try go
with the following:
We add two new procs, `setup_reskinning()` and
`check_setup_reskinning()`, and handle all this fuckery within those.
This lets subtypes override them with their own new checks or
differences in setup.
Then we override `setup_reskinning()` for `/obj/item/clothing/under` and
`/obj/item/clothing/accessory` to not register context again, and do the
same for `/obj/item/clothing/accessory/pride` but while also setting
`unique_reskin`.

This fixes it.

<details>
  <summary>Previous implementation for posterity</summary>
  
Back from my short code break, time to fix some of the things I've been
annoyed by.

Firstly, I noticed pride pins could no longer be reskinned since the
alt-click refactor.
Looking into it, this seems to be because we now only register this on
`Initialize(...)` if `unique_reskin` has been set:

https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/game/objects/items.dm#L267-L269
While due to using a global list we don't set this in the item
definition, but in `Initialize(...)` :

https://github.com/tgstation/tgstation/blob/9145ecb7e1e44635a1056fc704adfa3d764325e6/code/modules/clothing/under/accessories/badges.dm#L196-L198
Where we call the parent proc _before_ setting `unique_reskin`, and thus
not registering our ability to reskin.

So all we do is set this to our global list _before_ we call the parent
proc.
```dm
/obj/item/clothing/accessory/pride/Initialize(mapload)
	unique_reskin = GLOB.pride_pin_reskins // Set before parent proc checks for it.
	. = ..()
```
This fixes it.
  
</details>


## Why It's Good For The Game

Fixes pride pin reskinning.
Theoretically makes it easier to avoid this happening in the future, and
allows `setup_reskinning()` to be manually called in the case of values
being edited post-initialize.

<details>
  <summary>Previous pitch for posterity</summary>
  
Fixes pride pin reskinning.
  
</details>

## Changelog
:cl:
fix: Pride pins can be reskinned again with alt-click.
/:cl:
@NovaBot13 NovaBot13 added the Fix Rewrites a bug so it appears in different circumstances label May 8, 2024
@vinylspiders vinylspiders enabled auto-merge (squash) May 8, 2024 23:12
@vinylspiders vinylspiders merged commit 3ad0229 into master May 8, 2024
26 checks passed
@vinylspiders vinylspiders deleted the upstream-merge-82920 branch May 8, 2024 23:12
NovaBot13 added a commit that referenced this pull request May 8, 2024
github-actions bot added a commit that referenced this pull request May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix Rewrites a bug so it appears in different circumstances
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants