Jump to content
The Dark Mod Forums

Obsttorte

Active Developer
  • Posts

    6059
  • Joined

  • Last visited

  • Days Won

    96

Everything posted by Obsttorte

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. @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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. @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.
  12. 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.
  13. That's what I meant when I wrote about looking into the map from the outside. And having a filter for both caulk and portal_sky and using those materials only for outside facing sides will basically serve the purpose. There is a modifier+mousekey combo to copy a material to another surface. So you can fastly copy one caulk surface onto other surfaces and, if the filter is enabled, can let the surfaces disappear by that way.
  14. I found filters to be useful. I use one to filter away entities as well as one for patches that I use to check the sealing and the visportals and one that filters away caulk and portal_sky textured surfaces, helping me to get an overview from the outside. The shortcuts for texture pasting are also useful when working with patches and those opening the most used editors, of course.
  15. Are those visportals on the same plane? Did you try shifting the vp in the maintainance tunnel a bit? From my experience the engine sometimes has problems differentiating vp's that are coplanar.
  16. Light bleeding for me only occoured when portals open. I think the main reason are probably the portals, not the lights or the way the shadows are calculated. Portals can cause a lot of graphical glitches from my experience, although I never got an idea why. @JackFarmerThose area lock spawnargs look interesting. However, normally one don't want to limit a light to one visleaf. The light should be cast through doors and windows once they are open, shouldn't it?!
  17. When I had the issue in the past it was caused by the flame lights def_attached to torches. The only thing I changed back then was to decrease the light radius. The light center gets manipulated for flame lights, but not in such a manner or to that amount. Additionally, it would clearly look different if the light center would be in your room then in another room and bleeding into yours. Pretty distinguishable.
  18. I don't think there is a command for that in DR. I think the bounding boxes are created by the engine. They are basically cuboids containing the model, axis-aligned if not rotated as far as I am aware of. They serve the purpose to allow a fast way to determine which models cannot be seen and therefore doesn't need rendering (cuboids only have 8 vertices, and if none of them is visible than everything contained inside the cuboid is invisible).
  19. I haven't continued working on that map and never really investigated the issue. idTech4 can be pretty buggy sometimes. Light bleeding is only one known issue. Another is visportals that don't work if lined up with other visportals (they then act like portal_sky instead). I am not even sure whether all instances of light bleeding through world geometry have the same root or whether there are several possibles sources of that issue.
  20. @Frost_SalamanderGuessing from those shots I would stick with my initial assumption, that the bounding boxes of said models are reaching into the current visleaf. That's the only explanation that makes sense. Note that the bounding boxes are cuboid containing the whole model, so they can be quite a bit larger then the model itself. They are also slightly larger then they have to be to contain the model to accomodate for rounding errors. g_showentityinfo displays them. I don't know whether the models origin is taken into account here and whether it affects the bounding box (when creating models on my own I always place the origin somewhere at the models edge, usually at the bottom).
  21. Interesting. I wasn't aware of that. The question is whether this happens because of the models clipping into the sealing or because of their bounding boxes reaching into the other visleaf. The latter is inevitable, the first one would be odd. EDIT: Just tested this and I am not able to reproduce the behaviour described by you. @Frost_SalamanderDo you have any screenshots or an example map that demonstrates the behaviour?
  22. When using modules the wall segments are normally either patches or a brush with all sides caulked except the one facing inside the room. In regards to the 8+8 I mean that the wall surface is 8 doom units away from a larger grids line, but I do not seal each room with its own caulk shell. I place the modules and add the caulk afterwards, which, if in between two adjacenting rooms is usually an 16 doom units thick brush. It can happen that if added afterwards there are two brushes. It doesn't make a difference for caulk walls, though, so you can do it both ways or as it suits the situation. Check out the threads dealing with modular building techniques as well as information that can be found via google on that matter. There is plenty of information on that matter available. Creating angled brushes works imho best by either clipping them or by dragging the vertices in suitable place. Especially for sealing geometry it is important to have the vertices on grid. If the modules are of cosmetic nature and the windows are not openable, it is no issue for them to clip into the sealing geometry if the latter is textured with caulk. Caulk doesn't get rendered and will not occlude the model as long as some part of the model is inside the pvs.
  23. Well, you can either override the scriptobject file in your fm or you store it under a different name and use that modified version in your fm. Either way, script objects don't altered all too often for compatibility sake. Worst case scenario when overriding the stock file is that the new line added would have to be added to the updated file. An example were I modify the location system is the hitman style script iirc. You can find the file and a description in my mapping thread as well as in one of my wiki articles. See my signature.
×
×
  • Create New...