Obsttorte

Who cares?! It's a single player title. The questions are imho Does an addition mess with the fundamental gameplay concept behind TDM or our expectation on stealth titles in general? Does an addition change the gameplay of already existing missions in a way, that it may go against the intentions of the authors of said mission? Both are a bit subjective to be honest, but have always been discussed when it comes to adding something that affects gameplay to the core mod. What mission authors do in their fms or what you do to modify the game to your likings is none of our business. (And we couldn't hinder you anyways ) To be honest I don't really understand why we are discussing the frob helper here, as this is an already implemented feature (and therefore has already been agreed upon). The rejection has gone to the thief style container looting, which nobody has requested to add to the mod anyways. In regards to alterations to the frob behaviour of containers that doesn't change the ways players can interact with them, so in our case making only the lid frobable once the container got opened, there is basically only one question that arose in this thread: Is getting an item out of a container something that is intented to be challenging? And noone can honestly answer this question with yes (unless you expect our thief to be very, very drunk).

Just a short note on the func_fracture entities. The ai code will, if receiving a visual stim by an entity, check for the AIUse spawnarg and react accordingly. If, however, none such value is set upon the first stim, the ai will ignore the entity in the future. The issue is, that for breakable items the approach was probably intented as that the unbroken entity gets replaced by a broken model that has the AIUSE_BROKEN_ITEM tag set. The new security cameras might be an example for this, as they are destroyable iirc. Now we don't want to replace the func_fracture entity with something else, as it is capable of representing both the unbroaken and broken state. Therefore I would add a new AIUse tag to allow for that special case. This will take a bit, so if there are any possible drawbacks one can see here, please tell me.

That's actually what I've meant. The passing of the frob to a frob_master, if present, causes it to look like as if only one entity is capable of reacting to the frob. But that is not exactly how it works. Well, the prefab containers I tested had frobable chests. Maybe it was planned, though. Damnit. I'll tried updating the frob status first, but that didn't gave me the desired results. I haven't thought of that case, though. Will have to fix that. Thanks for the hint. EDIT: fixed (or so I hope )

@datiswous: You think wrong. Frobbing is applied to all entites, although normally passed onto the bind master. Otherwise a door would behave differently when frobbing the door versus frobbing the handle. @wesp5@Dragofer: The best approach might be to simple provide the setup for mappers to use as mission specific. If the feedback is positive and mission authors like it the may be going to use it and "upgrade" their old missions with it. Depending on the amount of agreement this setup gets this could then be done with all left out missions either as than we may agree on it not to be mission-breaking. The multi frob (or may I even call it mo-mo-mo-monster frob ) is something I'll look into. Let's see if I can get it to work in a relieable way.

I also wouldn't add it to the core mod. The whole game is setup for three movement speeds and two poses. Changing this to a system like in Splinter Cell would be a tremendous undertaking with very little benefit. I provided the script as I think that beeing able to switch between the three speeds via the mouse wheel is an understandable wish, and it wasn't much work to set it up, but not to suggest that it would be worthwhile adding it to the core mod.

I second that this should definetely not be a core mechanic. Specific setups can be interesting under special circumstances, if, as Wellingtoncrab stated, the mission is build around it. And hey, you provided the idea so maybe some mission author will pick it up. But as the current missions are simply not designed with something like this in mind, it will have a huge impact on how the missions play and feel, which some if not all authors may interpret as mission-breaking - something that has always been a no-go. (One of the few things all team members could always agree on).

Reverting it to the classic thief style wasn't really on the table, I think. It's just a statement that some players don't really care and are ok with a simple solution, even if a bit unimmersive. That's something I never really noticed, or I can't remember. Could be interesting to try to add this. I second this. It doesn't affect gameplay and is a nice addition for those who like it. The only question is on whether the default should be on or off. That's what this discussion is about and what the above mentioned script functions should help with. My idea is that the lid stays frobable after opening the container, while the body becomes unfrobable. Once the container got closed again, the body is frobable again. I think that is a good compromise that has the potential to solve this issue and don't annoy any purist. Why easy if it can be done complicated In the past I thought that a subtle reflection on the loot when lit would be nice. It wouldn't make a big difference in bright areas probably but would allow the player to utilize his lantern to help him finding loot while taking the risk of beeing spotted. Never really fiddled around with that setup, though.

Did you ever file a bugtracker for this? Added bugtracker entry #5976 and added the respective script functions to the code: void addFrobPeer(entity peer); void removeFrobPeer(entity peer); While doing so I encountered an issue that I have to resolve before commiting. The peer entity stays frobhilighted if the frob peer gets removed while hilighted, even if the player moves away. I guess the code doesn't reset the shader parameter 11 that is used for frob hilighting, as the entity is no longer in the frob peer list. EDIT: Got the issue sorted out. It doesn't work as intented on the doors in the prefabs folder, probably something caused by the was the auto setup works, but that isn't the intented use-case anyways. On the container in the prefabs folder it works pretty well. Added with revision 9935

