Ocn's questions on TDM editing.

[Serpentine]

Two common areas where you get things like that are :

• Areas which once 'optimized' by dmap have a nucleation of triangles converging at one point, overlaps show up as either dark/bright lines on the surface. Usually this can be worked around by adding in a detail brush or something. To check it, r_showtris 3 will give you an idea of what's going on.
  
• Sometimes when you have single sided surfaces that meet or skim over a plane you will get a bright line along that edge(s), this can sometimes be resolved by snapping the points to grid in the case of two patches meeting or seperating the patch slightly if it's skimming over a surface.
  

 

You also get it in models, something similar to the second case, usually single sided surfaces intersecting, but it's a bit less commonly seen.

 

I'd suggest playing around with the wireframe visible using r_showtris 2/3 and you should get a better idea.

[Tels]

What do you supposed these lines could be? I've tried moving things around, but they won't disappear. It's not too big of a deal, I'm just wondering what the reason might be.

 

Probably the verts/brushes are not grid-snapped, and you see whatever is behind this. Ways to avoid: grid-snap things, and if using patches, put "caulked" brushes behind.

[ocn]

I'm not sure how to decipher what r_showtris tells me. I've tried gridsnapping, caulking and replacement, it's still there. I'm going try and rebuild the scene and see if it happens again.

 

EDIT: I managed to reproduce the lines. It was a poorly placed light source. A lantern, but light sources are portable so there's no guarantee noone will ever see them.

Edited December 10, 2010 by ocn

[ungoliant]

However, the radius actually determines how lit the player is X meters from the light source, not the color!

 

disagree. Are you telling me that standing next to a light source with .50 .50 .50 color value you will be lit the same as another light source with .05 .05 .05 value?

 

speaking of how well lit a player is by light radius, I've been having issues with adjusting light radius down to the floor. Sometimes a floor looks moderately lit up, when player stands there, he is well lit, but then crouching the light-gem is near-black in that seemingly moderately lit area. This is annoying as hell.

[Fidcal]

I think the problem there is when the vertical component of the light radius does not go far beyond the floor and the torch is not very high. So the falloff in brightness from max (centre) to zero (just below floor surface) is rapid, ie, say 25% fall off within only 25 units. So the difference in light gem reading while standing and crouching is large. If the light were a hanging lantern much higher then the fall off in brightness is spread over a larger distance. In addition there is a crouch deduction (because even in the same light you would be less visible if crouched.) So the solution is make sure the light radius goes sufficiently below the floor surface by testing the crouch in your maps.

 

[EDIT] I am presuming here that the light gem is read at a lower height when crouching as well as the deduction. In any event I think the principle is sound that if you increase the vertical radius deeper below the floor it should solve the problem.

[Fidcal]

This also reminds me there is some modification to the light gem in the coming update. I don't know without searching how it affects this.

 

http://bugs.angua.at/view.php?id=2319

[ocn]

This brings up a burning question for me: is there a light absorbing texture by any chance? I have a rather thin wall (not too thin imo, 1 grid unit at a setting of 8), and light seeps through it. It'd be great with an invisible non-solid light absorbing brush to cover it with.

[Tels]

disagree. Are you telling me that standing next to a light source with .50 .50 .50 color value you will be lit the same as another light source with .05 .05 .05 value?

 

As fidcal says, it depends on the radius of the light and the alloff. The above scenario is possible.

[ocn]

I just noticed that my visportals do not supress the sounds that AIs make, but every other noise is masked out just fine. And it is not just where the walls are thin either. What am I doing wrong here?

[Springheel]

It's a bit tricky to wrap your head around, but visportals don't suppress sound, they just channel it. Have you read this? http://wiki.thedarkmod.com/index.php?title=Visportals#Sound_Propagation

[ocn]

It's a bit tricky to wrap your head around, but visportals don't suppress sound, they just channel it. Have you read this? http://modetwo.net/d...und_Propagation

 

