stgatilov

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.

I temporarily removed the mission from in-game downloader by @geegee request. Could please someone who had the T-pose guards issue update to the new version of FM and post whether they still have the issue or not?

I'm very sorry for the long delay on this matter. I have extracted two fixes from the patch and committed them to SVN (no cvar): 5961 Fix rope/ladder speed while crouched 5973 Change crouch state on key down with crouch toggle Speaking of the rest of the patch (5962), I did not commit it. As I said, I personally don't like this behavior change, and given that it adds some stuff to the code, I'd commit it only if several team members agree that it is worth it. However, @Daft Mugi has found two more issues which are still present: 4247 Using the crouch key when climbing a ladder or a pipe 1746 Climbing physics should use crouched player bounding box I think the real problem here is that when player is on rope/ladder he can oncrouch, but he cannot crouch. I have no idea why. I'd say: we should allow player to crouch and uncrouch regardless of whether he is on rope/ladder or not. That would be simple and consistent, and will solve the issue of going into narrow ventilation shaft immediately after climbing a ladder.

We have never removed any FM from the new database yet. Looking through the scripts, I think simply removing the directory should work. The best thing would be to "svn move" the directory outside "fms", so that later we can "svn move" it back with some updates. @geegee, Should I do it right now?

It takes the latest quicksave. Perhaps main menu does not display both keys because one is "loadgame" but another is "loadgame quick". While they are functionally equivalent, the code which displays controls in the menu is not smart enough to understand that. Of course, it would be more appropriate to use the same command for both keys, which will probably fix the display error. Or even better: change to F5/F9 scheme without alternatives

I am also annoyed with F4+F5 combo every time I reset my config or take a fresh release installation. I think F5+F9 combo is more standard today, and it would be great to change. I see the following in default.cfg: bind "F4" "savegame quick" bind "F5" "loadgame" bind "F6" "_impulse20" bind "F7" "_impulse22" bind "F9" "loadgame quick" How "loadgame" is different from "loadgame quick"? void LoadGame_f( const idCmdArgs &args ) { console->Close(); if ( args.Argc() < 2 || idStr::Icmp(args.Argv(1), "quick" ) == 0 ) { idStr saveName = GetMostRecentQuicksaveFilename(); sessLocal.LoadGame( saveName ); } else { sessLocal.LoadGame( args.Argv(1) ); } } There is no difference. You pass filename as argument, or "quick" to load latest quicksave. But if you don't pass an argument, it just default to "quick".

Yes, I think it is very likely. If they stay dormant since the beginning of the mission till the moment you see them (which is a bug of course), then you should see them as T-pose still figures. If someone can reliably reproduce the issue from fresh start, then it would make sense to drop the spawnarg on these AIs and check if it helps. To be honest, I recall seeing guards in T-pose some time ago, most likely when I tweaked/broke something. I'd suggest to check if people who have/haven't the issue have the same version of TDM: maybe e.g. they use dev build where this is broken. UPDATE: I think I got T-pose guards after I set wrong cvar related to AI interleaved thinking. Surely not the problem that people have, but the mechanics is the same: AI has never "think"-ed -> you see T-pose AI.

I'm pretty sure developers will find this thread useful! Personally, I'm not very good with assets, so I'll avoid integrating these myself... But I'd like to warn about one thing. Sometimes moving/renaming an asset or file looks like a simple fix for a problem or a warning, but keep in mind that this asset can be referenced elsewhere, even from unexpected locations. So careless moving/renaming of core assets can do more harm than good. I created a script in assets SVN (devel/find_in_fms.py or something similar) which can search files in FMs for a particular string or regex. Perhaps it is not very easy to use, but it helps to find all usages. Of course, it requires all FMs be downloaded locally (from missions database SVN).

TDM 2.11 should work perfectly on Windows 7. It is only dev builds which are affected, and I hope to fix that. There is no reason to avoid TDM updates: tdm_installer allows you to downgrade your installation if you find that new version has some critical issue.

It applies to all dev builds I think. I have added it to changelog as "known problem". For more detail, go here: