TDM 2.03 Glitches/Bugs

[Dunedain19]

I have created this thread to act as a central repository where community members can share any glitches, bugs or strange occurrences, which they discover when playing TDM 2.03.

 

I've just encountered a very strange phenomenon which was not present in previous versions of TDM.

 

I extinguished a light source in my WIP, and without having a moveable candle to relight it, I fired a fire arrow at it. While it did relight the targeted light entity, the "explosion" snuffed out all the nearby light sources!

 

I then placed an AI in the room, and as the fire arrow hit (and killed) him, all the lights were extinguished.

 

Is this a new feature by design, or a bug?

 

--------*--------

 

This one animation has been bothering for some time now. I have attached an image below which shows exactly what I'm about to describe.

 

By design, TDM allows the player to holster their selected weapon. If I am about to swing my sword or fire an arrow at a guard, but then decide against this action - I can simply press 'Z' and the character cancels the intended strike or "de-nocks" the arrow. The same applies for the blackjack, which the player can raise and cancel.

 

However, while animations for the cancelling of the sword strike and the "de-nocking" of the arrow play perfectly, the one for the blackjack does not - as the attached image demonstrates.

Edited February 16, 2015 by Dunedain19

[SteveL]

Is this a new feature by design, or a bug?

 

--------*--------

 

However, while animations for the cancelling of the sword strike and the "de-nocking" of the arrow play perfectly, the one for the blackjack does not - as the attached image demonstrates.

 

1. That's by design Fire arrows create a blast of air in 2.03, enough to extinguish nearby candles.

 

2. I've never noticed that before... For anything like that, please file a bug report. It's not urgent enough to pull anyone off what they're doing right now, but like you say it would be good to fix so we need a bugtracker so we don't forget about it.

[Dunedain19]

Thanks for the clarification, SteveL.

 

I will go log a bugtracker on it now.

[Dunedain19]

 

1. That's by design Fire arrows create a blast of air in 2.03, enough to extinguish nearby candles.

 

However, shouldn't fire arrows have no effect on electric lights?

 

As it stands, when fired at electric lights that are either on or off, a fire arrow will change the lights to the opposite state.

 

Surely, this should not be happening?

[grayman]

Are you sure they're electric? Gas lights, which look like electrics, should go out, but electrics should be unaffected because they're not flames

[Dunedain19]

Yes, I'm sure.

 

I'm using four atdm:cagelight entities and all four are being simultaneously relit/extinguished.

 

EDIT:

 

I tested again, turning up the volume on my speakers, and I made an interesting discovery. What is happening is that the "air bubble" from the fire arrow is actually pushing the button controlling the lights. The sound of the exploding fire arrow was masking the sound of the button being used.

 

Just how big is the radius of the air bubble, because the switch is 112 DU away?

 

Gas lights, which look like electrics, should go out

 

This actually isn't the case at all. After reading this, I went back to my WIP to test this and despite firing fire arrows directly at the gas lamp entities, they continue to stay lit/unlit.

Edited February 18, 2015 by Dunedain19

[grayman]

1 - The buttons

 

The force radius from a fire arrow is 155. Buttons can be pushed by an outside force. This predates 2.03.

 

2 - Gas lamps

 

You're right. Our gas lamps are treated like switchable electric lights. Though a GASLAMP designation exists in the code, none of our gas lamps use it. I suppose this is okay, since our gas lamp models have a glass enclosure, so one could argue that a nearby force wouldn't extinguish the flame. And there's no attached flame anyway, which I suppose is a separate long-existing problem.

 

So the force from a fire arrow extinguishes nearby flames only.

[TheUnbeholden]

I noticed that crouching before landing doesn't cushion most of the sound anymore. I thought that was a nice feature (à la Dishonored), that made sense to me because it reflects how you would land in real life bending to absorb more of the weight, some into your arms and not all at once but landing on one leg, bending your knees as you land on the other leg. How much sound does it block out now? (audio wise it sounds the same)

Edited March 6, 2015 by TheUnbeholden

[SteveL]

I was the last person to make changes to landing sounds, about a year ago in 2.02, so I'll check when I finish work. It might be that the sound you hear is the same but the sound that AI hear is muffled. The two are controlled independently, and I can't quite remember how it works.

[Oldjim]

I would agree with that - it is a right pain

Playing NHAT2 beta

Dropping down into the Guardroom as usual I fired a moss arrow then dropped down from a crouch behind the guard and he would often be alerted and stand up

Dropping from the desk had the same effect

In the end I had to use several moss arrows to cover all the bits

Now this may be the effect of dropping but it may also be that the moss arrows are not too effective at muffling sounds when you drop onto them

Edited March 6, 2015 by Oldjim

[Springheel]

Dropping onto moss should be virtually silent.

[Oldjim]

That is what I thought - but it wasn't

[SteveL]

I did some tests and at least in my test map, it all looks sounds ok.

 

First, the rules in the code:

 

The player hears:

• A default sound level specified for the exact footstep sound. These are quite specific, such as tdm_footstep_stone_crouch_walk, or tdm_footstep_grass_jump_land
• Plus or minus a modifier for the movement. For crouching, it's -2 volume
• Minus an extra modifier if the player is falling or dropping off something in a crouched position, i.e. not actively leaping into the air. That's -7

AI hear:

• A base sound level for the footstep type, not the same as the base level that the player hears. It's got from a spawnarg on the player.
• Minus the same -7 modifier if the player is falling crouched, i.e. not actively leaping (there's no adjustment when leaping, just when stepping carefully off things. That's a fix for the bunny hopping exploit).

 

Some measurements

For the player leaping or dropping off a 120-unit high wall onto a tile floor, with or without moss blobs.

I shot only 1 moss arrow and never missed the blobs once -- always got the softened sound.

I don't know what these numbers actually mean or where the "no sound" level is. Small negative numbers still result in an audible sound. but clearly, lower number means less sound and it's all doing the right thing, at least in my test map.

 

Landing on Tile:

Standing drop: Player hears: -4. AI hears: +6

Crouched drop: Player: -13. AI: -1

Standing Jump: Player -4. AI: +6

Crounched Jump: Player: -6 AI: +6

 

Landing on moss:

Standing drop: Player hears: -14. AI hears: -3.8

Crouched drop: Player: -23. AI: -10.8

Standing Jump: Player -14. AI: -3.8

Crounched Jump: Player: -16 AI:-3.8

 

The basic mechanism clearly isn't broken. So what you observed is probably situation-specific. @Oldjim: It sounds like moss blobs did work for you, you just had to use more than one. Does anyone know if the player clunks audibly against furniture on the way down?

[Oldjim]

Sorry - that was a duff report

I had completely forgotten that this was the first time I have played it on hardcore/hardcore which easily explains the difference

[SteveL]

np, thanks for confirming

[Dunedain19]

Noticed something weird while testing my WIP, so posting the experience here.

 

As I understand it, proper sound propagation depends entirely on the presence of visportals. The more portals a specific sound has to travel through, the quieter it becomes by the time it reaches the player (or the AI).

 

Provided that the above is correct, I have noticed that I am still hearing the opening/closing sounds from a door that a patrolling AI uses - even when I am well out of auditory range.

 

To elaborate further, I am currently situated one entire floor away from where the AI is patrolling - thus, there are over five fully sealed rooms between him and I, and yet I can still hear him open and close the doors that he encounters.

 

To clarify, it is not as if the sound appears directly next to me, it is muffled to a certain degree; however, surely I shouldn't be hearing those sounds at all - given that I am out of both visual and auditory range?

Edited April 3, 2015 by Dunedain19

[grayman]

Sound is not occluded simply by going through a visportal. See details here. Visportals w/o doors or info_locationSeparator or info_portalSettings entities touching them only define the path a sound takes as it travels.

 

If you're hearing a sound you don't think you should be hearing, then either the sound is louder than you think it should be when it starts off, or there's a leak between the sound origin and you and a propagation path through that leak is allowing the sound to take a short cut, skipping visportals.

[SteveL]

Try setting console var tdm_showsprop. It shows that path taken by sound from you to an AI. So you won't see the door sound made by the AI, but when you hear that sound and so know the AI is at the door, you can try jumping or throwing something to make a clatter, and you'll see the path taken by that sound to the AI who just opened the door.

[Dunedain19]

@SteveL, I have attached two pictures below both were captured after inputting the 's_drawSounds 1' cvar.

 

The first image (immediately below) depicts the sound from a guard yawing (or making some sound) that is on my current floor. While the line is shown as reaching me, I cannot hear it because the guard is simply too far away.

 

 

 

 

 

 

 

 

The second image shows the existence of the door opening sound, as it occurs in real-time. There is no directional arrow that appears when the sound is played, and having heard it again today - the sound is actually quite loud, despite the fact that it is even further away from the player than the sound depicted in the first image.

 

 

 

 

 

 

 

 

@grayman, I haven't yet set up any info_locationSeparator or info_portalSettings entities yet. Perhaps doing so will solve the problem?

[grayman]

@grayman, I haven't yet set up any info_locationSeparator or info_portalSettings entities yet. Perhaps doing so will solve the problem?

 

You might not need or want them; it depends on your architecture. If there's an internal leak, they might not solve the problem.

 

Rather than guess about what might be wrong, I'd rather see the map or the segment of the map exhibiting the problem. Sometimes the root causes of problems have nothing to do with the suggestions made to fix them.

[Dunedain19]

If I'm not mistaken, the map I sent you some time back should exhibit the issue. Just move the 'Player Start' entity out of the hallway where it is located in that particular version.

[grayman]

Where are you standing when you're hearing sounds you don't think you should be hearing?

[grayman]

And ... are you hearing the 'bad' sound only once, or all the time if you stand still?

[grayman]

Corporal Fredericks appears to be the only AI opening doors. If I start him at a different place, where he has to go through three doors to get to his first path_corner, I hear all three doors when they open, but I don't hear them close.

 

I'll prolly have to debug the sound paths. I don't see an obvious internal leak, but you never know.

[grayman]

I find that being able to debug this atm is going to require more time than I can give it.

 

Please file a bugtracker issue and I'll tend to it when I get the time.

 

I can reproduce the problem. In fact, if I give the only AI who's opening doors at mission start three upstairs doors to walk through before he reaches me, I can hear all three doors opening. If I move around a bit, leave the hallway, go into adjoining rooms, come back, and stand in the same spot where I started, I can no longer hear the upstairs doors open when he gets back to that part of his patrol.

 

So something changes, simply because I walked around some.