Yes, I did. My head don't wrap very well, that's true. But I observed that all sound travelled through a hole in the roof without the visportal in place, but with it there only the

sound of the AIs managed to leak through. So, it obviously has a stronger effect on some sounds.

[Springheel]

But I observed that all sound travelled through a hole in the roof without the visportal in place, but with it there only the

sound of the AIs managed to leak through. So, it obviously has a stronger effect on some sounds.

 

When you add a visportal to a sealed room, then sound has to travel to the visportal first, then to the player. This usually makes the distance the sound has to travel longer (though not always...depends where the sound originates). All sounds have a "maxDistance" property that determines how far they go, so it's possible other sounds in the room now hit their maxDistance before reaching the player. AI vocals and footsteps have a large maxDistance (25, usually) so that players can hear them a distance away.

[Serpentine]

This brings up a burning question for me: is there a light absorbing texture by any chance? I have a rather thin wall (not too thin imo, 1 grid unit at a setting of 8), and light seeps through it. It'd be great with an invisible non-solid light absorbing brush to cover it with.

 

If you could check if the material name ends in _ns for "noshadow", or failing that find the material in the material browser, right click its name and "Show Shader Definition", there's a good chance that it's got "noshadow" set, if there's no solid alternative you can make a duplicate material with a slightly different name in your fmfolder\materials and change its name slightly

[Mortem Desino]

It sounds like your light is set to noshadows. If you really need it to stay noshadows, there is a light texture called "roundhalf" that you can use.

[ocn]

If you could check if the material name ends in _ns for "noshadow", or failing that find the material in the material browser, right click its name and "Show Shader Definition", there's a good chance that it's got "noshadow" set, if there's no solid alternative you can make a duplicate material with a slightly different name in your fmfolder\materials and change its name slightly

 

You were right. I was wondering what that _ns ending meant. Funny how much richer one feels after learning something new. Thank you, Serpentine.

[ungoliant]

give DR another month or 2, you'll feel like a billionaire

[ocn]

Um... What would the criteria be for a secret to really be a secret, in your opinion? I mean for the player to really feel that they've discovered something hidden.

[Fidcal]

Either a message pops up "found a secret" as in Heart - or an easter egg which is not an essential part of the main game and is so hard to find that almost nobody finds it until it is mentioned say on a forum that it exists.

[ocn]

Either a message pops up "found a secret" as in Heart - or an easter egg which is not an essential part of the main game and is so hard to find that almost nobody finds it until it is mentioned say on a forum that it exists.

 

I'm thinking that a secret (or its whereabouts) might be referred to in clues given throughout a mission, so that only the most observant thief can pick it up. Of course you may stumble upon it by pure luck, but then without knowing its story. But others might see it differently, and not regard this as much a secret as a golden ring underneath a rock.

[OrbWeaver]

Note how the ceiling hidden by the vault is caulked? It is because the vault touches the ceiling brush at its highest point.

 

It's also a performance optimisation too; if the brush behind the patch is not caulked, it will be rendered in addition to the patch texture, even though it cannot be seen.

[ocn]

How can I set up a Parent/child relationship of a prefab? I can only select individual pieces.

 

CAPTAINS LOG SUPPLEMENTAL: Dark Radiant consistently crash whenever I try to save a readable. I've created an xdata folder under darkmod.

Edited December 15, 2010 by ocn

[Fidcal]

Don't know what you mean about prefabs. A prefab is just a section of a map so it has only any relationships that were in the original map. For instance if it is a table and chair then the table might be made of brush legs and a top and the whole thing is a func_static; similarly the chair a separate func_static. Once you insert a prefab into your map it is no longer some special kind of thing called a 'prefab' it is now just part of your map as if you built it yourself. A prefab could be a complete room with furniture, models, guards, brushes, patches, anything.

 

