* 10K hours
60,000 minutes
hahah
sure if you want a trailing newline i can do that
default cloak gets default skill
lazy list and no equip good
necessary ig
Update code/datums/skills/_skill.dm
Co-Authored-By: nemvar <47324920+nemvar@users.noreply.github.com>
Update code/datums/skills/gaming.dm
Co-Authored-By: Angust <46400996+Angustmeta@users.noreply.github.com>
WIP PDA skill monitor program
hacky fixes till i refactor skills
refactors skills a bit, adds admin skill edit menu
If you have a failing, it's that you're always demanding perfection
...IF you have a failing
i think that's it for the admin skill manger
appeases lord flord
bruh
level names
FUCK!!
unga
Update code/modules/vehicles/vehicle_key.dm
Co-authored-by: Rohesie <rohesie@gmail.com>
Update code/modules/admin/topic.dm
Co-authored-by: Rohesie <rohesie@gmail.com>
Update code/modules/admin/skill_panel.dm
Co-authored-by: Rohesie <rohesie@gmail.com>
Update code/modules/admin/skill_panel.dm
Co-authored-by: Rohesie <rohesie@gmail.com>
Apply suggestions from code review
frick
Co-authored-by: Rohesie <rohesie@gmail.com>
EOL and dumb spaces
more rohsie bait
tgui: Query Windows Registry for BYOND cache directory
hell yeah brother
update tgui and dmi
CLRF and bat file
typo ig
* tgui and new janicloak that i accdiently changed on another branch
* jani
* gamer cloak
* trim trailing whitespace
* tgui
* bruh
* variable renaming
Asset cache now caches the asset's md5 This should solve the high cpu usage issues with it. line by line profile suggests that the next hotspot is the asset log.
Simplied asset cache code, moved verify functionality to a flush_assets proc that blocks until a client has all currently sending assets. (sidenote: there is an argument for moving most of asset_cache's global procs onto the client, get_asset_datum and register_asset are really the only valid global procs.)
Re-added batched passive sends since it does speed up how quickly the asset cache pre-caches to clients.
* Automatic changelog compile [ci skip]
* Automatic changelog compile [ci skip]
* tablet good
* forgot something
* restoring what was lost
* hoping for the best
expecting the worst
* Why review when you can edit in place?
* Additions and fixes
* Here's hoping
* Why is this still here?
Co-authored-by: Changelogs <action@github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
The asset cache will now store json on the player's computer with info on what browser assets they have, all non-active assets (anything but .js(m) and .htm(l)) are reused in further connections. Browser assets in byond persist for an individual dream seeker instance, and are destoryed when the window is closed (so this only helps reconnects and round restarts) The data is stored in the client's asset folder to ensure its current and retrieved using javascript and sent back to the server using ajax(XHR).
The md5 of the asset files are generated on the server and stored on the client. It is used to validate the asset hasn't changed from a code update, and is not re-checked client side.
To ensure this can't be used by a malicious byond server to override javascript assets before redirecting people to /tg/ (where the attacker's javascript would then be allowed to run verbs and spoof topics) we do not mark javascript as pre-loaded when loading the client's asset cache json file on connection.
Other Changes
I moved some things around, the asset cache file was getting thicc:
Put new asset cache datums into code/modules/asset_cache/asset_list_items.dm
Find the asset cache datum abstract definitions inside code/modules/asset_cache/asset_list.dm
I fixed a bug where blocking asset sends would not block later calls to send the same asset while the send was still underway - todo: have it bind to the first send rather then initating its own.
The small file sent to the client to verify it got all pending asset sends will no longer use random names. This should keep the client's asset folder from exploding with hundreds of random htm files, much to the joy of oranges.
Passively loading assets no longer batches.
Unified the two procs.
