Itches, Glitches & Anything Else...

[Fidcal]

Yes, open maps\jdude\edridge.map, invert selection, try Alt + arrows.

[greebo]

Tracked here: http://bugs.angua.at/view.php?id=2112

[jdude]

This is driving me 'naners'. When you create an entity instead of creating it on the X, Y, and Z which are all located on the three views it creates it at 0 on one of the axis. So if you make a entity on the top window far from the Z origin, the entity pops to the origin rather than where your Z views are causing you to have to go find it.

[Fidcal]

Problem is I guess you might have 5 views or only 1 view. In other words I guess the code can only look at the window you are clicking in. What I do is to select another entity nearby then deselect it then create the new entity. I believe it takes the other coordinates from the last selected. But it's not that simple because it tries to 'floor' it and that in itself might go on the wrong floor. I generally insert always in plan view. Also, if you don't like the new entity and delete it and create a new one then it goes back to 0 I think. Hard to think of a perfect solution.

[jdude]

There could be an option to pick 2 views to use as reference locations. For example I always use ZX and YX so having the option to use the x and y from xy and Z from Zx would be preferential for me.

[greebo]

Rarely needed but Dark Radiant crashed when I tried to move an entire map (using Alt + arrows) but it worked OK if I first dragged out a brush and imported the map (probably the same if I just opened and added a brush then selected only the main map.) This was a big map. Not tried with a small one.

This one is fixed now - a rare situation, but it's covered now.

[jdude]

I just noticed atdm:mover_door function has an odd parameter:

 

1/0 is_manteable

1/0 is_mantleable

[AluminumHaste]

This is driving me 'naners'. When you create an entity instead of creating it on the X, Y, and Z which are all located on the three views it creates it at 0 on one of the axis. So if you make a entity on the top window far from the Z origin, the entity pops to the origin rather than where your Z views are causing you to have to go find it.

 

This is definitely new behavior as this used to work where the entity or brush is created on the same plane as your last selected brush/entities origin, or somewhere close to there. Now when I create a new brush in the Z view, it's like 3000 units away from where it should be.

[Fidcal]

Can I pass the engine path to Dark Radiant from a shortcut? I've only passed the game paths before. I want to work with release assets in another install but not exclusively.

[greebo]

Nope, the engine path is stored in the user.xml file and only read from there.

[greebo]

@STiFU and everybody else compiling from SVN: I've upgraded the boost headers and libraries so be sure to update the w32deps and possibly w64deps.

[AluminumHaste]

@STiFU and everybody else compiling from SVN: I've upgraded the boost headers and libraries so be sure to update the w32deps and possibly w64deps.

 

Yes I haven't done that in over two weeks now I will do that tonight.

[Fidcal]

1.1.0 x64 An old minor glitch I've been meaning to mention. If you clone a projected light it still works normally but the projected display is lost in DR and it cannot be manipulated by the vertices. It shows just like a normal light. Reload the map and it is OK again. I've tried different tricks like deleting it and then undo but only reloading the map seems to work.

[greebo]

If this is still existent in the most recent release (which I suspect it to be) please open a defect entry.

[Fidcal]

Not got the latest but this has been around quite a while so very likely still present. I'll add it to tracker.

[greebo]

Any particular reason you keep using version 1.1.0 instead of the more recent releases?

[Fidcal]

No. Long story short. This goes back to when I had a lot of back pain and wasn't using any version because I couldn't sit at my office chair for weeks. Then I started studying code so no mapping. Then GC and MD released their great campain so then I re-arranged my two pcs into different rooms as I couldn't play the FM on my slow PC. Then I vaguely heard of a DR release with some crashes so I thought I'd leave it a week or two... etc. etc. At some stage in that lot I forget where I did get a new DR version (on my old PC with a very old DR) and it lost all my settings (that was normal from one update as I recall.) Now I'm intensively mapping again and don't want to break my flow for another month or so (not that installing DR is normally any trouble but having just redone most of my keys and colors, etc. etc.) So, in a few weeks no doubt I'll update again.

[jdude]

This has likely been suggested before but it's a pain finding the original texture when using the texture replacement tool. Could it be made so you can select a brush's face and replace all the selected texture type including non selected with another.

[Fidcal]

A workaround is to select the two textures in the media browser one at a time. At the bottom you can click (right click?) the shader name and select copy shader name.You can copy one shader name to a notepad then copy the other direct into find and replace then get the other from notepad.

 

[edit] or copy from surface inspector of course.

[Fidcal]

Bug when thickening the sidewalls of a cone. Looks OK in editor but in game a vertex seems to be put at 0,0,0. I'll add this to tracker. This test cone was 8x8x8 and thickening only 0.025 but I think it's the same for larger.

 

 

[jdude]

Yea but it's still a little frustraiting when trying to see when different textures would look like. However I did end up finishing it up.

 

I noticed another bug. The position in the 3d view of decals (maybe all patches) shifts depending on distance in the editor. For example, create a small cup in the editor out of brushes. Maybe no larger than 10 units. Place a decal .125 units behind it and with the camera scroll from close up to far away and you will notice that the decal will plop infront of the brush at a particular distance when it's actually behind. I can take pictures if this isn't repeatable for anyone else.

[greebo]

I noticed another bug. The position in the 3d view of decals (maybe all patches) shifts depending on distance in the editor. For example, create a small cup in the editor out of brushes. Maybe no larger than 10 units. Place a decal .125 units behind it and with the camera scroll from close up to far away and you will notice that the decal will plop infront of the brush at a particular distance when it's actually behind. I can take pictures if this isn't repeatable for anyone else.

This is inherent behaviour when rendering decals. To avoid z-fighting, decals are usually offset by a small, nonzero epsilon in their projection matrix (towards the viewer). This epsilon is suitable for most distances, but when going too far away from decals, that epsilon is large enough for them to be rendered in front of other geometry, even though they're behind them.

 

Apart from tweaking the constant there is nothing DarkRadiant can do about this. You can also see this behaviour in the D3 engine, btw.

[OrbWeaver]

I wonder if it might be the case that our Z offset is calculated incorrectly -- I noticed when I was fixing the decal transparency in Fidcal's test map, the grime decals disappeared if you moved too close to them, but it seemed like they were offset some considerable distance into the room.

[jdude]

This is inherent behaviour when rendering decals. To avoid z-fighting, decals are usually offset by a small, nonzero epsilon in their projection matrix (towards the viewer). This epsilon is suitable for most distances, but when going too far away from decals, that epsilon is large enough for them to be rendered in front of other geometry, even though they're behind them.

 

Apart from tweaking the constant there is nothing DarkRadiant can do about this. You can also see this behaviour in the D3 engine, btw.

 

Yea I noticed it in saintlucia . It seems far stronger in DR though, but if there's nothing we can do so be it, it's not a priority imo.

[greebo]

I wonder if it might be the case that our Z offset is calculated incorrectly -- I noticed when I was fixing the decal transparency in Fidcal's test map, the grime decals disappeared if you moved too close to them, but it seemed like they were offset some considerable distance into the room.

I see that the glPolygonOffset() function gets called with (1, -polygonOffset*128). Decals have their polygon offset set to 1, so the function is called with (1, -128). The first argument (factor) is probably ok, but the second one (units) seems to be a bit high or at least arbitrarily multiplied by 128. Anybody knows where this number is coming from? I don't have any experience with these polygon offset units though, so I can only guess.