Quick server fixes for defrag 1.92

For those who want to give this test version a try, the servers are :

  • cggdev.org
  • cggdev.org:27961

Changelog is:
- fixed up broken "don't change map" option for nextmap votes
- fixed usage message for callvote map
- callvote console message back in
- added "mode" alias for callvote gamemode
- fixed numerous issues with callvote gamemode
- picked up flags are reset upon player respawn
- removed CVAR_CHEAT from cg_gun# cvars
- removed drowning sound effects when player damage is off

Download (only necessary if you plan on playing offline or running a server):
http://q3defrag.org/files/defrag/defrag_1.92.01.zip

By the way, usage for the map callvote is: callvote <map|devmap> <mapname> [vq3|cpm] [df|tm|fc|tm1-7|fc1-7]

Comments

Што за нах написуй по русски

Што за нах написуй по русски !!!

Я не говорю по-русский !

Я не говорю по-русский !

.

Why callvote mode in 1.92 needs map reload ? Also \callvote mode[ENTER] don't display modes description.

Sorry Alien I misunderstood.

Sorry Alien I misunderstood. Callvotes that only affect the game settings (and that do not load or restart a map) won't go through intermission / reload in the next versions.

That's an issue with the

That's an issue with the engine and g_gametype changes. Sometimes the client restarts.

.

So it can be fixed ? I can live with it but ...

Yeah it can be fixed in the

Yeah it can be fixed in the dfengine.
Defrag could stop using g_gametype 4 for fastcaps as well.

Just noticed online, if you

Just noticed online, if you grab flag and /kill immediately after, the server sees the finished time but the .rec file doesn't get written to. : D

Not sure what you mean -

Not sure what you mean - /killing right after capping?

Yeah. In this case I hit my

Yeah. In this case I hit my /kill bind too soon after capping the flag, the server saw the time set but locally it was if I've never played the map as I was missing my 'best time' for that map hehe :D

That one is actually a

That one is actually a problem with the game design as it is currently laid out. The defrag client detects transitions in the player status in order to make out events such as respawn or timer-stop. So basically when you hit a timer-stop trigger the server toggles a bit in the player status that says "hey I just stopped the timer".

The player's status is reset every time they respawn, so basically the client doesnt/can't account for status transitions when the same server snapshot spans both a respawn and timer events. The timing is almost uncanny though, I think this may be due to you having a poor connection on the test server. I'm able to reproduce the issue by emulating a poor connection.

This didn't happen in previous versions because players didn't respawn immediately.

Well, for this I think I was

Well, for this I think I was just a little too quick on the kill :) The server was online but it was a local server in Chicago where I ping 49ish. Maybe I just need to not be so hasty on the /kill bind :DDDD

I'll see what can be done.

I'll see what can be done. I'd like to fix that actually, but I'm afraid this will require some significant refactoring. I'll leave it for future updates if this turns out to be the case.

 

About timers, maybe starttimer should be activated when the trigger is actually left. There are a couple of maps, especially old ones with a starttimer all over the start and you then have to time it in order to get a good start. See the map lick-more2 e.g.

I've had the temptation to

I've had the temptation to make changes to the timer entities from time to time, but that means breaking a lot of things along the way, from demos/rankings to how a map is intended to be played. Not that this is bad in the long range, but backward compatibility has always been a daunting source of trouble in defrag.

I think this sort of variation from the original behavior would be best left at the mapper's discretion, but that also means the old maps won't benefit from it. For instance there have been talks about letting mappers flag timerstart targets as not being resettable, but that never made it into the mod.

Some new Spawnflags for the

Some new Spawnflags for the defrag entities would be great.
Especially players would benefit, cuz even unexperienced mappers could easily find the way to not make the timers retriggerable.
(ye, the experienced mapper anyway knows how to overcome this problem)

cgg, do you plan new entities - as they were suggested in prior "threads"?

yep, but the focus is on

yep, but the focus is on getting 1.92 out of beta and fixing 1.91 right now.
I'd first like to gather opinions from the ppl who are mapping.

 

Some people designed maps with trigger_multiple to never be retriggerable (unless you kill, etc).

Since all normal maps would allow times being 10-15 faster than what they're now it'd make sense to either only apply this "fix" to the maps where the spawn is inside the trigger or to reset all times (yet again).

After all it's probably the best to leave it unchanged since it's just annoying and the mapper's fault, but not that disturbing.

or maybe not so uncanny -

or maybe not so uncanny - I've been able to reproduce the issue with average connection settings, it's just harder to trigger reliably. Either way It needs fixing.

Hmm, did a /callvote nextmap

Hmm, did a /callvote nextmap on your FC server and went to intermission this time, but didn't change map for me as I was stuck at the scoreboard screen. Hitting 'tab' gave me 'Connecting...' for the Score and Ping fields.

Awesome work on the bugfixes :D

 

quick update, dl'ing and reporting later

 

Those 2 testservers of yours are weird...I can't callvote, switch teams etc at all....running around and shooting works

Very weird - I don't have any

Very weird - I don't have any trace of you connecting in the game log.

 

Done some more testings...it works fine with the original quake3.exe, but fails on dfengine, ioquake3 or any other custom compiled .exe

The scoreboard wont display at all too when I press tab, kill works neither, etc...weird issue unless you intended something alike :)

No idea why it would do that.

No idea why it would do that. It's a pretty basic server - it runs id's engine. I don't seem to be having that problem.