Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


Obsttorte last won the day on March 21 2021

Obsttorte had the most liked content!


1566 Deity


Profile Information

  • Gender
  • Location
    Observable Universe

Recent Profile Visitors

7717 profile views
  1. This is actually not true. The reason I wanted to implement this was to allow mappers to modify the gameplay in a way that causes players to actually risk something and for different kinds of overall gameplay. As I had tried to explain back in the uproaring discussion as you named it was that there was no intention to use this as a method to increase difficulty, as there were already other means to achieve this. So although using this will increase the difficulty, mappers can always outweight this by reducing the difficulty via other aspects (ai sensibility, lighting, equipment et al). Unfortunately this wasn't understood back in the discussion with the team members nor later on when discussing it with mission authors, as your comment illustrates. Dunno if this is some sort of language barrier or whether the opposition to ideas differing from the original gameplay caused this confusion.
  2. I've played around with a throw-hook in the past. It basically consisted out of a hook with a rope attached to it. The issue was the physics. IdTech4's physics calculations are pretty rudimentary and not very stable. If an object with an ragdoll (like the rope) attached to it becomes too fast, the attachment gets interrupted (the console literally stated: "Too fast, letting go" :D) Iirc the limit was about 128 doom units per second. An arrow is way faster. The problem is of course that if the hook is too slow, you cannot throw it very far, unless you manually keep the speed high via scripting to bypass that, which would look unrealistic, though. Maybe there have been tweaks made to the physics engine that lessen these issues, as it's been years when I was working on this. In difference to that approach an tightrope arrow doesn't need to be that dynamic. However, a proper animation would be needed unless you want the arrow to magically appear once the arrow has hit its target. Another issue is, that in difference to the current rope arrow, that chooses the length of the rope out of four possibilites depending on the space available, a tightrope arrow would have to relatively exactly fit the length between two points, which could become hard to achieve.
  3. One side of the exit location brush is textured with caulk, maybe that is the issue. Btw.: iirc if you set ongoing on the exit objective you don't have to use the enabling objectives logic, as the objective will only tick off if all not ongoing visible objectives have been completed. Could be worth a try, too, if the caulked surface isn'T the source of your issue.
  4. I guess we can agree on that. and I don't think it is very helpful to boil my comment down to morality play. I haven't had any morality in mind when posting my comment. It is a simple fact that disallowing certain modifications per se restrict the mappers. There might be good reasons to do so, but those should then be brought up to the mapper once necessary, and the mapper should have the choice to decide. That's what beta tests are intented for. That might be true. But players can only modify the game to the degree that they are allowed to via the settings menu, unless you expect the average player to fiddle with the files shipped with TDM or a fm. And in the latter case the player would not be able to modify it more then the mapper can. So I don't really see the point here. We are not talking about player versus mapper modifications.
  5. May he rest in piece. Condolences to his friends and family. He has definetely been a column for this community and the mod and a helpful and kind person throughout. I can't tell how much I have learnt from him, especially in my beginnings, and I bet I am not the only one. May he and his work be an idol for us.
  6. I have to say that I share @peter_spy's opinion on this matter. Even though frob hilighting is part of the ui, that is very well part of the artisitic design of a mission. Screen resolution or fps are not, therefore the comparision doesn't make much sense imho. It is odd that on the one side it is often stated how important the respect towards the artistic choices and mental property of the mappers is while on the other side they get restricted in how to shape their work. It makes sense to have a standard, and if it is customizable by the player that's fine, too. But a mapper should have the choice to alter that if he or she considers a different approach more suitable. Especially considering there is no harm done as it will only affect the autors mission. In addition: who is "the majority"?! I can only see roughly half a dozen team members having discussed this matter. I am pretty sure the team consist out of more then just those few.
  7. @datiswous I guess this has to do with rendering order. First of all are solid surfaces are rendered. Everything that is more complex, because it is translucent for example, gets rendered afterwards. I barely remember that the water shader uses the currentRender image as base for its calculation, that is the image containing the solid stuff rendered. The translucent window texture is not part of that image, so it gets ignored and does therefore not been rendered. Question: You wrote that you want the window/glass material to be light up by the light behind it. So you don't really want the actual lamp to be visible, but more the effect of light shining through the glass. Is that correct? In that case, your setup in unneccessary complex. Instead of a translucent window texture you can make an additively blend texture. There are lit window textures where you can check how this is done.
  8. I don't know whether there is a difference between old and new missions in regardence to translatability (is that a word?). However, regarding the wiki The Outpost is already converted to the I18N format and some translations have been provided, although not a russian one. (It seems there are no russian translations whatsoever even though there have been attempts in the past, but that is based on the wiki which may be outdated in that matter). If you want to provide translations I would furthermore suggest to use the english.lang string file as starting point and translate the strings inside those files instead of running the script on the mission pk4 again. I wouldn't blindly assume that the results are always the same, so strings might get mixed up. Also note that when translating you have to keep the amount of space required by the strings in mind, as they could otherwise get cut off ingame. You'll as well as other russian speakers have to check that ingame. Regarding the tooltips. They are part of the loading screen gui I guess. This feature was added after the script was written. As the member who wrote that (Tels if I am not completely mistaken) is no longer active, the script probably haven't been updated for a while now. You can alter that manualy, I guess. Note, though, that any change on mission pk4's need permission by the respective mission authors.
  9. I don't know. I haven't written said script and don't use perl normally. As long as there is no error message or similar I can't help. EDIT: Just tried it myself and the script doesn't create an output as it isn't able to read a specific string within the fm. So this is an FM issue, not a script one. @Gadavre Would have been helpful if you have noted the output yourself. How should anyone know what is going on if you don't provide the necessary information? And please stop demanding fixes for things that ain't broken.
  10. If the normals are accessible to the shader (I think they are stored globally), then creating a frob shader hilighting the outlines should be doable by identifying areas where said normals change strongly. This approach may fail with compareable round objects. Another approach would be to utilize the depth image, which could be troublesome with compareable small objects, though. A third approach would be to combine those two, which may fail with small round objects A post processing of the above effect might also work. Strengthen the effect if not all surroundings are affected and dimish it otherwise.
  11. As most players do not seem to have any issues with the current implementation I don't see any need to change it, more so I would assume any change to cause more confusion rather to improve the game feedback and that new players may simple have to get used to the way it is handled in game instead of immediately asking for changing something they blame the game to do wrong even though the majority of the players both in TDM as well as in the orignal Thief games are pretty happy with. On the other side we could see the suggestion of making the player invisible as an incentive to finally implement the rocket launcher players were asking for all the years and, if some of the coders have some free hours on the weekend left, port TDM to the CryEngine.
  12. @Zerg RushAs Springheel wrote there is a noteable light coming from behind you. It appears that the lighting is setup in a way, that if the light source in the room gets extinguished, the light level of the moonlight coming through the window either increases or the light was off before and get turned on. There are two reasons I think it could be set up like this. (1) is for performance reasons (only one light source in that part of the map at a time and (2) moonlight coming through the window would be barely visible when there is an active light source in the room, but the renderer might not reflect that all too well. What is happening in your shot is that the light level of the moonlight is too high (way too high, to be honest, it almost looks like a stadium spot light shining through the window), and in this case, even higher then the light inside the room, causing your visibility to increase. This is than not a mod issue, though, but an issue with the mission. It might be worthwhile reporting it in the respective mission thread to see whether other players or the map author can second this.
  13. Can you verify this by also displaying the lightgem values? I think there was a console command for displaying it. If not I may have done it differently in the past and would need to provide something. Note that a brighter lightgem can have to reasons: (1) the lightgem value is higher, which would also result in you beeing more visible to the ai (which doesn't seem to be the case) or (2) the surface just gets rendered brighter. Increasing gamma and or brightness will probably also effect the appearence of the gui elements, unless it is explicitely designed to not to. I don't know that. That the gem appeared to be brighter after turning of the light could be an optical illusion, though. It may appeaed brighter as everything else got darker. Especially when playing in a dark room this could be the case, imho. But as afore mentioned this needs testing.
  • Create New...