We are not really talking about screen bling here. No fancy popups, markers or whatever else modern games tend to "please" us with. But the mentioning of the term "immersive sim" makes the issue pretty clear imho. I hear that term every now and than and honestly it doesn't make any sense to me. All games except maybe abstract ones should or do provide a certain degree of immersion, and neither Thief nor TDM nor any other stealth game are simulations. There is nothing that gets simulated here. You don't have to, I am no idiot. I see were you are coming from, and I see what the people arguing against specific changes are coming from. At a certain point comfort features can have an impact at the gameplay, sometimes to a point were the soul of the game vanishes. But for one many comfort request like the frob helper doesn't arose from the desire to simplify the gameplay, but because the original implementation has its issues. The original Thief games, as much as we may love them in our nostalgia, are far from perfect and full of issues in many respects. Their were outstanding for their time, but there is lots of potential for improvement. Another point is that we really have to judge as objectively as possible on whether a comfort element really messes with the fundamentals of the gameplay. And I cannot see this here. I neither see how the frob helper impacts the basic requirements on the player nor how changes to the frob behaviour of containers would. Taking something out of a chest isn't a difficult or clumsy task in real life. So if it is in a game, the game is broken and needs fixing. I don't know if this design doc still exists in written form, but due to the time TDM already exists I may dare to note that a lot of the members who influenced that aren't part of the community anymore while a lot of new members joined later on. And from my experience the design philosophy of the different team members already differs strongly.

The func_fracture is more a visual thing that was already part of Doom 3. The whole notice something is broken was setup later for TDM and relies on visual stims by the entity in question, which isn't provided by the func_fracture class. I doubt that is the reason. Func_fracture were just never setup for what you are trying, probably because they are rarely used. Maybe something to be added for 2.11, though.

This is a bit of a contradiction. The classic games just gave you the content of the container after opening, so they were not as realistic as possible. And a higher accessibility doesn't mean less realism. Which basically results in the players having to check the options either way as they have no idea what is setup in which way for whatever reason. I am no fan of such automatisms to be honest. I never said it would. The problem is that their may be different setups in use. It is like with the other stuff. Some place a torch model and than the fire particle in addition, some place doors and then the hinges in addition. Making changes to such setups without missing some special case already present or possible in the future is nearly impossible. That's the issue with non-uniform building styles. Did you ever file a bugtracker for this?

Dunno. I don't really know what kinds of setups are commonly used. Would have to get an impression of that first. It is basically possible, but might not apply to all containers in use. What is easely possible is to create entity definitions and script that could be used on containers to get this behaviour, but than mappers would have to actively add it. While I don't really care about ghosting I guess that the setup described by wesp5 wouldn't contradict it, as the lid could still be closed but the body wouldn't get in the way.

Instead of stars the mission rating could be represented by text color, too, if desired. The question is how many users are really desiring this, as in are there enough to motivate someone who has no interest in this but the skill to apply such changes to actually spend time on this. Otherwise you have to change it yourself.

In this community, yep In the original games contents of openable chests etc. was directly transfered to your inventory. There was no picking the items physically out of the containers, at least not for the standard stuff like footlockers et. al. This was introduced with thief deadly shadows, and they bypassed the frobbing issue by making all items comically large. In regards to the frobing container issue. A good solution might be a compromise. Once a container got opened by the player it becomes unfrobable, so the player can loot it without interferences from the container. Once the container is empty it could close itself or become frobable or both, although this would only be necessary if the mission is setup in a way were the ai actually notices open containers. Another approach could be to utilize the lean forward action. If the player leans forward frobbing is only enabled for small items. Personally I would second the empty container once opened setup, as well as looting dead or unconsciuos ai upon frob. As stated above, the game is not about frobbing.

Fixing an issue isn't the same as making the game easier, honestly. The frobbing has always had its limitations and can become frustrating. For the very same reason there is a mantle key. Nobody complains that that makes the game easier. And regarding the second point. There are tooltips displayed in the menu, in this case: "Makes interaction with small objects easier by temporarely displaying a small white dot." So, what is the white dot for?! It basically moves the loot and other items towards the player a bit before putting it in the inventory upon frob, thus underlining the impression of actually taking it the way it was done in the Dishonored games. And yes, it is a script I've created at request by Goldwell.

