stgatilov

Does the issue happen with r_useLightPortalFlow 1 or r_useLightPortalFlow 0 ? If it does, then it should happen in 2.11 as well.

I guess this is some kind of issue with blocked portals. I think I need to create a test map. Is the light moving all the time? Does anything change if you move door/visportal a bit? Maybe visportal is exactly on the surface of door bounding box?

I probably won't follow this link for safety reasons...

Yes, you still should. We don't know what we are going to do with these issues. Without knowing how many of them exist, we can't make a decision. Viewpos is imbued in image filenames, although some guessword is left for minuses. It is at 2800 -1020 -515.

No, it does not. Caulk, shadowcaulk, or any other opaque material are the same for the sake of area/portal structure. All brushes with such textures are blockers of the same kind. The difference is that caulk is not rendered, is not lit, and does not cast shadows. Shadowcaulk is supposed to cast shadows (while still not being rendered and not lit).

I think it won't work until game restart, and won't work at all in fullscreen/borderless mode. Yes, it's either we need to fix the old tiled rendered, or we need to allow rendering screenshot frame with different resolution.

dev16842-10488 is available.

Yes, this will be fixed in next dev build.

The modules are comprised of models, they are completely ignored by the area-portal graph. And now they don't cast shadows if it is proved that light beams travelling though visportals don't touch them. If you use caulk to create areas, then there is nothing that would cast shadows: brushes don't cast shadows because they don't exist (caulk), and modules don't cast shadows because according to area-portal graph they are not hit by light to begin with. There is internal material called "shadowcaulk". As far as I understand, it is not drawn as ordinary surfaces, but it does cast shadows. I think in order to work properly with new optimization, shadowcaulk should be preferred to caulk for the brushes.

Perhaps because you have too many proguards and they pee too much. I think the core parts for it to trigger is when player switches weapons and then shoots bow at the same time when one of these guards perform "urinate" animation. Maybe we should try to make a test map with horde of these guys, making sure they can run "urinate" animation. By the way, does it has some condition? I can't find any references to this animation in def files, but I think there should be some condition...

In theory, you can pass resolution to screenshot command: screenshot 1000 1000. But in practice it is broken now.

Well, my idea does not work. In reality, the penis gets created/recreated/reattached many times: anim urinate models/md5/chars/guards/proguard/animation_urinate.md5anim { prevent_idle_override frame 1 call overrideLegs frame 30 attach atdm:penis_s penis hand_l frame 30 sound snd_rustle frame 55 reattach penis LeftHips_Dummy frame 70 destroy penis frame 70 attach atdm:penis_urinating_s penis_urinating LeftHips_Dummy frame 70 sound urinate frame 340 destroy penis_urinating frame 340 attach atdm:penis_s penis LeftHips_Dummy frame 375 reattach penis hand_l frame 425 destroy penis frame 425 sound snd_rustle } As you see, the penis is already destroyed at the end of animation. And then there are two more ways to delete it: "attach" command looks at "remove_delay" spawnarg, and if it's positive, then schedules removal of the attachment penis also has "tdm_suicide" script attached, which also checks the same "remove_delay" spawnarg and deleted the same entity after this delay from script thread. So, why do we have 3 ways to destroy the penis?

There are two recordings in the engine. One is "avi" or "render demo" recording, which records the data which flows into the renderer. I generates a lot of data, but I think it worked more or less recently. The second kind records player inputs, and replays them later. Indeed, randomness has to be deterministic to make this work. However, it does not work: the player movements don't repeat. I tried to fix it, but could not find the problem.

I created third version of debug executable (for TDM 2.11). Could someone please reproduce the crash again and post new console log?

I have an idea. From time to time, these kind of guard create a penis during animation. This penis creates a thread during spawn, but it starts it as DelayedStart(0 ms). Instead of running the script immediately, it stores its entityNumber onto the callstack of the script thread. Let's suppose that for some reason penis gets destroyed immediately, and bow attachment gets spawned at this exact moment: then the bow attachment reuses entityNumber of the penis. At some moment suicide thread wakes up, reads entityNumber from stack, and kills the entity with this index --- but now it is bow attachment instead of penis. That's a simple explanation why dangling pointers are dangerous! However, if this really works like this, the whole scripting should be completely broken, since scripts in general often wait long time, and all the entities they reference might die during waiting. I can hardly believe this situation is always handled that bad. I'd like to ask people who have used scripting a lot. What happens if you have a local variable X of type "entity", then you do "sys.wait(1.0);", and then try to use X but it has died during waiting?

Yes indeed, I would be surprised if it fixed by itself. This log files is rather useless in most cases. By the thing is: in case of bow crash, you won't see anything useful in console log either. We already know that bow attachments (or something like that) are unexpectedly killed by tdm_suicide script, but I have no freaking idea why this script runs. The chain of events is long, looking at things at the moment of crash won't help.

I see you are trying to make subtitles system more complicated, but I don't understand what's the reason. And I prefer not to add complexity/normalization if not needed. If someone needs visual cues, he most likely needs them for all sounds. Why do you suggest adding another parameter about visual cues to subtitles definitions?

Yeah, that's the case: 6330 I think I'll be able to fix that. UPDATE: I think I have fixed it.

Nobody should ever play in no-save mode! If you want "ironman" experience, better play in no-load mode.

I would agree with @snatcher, and I think it was the original idea. Speech level is for people who hear sounds well, but don't understand spoken English well (like me), especially if it is stylized (e.g. drunk). Effect level is something even more widespread. It might be useful in the distant future for people who have problems with hearing or just lack speakers/headphones today for whatever reason. I heavily doubt we'll be able to support this case properly, but added this level early anyway. For instance, "Heyyah!" should most likely be on Effect level. Story level was added as default for TDM veterans who also hear well but don't understand English well (like me). I don't want to see these "I've got him cornered here!" and "Just you wait!" all the time, it's enough that I hear them all the time Whether speech is dangerous or not does not matter. If some speech has angry tone instead of quiet, then you can add exclamation mark to carry this information (useful in case player has hearing problems). But whether guards are just talking calm or already want to hang player up --- that he should understand himself by reading the text and listening to intonation. Actually, I don't like the idea of giving any visual difference between Story and Speech for this exact reason. We use subtitles to help player understand English, not to help him draw correct conclusions from it. He should be able to understand himself whether some text is important for his quest or interesting, or not.

Remove setting from main menu means only having the current default value. Anyway, I doubt this would ever happen.

I think it can show different color somewhere based on how much time ago you got the item. This could be useful even in general, not only for multiloot.

There is always something else in some mission which you can miss, which don't fit your classification. Mere fact that the sounds has two beeps should be enough to warn that several items were picked up.

Well, I can propose the best solution to the problem: delete the "Open doors on unlock" setting. But as long as people want to push many tweakable settings into TDM which are deeply connected to game logic, someone should go and fix the mission.

Maybe the reason is that these sounds are non-streaming in the engine...