Obsttorte

Actually I meant both.

That's bad. That's bad, too.

There is definetely a need for a readjustment of the sound volumes caused by some of the player actions. Especially running and AI dying barks are far too silent, so I second that. The map is in fact relatively dark. The problem is that most maps tend to go into that direction, so the game mechanics have to pay its tribute to that. I've seen this quite often and I guess it's a pathfinding problem. This can happen especially if there is not much room for the AI to navigate. Another possibility is the low amount of light in this specific mission, that probably causes the AI to loose track. For the latter I already suggested to increase the visibility much more when moving as it is in the current setup. I think if you are running with a weapon in your hand your visibility should be at roughly 50% to make sure the AI definetely recognizes you. A last point to the one strike kills. If and only if we would stick to the reality/leave the player all options on how to play/Call of Duty approach, it would only be fair if the AI has the same chances as the player have. Thus meaning that especially the elite guards, as they are ELITE, should be able to take out the player with one strike. Maybe also bowmen should be able to do so. (Please take yourself some minutes to think about if this would be enjoyable for the player). So let's do a summary: The noise caused by the player needs some tweeking. This affects AI dying barks as well as movement noises (as already discussed in other threads) Slightly increasing the AI's health so alerted guards can not be taken out with one headshot. I guess one headshot + one bodyshot is fine. This would guarantee that the player at least looses one broadhead arrow when alerting a guard. Unarmed AI may be taken out with one shot even if alerted. I would apply the same to melee if possible. The bow should need some time to "focus" Sounds are not propagated to the AI if they are caused by someone from the same team (this does exclude barks). So the AI may not hear there comrades fall. If this is the case this should be tweaked. If done so it would make a difference if you take out an AI on a "silent" surface (wood for example) in difference to a "loud" surface (metal, tile) As far as I recognized it most people here seem to agree to that. A further note: Someone (I forgot who) has mentioned he is designing a map were the player actually gets into the position that he have to fight. The person may already know, but it is possible to adjust the AI's health using the difficulty editor.