So I've looked into #5319 and was able to solve the issue. By default, ai only activate triggers if they have changed their position in the last frame. I don't know whether it was setup like this for optimization purposes or whether there is another reason. The Bugtracker list a couple of missions that use those triggers in combination with ai, so someone who knows the mission or the mission creators themselves might investigate whether the current behaviour is required for those setups to work. I haven't commited anything yet due to this but imho it is rather inconsistent if a trigger reacts differently to the ai as it does to the player. At least I suspect most mappers wouldn't expect that, as both represent humans. UPDATE: After looking at most of the missions myself (except winter harvest, that isn't listed in the downloader), there seem to be no case were trigger_multiples or other multiple firing triggers are used with ai. So I commited the change as it shouldn't influence existing missions.

https://wiki.thedarkmod.com/index.php?title=Internationalization

Nobody says this gets implemented in the core mod. I just fulfilled a request. Of course modificators can be used. You can replace the mousewheel stuff with this for example !wheeldown ; ALT+mousewheel down ^wheeldown ; CTRL +wheeldown ; SHIFT <^>!wheeldown ; AltGr analog for wheelup ~wheeldown ; don't block native function you can combine them ^!wheeldown ; CTRL+ALT+wheel down More info here. Customize as you need it.

Second version (should have waited :P) speed = 1 ; init with walk speed steps = 3 ; amount of steps needed for switching state state = 0 ; counter for state switch wheelup:: state += 1 if (state > steps) state = steps if (speed == 0 && state >= 0) ; we are creeping { speed = 1 Send {u up} } else if (speed == 1 && state >= steps ) ; we are walking { speed = 2 Send {z down} } return wheeldown:: state -= 1 if (state < -2*steps+1) state = -2*steps+1 if (speed == 1 && state <= -steps) ; we are walking { speed = 0 Send {u down} } else if (speed == 2 && state <= 0) ; we are running { speed = 1 Send {z up} } return The important things to modify to your likings are u and z as above, as those control which keys are used for running and creeping as well as steps, which specifies how many digits the mousewheel needs to be turned to switch the movement. Setting it to 1 let it behave like the first version posted earlier.

First version (I couldn't resist ) speed = 1 ; init with walk speed wheelup:: if (speed == 0) ; we are creeping { speed = 1 Send {u up} } else if (speed == 1) ; we are walking { speed = 2 Send {z down} } return wheeldown:: if (speed == 1) ; we are walking { speed = 0 Send {u down} } else if (speed == 2) ; we are running { speed = 1 Send {z up} } return In this setup u is used for running and z for creeping. You can other keys, of course, although I would avoid modificator keys as used by TDM per standard. Works quiet well. I'll add a constant to allow to alter the sensivity so that you can adjust how much you have to turn the wheel to switch between states. You have to have AutoHotkey installed nevertheless.

Note that a missions needs to be setup to be translatable, which is often not the case. If so, contact the author.

Yeah, manipulating the movement speed via the mouse wheel is actually something I like about the Splinter Cell games, too. And yes, changing that would indeed not be a minor thing, but you could use Autohotkey for your purpose.

I've just gave this mission a try and it was actually quiet entertaining. It's nice to see the savegame mechanic in action. The visuals were pretty good and atmospheric, although not extremely detailed you have proven a talent for consistency and atmosphere. Especially in regards to the lighting. The whole mission has this return to the lost city vibe. Nice. Storywise I won't say much as I don't play games for the stories sake (I read books for that - sorry games, still got a lot to learn in that aspect). Nevertheless I like the fact that you were saving on the readables and there content (length-wise), although some background info about the excavation site would have been nice. Now for the most important part: Gameplay. Obviously I have played under the highest setting just for the sake of seeing the savegame mechanic in action. Due to the sometimes clumsy controls and me not having played TDM in a while (the latter is probably the bigger issue) I managed to fell to death on the first two approaches (without having saved til that spot), but managed to get through the mission in roughly one hour with three saves total, the last one two minutes before the end. As stated, I was well entertained. Some thoughts nevertheless, if I may. Overall it is the first TDM mission in a long time that I actually like and would recommend. Well done, thumbs up, like and may the Builder bless you.

As requested by @Spooks (#5930) I've created a set of modified versions of the graffiti decals added by Necrobob and Bikerdude (Commited with revision #16491) Those materials are placed under textures/darkmod/decals/graffiti and located under darkmod/materials/tdm_decals_graffiti.mtr (new file). The upper version can be colored using the _color spawnarg if turned into an entity. As using black as a color will make the decals dissapear (it is na additive blend), I've created a black version, too (multiplicative blend). Their names are extended with _black, e.g. the cross most-left is textures/darkmod/decals/graffiti/allright textures/darkmod/decals/graffiti/allright_black ############################### While working on this I've noticed a bug: When turning the decal into a func_static it can happen that it won't get offset anymore, so when placed exactly at a surface it simple isn't visible. As there is no z-fighting I assume that the polygon offset gets screwed up. The occourence of this issue depends on the direction the decal is facing. It works when facing the positive x-,y- or z-direction, but not in the negative one. Is this a known issue? EDIT: I've tried to create a testmap to file a bugtracker entree but wasn't able to reproduce the issue. It occours in the map the above image was taken, however. Guess there is something screwed up with that, dunno. So probably a map and not a TDM bug considering it doesn't seem to have been reported before. (Which is somewhat good news but leaves me confused ... and sooo tired )