Obsttorte

@Frost_SalamanderI've looked at the code and it appears that the intent is to let the ai use a controller if present, but not the door. Therefore I've tested your map and am not able to reproduce the issue. Here are my observations: ai_no_open causes the ai to not open the door at all (neither directly nor via controller), which is basically what the name implies if not set, the ai will only open the door via the controller, not directly (neither armed nor unarmed). In your test map the unarmed ai tried to reach the controller, couldn't do so because of the locked door and made a very sad face, but it doesn't opened the door directly. you have not monsterclipped the controller, which can lead to the ai beeing unable to open the door with it because it keeps blocking it due to standing too close (unrelated to the issue, but a noteable mention). Overall there are pathfinding issue in the test map, probably due to the strange geometry (haven't checked the aas areas, as I would have to lookup first how the command was and it is not the issue here) I have tested both under 2.10 and svn. Maybe you can make a video of your observation so I can see what you mean, just in case I missunderstood you. But so far it appears to be working as intented.

I see what you mean and admit I haven't thought of this specific case before. Can we work under the assumption, that if at least one controller is targeting a door it is not meant to be opened directly? It appears to me that there is a reason for the door handle entity having those spawnargs. The implementation has some flaws, though. The other spawnarg on the door itself seems to be a leftover of an earlier implementation attempt, which may not got finished or throughly tested. It is a bit redundant. I may take another look to take you case into account.

@Frost_Salamander@Geep The desired setups can be achieved by using door_handle_position entities. If a door should not be able to be operated from one side, place such an entity on that side, add it to the dhp of the door (via door_handle_position spawnarg) and set ai_no_open on it to true. The same setup works for secret doors. The ai will walk through the door if it is open, but will not open it on itself, even if fleeing. ai_should_not_handle is not working as intented, but I don't know the exact reason. The forbidden aas areas mentioned earlier on are temporary and used by all doors. By default they get removed once the door is open. I guess the serve the pathfinding algorithm, even though the naming is odd. As the above way works, I closed the entry and suggest to not use ai_should_not_handle at all, but the above approach instead.

@wesp5Your code would only work if the entity that got extinguished is the one that got frobbed, I assume. In case of torches and candles and alike this won't work. Check the code for how attached light entities are handled and try to mimic that.

https://wiki.thedarkmod.com/index.php?title=Triggering_events_when_looking_at_something If you use this, there is no need to use S&R.

YouTube has the habit of recommending me the funniest things. However, in regards to music it is quiet good at predicting my taste, especially considering I didn't even knew I would like it beforehand.

I agree with @AluminumHaste. It looks more like light below the water as well as the wooden beams continuing there, distorted by heat haze. There are, however, means to create reflections in tdm. For one you can use realtime reflections (mirrorMap), which are performance houngry and, at least the last time I played with them, unstable (got some nasty ctd's). The other approach are cubemaps. There is a wiki article dealing with the latter. There was also a thread once discussing another approach, also using shaders.

The Stim&Response system has nothing to do with particles. It's a signaling system. If an entity with a response to water is within the radius of the water stim, the response gets triggered. Think of it like a sound for example. The magnitude might only be important for specific stims, and the respective information would be needed to be evaluated by the response action. I am not sure whether there is a stim currently using this, though.

I do agree. And unless someone is against it, I guess it's safe to change that.

Well, that could be intentional, though.

I thought so because I consider frob as an equivalent to "interacting with a highlighted object". That's a player specific thing, but I may think of the term wrong. However, the ai in my test scenario uses the lever independent from whether the door is frobable or not, even if the door itself is closer to the ai then the frobable door, which underlines the assumption. But as you wrote: without looking at the code that is more guessing then knowing. Thanks. Will take a look this weekend.

Now I understand what you mean. I just tested and can second this. Well, that's obviously a bug. You should file a bugtracker. I will take a look at the weekend to see whether that's somewhat intented and fix it if not.

I did, it works.

@Frost_SalamanderI've just tested it with a mover_door and a switch_rotate_lever. It works exactly like you want it, without the necessity to change anything. So obviously your setup is wrong. Correction, the default lever works, too. My bad.

You need something to tell the ai when it can pass the area blocked by the secret door and when not, similar to how you have to tell the ai when it can step into an elevator shaft or not. There are probably other ways to create the setup you want, but I would have to test it. First off, ai don't frob doors. That's what the player does. So the frobable spawnarg has no relevance to them I assume. By default, if a door is operated by a lever, the ai should automatically use the lever. If that is not the case, then probably something is wrong with your setup. Does the lever use the correct entity class? Again, I would have to test it to be sure.

For an ai to be able to operate a door they need to know that it is one. This is mainly controlled by AI_USE. If it is not set to AI_USE_DOOR, the ai will probably not recognize it. If you want the ai to walk through a secret door after it has been opened (assuming you set it up so the ai doesn't know it is a door), you would have to let the secret door or the switch opening it trigger a func_aas_obstacle entity. You can check here as well as in the elevator prefab to see how it works. I don't understand that. Either you want the ai to operate the door or not. If you set it to don't operate, why should it operate the lever that operates the door?

@Wellingtoncrab In regards to getting discouraged by criticism I was more refering to the reaction of mappers in general. And as stated, I am not for changing it in the core mod (don't mix up my posts with those of others). It has been like this for so long that it doesn't make sense to change it. I, however, consider it important to discuss such things to simple bring it to the mappers attention, as if something is done in a certain way for long enough, people, including myself, tend to stop thinking about it. And yes, the missing balance in tools given, among other aspects, is a general observation. It neither implies that it is like that in every single mission nor does it mean that there has been no thought put into this by the respective mappers. However, putting thought into something doesn't guarantee the best results, so feedback and criticism is vital, as maybe the concepts that went into those thoughts have issues or things have been overseen. I for one just added my opinion in a response to a statement made by Dragofer. The original intent of the thread is not refered to by me. Despite beeing named as mission author I am not. The mission is by Bikerdude, I just helped with scripts and performance. And it has quiet some of the flaws I mentioned here and in other threads, too, like my own mission have (Old Habits and Builder Roads). One other thing both the Elixir and my first Release have in common is bottleneck design, something extremely common among TDM fms. In Old Habits you have to find a specific key to be able to get to the upper levels, and the key is hidden. If you are unable to find the key, something that happened to some players, you end up coming to the forum and making a post starting with the magical words "I am stuck...". Something you read in a lot of mission threads. The Elixir suffers from the same issue. That's one thing I changed when creating the rebuild, providing an alternative way. Other things are no kill objectives (I added it because Thief had them, not for a gameplay reason), and today I would probably not add loot objectives. The light placement allows for players to always have a corridor of shadow to walk through without getting spotted, which is extremely artificial. In regards to the loot amount I am not sure anymore, but iirc it at least differs difficulty dependent. Builder Roads was a bit of an experiment, which automatically leads to flaws. The main thing is that the whole setup doesn't allow for much variety in how you approach the mission. And again there is only one way to fulfill the main objective, requiring the player to solve a puzzle (which sometimes doesn't work ). If he is unable to, he cannot finish the mission. Those missions are old, though, and so are others. I am not as critical to old missions as I am to new ones, because there was a lack in experience back then. But I would have liked to see some sort of evolution in terms of gameplay, which didn't happen (in the sum!). The missions get bigger, they look better and overall production quality increased. But the gameplay didn't. And this is no surprise if almost everytime you write a critic mappers feel offended, even if you stress positive aspects, too, and try to be as objective as possible. This was more so in the past then in the last time, so I guess the mood has changed a bit around here. (Lots of drama going on in the past, so people were probably a bit more thin-skinned). There are two things btw. where I have gotten positive feedback on Old Habits. The loot placement and patroling. The first caused me to pay more attention to it in other fms, noting that there is no (obvious) logic behind it. So I asked. And tell you what: Neither players nor mappers consider loot placement or the values important. At least back then, although I can't say it has changed much. In regards to patroling I was told that it almost appeared as if the patroling was timed (aka thought went into it) and I just thought: "Of course they are, that's a fundamental part of the gameplay. To tight and it becomes unfair, to loose and it becomes boring." But the response and my own observation in other fms tell me that this is something rarely (not never!) taken into consideration. So I don't consider my own work much better in regards to gameplay, from my nowadays standards they are mediocre at best, and my criticism is not only based on how I perceive the missions, but also on the kind of feedback and statements I have read in the forum over the years.

Again, I'm not for changing anything in the default configuration. I just expressed an opinion. I am not for overwriting mappers intention, the opposite is the case, which leads to You are contradicting yourself a bit here. If the mapper does a good job, players will most likely not feel the urge to change anything. You don't buy a picture to paint over it And it basically reflects the "play it as you want" attitude which I am absolutely no fan of. But maybe I am just getting old. I can't speak for @snatcheron why he necro'd this thread, but it's a reoccouring thing that mappers always state how discouraging it is getting criticised, something that is completely normal in any other hobby. You could see it as something to improve upon instead of acting as you would get bully'd. As I am not only a dev but a mapper myself it might be less discouraging if I would pick up my own missions and start to list up the things I messed up from my nowadays viewpoint?! That would be a long list, though . (And one of the reasons I haven't released another fm in years. I wanted to do it better and somehow got stuck. But maybe the goddess of motivation will shine her light on me, who knows).

This common idea is at least a common statement by map authors, and more or less what I've meant by "it might be useful". I am simply not a fan of this "play the game the way you want" design philosophy, throwing everything at the player and tell them to simply not use it if they don't want to or to adjust half a dozen gameplay settings to make a game fun, all of which is actually the job of the game designers. If a player gets tools handed out, there should be specific usecases for them. If I can avoid most extinguishable lights or just ignore them if I am a bit patient, as most of the time I am not in the viewcone of any guard anyways, I don't need to have water arrows. I don't need flashbombs if reloading a quicksave is the easier way to "deal with a situation". And I don't need lockpicks if I can't unlock most of the locks with them anyways. I don't argue for adding this, personally I don't care. I just wanted to state that your argument doesn't reflect the state of most of the fms imho.

If there is something almost all missions have in common is that there is no balancing in regards to the amount of tools given. The typical answers I got when asking mission authors on that matter is "it might be useful/needed". At the same time, the majority of the people on this forum consider ghosting more or less the way to play. So any discussion about tools is more or less pointless. This. On the other hand, mappers are free to customize the way the player can interact with the environment, and in this particular case I even think that there are missions who allow frob-extinguishing oil lamps, like there are fms that allow to douse candles without having to pick it up.

Making an entity unfrobable that has a frob peer to other entities will make the latter unfrobable, too. Hence there was no way to implement the container stuff and that's why I've added the new script functions. So first off you have to remove the frob peer when opening and then make the base unfrobable. So the steps after frobbing are remove the frob peer via removeFrobPeer find out which entity is the base (the lid is usually a door, whereas the base is a froblock) make the base non frobable If you want to apply this to all containers it probably makes sense to alter the frobaction script used by froblock entities.

There was success, but it was only a proof of concept. As explained in the respective thread, it is hard if not impossible to reversivly implement this for existing missions. Therefore, it is something mappers can implement in their own mission, and if it is liked, it may establish as new standard (maybe causing people to successivly updating older fms with this). @snatchershaderParm11, as used by the standard frob hilight method, is set by the engine. But there is the possibility to create time-depending effects in material shaders. http://old.mrhide.fr/doom3/materials.html Using shader programs for frob-hilighting or outlining is a new approach. There are some tests been made and if I am not mistaken the fundaments are there, but I haven't fiddled with it by now.

Uhm ... nope.

I haven't setup anything useable. I tested the implemented script function to make sure they work, and used a chest as testing ground.

That's not planned afaik. I just added the script functions required. You could change the frobhilight shader.