Search the Community

Did this happen after loading a saved game? @Springheel: http://forums.thedarkmod.com/index.php?showtopic=8904

I would think 500K is reasonable at least. If we post screenshots we want to post high res and one jpg migh be 100K to 200K. I've just posted in one of the private forums 4 modest jpgs to help clarify a prefab and had to post each one on a separate post.

Asked, and answered. Good thing they did research this in advance, or there would've been one monster sized patch shortly after release.

Thanks! Oh yeah, I'd say it has been worthwhile. To give you an idea, I haven't been able to visit these forums for over a week because I've simply been too busy doing things with my own game; doing support, talking to fans, trying to encourage the growth of the community that's suddenly emerged around the game, fixing bugs, doing additional promotional work, etc. etc.

I see now some smileys aren't working in posts either: http://forums.thedarkmod.com/index.php?s=&am...st&p=176285 laugh.gif instead of .

I typically read the Dark Mod forums every day. I usually don't have much to contribute; however, I just went through this myself. I did a lot of research on LCD monitors recently and this one is a beauty, both aesthetically and feature wise. I just upgraded from a Samsung Syncmaster 216bw LCD, which is an excellent screen, to a Dell SP2309W LCD monitor. It's a significant bang for the buck. It's a 23" LCD with a 2048x1152 resolution, a 2ms refresh and an amazing contrast ratio. It has a glossy screen, and unless it's off, there is no noticeable glare or reflection. I played Thief 2 with it's dark settings and didn't notice any noticeable distractions from glare or reflection. The blacks looked very black, and I haven't noticed any ghosting or blurring. I cant find any numbers to verify this, but from my experience so far, it appears to have a very low input lag. Quick Specs: Panel Size: 23" Optimal Resolution: Higher than Full HD 2048 x 1152 at 60 Hz Dynamic Contrast Ratio: 80,000:1 (max) Brightness: 300 cd/m2 (typical) Response Time: 2 ms (typical) Viewing Angle: 160° / 170° (typical) Color Support: 16.7 million colors Pixel Pitch: 0.249mm It also has an adjustable stand with height and tilt adjustment. The monitor can be used in both portrait and landscape. It also built in 2 megapixel webcam and 2 mics, as well as a built in USB hub. I actually prefer the Dell SP2309W over the Dell 2408WFP Ultra Sharp that I use at work. It's currently $379 which is not bad. I got lucky and was able to purchase it when Dell had an $80 off + free shipping sale. I consider it an excellent monitor for both production ( coding / graphics / etc ) and entertainment ( games / movies / etc ). Based on my personal experience with this monitor, I strongly recommend it if it fits your budget.

I just checked the code for CAP Texture and I think it should be the patch equivalent of Axial. But it doesn't work, and I think the command can be ditched along with the weird code. It seems to be trying to calculate a normal out of the control vertices and this normal is checked for its axis dominance (which component of the vector has the largest absolute value). A projection is then performed on to that axis, but this doesn't seem to be functional. Given the fact that we already have better tools to texture such (inverted) endcaps, I vote for removing that thing.

Here's a general question (not a request, necessarily). I'm not sure if, a.) I just don't know how to do this, b.) there's a possible bug which prevents this, or, c.) there's currently no way to do it See the image below. In testing out the texture stitching, I used the left patch stitched to the top right, and then the bottom right stitched to the top right. These were the expected results, because the patches are completely different in grid space. What I'm interested in is the flattened, warp section of the texture in the middle, because the endpoints meet up nicely. We have the S and T fields. These have wacky calculated values in them where the editors handle texture layout for us and spit out a number we can see or modify if we're daring enough. The other dimension is the dropdown boxes above these fields, with values of 0,1,2 and 0,1,2. These correspond to the control points. For example, changing values on 0,0 will move one of the corner control points. And changing S and T for 0,0 will affect the shift and what appears to be the tile values. Sometimes these are actually useful. What I'm wondering is the following: How to affect the texture at the center of the bend, the flat warped area? One would suspect they could by going to coordinates 1,1; 0,1; and 1,0. But changing the S and T values for these points does nothing at all. Is this a bug? It seems so. And it's in both DarkRadiant and DoomEd. Or is it just impossible to affect the texture layout at those points through these editors (or even the game itself)? "Natural" does it, so surely it can be done, but why were we not given that ability? It'd certainly be useful, and consistent, to be able to affect the texture at all three sets of control points instead of just the ends.

