Goonhub
02-23-2019, 05:03 PM
(This post was last modified: 02-23-2019, 05:27 PM by kyle2143. Edited 1 time in total.)
Yes, that was something that might be a little circumspect. I tested a bit with it and noticed no problems though.
I usually try not to make changes outside of what is necessary, but this was rather useful. See, I couldn't just set the var/obj/item/thrownlimb to one of the limbs and then call the remove proc like this:
thrown_limb = H.limbs.l_arm
H.limbs.l_arm.remove()
Inside each conditional. Because that remove proc both changes information on that limb before it is removed and removes itself from its holders limb variable.
Also, it's a rather common practice to do things like return a removed value or object when you have a function doing that. We don't really throw exceptions so much. And afaik, returning a reference to that object is basically the same in terms of performance as a primitive.
Edit: Wait that middle part isn't right, idk why I wrote that, it woulda worked just as well. I think I was just trying to reason why I did it that was and defend it, but I honestly just don't remember what my thought process was. Probably thought it was just cleaner and wished more procs in the codebase bothered with returning true/false and references related to successes/fails or something.
I usually try not to make changes outside of what is necessary, but this was rather useful. See, I couldn't just set the var/obj/item/thrownlimb to one of the limbs and then call the remove proc like this:
thrown_limb = H.limbs.l_arm
H.limbs.l_arm.remove()
Inside each conditional. Because that remove proc both changes information on that limb before it is removed and removes itself from its holders limb variable.
Also, it's a rather common practice to do things like return a removed value or object when you have a function doing that. We don't really throw exceptions so much. And afaik, returning a reference to that object is basically the same in terms of performance as a primitive.
Edit: Wait that middle part isn't right, idk why I wrote that, it woulda worked just as well. I think I was just trying to reason why I did it that was and defend it, but I honestly just don't remember what my thought process was. Probably thought it was just cleaner and wished more procs in the codebase bothered with returning true/false and references related to successes/fails or something.