SabbyKat Zulo Refactor First Release - #1234
Conversation
…Commentary First Zulo Upload for Help Commentary
chazzyjazzy
left a comment
There was a problem hiding this comment.
extremely excessive comments - keep in mind that we as coders know what your files do, please keep it only to whats strictly necessary / sorta funny
|
A bit of warning in that: I tend to comment my code a lot. But I fully intend to clean up the unnecessary commentary in the code if this is approved! |
| TRAIT_PUSHIMMUNE, // Sabby: present in oldcode. According to living_defense.dm, it prevents an agg grab. By name, I thought it would prevents shove. I still believe it makes sense for a war form to not be agg grabbed. | ||
| TRAIT_HARDLY_WOUNDED, // Sabby: present in oldcode. Functionality found in wounds.dm line 61. | ||
| TRAIT_BRAWLING_KNOCKDOWN_BLOCKED, // Sabby: new feature. Found from declarations list and studied from item_attack.dm line 463 and tackle.dm. Basically keeps target from getting knocked down on hand-to-hand. | ||
| TRAIT_NO_STAGGER, // Sabby: new feature. Found from declarations list and studied from staggered.dm. Prevents application of /datum/status_effect/staggered (which is basically a daze sort of effect). Same reasoning as above. |
There was a problem hiding this comment.
So i think your going about comments slighty wrong here-
one thing, dont author every comment. Its just not super required as gitblame exists if you really need attribution but most future others wont even know who you are.
Second, your comments should really describe things within the context of your pr. "new feature" is really only relevent here within someone reviewing a pr but means nothing to a future coder.
You also dont need to explain code like this if the explaination already exists elsewhere (like the trait definition or usages)
There was a problem hiding this comment.
Gotcha! I do tend to overcomment quite a bit when working with stuff I'm inexperienced in. I'll be cleaning a lot of these up very soon.
| if(zulo_backpack_to_hide) | ||
| zulo_backpack_to_hide.worn_icon_state = "empty" | ||
| human_who_gained_species.update_worn_back() |
There was a problem hiding this comment.
Why do zulo even get backpacks in the first place?
If they do really need them, you should just cancel the rendering of backpack overlays on the mob rather then setting the backpacks state.
There was a problem hiding this comment.
Sadly, this is because we really have no other option to deal with the fact that Tzimisce character need to keep carrying that soil bag around. Without some way to keep the bag on the character, Zulo effectively unusable for pretty much any Tzimisce.
| human_who_gained_species.hairstyle = "Bald" | ||
| human_who_gained_species.facial_hairstyle = "Shaved" |
There was a problem hiding this comment.
Should not be needed. You can just block hair rendering. I do this for wolves.
There was a problem hiding this comment.
I will check the fera code for it!
| var/old_appearance | ||
| var/old_manipulation | ||
| var/old_charisma |
There was a problem hiding this comment.
These dont need to be scoped here. They are only used within the context of a single proc.
There was a problem hiding this comment.
Gotcha. I'll scope them within the on_gain proc. I sometimes tend to separate vars like this thinking it will help make the code more readable.
| TRAIT_MUTANT_COLORS // Sabby: paired with fixed_mut_color below to give Zulo its own fixed sprite color rather than the character's skin tone | ||
| ) | ||
| no_equip_flags = ITEM_SLOT_MASK | ITEM_SLOT_OCLOTHING | ITEM_SLOT_GLOVES | ITEM_SLOT_FEET | ITEM_SLOT_ICLOTHING | ITEM_SLOT_SUITSTORE | ITEM_SLOT_HEAD | ITEM_SLOT_EYES | ITEM_SLOT_EARS | ||
| var/obj/item/zulo_backpack_to_hide |
There was a problem hiding this comment.
this shouldnt be a required var but if it somehow as this would need to be a weakref.
| var/old_size | ||
| var/mob_pixel_w = 0 | ||
| var/mob_pixel_z = 0 | ||
| var/sprite_size_transform = 1 //Sabby: in case any new future sprites are 32x32, not 64x64, overwrite this with 1.50 on the new form's datum. |
There was a problem hiding this comment.
we are apparently in the future already.
There was a problem hiding this comment.
Yep! I meant for any new sprites. The one Paul made was 32x32 so technically that already applies. Haha.
| return values | ||
|
|
||
| /datum/preference/choiced/zulo_form/icon_for(value) | ||
| /datum/preference/choiced/subsplat/zulo_form/icon_for(value) |
| old_manipulation = human_who_gained_species.st_get_stat(STAT_MANIPULATION) | ||
| old_charisma = human_who_gained_species.st_get_stat(STAT_CHARISMA) | ||
| // Sabby: +3 stat boots to all physical stats, and socials to 0 as per V20 - pages: 242 | ||
| // Sabby: below is the most reliable way I found of doing something I struggled with: set social stats to 0 and restore when out of Zulo. |
There was a problem hiding this comment.
Yea. we prob need a var to set a cap for stats.
There was a problem hiding this comment.
So, I tested it extensively and, while a bit clumsy with all of the if statements, it does work! The logic is simply that those "old_" vars on gain capture the character's stats pre-transformation, and then below applies a stat mod which basically subtracts it all to 0. The reason I set it into a > 0 if is because I was unsure if any crashes or bugs could happen if the code ended up trying to subtract 0 from a character that already had, say, appearance at 0.
However, I did several tests in games, such as doing social stat rolls before transformation to see how many dice are rolled, then again while in Zulo, and then rolling again after getting out of zulo, and the stat adjustments work just fine! :D
| var/mob_pixel_w = 0 | ||
| var/mob_pixel_z = 0 |
There was a problem hiding this comment.
Unused? this should be used to do pixel offsets to center them onto tiles.
There was a problem hiding this comment.
I genuinely forgot to do the centering part. I'll take care of that. I do have one question on this, though: I do believe that the different sprites (4-armed zulo, the werezulo, etc.) might require different adjustments in the offsets to have them properly centered on sprites. Would you happen to have any suggestion on the best way to do that? One option would be to manually set the offsets for each form subspecies, but we've already talked about how we'd like, ideally, to move away from having all the subspecies.
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>
Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com>

About The Pull Request
This is the first release of a large project to completely refactor the Rebase Zulo Form away from being a basicmob and back into being a carbon form species code, similarly to how it functioned in pre-rebase code. The project restores many functionalities to Zulo Form (ability to target body parts, bash in doors with right-click, etc.), as well as brings it up to TTRPG parity by giving it the proper boosts to physical stats and reductions to social stats while in form.
The refactor also preserves the functionality of having multiple Zulo form sprites to select at the character menu, and adds an entirely new sprite made by Coworker_Paul.
Why It's Good For The Game
Many Tzimisce players have felt that Zulo Form needed some love after the rebase, and this project accomplishes that and also brings it to much closer parity with the TTRPG.
Changelog
🆑 SabbyKat
refactor: refactored Zulo Form functionality into carbon form code.
add: added new Zulo Form Sprite.
code: changed some zulo preference code.
del: removed old Zulo basicmob code
balance: implemented Zulo form with closer parity to TT
/:cl: