Adds Sprinting to Doppler - #1178
Conversation
github-actions
Bot
added
Sprites
|
Just one more step to roguecode.... Add parry and dodge next... |
|
This PR has been inactive for long enough to be automatically marked as stale. This means it is at risk of being auto closed in ~ 7 days, please address any outstanding review items and ensure your PR is finished, if these are all true and you are auto-staled anyway, you need to actively ask maintainers if your PR will be merged. Once you have done any of the previous actions then you should request a maintainer remove the stale label on your PR, to reset the stale timer. If you feel no maintainer will respond in that time, you may wish to close this PR youself, while you seek maintainer comment, as you will then be able to reopen the PR yourself |
|
this may be bad practice but im gonna set this one ready to view only because i don't know how to do the last 2, waiting for contributer input now |
|
Big fan of this personally, great work @BasilTamaya ❤️ |
|
This PR has been inactive for long enough to be automatically marked as stale. This means it is at risk of being auto closed in ~ 7 days, please address any outstanding review items and ensure your PR is finished, if these are all true and you are auto-staled anyway, you need to actively ask maintainers if your PR will be merged. Once you have done any of the previous actions then you should request a maintainer remove the stale label on your PR, to reset the stale timer. If you feel no maintainer will respond in that time, you may wish to close this PR youself, while you seek maintainer comment, as you will then be able to reopen the PR yourself |
TheOneAndOnlyCreeperJoe
left a comment
TheOneAndOnlyCreeperJoe
left a comment
There was a problem hiding this comment.
I've adressed some stand-out things as well as how to implement the two points you mentioned.
| if(iscarbon(source) && source.move_intent == MOVE_INTENT_WALK) | ||
| return // stealth | ||
| //if(iscarbon(source) && source.move_intent == MOVE_INTENT_WALK) // DOPPLER EDIT REMOVAL | ||
| // return // stealth DOPPLER EDIT REMOVAL |
There was a problem hiding this comment.
| // return // stealth DOPPLER EDIT REMOVAL | |
| // return // stealth // DOPPLER EDIT REMOVAL |
Forgot slashes preceding the DOPPLER EDIT REMOVAL
| // DOPPLER EDIT CHANGE START | ||
| if(move_intent == MOVE_INTENT_RUN && !(movement_type & FLYING) && (mobility_flags & (MOBILITY_MOVE|MOBILITY_STAND)) && !pulledby) | ||
| drain_sprint() | ||
| // DOPPLER EDIT CHANGE END |
There was a problem hiding this comment.
| // DOPPLER EDIT CHANGE START | |
| if(move_intent == MOVE_INTENT_RUN && !(movement_type & FLYING) && (mobility_flags & (MOBILITY_MOVE|MOBILITY_STAND)) && !pulledby) | |
| drain_sprint() | |
| // DOPPLER EDIT CHANGE END | |
| // DOPPLER EDIT ADDITION START | |
| if(move_intent == MOVE_INTENT_RUN && !(movement_type & FLYING) && (mobility_flags & (MOBILITY_MOVE|MOBILITY_STAND)) && !pulledby) | |
| drain_sprint() | |
| // DOPPLER EDIT ADDITION END |
No existing lines/behavior were changed so addition is more apt than change.
| /// If TRUE, we are being affected by run momentum | ||
| var/has_momentum = FALSE | ||
| /// Our last move direction, used for tracking momentum | ||
| var/momentum_dir = NONE | ||
| /// How many tiles we've moved in the momentum direction | ||
| var/momentum_distance = 0 |
There was a problem hiding this comment.
Unused vars?
Also not sure why you're defining them on carbons when this mechanic (seemingly) is human catered?
| /mob/living/carbon/proc/drain_sprint() | ||
| return | ||
|
|
||
| /mob/living/carbon/human/drain_sprint() |
There was a problem hiding this comment.
I feel like drain_sprint() would benefit from having a value passed in the arguments rather than the assumption that every call is "1", as largely a measure of future-proofing and allowing to arbitrarily pass sprint drains on future-things.
| if(move_intent == MOVE_INTENT_RUN || sprint_length >= sprint_length_max) | ||
| return | ||
|
|
||
| adjust_sprint_left(sprint_regen_per_second * seconds_per_tick * (body_position == LYING_DOWN ? 2 : 1)) |
There was a problem hiding this comment.
I feel like you should delegate this to a proc that handles recovery factors rather than including it in the adjustment call, given that any future additional forms of recovery (e.g sleeping, performance enhancing drugs, etc.) would need an insertion point that isn't just piggybacking off of stamina.
E.g
/mob/living/carbon/human/proc/run_sprint_recovery()
var/recovery = 0
recovery = sprint_regen_per_second * seconds_per_tick
if(body_position == LYING_DOWN) // laying down bonus
recovery *= 2
if(HAS_TRAIT_FROM(src, TRAIT_INCAPACITATED, STAMINA)) // no recovery during stamcrit (adresses point 2 of the bar recovering during stamcrit)
recovery *= 0
adjust_sprint_left(recovery)
Later on you can add a signal sender that basically sends to any listeners "hey, would you like to modify the recovery?" which would be nice (especially integrating it with existing systems), but this works for now.
| // Minor stamina regeneration effects, such as stimulants, will replenish sprint capacity | ||
| /mob/living/carbon/human/adjustStaminaLoss(amount, updating_stamina, forced, required_biotype) | ||
| . = ..() | ||
| if(amount < 0 && amount >= -20) |
There was a problem hiding this comment.
Curiously, why do we cut-off at 20 specifically? Where's the magic number coming from, given that something that gives 20 per tick is "fine" but 50 in one go isn't.
| // Sprinting when out of sprint will cost stamina | ||
| if(sprint_length > 0) | ||
| return | ||
|
|
||
| // Okay you're gonna stamcrit yourself, slow your roll | ||
| if(getStaminaLoss() >= maxHealth * 0.9) | ||
| toggle_move_intent() | ||
| return | ||
|
|
||
| adjustStaminaLoss(1) |
There was a problem hiding this comment.
Ideally you'd insert Add some sort of to-chat when one has used up their sprint threshold and is now using their stamina threshold, as well as another more aggressive to-chat about attempting to run when exhausted here.
Generally speaking to_chat(src, span_warning("Your sprint has started exhausting you!")) should suffice, then use a COOLDOWN_DECLARE(stam_sprint_warning) to add a cooldown to the message as to not spam the user. Alternatively you can set a var that sets the message has been sent, and unset it once sprint_length is at a certain value again that would warrant the message. You could also use a balloon_alert() which is much more noticeable.
For the more dangerous warning, you're going to need to be more specific on intended behaviour. I would suggest at line 79 to add a to_chat() or a balloon_alert() informing them that they've stopped sprinting.
| /datum/movespeed_modifier/momentum | ||
| movetypes = GROUND | ||
| flags = IGNORE_NOSLOW | ||
| multiplicative_slowdown = -0.1 |
There was a problem hiding this comment.
Unimplemented?
|
This PR has been inactive for long enough to be automatically marked as stale. This means it is at risk of being auto closed in ~ 7 days, please address any outstanding review items and ensure your PR is finished, if these are all true and you are auto-staled anyway, you need to actively ask maintainers if your PR will be merged. Once you have done any of the previous actions then you should request a maintainer remove the stale label on your PR, to reset the stale timer. If you feel no maintainer will respond in that time, you may wish to close this PR youself, while you seek maintainer comment, as you will then be able to reopen the PR yourself |
4 participants
About The Pull Request
Ported directly from Maplestation.
Why It's Good For The Game
There's a bit of a nuanced interaction that doesn't get talked about or addressed, but the two-gear system of toggling walk and run doesn't feel good, and often times this defaults to everyone running through the halls and shoving past people as a natural occurrence with TGstation. I will, however, say it's weird that this happens. Normally running into people causes some sort of interaction; either an apology, or "no running in the hall!".
Miners will not need to fear, for stimulants included in their medipens will aid in this. Walkspeed will need to be ticked just a tad enough to dodge some fauna.
Key Features:
To be address or added:
This PR will be marked as a draft per discussion with maintainers and to allow them to make or request necessary changes, or discuss if this should be added at all; as well as communication for changing the default move speed in the config files to adjust.
It isn't exactly complete, but I want to know what else I should be adding that's a concern for maintainers before I proceed.
Testing Evidence
NOTE: I did not edit the walk speed in the config files. What is seen in the video is not what I aim the walkspeed to be.
2026-08-08.15-07-01.mp4
Will provide screenshots but the code currently presented functions as intended. There's a few things I need to work on, but I'm waiting to get some maintainer input/discussion on concerns that I can address.
Changelog
🆑FoundInJune
add: Adds Sprinting Mechanic, ported directly from Maplestation.
/:cl: