if no mapscripthash is specified, any mapscript is allowed
if a mapscripthash is specified, and the hash of the loaded mapscript does not match, an error message is sent to all clients, and the config is cleared.

the hash of the current script is stored in the readonly server cvar b_mapscripthash, so clients or server admins can query it.

Also improved config error handling. Now all parse errors result in the config being completely cleared, and a message broadcast to connected clients.

lua changes:

ps.viewangles added

s.eventParm added

ps.origin added

specinvite improvements:

show spectator invite status in /players.
Where /players previously showed a red X for axis or a blue L for allies, it shows the following for spectators
SH shoutcaster
SB invited both teams
SX invited axis only
SL invited allies only
S not invited
This could be made more verbose if people think it is too obscure.

add specuninvite command. Refs and shoutcasters may not be invited or uninvited

#939 - etpro doesn't play the the prepare and fight sounds when unpaused

#954 - setcs rcon abuse

#948 - using a fixed MG pauses panzerfaust

#955 - some trigger_objective_info fields cannot be modified from mapscript. We now allow trigger_objective_info fields to be changed in mapscript spawn section. Some (spawnflags, customimage, score, target, track, message) must be changed in the first frame, or first 3 frames.

#949 - don't leave the player with an empty grenade launcher (weapalt bug);

#962 - revive can leave you with an empty rifle grenade launcher

#957 - weaponbank 10 crashes the client

Prevent antiwarp circumvention via pmove_fixed

#961 - Having too many counters drawn crashes the cgame

#969 - accum buffer index validation is borked. allow 10 global or local accums, and correctly print an error if the script tries to use too many.

#970 - some items in the etpro config menu first page cannot be bound. make resettimer, opentimerinput selectbuddy 6 and 7 bindable in menu.

I don't resemble that remark!
Tigers are not turnips, you silly American!_________________Weblion "Th' Politically Inco'reck Tiger" X
If a VCR uses the 24-hour time format, does it still blink 12:00 after a power outage?
Pushing electrons since 1990
120VAC -> Ground == Bad

Pfft. Go jump down gamma ramps all night with your pmove_fixed 1 and your b_fixedphysics 0 and your com_maxfps 333. The rest of us like to play normal W:ET without being limited to one or two com_maxfps choices, while still being able to make the jumps that matter (Radar, etc.).

b_fixedphysics FTW. Hard-code that shit.

P.S. There is a similar stink in the Q3 community over what arQon did to VQ3 (read: OSP) in CPMA. The noobs can't make bridge-to-rail on q3dm6 with CPMA's fixed physics, so they cry and say he's destroying Quake. Meanwhile the players who actually had skill to begin with are still able to make the jump with ease. In fact there's a video someplace of a guy jumping back and forth like 50 times with fixedphysics like it ain't no thang . . ._________________Please direct all gameplay-changing feature requests here.

I, too, want to support setting b_fixedphysics to 1 (and b_fixedphysicsfps to 125). I'm not sure if the argument I'm bringing forward here has already been mentioned on the other threads discussing the matter, but I'm too lazy to search now. The argument really is common sense to me, but maybe not everyone knows about it yet.

As we all know, cl_maxpackets is limited to 100 in ET (unlike 125 in Q3). If you have com_maxfps 125, you can have a maximum effective number of sent packets per second of 60 (or 62(.5)? not sure atm), regardless of your cl_maxpackets setting. If you have com_maxfps 100 however, you can get those 100 packets for (presumed) ultra-smooth gameplay. 100 Hz is also easier to achieve with CRT monitors, or allows to use higher resolutions while still being in sync with your fps. Running the game at 100 fps without fixed physics reduces your jump height though, so that's not really an option.

And this is only the high specifications side of the coin; there are still many people playing who can't reach stable 125 fps, even more so on packed public servers.

Competitive play isn't affected, obviously, because all competitions I know have fixed physics enabled. The better administered public servers use it, too. And those also had b_realhead 1 when it wasn't default yet. I can't see a reason why there should be a difference in gameplay between competition matches and public play. Let's face it, the majority of server admins don't know what b_fixedphysics does or even don't know about it at all. It seems natural to me to apply the same logic as with b_realhead.

I have two loosely related questions to the devs:

1) Is the reason why the fps dependency of recoil hasn't been fixed yet because it can't be done without modifying the game engine? Or because it's too nasty to implement? In an ideal world, you wouldn't be obliged to switch fps to 76(72) when you're sniping or using a pistol to minimize recoil, because running 76 fps with a screen refresh of 120 Hz (I can't tell about 100 Hz yet because I haven't tested it) gives me a very unsteady view.
2) Same question for the turning spread issue discovered by madscientist. PCs are picking up speed rapidly atm and my guess is that more and more people will be inclined to exploiting it. For a few weeks, I could run those 250 fps necessary for fully capitalizing on it myself.

*EDIT*
I was asked to add another question, while I'm already at it.
3) Is there any chance of implementing cl_maxpackets 125? If engine modifications are necessary anyway, maybe this could be done at the same time.

PCs are picking up speed rapidly atm and my guess is that more and more people will be inclined to exploiting it. For a few weeks, I could run those 250 fps necessary for fully capitalizing on it myself.

Don't worry about that, punkbuster updates will keep a lid on the framerates.