stgatilov

In order to depth sort, it is desirable to take bounding box of surface into account. That would allow to support world surfaces, and entities not centered at origin. Depth sorting has one major problem: as player moves, objects order sometimes changes, which results in a hugely visible "toggling". In a sense, it is more pleasant to render surfaces in fixed order than to sort them dynamically. Wouldn't it make sense if we apply proper sorting only for static surfaces whose bounding boxes don't intersect? I believe it is possible to reliably decide which box should be more distance in this case. Not sure yet what to do if boxes intersect, or how to mix it with dynamic objects: comparison must be transitive...

So if you have two similar translucent objects with different colors, they will look good from one side, but wrong from the other?

So, the latest commits are trying to add "sort by distance/depth" for some surfaces, as well as allow several copies of currently rendered framebuffer. I wonder: how is the problem of Z sorting solved for translucent objects? I mean: the engine probably already has some sorting for translucent objects to make translucency correct... where is it implemented in the code?

Actually, I'm still not certain the script does anything with T-pose issue. I spent a week trying to understand and replicate it to not avail. It is probably some timing-sensitive bug which just just does not happen with script... thank god it does not The original release has 180 "neverDormant" spawnargs but the map has almost 300 AIs. I guess that's why the script improves performance even further.

As you probably remember, I'm strongly against tying LOD setting to all kind of unrelated graphics settings I did not look the latest commits yet, but I think I glimpsed this kind of dependency...

Returned to this story. Looking at flathub requirements: It means running tdm_installer is explicitly forbidden.

To whoever has access to SVN and Visual Studio. I have applied the original patch by @Daft Mugi, except for the code in Physics_Player for automatic crouch/uncrouch depending on direction. And I did not add a cvar, since I believe this change should simply "be or not be" I'd say it feels good. Some minor questions: Pressing crouch on ladder results in crouch indicator quickly going down/up. Perhaps it would be better for it to stay "uncrouched" until sliding down starts? When slide-down is over, player stands up on key release, regardless of whether he was crouched or not when he initiated the slide. Initially I through it would be wrong, but on the second thought this is better because player can simply remember that he will be standing after slide-down, and crouch on muscle memory if he wants.

@Daft Mugi, then don't waste your energy right now. Just wait a bit until some more commits come, then say what's wrong. Such discussions are lengthy, especially when no perfect solution exists. I think sooner or later we come to same solution as @Daft Mugi . I'll review the original patch and see if I can remove the direction-specific behavior but retain the ladder/rope + slide-down handling.

I'm asking the people who had the original problem, i.e. guys on rather vanilla Windows 7. Like @Gadavre

Well, the problem is that I don't like having a bunch of cvars either. We had a story when we realized that multiple missions are broken with use-on-frob turned off. Nobody noticed it because it is turned on by default, and only rare players changed that. I don't even remember if it is fixed or the missions are still broken. Adding cvars will be temporary solution. Sooner or later someone will notice that cvar is broken in a mission and remove it, or declare it unsupported since it is not in the menu, or someone will find out that nobody uses cvar and will delete it, or somebody will delete it because it does not allow to change something which needs to be changed (or because it got broken due to already committed changes), etc. Adding cvars as kill switch or for testing is OK, but adding cvars as legit player's choice... we'd better not. We still have a very lazy solution which does not introduce new problems: use crouch on keyup while on ladder/rope. In the worst case, we can just use it. And since everybody agrees that crouching while on ladder/rope makes no sense, hardcoding state to "standing" is probably OK too.

Protecting children from pornography? Don't believe that shit! That's exactly how internet censorship started in Russia: forbid child pornography, drugs, and suicide info online. By this moment they just ban and disable everything they want for whatever reason. Parents can protect their children themselves using parental control features. There is no need to ban websites or block everyone in order to protect children.

Note that the lightgem indicator does not reflect whether player is currently crouched, it shows "crouch intent" --- whether player wants to be crouched or not. For instance, when you go through a pipe, you can toggle crouch and the indicator near lightgem will toggle too, but the player will stay crouched all the time.

Originally I planned to send the chassis by post. I abandoned monitor, speakers, keyboard + mouse, headphones + mic, and only took the chassis.

Could anyone check if the just released dev build works?

dev16498-9944 is now public! P.S. This is how I celebrate resurrection of my PC

I have successfully resurrected my PC! Here is it packed initially: And this is it unpacked: Yesterday I finally bought a monitor, and everything works: Thanks to everyone for advice! I carried the chassis in luggage all the way through, including flights.

So, this is basically "always slide down crouched, but then restore state". What feels wrong is that when I hold crouch button, I don't really know when sliding will stop, so I hold the button for longer than necessary. It feels wrong that player lands crouched, then thinks for half a second, then for some reason stands up on key release. Anyway, I fell really vague about controls, and I think we need more team members here. @Obsttorte@Dragofer@STiFU@kingsal The initial simple idea "crouch-toggle immediately when key is pressed down" faced the following problem: if player is on ladder (or rope) and he holds crouch button for some time, then he slides down. Previously the toggle-crouch did not happen if sliding was detected, now it happens first, then sliding down follows. So we try to find simple solutions for the issue.

So, we have some more simple solutions: Retain old behavior on ladder/rope, do crouch-toggle only under normal conditions. While on ladder/rope, use crouch key only for immediate slide down, don't let it change crouch intent at all. I tried to do that on top of the current trunk code: toggle crouch again when key is released if slide-down was used. To be honest, it does not feel good, better not toggle crouch state to begin with.

Just checked: yes, the player mantled into crouched state if there is not enough room, even if I was always standing up. Then he stands up automatically when room allows. What if crouch will take effect on keydown under normal conditions, but will take effect on keyup (as before) if pressed on ladder/rope?

Well... yes, sliding down has an issue now for "toggle crouch" people. Do you think that clunky slide-down is worse than toggle-crouch on key release? Do you think it would be better if sliding down forced player to become crouched? On the other hand, I don't agree with what your patch does. I find it particularly bad that crouch state depends on direction of movement when on rope/ladder. P.S. To me crouching on ropes/ladders has two major ponts: If I enter rope/ladder crouched, I expect to remain crouched when I detach (and same for standing state). It would be great if player could detach rope/ladder in crouched state so that he could pass through narrow hole. I agree that existing missions probably avoid such case, and that is not good.

I don't think such distinction will do any good. I think it is better to open equally faster regardless of direction. Thief is in a hurry, he pushes or pulls the door with full force to make it open faster.

I think you won't get a smooth run anyway, because when a door opens to your side, you often block it accidentally. And avoiding that it quite complicated without forcing animations onto player.

Ok, I know why crouching on ladder and rope is blocked! That's because when "toggle crouch" is disabled, you cannot crouch on rope/ladder anyway. Because to achieve that, you need to hold crouch button for long time, and that would trigger slide down to the very bottom. So even if I allow crouching on ladder/rope, players without "toggle crouch" will have very hard time trying to move from the top of the ladder into ventilation shaft. The easiest way around that would be to force "toggle crouch" behavior when on rope/ladder. Otherwise I don't know how to achieve all of the following at once: support "toggle crouch" = off allow sliding down on ladder/rope by holding crouch button allow player to fully control whether he is crouched or not on a ladder/rope

I agree that frob helper should be made default. And the people who are against it should enable it and play for some time, then think again: does it really annoy them or make frobbing things too simple? Also, I don't think frob helper helps you detect hidden loot. It only triggers if you look exactly at a frobable item for a few seconds. If you are looking at a part occluded by something non-frobable, it won't trigger. If you are looking at a part occluded by another frobable item, it will trigger, but it won't help you understand that there is loot hidden underneath.

By the way: I would be glad if someone shared a savegame with T-pose guards on the original version of the mission. If it persists after save/load of course. Such a save may help diagnose and fix the original problem.