I have found that simply reducing force power rank via g_maxforcerank is insufficient for my server.
I'd like to maintain all of the jumping powers, and permit push and pull, as well as all the saber skills (including throw) but the additional powers are becoming a problem,
I'd like to restrict just the dark and light specific powers (heal, drain, lightening, etc.)
I see the setting "g_duelWeaponDisable" with a "65531" in it, leading me to believe you can very specifically allow and restrict various weapons (and perhaps force powers?).
Does anyone know how I can impose the restrictions I'm looking for on a dedicated server?
Failing that, perhaps there's a way to specifically adjust how many points each level in "g_maxForceRank" has?
[Edited to ask last question]
From Ravens New Faq:
g_forcePowerDisable:
Nothing is disabled if set to zero. All force powers are disabled if set to 32767. The number is the total of a bitfield with 15 bits, each bit representing a force power.
Actually, while this appears so its VERY hard to figure out what bit is which.
Ugh.
Best I can tell:
1- Heal
8- Push
32- Mind Trick
64- Grip
128- Lightning
256- Dark Rage
8192- Drain
Unfortunately, many of the bits also seem to disable saber throw and jump.
Anyone have others, and can anyone explain why saber throw and jump seem to be disabled when any of these bits are set?
Also, there is a bit of a bug. Setting g_forcePowerDisable to anything but "0" disables the ability to change force settings at all and indicates "Force Disabled" such that players cannot change their settings. This means they have to leave, go to a server with g_maxForceRank "7", set their settings, leave and come back. That's a pain.
This is a problem in that, at least on my server, we would like to eliminate Drain, Rage, Lightning, Heal, Grip, Protect, and Absorb, but leave Jump, all 3 Saber forces (attack, defend, throw), Push and Pull.
So is this possible? After 3 hours of experimentation I don't think it is.
You know what is the number for Jump force only ?
Originally posted by Leo
You know what is the number for Jump force only ?
No. I wish I did.
It seems to get disabled whichever bit I set.
Have you had any luck?
No, I wish we could have more details on this matter. With the right settings we could make a very enjoyable server to play.
I would very much like to do exactly that also, I hope you guys can figure it out.
g_forcePowerDisable appears to be very buggy -- unless there are some logical dependancies in the force powers?
Raven, any comment on this?
So far all of the higher force powers I've tried disabling end up
disabling everything.
Is this anything like the ol dmflags options from the like quake 2 and stuff, where depending on what the final number is, is equal to the total things you want in the game? In other words if you just wanted Heal and Push in(by what you were gathering), the number should be 9?
0 -- Full Force
1 -- Heal
2 --
4 --
8 -- Push
16 --
32 -- Mind Trick
64 -- Grip
128 -- Lightening
256 -- Dark Rage
512 --
1024 --
2048 --
4096 --
8192 -- Drain
16384 --
32767 -- No Force
Thats all I can figure out so far. All the other settings dont seem to do anything..ugh.
Any bit disabled disables jump and throwing.
Some of the other settings are probably saber defende saber throw and so forth.
You add the bits together to get the combination of forces you want to disable read NOT disable as this is the nature of the variable.
I noticed that the client reports your force points to the server via the "forcepowers" cvar, perhaps there's a way to force this variable to be the same for every client that connects regardless of their config? Ideas?
Originally posted by Darf
I noticed that the client reports your force points to the server via the "forcepowers" cvar, perhaps there's a way to force this variable to be the same for every client that connects regardless of their config? Ideas?
Could you elaborate on this? Where did you see this?
Ok.... so I've been reading these boards since the 24th (when I got my grubby little hands on this fine game ;))
Now, I'd like to pay it all back :D
First, the good news....
HERE is the complete bitfield for forcepowerdisable
0 Heal
1 ?
2 Speed
3 Push
4 Pull
5 Mind Trick
6 Grip
7 Lightning
8 Dark Rage
9 Protect
10 Absorb
11 Team Heal
12 Team Energize
13 Drain
14 Seeing
If you're not familiar with bitfields (which most of us aren't, unless we're big into programming, or abstract geek math) this is how they work....
The numbers next to the forces represent powers of 2. The bitfield is a series of 15 1's and 0's, all next to each other. THE ZERO POWER IS ON THE RIGHT, AND THE 14TH POWER IS ON THE LEFT. Don't get that confused....
Now then, if g_forcepowerdisable is set to "0" (as it is by default) the bitfield looks as follows...
000000000000000
this 15 digit binary number (that means base 2) represents 0 (zero)
if we were to change this number from
000000000000000
to
000000000000001
we would have "flipped the bit" in the zeroth power. As we all remember from grammar school, anything to the zeroth power equals 1, SO.... now our string represents the number 1.
Now the other way. if we went from
(Sorry about the double post...)
Ok.... so I've been reading these boards since the 24th (when I got my grubby little hands on this fine game ;))
Now, I'd like to pay it all back :D
First, the good news....
HERE is the complete bitfield for forcepowerdisable
0 Heal
1 ?
2 Speed
3 Push
4 Pull
5 Mind Trick
6 Grip
7 Lightning
8 Dark Rage
9 Protect
10 Absorb
11 Team Heal
12 Team Energize
13 Drain
14 Seeing
If you're not familiar with bitfields (which most of us aren't, unless we're big into programming, or abstract geek math) this is how they work....
The numbers next to the forces represent powers of 2. The bitfield is a series of 15 1's and 0's, all next to each other. THE ZERO POWER IS ON THE RIGHT, AND THE 14TH POWER IS ON THE LEFT. Don't get that confused....
Now then, if g_forcepowerdisable is set to "0" (as it is by default) the bitfield looks as follows...
000000000000000
this 15 digit binary number (that means base 2) represents 0 (zero)
if we were to change this number from
000000000000000
to
000000000000001
we would have "flipped the bit" in the zeroth power. As we all remember from grammar school, anything to the zeroth power equals 1, SO.... now our string represents the number 1. AND WE HAVE DISABLED HEAL!!!!!
Now the other way. if we went from
000000000000000
to
100000000000000
we would have flipped the bit in the 14th power. Since this is, again, base 2 notation, that means that we have 2 to the 14th power in our bitfield. So this new string represents the number 16,384. AND WE HAVE DISABLED SEEING!!!!
To enable and disable forces together, you have to flip the appropriate bits, according to the table above, and then convert the binary number you get to decimal notation. You may either work out these numbers as sums of values, or by using a fancy int-o-net converter. I found one which is real useful here:
http://www.onlineconversion.com/base.htm)
so to disable grip, push, and mindtrick, we would create the following bitfield
000000001101000
This comes out to be 104 in decimal (2^3 + 2^5 + 2^6). g_forcepowerdisable = 104......
Have fun....
:P
Also, the forcepowers cvar, follows the same ordering scheme, REVERSED however, with a little more info tacked on for good measure...
7-2-030000003000020321
as a forcepowers cvar means
7 - g_maxforcerank
2 - Darkside force (1 is Light)
Jump 3rd Level
Dark Rage 3rd Level
Drain 3rd Level
Sabre Attack 3rd Level
Sabre Defend 2nd Level
Sabre Throw 1st Level
you can view this by typing \clientinfo in the console
This might be the right place to look to solve our pickiness.... ;)
ok, 99% of us are not going to learn this math/computer crap, so somebody please just kinda outline a set popular setttings?
some nice server sets come to mind:
- saber powers only
- push/pull + saber powers
- only generic (non dark/light) powers
- keep everything but heal and drain
Full Push/Pull/Jump and maxxed saber skills ONLY would make for the ultimate setting imo
People are getting around the no force powers setting somehow, no idea how though..
- saber powers only
- push/pull + saber powers
i would LOVE that too, im suck of people that run stay as far away as they can and use lightning or what have you in a server im trying to run for saber duels.
i would be very grateful if someone could also help out with a compleat server config (for a small saber duel server) and or startup command.
email me headless@ez69online.com or post here.
-Thanks in advance! :)
Headless
It would be really cool if we could limit the healing to 1 "step" so that you would have to kneel to be able to heal.
Very nice job ManeFraim! (Geez, Id rather write MainFrame =P )
Btw, it's very easy to get the number .. just start up your windows calculator, choose scientific view, click on 'Bin' . Now look at the list of ManeFraim, and - starting at the end of it - push 0 if you want the power disabled and 1 if you want it enabled. Go through the whole list. Now in the calculator, hit DEC and it'll give you the number you need.
- keep everything but heal and drain
101111111111110 = 8190
Only problem.. there are no saber forces in the list?
good thing its not complicated :rolleyes:
Thanks Raze... I really wanted to help..... :D
BTW, Y'all, in the g_forcepowerdisable string, the 1st power bit (second from the right) HAS to be jump, (it is for the forcepowers cvar) but leaving it enabled does nothing!!!!
Arrgh...
Originally posted by Raze
Very nice job ManeFraim! (Geez, Id rather write MainFrame =P )
Btw, it's very easy to get the number .. just start up your windows calculator, choose scientific view, click on 'Bin' . Now look at the list of ManeFraim, and - starting at the end of it - push 0 if you want the power disabled and 1 if you want it enabled. Go through the whole list. Now in the calculator, hit DEC and it'll give you the number you need.
- keep everything but heal and drain
101111111111110 = 8190
Only problem.. there are no saber forces in the list?
No, the problem is that there is a bug and if you disable anything above the third bit saber throw and jump get disabled too. This is not a priority for them to fix, according to my limited discussions. I suggest if you want this fixed you ask the people at Raven directly so they can see there is an interest in fixing this.
I've spent 5-6 hours trying to get a server without any light or dark powers but all the neutral powers. (i.e. a server you can throw saber and jump on, push and pull, but none of the "cheap" powers like drain and grip). Pretty much impossible so far as I can tell. According to Raven the g_disableForcePower feature is broken.
If anyone has a work-around I would REALLY like to know.
ok, we NEED this.
i assure you that folks are gonna massively move one way or another around variations on the weapons and powers.
this is the kind of thing that can help the community grow and make servers really fun places to be
i will do what i can do make sure this stays on raven's radar, because i REALLY doubt it's that hard to tweak.
this would truly be a nice feature for admins...
meanwhile, i'd love to know how that code mentioned above tests out and what other codes folks have worked out.
saber-power + jump pelase
Agreed. I posted the same thing in other threads, but Im afraid it will get lost in all the nonsense people are requesting. THIS NEEDS TO BE FIXED! No force is fine, but not what Im looking for, and apperantly alot of others share my viewpoint. Lets us disable certain powers without disabling Jump and saber skills! And a little 'official" documentation would be nice as well, so we dont have to alter server.cfg's from other Q3A engine games :/
saber-power + jump pelase :D
Originally posted by TseTse
meanwhile, i'd love to know how that code mentioned above tests out and what other codes folks have worked out.
saber-power + jump pelase
I tried setting it to 8673 = No heal, no mindtrick, no grip, no lightening, no darkrage, no drain. Unfortuantely, it also has no Jump or saber throw. Clients who connect are always puzzled because the server claims "forces disabled" then they get pushed and start to accuse people of cheating. To top it off they can't change their force settings without going to another server. Very frustrating.
Ok, for those who do not wish to take up "geek math" here is a simple list that should work if/when raven/whoever sorts out g_forcePowerDisable (which NEEDS TO HAPPEN if anyone important is reading these forums).
-------------------------------------------
1 Heal [light]
2 Saber Throw
4 Speed
8 Push
16 Pull
32 Mind Trick [light]
64 Grip [dark]
128 Lightning [dark]
256 Dark Rage [dark]
512 Protect [light]
1024 Absorb [light]
2048 Team Heal
4096 Team Energize
8192 Drain [dark]
16384 Seeing
This is just a list of the force powers and there associated values. Just pick which powers you want to disable and their values together to get your final number. If you want to get rid of the sissy powers like drain and heal, you would add 1 plus 8192 to get 8193. Then just "set g_forcePowerDisable 8193". When you add them all together you get 32767, which disables all of the force powers.
The powers were posted earlier in this thread and I tested them on my own, the only blatent mystery is the second power. Being that g_forcePowerDisable breaks Jump and Saber Throw, it is hard to know for sure which it disables. Being that Jump defaults to first level at 0 points, I would assume it is not the one being disabled, and that leaves Saber Throw. I could be totally off on this as well so do not take any of what I say as fact.
Just remember that this feature does not seem to work properly (as listed in this forum: disables jump and saber throw no matter what as well as disables force power adjustment by the clients).
I made up a quick program in Visual Basic that will generate a value for g_forcePowerDisable based on the ones you check off. The program is downloadable from my website (it's only like 9kb, and the source is included if you want to take a look/modify it, etc). As far as I know, there are no bugs.
File: ForceCalc.zip (
http://www.binarynirvana.com/ForceCalc.zip)
Unfortunately, the quickness of writing VB apps comes with a price: the damn runtime file. So, if the program won't start and gives a weird error about not finding MSVBVM6.DLL or something, you need the runtimes from Microsoft which are about 1mb. You may not need them, however...try running the program first.
VB6 Runtime files (
http://www.microsoft.com/downloads/release.asp?releaseid=28337&area=top&ordinal=23)
If that link breaks (because they seem to like to do that), just go to Microsoft's search page and search for "visual basic runtime". If you find any bugs or anything, or if you find this even remotely useful, post a reply or send a mail.
It's a pity the feature doesn't actually work very well yet...maybe this program will actually be useful some day when they fix it :)
-Syko
As soon as a point release or otherwise fixes the current issues with the server configuration I will release my php server config maker. However, there is no use releasing it yet as I can not test the useful features with 100% accuracy, and there are plenty of other quake3 config examples that do the basics until then.
Hopefully there will soon be a point release with fixes for the cl_parsepacketentity disconnect errors, borked server configuration variables, and a map editor that I believe should have been included with the game. One can hope anyway.
the second bit is not sabre throw...... I'd bet a sandwich on it....
the forcepowers cvar would have no reason to reorder the bits....
;)
Two things:
I am in the process of making a list of weapons for "g_weaponDisable". It is going well, and I will post it when I'm done (later today).
Second, I have a theory about the second bit:
The second bit somehow affects the "jump bug" with other bits.
this is just a theory, but I will try it out when I'm done with the weapon list.
Okay, here is the weapon list:
bit 0 (1): No Weapon (not used)
bit 1 (2): Stun Baton
bit 2 (4): Sabre (doesn't work)
bit 3 (8): Bryar Pistol
bit 4 (16): Stormtrooper Rifle
bit 5 (32): Disruptor
bit 6 (64): Bowcaster
bit 7 (128): Repeater
bit 8 (256): DEMP Gun
bit 9 (512): Flechette Rifle
bit 10 (1024): Rocket Launcher
bit 11 (2048): Thermal Detonators
bit 12 (4096): Trip Mines
bit 13 (8192): Detonator Packs
Now, the ones marked with '?' are unknown. I am assuming one of them is the DEMP gun. I'm guessing that another one is the Detpacks.
As for the force thing, I set g_forcepowerdisable to "18" and jump still worked, so I may be right. I'll try again to be sure though.
The force thing was wrong, jump was just restricted to level 1 (same as it is with all force disabled, must be the zero cost thing)
I found the rest of them. The list has been updated. In case anyone is wondering, I found a list of weapons in the assets0.pk3 that had them in the order they appear in this bitfield, so I assume that if you run across anything else that refers to weapons, this list probably applies there too.
I found another list that showed the locations of the various force powers in the force power cvar/config file. Actually, it was located in the comments in one of the bot files. Anyway, it has stuff in the same places as ManeFraim said. Not that I didn't believe him, though :) .
heh.....
We draw ever nearer to a cure.....
Please. Support our cause....
Another weird thing I found goes like this.
If you choose no saber attack when forces enabled, you get a stun baton instead a saber..
However, when you do force disable, u'll the saber again!
I found your missing bit that "might" be messing things up.
HERE is the complete bitfield for forcepowerdisable
0 Heal
1 ?
2 Speed
3 Push
4 Pull
5 Mind Trick
6 Grip
7 Lightning
8 Dark Rage
9 Protect
10 Absorb
11 Team Heal
12 Team Energize
13 Drain
14 Seeing
This was posted a couple posts up.
This is what I found in the folder in the assests pk3 ui/jk2mp
#define UI_FORCE_SIDE 257
#define UI_FORCE_RANK 258
#define UI_FORCE_RANK_HEAL 259
#define UI_FORCE_RANK_LEVITATION 260 <-------- this is your ?
#define UI_FORCE_RANK_SPEED 261
#define UI_FORCE_RANK_PUSH 262
#define UI_FORCE_RANK_PULL 263
#define UI_FORCE_RANK_TELEPATHY 264
#define UI_FORCE_RANK_GRIP 265
#define UI_FORCE_RANK_LIGHTNING 266
#define UI_FORCE_RANK_RAGE 267
#define UI_FORCE_RANK_PROTECT 268
#define UI_FORCE_RANK_ABSORB 269
#define UI_FORCE_RANK_TEAM_HEAL 270
#define UI_FORCE_RANK_TEAM_FORCE 271
#define UI_FORCE_RANK_DRAIN 272
#define UI_FORCE_RANK_SEE 273
#define UI_FORCE_RANK_SABERATTACK 274
#define UI_FORCE_RANK_SABERDEFEND 275
#define UI_FORCE_RANK_SABERTHROW 276
Not sure but this could prove to be somewhat usefull but who knows, guess they took this out of the game.
Force Levitation seems to be the name given to Jump in the data files, and probably the code itself.
BTW, the file those defines are from seems to be used for parsing of the .menu files; if you look at ingame_playerforce.menu you can see all of them in the definitions for the force selector files.
those #defines are preprocessor commands to replace the text with the #'s immediately following them. Its a programming convention, makes the crap easier to read.
The #'s specifically don't necessarily relate to the bitfields, the order is interesting tho.
Bill yer absolutely right, undoubtedly levitation is how they must refer to jump in the actual code.
If you'll notice however, there are 20 of these 'variables' and only 16 bits. Which means the variable they used in their code isn't big enough to hold all 20 types. Most likely they used an integer which is 4 bytes. This *could* mean they have multiple force powers on one bit to keep the whole shebang on one variable.
1#define UI_FORCE_RANK_HEAL 259
2#define UI_FORCE_RANK_LEVITATION 260 <-------- this is your ?
3#define UI_FORCE_RANK_SPEED 261
4#define UI_FORCE_RANK_PUSH 262
5#define UI_FORCE_RANK_PULL 263
6#define UI_FORCE_RANK_TELEPATHY 264
7#define UI_FORCE_RANK_GRIP 265
8#define UI_FORCE_RANK_LIGHTNING 266
9#define UI_FORCE_RANK_RAGE 267
10#define UI_FORCE_RANK_PROTECT 268
11#define UI_FORCE_RANK_ABSORB 269
12#define UI_FORCE_RANK_TEAM_HEAL 270
13#define UI_FORCE_RANK_TEAM_FORCE 271
14#define UI_FORCE_RANK_DRAIN 272
15#define UI_FORCE_RANK_SEE 273
16#define UI_FORCE_RANK_SABERATTACK 274
17#define UI_FORCE_RANK_SABERDEFEND 275
18#define UI_FORCE_RANK_SABERTHROW 276
But, and I just realized this =P
bit 0 (1): No Weapon (not used)
bit 1 (2): Stun Baton
bit 2 (4): Sabre (doesn't work)
bit 3 (8): Bryar Pistol
bit 4 (16): Stormtrooper Rifle
bit 5 (32): Disruptor
bit 6 (64): Bowcaster
bit 7 (128): Repeater
bit 8 (256): DEMP Gun
bit 9 (512): Flechette Rifle
bit 10 (1024): Rocket Launcher
bit 11 (2048): Thermal Detonators
bit 12 (4096): Trip Mines
bit 13 (8192): Detonator Packs
There are 14 of these. Now if you cram the first list into a 4 byte integer, and you have 2 items you have left over, where would you put em? Possibly in yer other bitfield?
The probability of them doing this is actually sort of slim, simply because of how I imagine they would have split their code up.
But, if they have it split up by server options then quite possibly both bitfields are in the same file and it made perfect sense to pop the extra 2-3 bits onto the other bitfield.
14+18=32. Which is 2 4 byte variables. I think your extra powers might be on the weapons bitfield.
Specifically Jump. Bill, whats the size of the bitfield for the weapons? I bet its 4 bytes with that last bit reserved for somthing we don't know about just like the force power bitfield.
And I bet they tossed jump either in the 1st bit of weapons, which bill said wasn't used, or they put it in the last bit.
Actually, seeing as how bill was messing with the 1st bit and thought it did nothing, and yet his jump worked, i bet thats precisely where it is. Saber throw is the 2nd bit on the force powers bitfield, and jump is the 1st bit on the weapons bitfield.
/edit
Bill you sure it didn't work? Sure you didn't change yer weapons and force on one test and then only yer force on another? The order of those preprocessor commands is definitely not overly related to the bitfields. Its most likely just a convention they tried to stick with thru out their code so they could remember the list easily
/edit
Test it out and tell me if I'm off my rocker =P
/edit and with this post I am now a sith probe droid. I think =P
Lucky
Lucky:
The standard integer on an x86 processor is 32-bits, and I doubt that id (who probably wrote the cvar code) would set all cvars to 16-bit instead. For that matter, they are probably stored as strings and later converted to whatever type they need to be. If this is the case, I can't see any reason Raven would restrict the bitfield to 16 bits instead of 32, and as a result, they would have no reason to store the weapons and force powers in overlapping bitfields.
As for the jump thing, when I set anything except "0" or "1" as the g_forcepowerdisable, jump is set to level 1, even if I have it set as level 3. Even if you disable force altogether (either manually or through the menu), jump still stays at level 1. Which leads me to believe that there isn't any trickery that we aren't understanding, Raven just missed that particular bug. Fortunately, that's the kind of bug that we will probably be able to fix once we get the SDK even if Raven doesn't fix it, which I'll bet they will in the first patch.
As for bit zero in the weapons, I've looked through the files in the pak, and I believe that the same bitfield is used for identification of weapons in all areas, including NPCs, the player's holdings AND disabling. Also, in the file where I found the list that included the no weapon stuff, it also had the non-player weapons listed (ATST cannons, etc). This makes me think that (a): we could tweak some stuff to give the player an ATST cannon (which is actually done with the drive_atst "cheat") and (b): bit 0 (when the bitcodes represent the weapon in use) says that the bot/player/npc does not have a weapon selected (you can see this if you set god mode for the first fight with Desann and let him pull your weapon; you will have your other ones, but it won't select another one automatically)
----
That was a pretty long-winded post, but hopefully you can still figure out what I'm saying without too much of a headache :)
Originally posted by Syko
Unfortunately, the quickness of writing VB apps comes with a price: the damn runtime file. So, if the program won't start and gives a weird error about not finding MSVBVM6.DLL or something, you need the runtimes from Microsoft which are about 1mb. You may not need them, however...try running the program first.
If you got to the add-ins menu option in the vb 6.0 environment (I haven't used the others but I assume it's similar), there should be an option call package and deployment wizard. If it's not there go to the add-in manager and load it up from inside there. If you use the wizard it creates the cab files for distributing your program, upside, you don’t need to send people elsewhere to get the runtime files, the downside is that it makes the program bigger. I hope that helps in future :D
BTW I like the way you laid out the UI. :)
Please just give us the options to easily turn on and off force powers we want on our servers! It doesn't seem very hard to do, and it would make multiplayer NOT SUCK for once.
Oh and fix that damn parse disconnect, I can't even play online.
gah, yeah bill i dunno what i was thinking, was just late at night.
Anyhow, the bitfield is 16 bits, not 32, which is 2 bytes. There's a few extra force powers that don't have room on the first bitfield unless they're linked or simply not represented by any of the bits at all.
There's no reason for any of em to make it 2 bytes, but if the thats what they say the size of the bitfield is, then thats what it is. Which means, they prolly didn't use an integer, lol. I was just counting like a fool when i was typing. Shorts are 2 bytes, mebe they used a short.
My point was, if the weapons bitfield and the force power bitfield are in the same file, they could have tossed the extra force powers on the other variable.
And I'm not saying in the same file that you found them, I'm saying when they wrote the code, if the variables were declared in the same cpp, then they might have been in the same scope, which would mean that they could use either bitfield in either instance and thus they might have. It's a long shot, and I'm really inexperienced in messing with what we're talking about, but its still worth checking out.
Didju check it out? There's a ton of reasons for them to not have done this, but if they did, it might be a really un-apparent solution to our probelm. It seems like they have less spots than they needed to represent all the different force powers in one 2 byte bitfield. The only other thing I can think of that would result in jump getting set to 1, is that if you call that disableforce function jump gets *defaulted* to 1. Then there's not a crapload we can do about it.
Chances are, they used a 2 byte bitfield for both chunks of data, which means that there's extra bits on the weapons bitfield. See if they do anything when u flip em.
Lucky
I tested out some of the higher bits in the weapon field. It appears that one of them controls the sentry gun, but as far as I could tell, none of the force powers changed (definately not jump).
Near as I can tell, the cvars are stored as strings, not numbers. Which means that Raven could use whatever size data they wanted. Which means they would only use 16 bits if there was some size concern, which is unlikely. Which leads me to believe (even more) that it is just a bug, not a workaround for some kind of even bigger problem.
from a server settings file I got from somewhere (I know it was official)
g_weaponDisable:
Nothing is disabled if set to zero. Lightsaber only if set to 65531. The number is the total of a bitfield with 16 bits, each bit representing a weapon.
g_duelWeaponDisable:
Same as above, but only when playing Duel. This is separate because we encourage Duel mode to be saber-only.
g_forcePowerDisable:
Nothing is disabled if set to zero. All force powers are disabled if set to 32767. The number is the total of a bitfield with 15 bits, each bit representing a force power.
That makes me think that you just can't disable the saber powers, but everything else should work (if it wasn't buggy).
Neat, do they use strings for bitfields? I usually use any of the standard variable types, but I never have anything that needs more than 8 bytes (double) in which to store data.
I know u can make a bitfield out of a char, which is 1 byte. Have you tried plugging crap into disableforce that was out of the range of the given bitfield? Might make for a neat crash =P
Lucky
I don't know if this helps, but I've seen some server with g_forcePowerDisable set to something like 204419... Yes, that's over 16bit.
Note: Jump/Throw were disabled..
What I mean is, the number is stored as the string "65531", not the number 65531. When the code uses it as a number, then it is converted to a number using the c function "atoi" and then the bits are compared.
As for invalid numbers, I believe the "atoi" function returns zero if the string isn't a number. In other words, it won't cause a crash.