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

Some minor fixes #4150

Merged

Conversation

Absolucy
Copy link
Collaborator

@Absolucy Absolucy commented Nov 7, 2024

About The Pull Request

these two runtimes keep showing up in the logs...

Changelog

no player-facing changes

Absolucy and others added 11 commits November 13, 2024 00:07
[Removes all other listlike var
accesses](tgstation/tgstation@4c5996b)

Also fucking dumpsters an unused proc that allowed for arbitrary
variable modifcation. Bad juju

This is undefined behavior and errors in later 515 versions. also it's
stupid as hell
…(#86065)

## About The Pull Request

During initializing persistent wall engravings, the game picked a number
between 15 and 25, and attempted to load that many. However, if there
were less engravings than that, the loop went on even after the list it
was calling `pick_n_take` on was empty, and multiple times it has logged
a runtime claiming that the engraving was in an incorrect format when it
tried to parse the returned nulls.

This PR ensures that the game will not attempt to load more engravings
than the amount that exists in the persistence files, ensuring less
incorrect error messages during initialization.

## Why It's Good For The Game

Less incorrect lines during initialization on maps that have not
received enough engravings.

## Changelog

Nothing player facing.
@Absolucy Absolucy force-pushed the i-dont-know-how-this-happens-but-whatever branch from 664e8fc to 5d19101 Compare November 13, 2024 19:08
@Absolucy Absolucy force-pushed the i-dont-know-how-this-happens-but-whatever branch from 5d19101 to 2967367 Compare November 13, 2024 20:39
… 516 (#87889)

This makes `/datum/player_details` properly track BYOND version and
build separately, as opposed to just the full version string.

Whenever a client logs in, and their BYOND version is 516, while their
previous version was 515, or vice versa, it'll set a newly added client
var, `rebuild_plane_masters`, to TRUE.

During the `COMSIG_MOB_LOGIN` signal handler of a mob's HUD
(`/datum/hud/proc/client_refresh`), it will check to see if
`rebuild_plane_masters` is TRUE - if so, it will set the appropriate
`relay_loc` of (based on client BYOND version) of its plane master
groups, and rebuild their plane masters.

Makes testing stuff across 515 and 516 easier, as your screen won't
break when switching between the two.

516 is _still_ in private alpha, so no user-facing changes.
@Absolucy
Copy link
Collaborator Author

okay this has gotten out of hand, way more than "some minor fixes", albeit still fixes.

@Absolucy Absolucy merged commit 06bda09 into Monkestation:master Nov 16, 2024
23 checks passed
@Absolucy Absolucy deleted the i-dont-know-how-this-happens-but-whatever branch November 16, 2024 06:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants