[MIRROR] Techweb nodes DEFINED & bug fix #4137
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Techweb nodes DEFINED & bug fix (#84177) ## About The Pull Request 1. Techweb strings are now defined in `code/__DEFINES/research/techweb_nodes.dm` many thanks to @ShizCalev 2. All places that used those strings have been updated with the definitions as well. 3. `code/modules/research/ordnance/scipaper_partner.dm` had some old boosted ids, they have been updated as well along with their values. ## Why It's Good For The Game fixes #84153 - I found this through a runtime, but basically the boosted nodes missed unit test checks. Having them defined should in future ensure that any changes to them alert the maintainers. This will help in furthur modularizing the code. - As for the nodes themselves, I have put the exact nodes as much as possible so they dont differ much from previous gameplay and how they worked. Researched nodes that used to give points to those experiments, will continue to do so, but albeit at a slower rate. This is because the research point generation rate overall now has been increased. ## Changelog :cl: ShizCalev, SpaceLove refactor: Techweb strings are defined now so to maintain modularity balance: Research papers will have less overall point generation. /:cl: --------- Co-authored-by: ShizCalev <[email protected]> * Techweb nodes DEFINED & bug fix * wew * forgot this one? --------- Co-authored-by: SpaceLoveSs13 <[email protected]> Co-authored-by: ShizCalev <[email protected]> Co-authored-by: NovaBot13 <[email protected]> Co-authored-by: Fluffles <[email protected]>
AnywayFarus
added a commit
that referenced
this pull request
Jun 30, 2024
Iajret
pushed a commit
that referenced
this pull request
Jul 31, 2024
…E] (#4137) * Fix some wonky anchored_tabletop_offset rendering (#85372) ## About The Pull Request While working out railing layering rank, I noticed this issue:  This seems to be because we allow objects to have their `pixel_y` be offset when anchored on top of a table, which causes it to peek into the next tile up, thus layering us on top of it. Making it use `pixel_z` instead such that it's only visually offset fixes this:  Additionally, while we're touching the `check_on_table()` proc, we make it remove the `pixel_z` offset whenever it gets unanchored instead of only whenever it gets unanchored _on a table_. Ideally we would also make such vertically offset objects remove their offset when the table they're on gets destroyed, but that's not the point of this pr. ## Why It's Good For The Game Tends to be better to not look like you're standing on something you're not. It's a bit annoying when you destroy the table under a vertically offset object and now can't remove that offset until you put it on a table again. ## Changelog :cl: fix: You no longer render on top of tall enough objects that get vertically offset when anchored to a table when standing on the tile directly to the north of them. Examples are soda and booze dispensers. fix: Removing the vertical offset some objects get when anchored to a table can be done by unanchoring it at any point, rather than only on a table. /:cl: * Fix some wonky anchored_tabletop_offset rendering --------- Co-authored-by: _0Steven <[email protected]> Co-authored-by: NovaBot13 <[email protected]>
FeenieRU
pushed a commit
that referenced
this pull request
Jul 31, 2024
* [MIRROR] Fix some wonky anchored_tabletop_offset rendering [MDB IGNORE] (#4137) * Fix some wonky anchored_tabletop_offset rendering (#85372) ## About The Pull Request While working out railing layering rank, I noticed this issue:  This seems to be because we allow objects to have their `pixel_y` be offset when anchored on top of a table, which causes it to peek into the next tile up, thus layering us on top of it. Making it use `pixel_z` instead such that it's only visually offset fixes this:  Additionally, while we're touching the `check_on_table()` proc, we make it remove the `pixel_z` offset whenever it gets unanchored instead of only whenever it gets unanchored _on a table_. Ideally we would also make such vertically offset objects remove their offset when the table they're on gets destroyed, but that's not the point of this pr. ## Why It's Good For The Game Tends to be better to not look like you're standing on something you're not. It's a bit annoying when you destroy the table under a vertically offset object and now can't remove that offset until you put it on a table again. ## Changelog :cl: fix: You no longer render on top of tall enough objects that get vertically offset when anchored to a table when standing on the tile directly to the north of them. Examples are soda and booze dispensers. fix: Removing the vertical offset some objects get when anchored to a table can be done by unanchoring it at any point, rather than only on a table. /:cl: * Fix some wonky anchored_tabletop_offset rendering --------- Co-authored-by: _0Steven <[email protected]> Co-authored-by: NovaBot13 <[email protected]> * [MIRROR] Fix some wonky anchored_tabletop_offset rendering --------- Co-authored-by: NovaBot <[email protected]> Co-authored-by: _0Steven <[email protected]> Co-authored-by: NovaBot13 <[email protected]> Co-authored-by: StealsThePRs <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mirrored on Nova: NovaSector/NovaSector#3319
Original PR: tgstation/tgstation#84177
About The Pull Request
code/__DEFINES/research/techweb_nodes.dmmany thanks to ShizCalevcode/modules/research/ordnance/scipaper_partner.dmhad some old boosted ids, they have been updated as well alongwith their values.
Why It's Good For The Game
fixes #84153
I found this through a runtime, but basically the boosted nodes missed unit test checks. Having them defined should in future ensure that any changes to them alert the maintainers. This will help in furthur modularizing the code.
As for the nodes themselves, I have put the exact nodes as much as possible so they dont differ much from previous gameplay and how they worked. Researched nodes that used to give points to those experiments, will continue to do so, but albeit at a slower rate. This is because the research point generation rate overall now has been increased.
Changelog
🆑 ShizCalev, SpaceLove
refactor: Techweb strings are defined now so to maintain modularity
balance: Research papers will have less overall point generation.
/:cl: