Obsttorte

You can right-click on the selected group and ungroup it in the context menu.

You have to make sure that all moving parts are separate models. So you have the safe body, the door, and the handle. In case of a numberwheel/combination lock those parts need to be separate, too. If the keyhole uses his own material, it can be made invisible via skins (the eyepatch on some ai can be made invisible to create a two-eyed guard, for instance ) If you provide the respective model files plus the textures, I can setup the entity definition and material for you.

Well, from that perspective TDM simplifies a "complicated" principle considering that in the original games there was the intention to use the loot for something (hence non of it in the final mission). Actually any game that allows you to acquire valueables intent the player to use it for exchange. I don't think this is overly complicated. That's probably one of the reasons I find arena shooters like quake or the latest doom installment rather boring. It's only satisfying to a certain degree, and still needs to serve some purpose. Pushing a button just because you can feels like small child logic. I don't have to put my fingers into the power point, but I do it either way because it's fun.

This depends on how the mission is setup. Surely, in the current way missions typically handle loot your statement would be true, but the way loot should be handled has always been a flaw in TDM mission design. In the original games there is no loot to be found in the last missions, simple due to the fact that the player wouldn't have any use for it. In TDM, due to the single mission setup we have most of the time, the player also has no use for it (besides some missions featuring in game shops), but still he is required to gather it. Mappers have thus far haven't come up with creative ways on how to deal with that issue or haven't even tried to deal with that at all. And just making the loot objective optional is not what I consider creative So it makes sense to think this concept through eitherways considering how crucial it is both for gameplay as well as the whole setting (you are a thief, so it is a basic part of your character) and I personally think that a design that does not rely or require the player to gather as much loot as possible, but instead tries to get the player to weigh the risks and the effort against the potential benefits, could indeed lead to a fun and extremely rewarding gameplay, if done right. Another benefit could be that if the part of the existing loot the player is supposed to gather is way lower then in usual fms, the risk of the player getting into the situation of not beeing able to finish the mission although all the main objectives are done, just because he is missing that few pieces of gold, is much more unlikely.

That speaks for you.

Shouldn't a direct impect on gameplay and immersion have a higher value then some artificial score? It is believable that guards recognize stolen item, if in prominent spots, which adds to the immersion, making the world more believable, and it adds to the gameplay if the player is put in a spot where he has to decide on whether and when to steal an item, or whether and what measures he performs to avoid the item to be missing (like creating darkness, if possible, or taking out nearby guards). The whole "but it messes with my stealth score, it's unfair" argument sounds like if we were talking about Doodle Jump. Besides the fact that an uniform scoring system does neither take the missions size nor the overall setting into account, which is very individual among missions and can make the difficulty in reaching a specific score differ vastly. You notice whether or not you cause a mess when playing a mission and how often you get spotted. Do you really need a piece of code to tell you how well you've done? In regards to what @demagoguewrote: It is always a good idea to question an author decisions in regards to what said author was aiming for, to which extent this was reached by the measures applied and whether and how the specific design goal could have been reached better by applying those measures in a different way. IMHO TDM is heavely lacking such discussions. But changing something just because some players say they don't like it and for reasons that have nothing to do with the original design intent is a terrible, terrible idea. But if the player understands what you wanted to achieve and can give reasonable arguments on why he thinks a different approach would work better, it is worth thinking that through and see if there are ideas worth adopting.

It is, if done right. It is however advisable that you create all the patches needed for the final setup beforehand and move their vertices together to avoid gaps (and if they occour, then only due to different subdivisions which can, as said, be adjusted manually). And don't use brushes for that!

Well, stuff that is displayed in an obvious way has a unique look is very valueable is likely to be noticed when missing. Obviously some golden cups locked in a closet or a bottle of wine should not be noticed. As stated, it needs to have a reasonable logic behind it. Once you have that, a simple voice over once the player approaches the first loot item that matches the above stating something like "That will surely be missed" should suffice to give the player an idea. However, all of this only makes sense if the mission is designed either on the player planning in which order to fulfill his objectives (possibly putting such valueables on a todo list upon encounter) or if the loot objective is designed in a way, that the player has to keep the balance between achieving that goal and don't raise too much attention. As far as I am aware of not a single mission is designed for that, so either you are going to change that for your mission or you remove the spawnarg.

You probably have to set the subdivisions manually. Otherwise it will be choosen depending on size and bending.

I never considered it an "established rule" that it should be possible to ghost a mission, not to mention to fulfill some artificial stealth score. I have objectives to complete and tools at my disposal, and if I finish the mission I am fine. I don't have to compare to someone or something to see how good I am. That beeing said, I assume it would be more purposeful if there is some logic behind how likely it is that a specific items absence is noticed and how the impact on gameplay is, and obviously this should be communcated to the player to some extent. I don't know how you did it with your fm, but obviously randomly setting this property to whatever value does probably not improve gameplay. But if the player has to choose on whether or not to take an item (or at which stage of the fm), it might spice up things a little bit. Oh, and the more mappers tend to move away from any established rules, the more likely it is I will like the result. I don't need to play the same game over and over again. But I may not be representative for the community. In the end it is your mission. You decide.

You have to do anyway. But why shouldn't you attach the light to the model than? You set the radius via the args and you have a grid in the background, so not really a problem. It get's easier if you use simple numbers (so multiples of powers of two). The positioning can be altered by changing the attachment position. (Note that you usually do such things once, not dozens of times). In the end it is up to everyone themself on how they setup their workflow. To me it just always appeared as if the arguments against the usage of combined entities are not really objective ones, as all the things that can be done with separated entities can be done with combined, too, but more in the manner of "it appears odd and I don't wanna try getting used to it". IMHO the advantages outweight the downside of it beeing a more abstract approach by far, and I have seen a lot of missions going into beta with misaligned lights, misaligned door handles, inconsistent light values etc..., things that are avoidable and that might even carry into the final release especially on bigger mission. And the amount of work you can spare on the long term is way bigger then the tiny bit of time it takes you to get used to it.

Yeah, grouping is an option. I normally don't think of it as it was added years after I've started working with DR. You can edit combined entities as easy as non combined ones. And electric lights are one entity either way, so it really makes no difference there. One big advantage of combined entities, for example torch models with a light def_attached to them, is, that you can alter the appearence of ALL those entities by making one adjustment in the respective definition file. If you use your approach and notice later on that something with the torches isn't quiet right (let's say, they are a bit too bright, making the mission too hard), you would have to go through all said torch lights to change that. Another aspect to consider is that this can easely cause similar models to have lights with different properties (big differences, not slight variations that may even be a good thing), either by oversight or because you forgot to consider it, which would create inconsistencies that the player may not even be able to put his finger on what's causing them. That's not really a good thing design-wise nor considering how often the unreliability of the gameplay in TDM and the considerable high difficulty level tends to frustrate players, especially new ones.

@BaalStill there, nice Performance-wise those visportals will probably not have much of an effect, as they cover most of the screen and therefore don't really block anything off. It is hard to see due to the dark image, but especially the vp on the right looks like it is bigger then the gap left by the architecture, which doesn't make it very useful in regards to performance. As long as you don't tend to add houndrets of visportals in each area, they normally don't decrease performance at least. In regards to sound propagation I would expect them to do their job. You just have to make sure that if there are sufficiently large obstruders in the way (like walls), that the respective areas are seperated via visportals, which appears to be the case here. Pathfinding is not affected by visportals. That is solely handled via worldspawn brushes (unless the material used on them explicitely excludes this behaviour, like for triggers). I hope that helps and next time, a brighter image please

Like @thebighwrote. AI get signals from the surrounding that can increase there alert level, a numerical value that represents the alertness of the ai. After exceeding a certain threshhold the alert state increases. The above mentioned behaviours correspond to those states. Besides seeing or hearing the player also weapons lying around, bodies or missing items or open doors can add to this. Taking out an enemy does not count in, though, as the ai doesn't notice it been taken out anymore

Thanks for looking into it and for the feedback. Good to hear it is working out for you (means less work for me :D). And changing the thread title isn't really involving a lot of work and in this case, makes sense, so akabadabra... renamibus.

@Daft Mugiexplained it pretty well, and I thought I did so, too in the original build. The custom manifest was for usage with the dev build that was available back when I made the post, but the respective changes were already commited to svn so all subsequent dev builds should contain them. @WellingtoncrabIf you would have played without the code changes, the preview animation (raising the blackjack) wouldn't have worked either. So if you got that one, you got the code. No updates to the code have been performed after I have create the latest custom manifest, which was at the same time I have updated the code in svn. The simple reason is that I am collecting feedback, the initial purpose of this thread

That pretty much sums it up. The ruleset stayed the same, as there was no consensus to change it. You got a point. The comment was more aimed at the person involved in the discussion the whole implementation originated from. They asked for a change, I said I could provide it, they noticed it, I started the above mentioned thread, they were gone. Typical TDM workflow, I guess. Nevertheless, I am not much into advertising a change I don't care about. I made it because it was asked for and I had some time. The only aspect that I could think of is the fact, that there is some time passing after you start the blackjack attack before the hit calculation takes place. This means that you may get indicated that a blackjack would succeed by the raised bj, but during the attack the ai may have moved in a way that causes the blackjack attempt to fail. This was explicitely stated by me, though. The indicator is no 100% success guarantee if things change. It only indicates that under the current situation the bj would succeed, so if nothing changes. It's like with crosshairs that change color when aiming at an ai. This tells you that you would hit, if the ai does not move. Dunno if this is still a thing in modern shooters, though. Haven't played one in ages.

@WellingtoncrabThe blackjack behaviour isn't controlled by scripts, but by code. The binaries you download when using the custom manifest contain those code changes. So you have played with the changes, even though you may haven't noticed a difference, which wasn't the aim anyway. The point is to get rid of flaws and unreliabilities the current setup suffers from. Nice to see that you are fine with the animation prompt, though.

The main goal was to make it more reliable. I already commited the change as it is easely revertable. To be honest, after all the fuzz people made due to this I expected that some people would actually test the change, so I can decide on whether to add it and in which way or whether to reset it to the original implementation. But after almost two months there hasn't been much feedback at all. Personally I don't care. In the above linked thread there is a description on how to revert the change if people don't want it.

They are. But as not everyone has access to it, I create the custom build as proposed by Dragofer iirc. The behaviour is toggled via the weapon def (basically commenting the current command and uncommenting the previous one), so there is no harm imho.

There is no need to create light source and model seperately. You can easely tweak the light on combined entities, and having two seperate entities serving one purpose is a guarantee for additional work and errors. If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc... You should really not get used to this kind of workflow. Create lights via the create entity menu.

Set the spawnarg "def_attach6", that defaults to ""atdm:prop_lootbag" with "-". Read up on the wiki on how to attach items to ai (definition attachment is covered there)!

Because it is an alternative branch so to speak. That's why it is called custom manifest!

Note that only missions with at least 4 ratings are listed there, so you might miss some.