Had weird announcer sounds in CTF. After capping the flag I heard "3 frags remaining". Then I did a frag. Nothing happened. NO announcer sound. After capping another flag I heard "2 frags remain". Then I figured ... maybe the announcer wanted to tell me "x captures remain" ?

Anyways, as I've access to the config of the server, I could only find this limiting setting:
g_ctf_capture_limit 250

Ideas?

It's rather simple, just switching the sounds to say "x captures for victory" or something. ^_^ Of course they have to be made first
The other sounds could just be used for DM and TDM and such.

Btw, anyone knows how Tenshihan's doing? He's been quiet for a long time now.

Tenshihan has been really ill. Last I heard from him he was headed to the hospital with pneumonia.

In revision 5160, the hookbomb was changed to apply its bomb damage over time. This produces a series of hit.wav plays: one per tick per player. It's bearable when you've only snagged one enemy with the bomb, but gets annoying if you've hit two or more.

divVerent wrote:As for the crylink fire - you're right, but it fires many projectiles at once. Dynamic light from that would easily bog down many systems.

Yeah, that is true although I don't think it could create enough dynamic lights to slow down the system. The crylink fire is fast, and it would be hardly possible to have even three crylink projectiles in the air simultaneously from the same gun... so far I could only have two by shooting at a far distance. The hagar creates much more dynamic lightning then that when its rockets explode into walls, and not even that slows the FPS down any.

If it is indeed that bad however maybe a limit could be made, so as long as one or two projectiles from the came Crylink are in the air anything after then that would not have dynamic lightning until one of the previous hit, reflected and died away. Maybe a cvar for it would be useful, or maybe an overall limit for dynamic lights.

Surb wrote:In revision 5160, the hookbomb was changed to apply its bomb damage over time. This produces a series of hit.wav plays: one per tick per player. It's bearable when you've only snagged one enemy with the bomb, but gets annoying if you've hit two or more.

It's not that annoying to me. Also, it is the very same sound no matter how many players you hit, actually. Only one hit.wav is played per frame. See the code.

I wonder if the volume of the sound should vary according to the damage.

If you fire a hook, hold shift, and then release primary fire, the hook will still cling to whatever you hit, but not pull on the player. If you press primary again, the hook will start pulling again. If you release shift, the hook will disappear.

I found a bug regarding trigger brushes in maps, which appears to happen in both the 2.4.2 release and in the SVN alike: Triggers which are set to be shot to trigger do not appear to work. To reproduce, make a map and create a door with func_door in it. Now make a brush and put the Trigger common texture on it (put it somewhere where you know it's position as it's invisible in-game). Now link the trigger and the door together and to make sure everything is right so far, compile the map, go into it and touch the trigger which should open the door.

Now return to Radiant and open the trigger's entities menu. Add the flag "health 5" to it, which in the latest entities.def file says that if this key is set the brush is triggered once X damage is done to it. Recompile the map then go in-game and shoot the trigger with any weapon you wish for as long as you wish. Neither shooting it nor touching it does anything this time, while normally (as far as I understood) the trigger should act once X units of damage are done to it.

I tried setting the Health key to different values, enabling the allents spawnflag, texturing the trigger with normal textures rather then the trigger one, shooting it then touching it and all sorts of combinations in the entity settings to be sure I didn't miss anything, but nothing makes the brush be triggered when shot so I'm guessing this is a bug in the game. I used NetRadiant to compile and test my map with this, compiling the BSP, vis and lightning separately.

This is not a bug, it's a feature
You just need to shoot at the entity linked to the trigger brush, not at the trigger itself, and it should work.

Agelith wrote:This is not a bug, it's a feature
You just need to shoot at the entity linked to the trigger brush, not at the trigger itself, and it should work.

I see now. I still sense something's wrong however, although I'm not sure what the health key is initially intended to do. From my test after what you said the only way to make the door have to be shot open is to set the "health X" flag into the door itself, not any trigger (at that point the door likely works without any trigger attached to it even). So if the health flag is to be set in the func_door and the door itself be shot open then, what purpose does the health flag in a trigger_multiple and other triggers have?

