Skip to content

Commit

Permalink
Merge branch 'ParadiseSS13-master'
Browse files Browse the repository at this point in the history
  • Loading branch information
Legendaxe committed Nov 1, 2023
2 parents 393b101 + 5ea429e commit 658ec32
Show file tree
Hide file tree
Showing 316 changed files with 41,889 additions and 32,629 deletions.
1 change: 1 addition & 0 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -759,6 +759,7 @@ Each role inherits the lower role's responsibilities (IE: Headcoders also have c
* [Sirryan2002](https://github.com/Sirryan2002)
* [Contrabang](https://github.com/Contrabang)
* [Burzah](https://github.com/Burzah)
* [DGamerL](https://github.com/DGamerL)

---

Expand Down
6 changes: 3 additions & 3 deletions .github/TICK_ORDER.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
The byond tick proceeds as follows:
1. procs sleeping via walk() are resumed (i dont know why these are first)
1. procs sleeping via walk() are resumed (I don't know why these are first)

2. normal sleeping procs are resumed, in the order they went to sleep in the first place, this is where the MC wakes up and processes subsystems. a consequence of this is that the MC almost never resumes before other sleeping procs, because it only goes to sleep for 1 tick 99% of the time, and 99% of procs either go to sleep for less time than the MC (which guarantees that they entered the sleep queue earlier when its time to wake up) and/or were called synchronously from the MC's execution, almost all of the time the MC is the last sleeping proc to resume in any given tick. This is good because it means the MC can account for the cost of previous resuming procs in the tick, and minimizes overtime.

Expand All @@ -9,7 +9,7 @@ The byond tick proceeds as follows:

5. SendMaps is called for this tick, which processes the game state for all clients connected to the game and handles sending them changes
in appearances within their view range. This is expensive and takes up a significant portion of our tick, about 0.45% per connected player
as of 3/20/2022. meaning that with 50 players, 22.5% of our tick is being used up by just SendMaps, after all of our code has stopped executing. Thats only the average across all rounds, for most highpop rounds it can look like 0.6% of the tick per player, which is 30% for 50 players.
as of 3/20/2022. meaning that with 50 players, 22.5% of our tick is being used up by just SendMaps, after all of our code has stopped executing. That's only the average across all rounds, for most high-pop rounds it can look like 0.6% of the tick per player, which is 30% for 50 players.

6. After SendMaps ends, client verbs sent to the server are executed, and its the last major step before the next tick begins.
During the course of the tick, a client can send a command to the server saying that they have executed any verb. The actual code defined
Expand All @@ -18,4 +18,4 @@ for that /verb/name() proc isnt executed until this point, and the way the MC is

The master controller can derive how much of the tick was used in: procs executing before it woke up (because of world.tick_usage), and SendMaps (because of world.map_cpu, since this is a running average you cant derive the tick spent on maptick on any particular tick). It cannot derive how much of the tick was used for sleeping procs resuming after the MC ran, or for verbs executing after SendMaps.

It is for these reasons why you should heavily limit processing done in verbs, while procs resuming after the MC are rare, verbs are not, and are much more likely to cause overtime since theyre literally at the end of the tick. If you make a verb, try to offload any expensive work to the beginning of the next tick via a verb management subsystem.
It is for these reasons why you should heavily limit processing done in verbs, while procs resuming after the MC are rare, verbs are not, and are much more likely to cause overtime since they're literally at the end of the tick. If you make a verb, try to offload any expensive work to the beginning of the next tick via a verb management subsystem.
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -58,4 +58,5 @@ __pycache__/
dmm-tools.exe
OpenDream
paradise.json
$RECYCLE.BIN
sound/tts_cache/*
2 changes: 2 additions & 0 deletions SQL/paradise_schema.sql
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,8 @@ CREATE TABLE `characters` (
`organ_data` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`rlimb_data` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`nanotrasen_relation` varchar(45) COLLATE utf8mb4_unicode_ci NOT NULL,
`physique` varchar(45) NULL DEFAULT NULL COLLATE utf8mb4_unicode_ci,
`height` varchar(45) NULL DEFAULT NULL COLLATE utf8mb4_unicode_ci,
`speciesprefs` int(1) NOT NULL,
`socks` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`body_accessory` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
Expand Down
6 changes: 6 additions & 0 deletions SQL/updates/52-53.sql
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
# Updating SQL from 52 to 53 -Octus
# Add characther descriptors of height and build to preference menu

ALTER TABLE `characters`
ADD COLUMN `physique` VARCHAR(45) NULL DEFAULT NULL AFTER `nanotrasen_relation`,
ADD COLUMN `height` VARCHAR(45) NULL DEFAULT NULL AFTER `physique`;
4 changes: 2 additions & 2 deletions _build_dependencies.sh
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,10 @@ export NODE_VERSION=18
# Stable Byond Major
export STABLE_BYOND_MAJOR=515
# Stable Byond Minor
export STABLE_BYOND_MINOR=1614
export STABLE_BYOND_MINOR=1619
# Beta Byond Major
export BETA_BYOND_MAJOR=515
# Beta Byond Minor
export BETA_BYOND_MINOR=1614
export BETA_BYOND_MINOR=1619
# Python version for mapmerge and other tools
export PYTHON_VERSION=3.11.6
Loading

0 comments on commit 658ec32

Please sign in to comment.