If you want to manage a collection of things from a prefab (or from anything) then use a layer which is not just a layer but a group of anything you want. So if you load a complex prefab then it is a good idea to create a new layer and put the prefab straight into it while it is still selected. Then later you can select the layer and move, rotate, retexture the whole think if applicable. (note there are problems with rotate of multiple brush/patch entities at the moment.)

 

~~~~~~~~~~~~

 

I'm not certain but I think the readables error is this. If you insert a readable prefab then by default it is using a blank xdata definition which is inside a pk4 archive. This means the editor can't save it back (and shouldn't because they are just blank masters.) So instead you should rename the xdata name to something unique in your map such as Jims_Log.

[ocn]

Don't know what you mean about prefabs. A prefab is just a section of a map so it has only any relationships that were in the original map. For instance if it is a table and chair then the table might be made of brush legs and a top and the whole thing is a func_static; similarly the chair a separate func_static. Once you insert a prefab into your map it is no longer some special kind of thing called a 'prefab' it is now just part of your map as if you built it yourself. A prefab could be a complete room with furniture, models, guards, brushes, patches, anything.

 

If you want to manage a collection of things from a prefab (or from anything) then use a layer which is not just a layer but a group of anything you want. So if you load a complex prefab then it is a good idea to create a new layer and put the prefab straight into it while it is still selected. Then later you can select the layer and move, rotate, retexture the whole think if applicable. (note there are problems with rotate of multiple brush/patch entities at the moment.)

 

~~~~~~~~~~~~

 

I'm not certain but I think the readables error is this. If you insert a readable prefab then by default it is using a blank xdata definition which is inside a pk4 archive. This means the editor can't save it back (and shouldn't because they are just blank masters.) So instead you should rename the xdata name to something unique in your map such as Jims_Log.

 

One layer for each prefab? I added a jewel box, but soon discovered that I coudn't deselect it without losing the ability to move the whole shebang. And trying to select everything again is a bit of a pain.

 

DR crashes when I try to save after renaming, sometimes even as soon as I click the namefield.

[Fidcal]

One layer for each prefab? I added a jewel box, but soon discovered that I coudn't deselect it without losing the ability to move the whole shebang. And trying to select everything again is a bit of a pain.

Precisely. That's why you put it in a layer so it can be reselected as a whole group later. An alternative is:

• 
   
  
• Left mouse button drag over the whole thing in XY view.
  
• Menu > View > Hide/Show > Hide deselected (or use the hot key(s) shown.)
  
• De-select.
  
• Left mouse button drag over the remainder in a side view.
  
• Menu > View > Hide/Show > Hide deselected.
  
• Select and hide any odd bits you don't want and you should be left with only the whole group of stuff visible.
  

But it's easier to anticipate you might want to re-select a group of things and put them in a layer first.

 

DR crashes when I try to save after renaming, sometimes even as soon as I click the namefield.

This I do not know. If you are renaming regularly so you keep earlier backups then alternative is to keep a single name map as your main working map then use 'save copy as' to save with a new name (perhaps in a subfolder.) Or there is a snapshot save.

[ocn]

Precisely. That's why you put it in a layer so it can be reselected as a whole group later. An alternative is:

• Left mouse button drag over the whole thing in XY view.
• Menu > View > Hide/Show > Hide deselected (or use the hot key(s) shown.)
• De-select.
• Left mouse button drag over the remainder in a side view.
• Menu > View > Hide/Show > Hide deselected.
• Select and hide any odd bits you don't want and you should be left with only the whole group of stuff visible.

But it's easier to anticipate you might want to re-select a group of things and put them in a layer first.

 

This I do not know. If you are renaming regularly so you keep earlier backups then alternative is to keep a single name map as your main working map then use 'save copy as' to save with a new name (perhaps in a subfolder.) Or there is a snapshot save.

 

Sorry. I was a little unclear. It's not about renaming readables. It's about saving new ones. And I can't solve this, DR continues to crash.