The way I see it a trigger with the health flag in it needs to always activate when that trigger is shot. It's what the description also says when you select a trigger and read its entities definitions ("health: amount of damage that has to be dealt to the trigger to activate (it then won't respond to merely touching it)"). If someone wants the door to have to be shot open they just set the health key in the func_door rather then the trigger, and if they want to have a separate trigger needing to be shot to open a door have the health flag in the trigger.

I think its important to be able to make shoot triggers around maps at this point as well. I initially tried this on my map hoping I could make a shoot switch for a trap door, so if this won't be changed I'll have to go with other types of switches if there isn't any way to make a separate shootable switch for a door. Maybe at least a toggle key or spawn flag could be set up to allow shoot switches to work?

Check out red star republic to see how switches work.

Found 3 other problems in the SVN today:

1 - This issue always existed since 2.4.2. Enabling "Use GLSL to handle color control" from the Video menu darkens the menus and makes them hard to read, and no brightness or contrast setting can make them brighter. The menus should not change their brightness when that option is enabled or disabled.

2 - I'm not sure if this was done on purpose (I hope not) but dragging the bot slider to anything over 4 does not do anything any more. Normally one was allowed to add 7 bots into the match, but now if you drag the "Number of bots" slider to 5, 6 or 7 only 4 bots remain joined in. I know bots probably take some resources and having too many may be stressing to the server, but I think a maximum of 7 was reasonable. I always felt like even 7 was too little of a limit... this also makes things bad in team games especially as you can't even have 4x4 teams any more (you + 7 bots).

3 - This isn't so much of a bug as it is a change of settings, which most likely happened with the recent weapon rebalancing. Bots are becoming way too strong and on the Advanced bot difficulty it can take quite some effort to kill them now. There are times when I have to shoot bots with the shotgun more then 8 times (which hit I mean) and if they picked some armor up it may even take 4 or 5 rockets to kill a bot. It's very annoying to just shoot bots times and times again and have them not die sometimes, so maybe the bot strength could be decreased with at least 10-15% more then it currently is. To keep the overall difficulty intact, bots could be made to have a tiny bit more shooting damage at higher difficulties instead.

Apart from that I would like to say an opinion on something else which isn't really a bug. In one of the recent revisions there were some physics changes and at the ending it said "Please Test". I tested them and I believe that the new player acceleration is a bit too much. Personally I would go with a player acceleration half between what it previously was and what it was changed to currently... probably a bit faster then that.

IMO, most of the things you mentioned are not bugs.

Alien wrote:IMO, most of the things you mentioned are not bugs.

I considered the menu darkening a bug as I think GLSL color control should only affect the 3D environment, not the menus, so that's more like a glitch from some points. The bot number problem is a bug as the game and menus are set to initially allow 7 but the game seems to be stuck on allowing only 4, braking at least the menu setting and likely the Campaign and probably other things as well.

[EDIT] Bug 2 in my post above does not exist. The reason I was getting limited to 4 bots was because I accidentally dragged the Number of Players slider to 4, so both bots and players were getting limited to that. I apologize for my mistake.

GLSL can manage brightness, so why shouldn't it affect menu?

Bots are emulated clients with ClientConnect(); PutClientInServer();

Alien wrote:GLSL can manage brightness, so why shouldn't it affect menu?

Its problem is that it darkens the menus too much and there isn't any other brightness setting to brighten them back when it happens. I also see no use for it changing the menu darkness either. If it's a normal thing and better left unchanged however disregard my report.

Anyway I found another thing which I consider a problem... this happens at least for the Windows version of the game: If you let your client run in a match then minimize to Windows and return back to the game after a few minutes, when the game is restored after being minimized (and muted) all sounds which were played while the game was down (weapon shots, pain sounds, etc.) are played at the same time all of a sudden causing a loud audio explosion when the game is restored. The sounds are basically remembered, and when the client is restored they are all thrown at the same time instead of being forgotten and never played at all. I'm not sure if to consider this a bug or not so I hope I'm not going down a wrong path reporting such things here.

Nope. This is not a bug.

GLSL postprocessing takes place after scene rendering, before 2D rendering (so the same pass does bloom too).

Menu is not passed throuhg GLSL postprocessing, because it is 2D, and it really isn't feasible to do that (or menu would get bloomed).

So with GLSL gamma, the color control values can't affect the menu. With hardware gamma, they can and do (they also affect other windows on the screen of other apps - they affect EVERYTHING). That's all.

So GLSL gamma does not DARKEN the menus - but it does not BRIGHTEN them, as HW gamma does. This can't be helped.

Bot slider - works for me.

Bot skill - just reduce their skill value.

MirceaKitsune wrote:[

this happens at least for the Windows version of the game: If you let your client run in a match then minimize to Windows and return back to the game after a few minutes, when the game is restored after being minimized (and muted) all sounds which were played while the game was down (weapon shots, pain sounds, etc.) are played at the same time all of a sudden causing a loud audio explosion when the game is restored. The sounds are basically remembered, and when the client is restored they are all thrown at the same time instead of being forgotten and never played at all. I'm not sure if to consider this a bug or not so I hope I'm not going down a wrong path reporting such things here.

I had that on mac too, but it is gone now for like two months.

Current SVN Bug:
Take strength and go through a teleporter. Your weapon model disappears. It comes back some time after strength wore off. Changing the weapon during strength doesn't help to get the weapon back!

Found another bug in the latest SVN which has been there for a little while. Some announcer voices now play at a very low volume (possibly directionally?). For instance, after I kill a lot without dieing I hear the announcer voice saying "Rage!" at an almost unhearable volume. Voices such as "X frags / minutes remain" are heard correctly however and yes I have the announcer / Info volume slider all the way up to MAX as well as all other sub-volumes. Headphone Friendly mode is enabled... this may probably be the cause or it may not.

Found new bug in latest SVN, after div0 patched something having to do with invis:

Taking strength and going through teleporter works now (I still see my weapon).
However, I found 2 new severe bugs:

1) when watching the demo in chase_active 1 and my player goes through a teleporter, the view is screwed up and even if I switch chase_active back to 0 and then to 1 again, I can't get the old chase_active view back again!

2) I "lost" the flag while walking out of the facing_worlds base without doing anything. I can not really reproduce it though. That's why I uploaded the demo here

Stop blaming ME again. You always blame ME.

The patch that caused it was from the sourceforge bug tracker, and was meant to fix invisibility in minstagib after teleporting.

Well my statement wasn't meant that way. I wanted to say that the weapon-invis bug was solved by this, but that were other bugs left (that had probably been there before anyway).

In my sentence there was missing an "even". It should be:

Found "new" bug in latest SVN, even after div0 patched something having to do with invis

Not that I'd have to justify this... I do not always "blame you", this is ridiculous.

I somehow don't hear mortar, RL or other explosions anymore. I do only hear them if (in theory) a possibility exists that I could see (not taking my v_angle into account). However, if I go behind a wall, it's gone. This is not good!

I don't think this is a "bug", I think this has something to do with culling such entities or CSQC, or something like that. However, I really expect to hear explosions even if they happen behind a wall... everything else is misguiding!

What's the problem with that, why can't walls be "sound proof"? Could easily enable that again, but it's a sure way to get wallhacks to work easily (like before).

The problem is that is becomes very unrealistic, as this is also in effect when the explosion happens in the same room you are in, but you just decided to hide behind a small obstacle, e.g. a pillar, or behind the stairs, or whatever.

Also I don't understand why suddenly wallhacks would work because of that. In v2.4.2 I am able to hear the sound and can not see the player anyway...

that hack would be a simple engine change to show a sprite at any sound source. no more info, though.

I checked out latest SVN and am happy that the sound is back again (thank you!). However, if you find out that performance suffers due to this change, well, I think you could apply your mentioned hack. In the end the important thing is that players can hear the explosion sound, and not how they hear it.

GreEn`mArine wrote:I checked out latest SVN and am happy that the sound is back again (thank you!). However, if you find out that performance suffers due to this change, well, I think you could apply your mentioned hack. In the end the important thing is that players can hear the explosion sound, and not how they hear it.

No, the mentioned hack is a CHEAT.

divVerent wrote:

GreEn`mArine wrote:I checked out latest SVN and am happy that the sound is back again (thank you!). However, if you find out that performance suffers due to this change, well, I think you could apply your mentioned hack. In the end the important thing is that players can hear the explosion sound, and not how they hear it.

No, the mentioned hack is a CHEAT.

Oh ok. I actually didn't quite understand what you meant with the sprite at a sound source thing anyway