I tested it and you are right. I don't know how to really lose the report (if I even can). Anyways, I posted the suggestion to change the dmapping routine so it deletes the specific files before actually starting to dmap. Don't know if that is possible, though. I sometimes encountered problems that I solved by deleting these files (just didn't thought of it in this case). This is really something mappers can stumple over. But thanks a lot for looking at it.

Maybe the volume for the latter (alert kills) could be increased a bit. It really depends on the guard density in a map.

The difference between your bow and your blackjack (however you interpret that ) is that the bow is a ranged weapon. Most current maps have a relative loose AI network and are relatively dark or use a high amount of extinguishable lights what makes blackjacking everyone not a big issue, that's true. But that is more a matter of map design. What we are discussing here is a basic gameplay element. No one says that it should not be possible to take out an AI with a single shot to the head. What's been said is that the player should not be able to engage in an open combat with several AI ... and survive this. There have to be some mechanics that actually give you a benefit when sneaking. If ambushes are faster and easier, why should one attempt to sneak? I second that. In addition there should be a difference depending on whether the AI was alerted (so you really have killed here in a fight) or not (a headshot out of the dark).

OK. I just created a test map and it seems they are working. Don't know what happened in the first map. But what still occures is that if I rename a trigger it gets broken. If I rename it back to it's original name it works again. I filed a bug report for trigger_entityname about this but it seems to apply to all triggers.

Yes I mapped a lot over the last year. So I have a pretty fast workflow (sometimes). Overall it took me roughly 50 hours. Divided by 14 means roughly three hours a day. (Or let's say two hours between week and a couple of hours on weekend).

This is nice to hear. Actualy I'm quite sure that the deadline will be delayed a bit.

Maybe also the footstep volume when running. With a bow it is even easier. Once took out 20 AI in a map with thre arrows or so.

I know. That was what I was trying to say. Sorry if it was a bit unclear. If and only if some sounds seem not to alert AI in cases where they should, like it was mentioned with the broadhead arrow, then I think the easiest way to fix that would be to increase the propagated volume for the AI a bit. But it has to be discussed for every single case if it really is a problem. I thought about such cases earlier in for myself. For example if you shoot a torch with a water arrow where the guard is only two meters far away. I think the AI should hear the water arrow impact (maybe it does, unsure). But that's only my view. As said, such changes should be discussed. Regarding sound propagation to the player: I didn't think about the dependency of the volume estimation on speaker radius. This is a little problem, because if mappers don't set a minimum sound distance in a proper way (so there is a noticeable falloff) this might cause some problems. Using the sound_loss spawnarg for players, too would than mean that we have to take the falloff into consideration when transforming the actual spawnarg value (for example 10dB) into a proper distance to achieve the right effect. Regarding the code it just calculates the sound reduction depending on the distance. So an alternative would be to use a spawnarg "sound_loss_player" "X", where X is the amont of noise that should slip trough the visportal. So if one choose X=0.8 for example the sound volume would be reduced by 20%. I guess this is easier to handle then an actual volume based spawnarg, as the distance required for such an reduction would depend on the already achieved reduction on the on side and the falloff type (linear, quadratic) on the other side. Or we just choose a distance based spawnarg. Regarding some AI to hear better: I guess this depends on how loud the players footsteps actually are. It could be already a big change if the cutoff for werebeasts is set to 19dB for example without having a negative impact to the gameplay. I guess this should be tested. (If there is a chance that such things could be implemented without breaking the gameplay, I guess it would be fair to give the werebeast a disadvantage in return. Maybe it can see worse. But this is another story.)

I guess that both AI and player are "hearing" actually the same. The main difference is that for AI all sounds that have a volume below 20dB get cut off, so the AI don't hear them. Changing this value downwards would increase difficulty a lot. But I don't think that any changes are neccessary here. The players already got used to how noise sensitive the AI is, so why change it. Another point is that mappers can actually adjust the AI to sound behaviour (or make it difficulty dependent). Anyways, the system is good as it is. The player also sees more then the AI. The only think that really needs a tweak here is the visportal problem.

I guess so.

Putting your files in the fms folder and change the entry in the currentfm.txt should work. Since the files are no longer copied into the doom folder Fidcals suggestion may not work because of that. Anyways, mine should as I could load my map via console after it was installed (what only extracts the files and changes the entry in the currentfm.txt). EDIT: If this should work be sure to never press the clean button, or all your files will be deleted.

The sound is propagated trough the areas until it reaches the AI. The code only handles the falloff, thus meaning the amount by which the volume of the sound is reduced over distance. If a noise of an object seems to loud or to silent, the object sound volumes have to be changed, but not the sound propagation code. The difference to the sound propagation for the player is that it uses a distance based approach. The algorithm calculates the distance the sound has to travel to the player, and than calculates how much this dimishes the volume of the sound. The code for the AI works with the sound volumes directly. Anyways, the sound loss goes hand in hand with the distance travelled, so as said it can just be added to the travel length of the sound. (similar like it's been done with sound propagation to AI, just that this uses the volume instead)

As far as I can see it from the code the sound loss is additive For example. You have a room with two entries. Let's suggest the sound comes trough the first visportal at 40dB and when it reaches the second visportal it is at 30dB due to the distance. Let's assume furhtermore the sound_loss on the first vp would be set to 10. Then the sound would propagate with 30dB into the room (instead of 40) and would have a value of 20 dB when it reaches the second vp. If the value would have been set on the second vp instead, the sound would enter at 40dB, would reach 30DB on the second vp, but once it has passed the second one and is in the next room would be at 20dB. EDIT: It's the line with the door loss. (It's not clear on first sight but further below it is commented with "// add any specific loss on the portal"). So I guess the portal gives back the loss that is fitting in the situation.

Balancing this would not make much sense in this respect. When I was mentioning this I referred this to the "use two different spawnargs for player and ai" thesis by Tels. Regarding question #2 in post #51 (above). Wasn't it just supposed to reduce the noise that comes to the ai by a certain amount?

Seems so. But if you only need two buttons anyway, you could use the left mouse and middle mouse button for example.

I may should have mentioned that.

There is a script function called getButtons(). The problem is that it only reacts distinguishable to mouse keys/keyboard in the following manner. If nothing is pressed it returns 16, if a keyboard key is pessed it returns 48, if the right or the left mouse key is pressed it return 17, and if the middle mouse button is pressed it returns 20. There is another script function called getMouseGesture() which returns numbers according to the moving direction of the mouse. I don't know which numbers exactly as I didn't tested it. mouseGestureFinished() returns true if the player is not moving his mouse.

Actually it should be even enough to write the folder name into the currentfm.txt file.

What exactly do you not understand? How far do you come? Actually you just create a room in DR, save the map, open the dark mod, open the console, type dmap mapname to build the map and than map mapname to run it. mapname is the name of your map. Make sure it is located in doom3/darkmod/maps

+set fs_game mymap?!

This sounds messy. @Jesps: Can I ask you what exactly you are aiming for. This would make it easier to provide solutions.

OK Regarding the door thingy: there are spawnargs for doors ("loss_open", "loss_closed") that seem to handle this behaviour. I don't know if they only apply to AI though.