<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
title. this wont inform admins tho
also makes server maint signal to client tguichat that we are shutting
down (so it says that text)
i don't know why we keep doing crap like this
"oh, but it's unfair to have x"
"oh, but it's unrealistic to have x"
"oh, but we might upset people if we do x"
and then we end up massively overcomplicating the code by literal
thousands of lines of maintenance because no one wants to make up their
mind
out with the old,
in with the new,
there will be no more shitcode for the sake of appeasement.
**Yes, this is a shadekin buff. That's temporary until powers are
converted to abilities.**
I'm tired of nerfing crap by copypaste, 120 points of healing isn't
enough to justify 120 additional lines of code.
title
it now waits every 10 min and doesnt have any fancy priority/init order
(it doesnt need that this is a generic subsystem)
fixes `world.time - (world.time - SSticker.round_start_time)`
makes it able to sleep() as well
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
qol: reduces waiting for players spam
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
modifies the hollow metrics API; that'll probably be implemented soon
adds init stages
changes SSatoms to not abuse its `initialized` variable
closes#6858
…l-Station-13-RP into opendream_branch<!-- Write **BELOW** The Headers
and **ABOVE** The comments else it may not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
adjusts the repo to work with opendream
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
a more modern, and hopefully more reliable engine!!!
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
code: changed the code to work with Opendream
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
update init code, LateInitialize now complains if it doesnt have
anything in it
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
code: update how init does things
code: update matrix helpers
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Unless more than 0 Players have stated their intention of playing the
round, the round will delay by 1 minute, then check again.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Hopefully reduces the amount of dead dead rounds during low population
hours
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: Add a requirement of one player ready for the round to start
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
There's still some update ordering issues that seem connected to
lighting, but I'm not sure if this is actually an issue with ZM/O7L
itself or seeker having a moment.
Also fixes some issues with new atom notifications in ZM not working
with recursive mimic properly.
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
tweak: Tranfer vote ties resolve as extensions.
tweak: If the vote winner is chosen at random an additional message is
displayed.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
tl;dr refactors supplypacks to a new system
- all access locks yanked from crates other than the ones that actually
need to be locked
- preps system for reworks, translates stuff over to a new format
- adds unified subsystem parsing & support for other descriptors for
cargo crate contents other than typepath
makes projectiles faster
adds a tuning variable again
removes a useless button in set-ticklag
fixes homing
optimizes projectiles / makes them easier to reason about
Adds a system for persistence to bind to things without requiring the
type to never change
## but, why?
Usually we to finalize stuff like typepaths before persisting because
that's the smart thing to do
But for volatile things like organs that are under constant refactoring
by necessity this doesn't work
So we do this to allow type changes to not throw out data
At some point we'll also need a versioning system for serialize /
deserialize and semantics on when to "full serialize" / "full load", as
an example if someone serialized an organ with 100 maxhealth but code
changes made it 200, what then?
# why?
non-player facing
we're going to need fast lookups for "is this thing in range of this
other thing" at some point, for things like telecomms
this current solution consumes about 16KB per reservation level
we also add the capability to use spatial grids to quickly get atoms on
a level.
spatial grids are also at 16KB per grid, per world level
all in all worth it in my opinion.
i'm pretty sure we're supposed to ceil instead of floor there
(TIMER_LOOP timers are going off the handle)
this doesn't actually fully fix the issue it just fixes one of my
fuckups that was causing it
- moves stuff to more sane places so modules folder isn't so messy
- adds a world system that is the start of being able to data-define
world locations and having the game act differently based on which
location a map is in
there's no ability to separate 'pre-load map' (and a way for persistence
to inject this so we can have moving maps yet) but we can add it in
later since things are decently abstracted.
adds variable timing schedulers
adds core AI holder abstraction and services
kicks current AI to /polaris and shims everything; reconcilation will
come later.
i decided to atomize my prs a little
- map obfuscation module upgraded
- obfuscation now happens via mangling id, inspired by nebula. atoms loaded with the same mangling id will generate the same obfuscated ids from a given and matching input id
- /datum/map_injection added; it's a composition-based system for modifying maps during spawn
- /datum/map_injection/starting_gear; inspired by barotrauma, pretty much just injects starting gear as necessary with a given configuration. multiple of these can be stacked in a given maploading.
- /obj/map_helper/gear_marker; markers for where starting_gear should populate things.
