Jump to content
The Dark Mod Forums

Obsttorte

Active Developer
  • Content Count

    6054
  • Joined

  • Last visited

  • Days Won

    96

Everything posted by Obsttorte

  1. @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
  2. 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 ins
  3. 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.
  4. 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
  5. 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 imp
  6. @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
  7. 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. Th
  8. 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.
  9. 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.
  10. 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.
  11. 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?!
  12. 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.
  13. 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).
  14. 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.
  15. @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 m
  16. 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?
  17. 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.
  18. 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.
  19. You seemed to have misunderstood me. I was talking about adjusting the location_settings script object used by the location entities that gets shipped with the mod. This would completely neglect the need to call a seperate script function for each location. Instead, the only thing the mapper would have to do is to specify the lightgem adjust value one the location entity. Script functions placed in the mission script are normally only suitable for one time instances specific for the respective mission, like initiating a scripted sequence or event, something story-related, a custom objecti
  20. Yeah, 8 doom units is what I use for the sealing on both sides, so I end up with a wall thickness of 16 doom units (for indoor walls, outside walls are usually thicker), which isn't very thick. One doom units is approximmately two centimeters or a bit less then one inch, so we are talking about 30-40cm or a bit more then a foot here. 8 doom units should definetely be the absolute minimum for seperating visleafs imho. Note that I am talking of an approach where the wall itself has no sealing purpose, and therefore no thickness. I normally don't use that kind of walls, but I guess y
  21. If you wan't to adjust the lightgem modifier (or any other value) via the locations system, you should use the locations system. Modify the script to do what you desire and use an additional spawnarg on the location entities to specify the lightgem modifier for the respective location.
  22. This depends on the size of the wall segments, or more precisely their thickness. If the walls don't reach into the room too far (less that 8 doom units) you don't neccessarely have to mc them. It is often sufficient to clip the support beams, if any, although in that case a long mc brush might even be the easier choice.
  23. The problems might not be as hard as you described them, but at least pathfinding and sound propagation would suffer. However, you don't seal a cross-shaped corridor by creating a brush hollowed room around all of it. The brushes form the walls of the corridor. So if that is made out of models, you basically place caulk brushes right behind the walls. Also, using hollowed out rooms is only one way of building levels. I haven't build like that for years now. If you use world geometry mainly for sealing and culling purposes, you can create the walls as well as the ceilings and floors sepera
×
×
  • Create New...