Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Obsttorte

  1. Ok. Didn't notice that. But yes, as kingsal wrote it may be a different issue. It's hard to judge from the distance, but it doesn't sound like an issue with the FM or TDM to me. Did your savegames had the wrong naming, too?
  2. Your welcome. Didn't help much, though.
  3. I don't know. Maybe your installation is broken (TDM or the FM). It doesn't explain the odd savegame file name, though. But as you are the only one reporting this is likely something on your end. Sorry.
  4. Yeah, the formulation is misleading. You don't need to ship the script with your fm as it is now part of the core mod, but still need to include it. Well, it works fine on my end. Here are the steps: Create a folder script in your fm folder in that folder, create a file tdm_custom_scripts.script in that file, add the line #include "script/ai_trigger_look.script" #include "script/trigger_look.script" That's it. It is not included by default as some missions released before it was added to the core mod may have already used the script.
  5. This means the game can't find the script file. Did you include it into your fm as described in the article? If you include the corresponding script file, you can set the scriptobject to ai_trigger_look. Note that entities can only have on scriptobject, so if you want the functionality of the trigger_look on an entity that already uses one, a merge of the code is needed. I created the ai_trigger_look version in the past and iirc @Springheelused it in one of his missions. It probably needs to be included first, too.
  6. That's how it is now. It's will only have a consequence if some mission author has replaced the absence marker with something else (unlikely). And the only consequence would be that the AI's level isn't increased, while still noting something has been taken (not necessarely a mission breaker). I really don't consider this an issue. And if it is, we can deal with it once it occours and can talk to the respective mission author to see what his intentions were.
  7. That is true. But actually the only obvious reason to replace the absence marker with another entity is to alter the stim range or to add some custom behaviour. In that case one would derive the custom entity from the default one, though, so the condition would still be fulfilled. I don't see any other work case, to be honest, and therefore can only guess what behaviour may be desired by fm authors. I just checked and it seems you are right. I actually thought that this wouldn't be possible. Will tweak that. (EDIT: Done) That would be exactly the behaviour that was in place to begin with, and which we want to fix. The AI should NOT go to agitated searching everytime it spots a missing item. I would not want to make any changes to the absence marker related code. It is used by default and there may be a reason why the code is only executed in that scenario. So unless someone can come up with a scenario why it should be different...
  8. @McPhisto2051 Unfortunately there is nothing in the dumpfile that is of use. Did you fell to death?
  9. I've made the necessary modifications. absence_alert_increase replaces absence_alert, the above posted code got reversed to its original state and commented out, as it is unclear what the intention was but is causing the unwanted behaviour. The tooltips are as proposed by @Dragofer , in a modified form for absence_alert_increase: The amount by which the AI's alert level (NOT alert index) increases when it notices this item is missing. If not set the ai goes into agitated searching state. I added a mention of alert index, as mappers may not be aware of the difference and may misinterpret a value of 1 to get the ai from searching to agitated searching for example, which is NOT the case. Hopefully this will cause them to either look the terms up or ask in the forum if unsure. There is no cap in regards to how high the value can get. In addition point (3). The last line reflects the actual code better. The alert levels at which an AI changes from one stage to another aren't fixed values, but spawnargs. They are therefore subject to future changes in the core mod and modifyable by mappers. I've marked the bugtracker entry as closed. Should there be remarks or issues I can make modifications nevertheless.
  10. Well, the bugtracker is about alerts spreading too fast among ai. I don't see any relation to the above code, to be honest. It is likely that it was changed afterwards. Nevertheless we don't want that behaviour anyways. There are missions who used the spawnarg correctly, too. Although the ones pointed out by @stgatilov are rather high. So your suggestion may be the one doing the least harm, if any. I would then introduce a new spawnarg as suggested by you. absence_alert_level_increase is probably quiet long, but at least descriptive. absence_scale as proposed by you on the bugtracker is shorter but counterintuitive, as a scale to me implies a multiplicative behaviour, not an additive. Thoughts?
  11. @DragoferRegarding the bugtracker: It appears that the reason for the issue might be a typo. if ( alert < ( owner->thresh_4 + 0.1f ) ) // it should be > { alert = owner->thresh_4 + 0.1f; } I guess this code is intented to be used as a cap. In addition, the part of the description stating that the ai goes into agitated searching if absence_alert isn't specified is not implemented. Maybe the above code was also intented to do that but got changed afterwards?! Regarding your comment on the misinterpretation of the absence_alert spawnarg. The wiki explicitly states what it is intented to do and DarkRadiant explicitly states it to be a float, not a boolean. So either the fm authors who set that to 1 only wanted minor reactions which may accumulate, something we would break that if we use a new spawnarg instead, or they all suffer from dyslexie, which we hardly solve by introducing a new spawnarg. I would fix that so it does what it is intented to do but leave the spawnarg alone. If other members share your point of view that a new spawnarg should be introduced it can be easely changed afterwards. Additionally we may consider modifying the description, as "If set, the alert increase of the AI when the entity is missing" sounds odd to begin with and may be the root for misinterpretation. I would suggest "Set the amount, by which the alert level of an AI increases, if it sees this entity missing." EDIT: I've provided a fix with revision 9953 which can be tested in SVN. Feedback is welcome.
  12. I am not able to reproduce the issue. The code uses the name "default" as a fallback, in case the savegame name would get corrupted. And when saving after loading your savegame (the one that worked), it uses the correct names on all available spots. And as you seem to be running basically the same specification as I do (Win10 german with TDM in english) that's probably not the issue either. Any chance you could try to reproduce it? It would probably already be useful if you manage to get to the first save grammophon and see if the savegame gets wrongly labeled again. If so, the log may contain useful information. EDIT: You need to type conDump name into the console for the log to be created (it is a text file). In case of a crash the darkmod.log mentioned earlier on may also be of use.
  13. Just a wild guess, but is it possible that you have your language setting differing from english?
  14. @McPhisto2051Your link doesn't work ("Page not found")
  15. @McPhisto2051Do you have the darkmod.log that can be found in the darkmod folder? Maybe it contains some useful information. EDIT: Good timing
  16. I have never stated anything like that. I for one don't necessarely see those principles beeing hurt by what I have written or the example I gave above. A fail-safe route doesn't necessarely mean that the route is one that can be taken by ghosting imho and even if you assume this implication, a setup could also be such that it isn't fail-safe to begin with, but can be turned into such a situation by a minor change by the player, like taking out a guard or a torch. It comes down on how you interpret those principles and how close you want to stick to them. Not doing it in exactly that manner, even if on purpose, isn't rebelling. I know the original games were ghostable and that may even be by design. Deus Ex can also be played without killing anyone. But in most situation I would claim that ghosting (or in the example of Deus Ex not using violence) isn't the easiest and most straight-forward approach to a situation, especially when playing the first time. In TDM fms this is mostly the case, and that's something I am not happy with. Others may differ in there opinon, maybe even the majority. But when we are talking about what makes a game enjoyable, we are talking about a mainly subjective matter anyways. Not everyone has the same expectations towards games and not everyone expects TDM missions to be an exact copy of Thief, even if the latter served as inspiration. And in regards to what TDM is based on: The main motivation for starting the mod as far as I am aware of was the disappointment felt by many about Thief Deadly Shadows, which is probably based on the same fail-safe principles. So the question is on whether said principles are as important for the members here as you consider them to be. That is true, I could have written that in a less polemic way. I just tried to express that the success of those titles may appear as an questionable argument if most of those series aren't produced anymore. This would be a valid point if we would talk about what makes a game or a mission better in regards to how customers experience it. That was what I basically read from your post. He worked on successful titles hence he know how to make successful games. Something I don't doubt, but what isn't the point I was trying to make. This is a hobby. I am not here to do something successful, I don't have to create something a lot of people like. This is not my job. I basically use this as a way to express myself. This has come up in many discussion involving you. You are coming from a professional point of viewing things (which is fine and valid) while others trying to have a good time so to speak. I just assumed that you already know that I am not talking about improving fms in terms of how successful they would be when sold. Maybe my assumption was wrong. In that case you are right and we misunderstood each other. Nevertheless I said that I know that presentation and that I understand what it is about. I see that this is a good approach for making games as a living and that it might be a good guideline even for hobbyists. But there are other approaches to game design as well, some of which are not as popular, some of which are mainly applied in other genres maybe. I just think it doesn't hurt to involve those or our very own ideas, too. This isn't rebelship. The point I am trying to make in many of those gameplay discussions is actually that I get the feeling that mappers often don't have a fleshed out strategy when it comes to creating engaging gameplay. (#) That is probably not even because they couldn't have one, but it is simple not their main focus when creating missions. All I want is to get more focus on that aspect, as in the end we are talking about a game, so gameplay has, at least for me, priority. Obviously they could do this by applying proven strategies like the one you are talking about and this alone would improve the quality of their fms. But they could also apply a different one or come up with their own. They just have to have a strategy. (#) Sorry for the wall of text. @DragoferAs you are a moderator, can this discussion be moved to its own thread? I start to feel bad for abusing poor Goldwells thread and we are clearly off topic here. Thanks in advance.
  17. I actually know the presentation. I can't remember anymore whether you posted it somewhere or whether I stumbled over it by other means. And I obviously don't neglect that the LGS devs had an idea of what they are doing and have done a good job. But neither is their work perfect nor is there an obligation for us to stick to that. Especially as I heavely doubt other fm authors have read the presentation and am sure you will have a hard time finding many fms following these concepts. Which would be important if success would be my goal, or ours as a community. I am not sure whether this is the case. The Assassins Creed games are successful, too, as well as the Far Cry series or Call of Duty or any of the other of dozen AAA titles that I don't like. And I may repeat that the Thief franchise is essentially dead. Splinter Cell is dead. Deus Ex is dead. Dishonored is dead. So there weren't a lot of game series in this genre to begin with and all of them have vanished. So yeah, LGS had an approach that worked but how many other studios of comparable size tried a different approach to stealth games and failed? You can't assume there is only one working way if you never tried another. And from a scientific standpoint it would be nice to name more then one source if you are relying on the arguments of others when making a point. I mean, what are you trying to tell me. That game studios tend to create a gameplay in which the player gets the impression that he managed to handle an almost impossible hinderance that, without him noticing it was more or less handed to him due to clever level design. This is nothing new. It's a common approach and nothing that stands against anything I have posted. We are talking of different interpretations or implementations of the same thesises. And it is always a sure sign someone ran out of arguments if he starts citing the work of authorities and undermining the others position by putting him into categories like "rebel". There is a lot I am, but definetely not that. Because I don't see any conflict in thief gameplay and giving the tools handed to the player an actual meaning. Stealth gameplay for me doesn't imply to not interact with the ai or the surroundings. And I haven't implemented the stealth score. I am not even a fan of it. And how does that stand in contrary to my example? In the end it comes down to choices. All I say is that those choices should incorporate the use of your gear, so there is a value in having them.
  18. @snatcherAlthough no fan of the idea here are some for you: On reload you loose something of value. Either loot, or once that is getting low it takes away gear. Obviously the game needs to save automatically after load. The loot taken away could be respawned in the mission, so you can reobtain it. Enemies respawn and lights get relit. Obviously only a viable option if the mission is designed so that it encourages you to actually take out enemies or extinguish lights. An alternative could be to add guards or increase your visibility (maybe reloading is intented to take time, so the sun is rising) This may be avoidable by using a semi-randomized approach. The area you spawn after load will only check with progress. So if you spawn at a location A currently you will keep spawning there unless the amount of loot acquired has changed significantly or you have taken out guards or used gear or fulfilled an objective or a combination of both. Not easy to implement, actually an interesting challenge with the existing system.
  19. As said I haven't played the game, so maybe it was really bad design or to stretch the game. Regarding the endings: It doesn't have to be the other extreme. But if you can do whatever you want and then decide the faith of the world within the last hour of your playthrough, it just feels artificial and from my point of view negates the whole idea of meaningful choices and different endings. And no, I don't want to play the game several times to see the different endings. And I would neither do so nor look them up on youtube or anywhere else. Similar to how I ignore steam achievements, although almost all games I own have them. I am no completionist. In TDM missions, if there are optional goals I ignore them unless I get the impression it might prove useful to fulfill them. I don't care whether I found all loot as I have no use for it anyways and I couldn't care less about my stealth score (OK, I tried once to beat too late with a stealth score as low as possible. But I was bored and the mission is small.) And even though I may not seem to raise the impression, but I work for a living, too. (But I admit not having a kid. I have enough of those little zombies at work ).
  20. Because you obviously didn't read my posts carefully. And I am tired of repeating myself. But maybe this equilibrium helps: you can decide to not eat -> you fast you may have nothing to eat -> you starve So fasting and starving is the same?! "Play the game the way you want it." Who invented that slogan? Ubisoft. Or developers in the creation of a mainstream title. If you don't like the game, change some setting til you like it. Typical modern game design. And as you write yourself: it's like that for you. Is it such a burden to accept that others have a different perception. You are comparing apples and pies. The ability to take out enemies is a fundamental part of the gameplay. A savegame system in full control of the player is not. But it is ok for you to decide that they please you?! I don't say that every mission has to implement it, not even that it would be good if the majority did. What I say is that missions designed around this could be different from what we have now, both in terms of gameplay and immersion. Of course it will not please everyone, but current fms do neither. And if there would be a few fms which you personally don't like, but which others may see as enrichment, you still think it is up to you to decide that those fms are bad and they shouldn't exist?! I mean, the whole point of your post is: "I don't understand you so you must be wrong."
  21. I wasn't aware that there is a rulebook via are obliged to follow, nor do I agree that a stealth game has to be setup like this. Taking out a guard, interacting with your environment and even getting detected from time to time should be the default, and pretty much has been for everyone back when they played Thief for the first time. Or do you really wanna make me believe that the majority of players mastered the game by ghosting through it on their first playthrough? As stated in another thread I believe it's the lack of stealth titles in general that causes player to replay those and therefore become so good at it, that they invent house rules to keep things interesting. House rules, that after two decades are accepted as some sort of genre standard. But how can there be such a standard if there are only a few game series actually representing that genre, all of which have quiet some differences in gameplay ... and all of which are literally dead. Beeing able to always go the zero-failure path as you call it does imply, that any interaction with the environment means failure, which I consider nonsense sounds extremely predictable and boring. If mappers build their mission in a fashion that there is such a path my job as a player restricts to finding that path and following it. Considering that the games are meant to provide different approaches this seems to stand in direct conflict with one the fundamental stealth design principles (which, as stated, I don't believe exist anyways ).
  22. Have is probably not the best word to explain what I mean. For an example: Imagine you have an alley lit by some torches and one stationary and one patrolling guard (citywatch for example). There are a few shadows, but not in a way that you can sneak through the area unseen. The stationary guard cannot be sneaked upon due to the light, and the patrolling one is in the stationaries viewcone most of the time. The player can now decide whether to use a water arrow to extinguish a light, having to consider which one gains him the highest benefit, and how the ai moves if it decides to relight it. He could kill the stationary guard with a broadhead arrow, at best when the patrolling guard is looking into another direction. The latter may react nevertheless as he may heard the kill, but the player may get around to sneak up on him before he gets alerted, or he uses the diversion caused by the corpse to pass by. Maybe the player distracts the guards by using a noisemaker, or there is some clutter laying around he can throw to create a distraction, even if not as effective. Maybe there is a way to bypass the guards going upwards on a balcony or similar by using a rope arrow. Similar to broadheads this would be a thougher decision if they were not retrievable, as currently this is obviously the best choice in most cases, which should be avoided. If the player doesn't have a lot or even no gear left he has to become more creative. Is there something in his surrounding he can utilize? (I already mentioned possible clutter). Guards react to open doors if setup accordingly. Maybe there is a door on the route of the patrolling guard the player can unlock and open, or he can do something else that will attract the ai's attention. If no such options exist, just rushing through (even though alerting the guards) would be the last resort. So with having to use gear I don't mean that it should be impossible to get through without the usage of those (which would indeed be no good game design), but creating situations in which not using your gear is one of the worse possibilities. Currently the difference between using a gear or not is mostly neglectable, and sometimes not using your gear can even be the best approach, if you can just scurry through. Why risk causing the guards attention by using gear if not necessary?
  23. I am all with you here. But I think there is a middle ground between players could use a tool and players have to use a specific tool in a specific way (which, in a broader sense, is a very common thing in TDM fms actually). I would prefer a gameplay in which I have to use my tools, but can choose which one and in which way. This way experienced gamers would have to make use of them, too, whereas new games would have to spend more thought on how to use them. There would still be a difference between how many tools the respective groups need to finish a mission, but the difference may be smaller making it easier to use the three existing difficulty levels to find setups for each player group. Currently we have experienced gamers who use almost no gear on the one side and newbies who use their gear probably almost anywhere on the other hand, considering the sheer amount they get in most missions. This is a gap to big to fill.
  24. I don't know that specific game but it doesn't seem to obvious to me. It is also a possibility that the developer wanted the player to decide for one approach and then life with it. This is something I found tedious about the deus ex games, for example. There are alternative endings, but which one you get to see is decided within the last hour or two of the game. So you basically save there and once you get to see one ending you can reload that save and see the next ending and so on. This way on one hand you get to see all endings pretty easely, one the other hand this makes the whole decision absolutely pointless. It is a simple gotta catch 'em all approach with no deeper meaning. It is the modern way of gaming, with the completionist, steam achievement, explore everything, find every piece of loot approach to gaming which bores the hell out of me. An occupational therapy for an adhd generation of gamers. Developers seem to think that their customers play games because they don't know how else to spend their time. And from the post I have read here and in other forums, I tend to assume they are right.
  25. Dragofer: split off from the Noble Affairs FM thread. One thought on gear: There is nothing wrong with giving the player different gear to allow for different approaches. However, what I have never really seen in a fm and that is the case here either is that the mission is set up in a way that the player really needs this tools. And with need I don't mean playstyle-dependent. The playstyle might decide upon which tools one use or how useful one find one tool compared to the other, but it shouldn't decide on whether the player needs tools at all. And I don't go in with my blackjack only because I want to, but because tdm missions are rarely ever putting me in a situation where it becomes a necessity to use them. Speaking for TDM overall I think that there is a lot of potential for engaging gameplay and tension missed here and in all honesty I consider this a gameplay and design flaw. And as you illustrated that you are actually pretty good at what you are doing I am convinced that you could even do better in that aspect. I am writing this not because I think that you intentionally did something wrong but that to give you a different perspective. More gear doesn't imply more possible approaches and vice versa. There is a bit more to it imho.
  • Create New...