Wow, that's interesting and should definitely be useful, especially with terrain patches! I couldn't use it to make the arch faces align, but that much is to be expected, as the layouts of the patches are completely different. Is there any way to get rid of the drift that it does toward the front edge of the left patch, and instead keep it going with the original alignment? Either way, it's another cool tool for the toolbox. Note: I had a crash on resizing the camera window - I haven't reproduced it yet, so I'm not sure what may have caused it. I assume it's not related though.

Concerning this issue #82, this is what I could accomplish so far: It works currently with brushes only, I haven't looked yet at the patch code (this might be more complicated, but I don't know yet). The according GUI elements / buttons are still missing, but this is something related to the new Surface Inspector dialog that should come in the near future.

Damn! I got really excited when I read your second suggestion, almost positive it would work... but it didn't. :-/ The problem with single geometry comes if you want to be able to do more diverse things with it (like have it bend on the other axes too - like that guy that did the advanced arches map somewhere on d3world) or if you don't want a full arch. Or, when it's not even an arch (this was just a simplified example to make the request clear). For now at least, I can still open DoomEd and get the mirror alignment, if worse comes to worse. Also, there is the option to just twist and shift it around until I eventually get the right orientation by hand. Took me long enough before that I gave up though, and went to DoomEd. Is it really tough to get edge coords and continue from there on the next patch?

SneaksieDave, we better continue the texture flip conversion here: You posted these two images: But I still don't see what you're trying to accomplish here. In the first image (the 123456789 one) do you suggest that the texture should be continued on the second patch?

I always thought the ttlg forums were pretty civilized, aside from geting flamed when u use teh h4x0r speech, but I don't like that anyway, so I'm fine with that. Better stick to proper, readable english! I do hardly look into ttlg these days though. Since TDM, I lost interest in the TDS-deadend, so I mostly stayed around here.

You should be a member now. You should start reading here: http://forums.thedarkmod.com/index.php?showtopic=6694

I agree, the mapper certainly shouldn't be forced to create a brush if there is an alternative option. However the feature is useful if a mapper wants to specify in advance exactly how large the patch should be, just like when creating a light.

Moreover, it creates a patch that fits the size and location of the last selected brush (doesn't have to be selected anymore). So it gets created where you are actually working (I think this area is called "workzone", but I'm not quite sure. At least it gets created in the orthoview where you are currently looking at.

I think we're planning on keeping these forums going when TDM is released.

Yep, but it actually looks like the first has a problem too. I probably should have specified a thickness, so that it's easiest to see. It's hard to tell if it is warping down in the first pic (which would be much more troubling), or back toward the camera, but based on the known behavior, I assume it's back toward the camera. Instead of the normals being perpendicular to the surface, they're collapsing back toward the viewer. My original image above shows not just the before/after fix, but could also be seen as DR/DoomEd. The image on the right is what DoomEd builds. Probably the easiest way to see it is a square - all sides equal. Edit: In fact, looking at my original image and considering the basis for the original patch to be a square, and looking at the control points, it speaks to how it is built. It looks like two control points are placed on the endpoint edges, each half of the desired thickness inward (away from the surface), and then at the corner point, the same is done diagonally.

I think your second thickened patch is displaying the behaviour -- notice how it gets thinner in the middle and the lines in the "side wall" go diagonally. If it was extruded along the normal, I would expect both the start and end patches to be parallel at all points.

Ok, I just followed your instructions, but I didn't get a weird patch out of it. This is what I did: Created a cube: Clicked: Curve > Bevel, then deleted the cube: Then thickened the thing (first with thickness 16, then undid that one and thickened it with thickness 100): What did I wrong?

Ok, renamed. The new dialog is now on SVN and allows to choose whether the selected brush should be deleted from the scenegraph after patch creation (Is only clickable, if exactly one brush is selected):

OrbWeaver, I noticed that the map::countSelectedBrushes() method does not actually count the brushes only, but takes the patches into account too (it checks for Node_isPrimitive == true). This is ok I guess in the context of func_static creation (which can consist of patches as well), but I needed it to set the sensitivity of the "Remove selected Brushes" checkbox in the new patch creation dialog. Can I rename this method to countSelectedPrimitives() so that I can write another walker that only counts the brushes without patches?

Could you show me an example of such a patch, I'd like to look into that. I already though about taking a "mean" normal vector, as there are 4 available (at most, for a vertex surrounded by four nearest neighbours).

Thanks! Got it. Here's the result of my first official DarkRadiant thickened patch (there's a small issue which results in some distortion of it, but it looks like a simple problem - image is before/after a tiny amount of vertex manipulation): Will let you know if I come across any other issues of course.

Exactly. Two adjacent control vertices are taken into consideration for the normals, which allows the thickened counterpart to follow the shape of the source patch. @SneaksieDave: I will upload a new build for you, you can check it out soon.