Restricting Multiplayer Duel Weapons/Force Powers

[TseTse]

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

[Nefilim]

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 :/

[Leo]

saber-power + jump pelase

[The Austrian]

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.

[Devo]

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).

[Syko]

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

 

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

 

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

[Devo]

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.

[ManeFraim]

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....

 

[ManeFraim]

*bump*

 

This is important

[billcow]

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:

[theory]

The second bit somehow affects the "jump bug" with other bits.

[/theory]

this is just a theory, but I will try it out when I'm done with the weapon list.

[billcow]

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.

 

[edit]

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)

[/edit]

 

[edit]

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 .

[/edit]

[ManeFraim]

heh.....

 

We draw ever nearer to a cure.....

 

 

Please. Support our cause....

[Soul-Burn]

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!

[Valdarious]

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.

[billcow]

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.

[Lucky]

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

[billcow]

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

[Wyvern009]

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

 

BTW I like the way you laid out the UI.

[insaniak]

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.

[Lucky]

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

[billcow]

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).

[Lucky]

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

[Soul-Burn]

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..

[billcow]

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.

[Ideaman]