Obsttorte

@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.

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.

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.

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.

My reply wasn't referring to you.

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.

@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.

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.

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.

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.

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.

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?!

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.

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).

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.

@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).

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?

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.

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.

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 objective or whatever. For reoccuring stuff that is intented to be reused in other missions setups as the above should be avoided, as they are hard to adjust, most often more time consuming to setup and much more sensitive to errors, not to mention the amount of time it takes to find and fix said errors. I would advise that you familiarize yourself with scriptobjects as well as entity definitions.

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 you are right. I was more thinking of relatively flat walls with some support beams placed in front of them here and there. And I have the habit of using walls with no thickness as mentioned above, so that the caulk wall behind them ends exactly were the wall plane is. Maybe that neglects the need of monsterclipping the walls to a certain degree.

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.

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.

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 seperately once you need them, as they can be very rough (in terms of grid size) and therefore are unlikely to cause issues. Most of the time when I helped other mappers fixing their maps the root source of leaks (also internal ones) was, that they either created their sealing geometry on small grid sizes (the smaller the grid size, the smaller the gaps can be, and the more likely you'll going to overlook them) or that they used the hollowed out way of building and later on changed something, shifting a brush or resizing it in a way that cause a leak. This is especially bad if the leak created is internal, because it will take ages to even find out that there is an issue, not to mention the time it takes to find it. A good advice imho is to keep the detailing geometry and the one used for sealing as seperate from each other as possible. Make the detailing stuff out of models or stuff converted to func_static. Note that you can export func_statics as models which will help performance if reused (a copy of a func_static is handled as a seperate model, two instances of a model are not). And use caulk and portal_sky brushes, created on large grid sizes (8+) and axis-aligned if possible, for the sealing. This will spare you most of the headaches.

The name "world" is reserved for worldspawn! You don't have to and shouldn't name worldspawn. Delete the name spawnarg you have added. Note furthermore that spawnargs applied on one worldspawn brush or patch applies to all of them, as all of them are handled as one entity (with the name world). Why do you want to give it a name, btw.?