Dusty

Turns out my issue was that I had forgotten that I added a new value to the playerstate in q_shared in addition to the client values I was talking about. I seem to recall being told that modifying the playerstate is much more touchy than just adding new client values, which as far as SP is concerned achieves the same effect?

I believe this is what ent-modding is for. You can mod these things by text-editing a .bsp file without having to decompile and ruin the map. Still then you can't use GTK-Radiant. Maybe you could decompile the map, do your entity mods, re-compile, then copy the text for your added entities to the old bsp file, if you want to use GTK-Radiant to create the entities rather than doing it via text-editing.

^So, I looked into that. But I'm not sure how to "set" the SFL_NOT_THROWABLE flag back to not being on the saber after it is applied (setting it is easy as I can just copy Raven's code). I'm sure it can be done, but I'm not good with bitwise operators (the |=, &=, ~, and & are all used as bitwise operators by Raven) as they require me to wrap my mind around modifying binary code.
 
What I did find was a piece of code I previously overlooked, a function in wp_saber.cpp called WP_Forcepowerusable. That actually controls the ability to saber throw. So now holding use disables saber throw by modding that. It seems the purpose of PM_SaberThrowable is just purely for kick checking. I'm still a bit confused however as to why staff saber allows kicks and single does not (maybe it has to do with the saberAnimLevel == SS_STAFF in there?), as with staff saber even when I make the saber throwable, you can still kick as the saber is returning to your hand, while it's mid-flight, or when you don't have enough FP for a saber throw.
 
Still trying to solve the mystery I guess...
 
 
EDIT: I'm thinking that based on my observations, the "if player is holding use" chunk of code in PM_SaberThrowable is having zilch effect (maybe the expression I used has no value in the context of that function), as the next two pieces of code regarding saberAnimLevel == SS_STAFF and the one pertaining to the SFL_NOT_THROWABLE flag (which is set by throwable 1/0 in the .sab) are consistent with all my/our other observations.
 
Solution:
Posting this way later. It turns out it was a redundant piece of code (somewhere in bg_pmove I think) that would bar the player code-side from even being able to press the Alt-Attack button if they had a non-staff saber that wasn't throwable.