Replaces some progress bars with item bars, makes some bars be visible to the recipients #9361
Conversation
Co-authored-by: EvilDragonfiend <[email protected]>
|
This definitely should have a testmerge or two, as I could not possibly test everything on my own on local, and I'd like to catch the bugs and oversights before this gets merged. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
…Hornet into goonlike-progress-bars
…Hornet into goonlike-progress-bars
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Let's testmerge this when psyphoza or other stuff isn't TM'ed. |
EvilDragonfiend
added
Test Merged
| /** | ||
| * Returns a list that contains the leftmost, rightmost, bottom and top pixels in an atom's icon | ||
| */ | ||
| /atom/proc/get_bounding_box() |
There was a problem hiding this comment.
Unfortunately I just don't think this is going to work. Even with only around 300-500 calls getpixel becomes one of the most overtiming things on the server. Progress bar images need to be specifically chosen and have their parameters fed in directly, or they need to be an image with the normal progress bar below and ignore the fact that part of it might take a while to start showing.
| var/show_bar = TRUE | ||
| var/x_image_offset | ||
| var/y_image_offset | ||
| var/client/target_client |
There was a problem hiding this comment.
Does this handle target client disconnect properly? (Set this to null, clear the progress bar and clean references)
| */ | ||
| /proc/do_after(mob/user, delay = 3 SECONDS, atom/target, timed_action_flags = NONE, progress = TRUE, datum/callback/extra_checks) | ||
| /proc/do_after(mob/user, delay = 3 SECONDS, atom/target, timed_action_flags = NONE, progress = TRUE, show_to_target = FALSE, \ |
There was a problem hiding this comment.
Does this progrss bar cancel if add_item gets deleted? I'm pretty sure appearance will count as a reference but im not entirely sure. You'll have to check DM docs
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Pains me to do this, but due to DM's image procs being so costly, I can't make it look good AND perform well. |
About The Pull Request
Replaces some of the progress bars with 'item bars' that fill up the same way progress bars do.
Also makes certain progress bars be shown to the recipient of the action.
Partially ports Monkestation#878
Removes being able to stack several progress bars on one target, which means you cannot do multiple surgeries at once on one person, strip multiple items off someone or que in 5 feedings from a beaker at once.
Instead, actions like repairing mechanical bodyparts and doing CPR will be repeated automatically while gradually speeding up, capping out at a 5x bonus.
Feeding a mob food or reagents from something now initially takes 3 seconds, but each subsequent feeding will take only 1 second, for 15 seconds after the last feeding.
Stripping remains one item per attempt with no changes to speed, for now.
Why It's Good For The Game
It improves the visibility of the game, aswell as allowing more interactivity between players.
Testing Photographs and Procedure
Screenshots&Videos
bandicam.2023-07-08.19-46-17-546.mp4
bandicam.2023-07-07.21-51-52-870.mp4
Changelog
🆑dwasint,CydiaLamiales,HowToLu
add: Added 'item bars' in place of some progress bars, that show the item with which the action is being done with
code: Added a get_bounding_box() atom proc, which returns a list containing the bounding box of the icon of the atom
balance: Made people unable to stack several progress bars on one target. Which means you cannot que several strippings on one person or several feedings from one beaker
balance: Made previously repeatable actions be automatically repeated where it makes sense, with the speed increasing wiht each successful action. This does not include feeding or stripping
balance: Made feeding a mob speed up the consequential feedings for the next 5 seconds by 3 times
balance: Made stripping a mob speed up the consequential strippings for the next 5 seconds by 3 times
code: replaced most of the time numbers used for do_after to use the SECONDS define
/:cl: