stgatilov

These warnings come from core assets. I think I have fixed this issue already in recent 2.12 dev builds. But it indeed happens on 2.11.

One person has managed to run TDM in Parallels on M1: He ran 2.10 and he had to switch to old backend (r_useNewBackend 0). Same should help in 2.11 However, old backend no longer exists on the future 2.12 branch. Only one backend remains, which is a mix of the two. Let's hope it works in this scenario.

Oh my god! I can turn into a cup! I love the game

I have gone outside station. So... I have 6 buttons to accelerate along 3 axes, mouselook to rotate around 2 axes and 2 buttons to rotate around third axis. And 1 button to remove velocity limit and 1 button combo to brake. I suppose this is a nod to Descent (which I also did not play). Quite surprised to see such complex controls in a modern game.

dev16854-10518 is released Everyone who saw silver items overly bright, please check that it does not happen on a new build.

So, I started playing Prey. I see many similarities with TheDarkMod controls Mantling, leaning, crouching, grabbing objects to move and throw, even dragging bodies. Perhaps both Prey and TDM use the same game mechanics from System Shock. Did System Shock allow dragging bodies BTW? Dragging bodies even feels equally useless in TDM and Prey. My brother played System shock 2 but I did not. But my vague memory says Prey is a game of the very same kind.

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.