Search the Community

Ok, I'll put that in, although I fear that may add some confusion, but I'll try it out and we'll see. I tried to keep as close as possible to this sample dialog from the HIG: http://developer.gnome.org/projects/gup/hi...ges/layout2.png Although this dialog doesn't follow the 6/12 rule either, because it has 5 pixels as distance between the entry fields and far more than 12 pixels for the left indentation. Additionally it's not always perfectly possible to keep that 12 pixel gap between the label and the according entry field, because if anything widenes the dialog window, the alignment gets screwed up. GTK can be a real pain to do correctly what one intends, this reminds me a bit of cross-browser css, but I'll try to do my best. "Natural" is possible to affect both brushes and patches (it would just apply the default scale to the brush, nothing more). "Axial" is not yet done for patches, but I could add that functionality. I planned to desensitise that button when a patch is selected. I think "Cycle CAP" is intended for texturing the end caps and works similar to "Axial", but I have to check the code. Maybe we could remove that one completely in favor of the mouse copy/paste tools. That makes sense, so I'll go that way and strip the patch inspector from the texturing controls.

I don't see any problems there, a couple of possible improvements though: * Use Up/Down arrows for the vertical scale/shift operations rather than Left/Right * Align widgets using the 6/12 rule from the HIG -- 6 pixel separation for related components (like up/down buttons), 12 pixels for non-related components (i.e the gaps between each line of controls). * I wonder if we can replace the "Brushes" and "Patches" button with single buttons that behave appropriately whether a brush or patch is selected. For example, perhaps "Axial" and "Natural" could be single control for both brushes and patches. Do we even know what "Cycle CAP" does? I have never figured out its purpose. * I would be tempted to say don't merge the patch vertex editing stuff in here, because this is currently a purely texture-based dialog, and adding in extra stuff that is not always applicable could confuse the issue. There is nothing wrong with having a separate patch editing dialog, the current problem is that it duplicates texture alignment functionality that should only exist in this dialog. Some more advanced/labour intensive ideas: * Use icons to illustrate each operation, such as a "Flip horizontal" icon on the appropriate button. This adds some colour to the dialog and helps you find the operation you need quickly. * Lay out the scale and shift operations in a North/South/East/West block with the scale factor in the middle (with nice big arrows on them). This would make it very easy to find the right button to move the texture in the direction you want. * Use a slider for angle, that runs between -180 and +180 (or 0 and 360, whichever is more appropriate). Dragging this slider would immediately rotate the texture and provide very quick and easy control over rotations. * As well as the NSEW shift arrows, provide a slider which runs from 0.0 to 1.0 and allows precise and real-time control over the UV offset. This would obviously have to be updated when the world-space shift buttons were clicked in order to keep it in sync.

Ah I see - you mean that the humans the robots took were already used to a certain way of life. That's not what I was getting at, so I have to admit the Matrix was a bad example What I meant was what I was saying earlier. I just thought the Matrix example was similar, but its not. So back to Orb's statement - I think its a bit pessemistic to say the god would be evil or indifferent, because - what if things the way they are now are just the way they're supposed to be? (Because of what I was saying about "perfectness" not being engaging enough - here; http://forums.thedarkmod.com/index.php?s=&am...ost&p=99787 and here, in my reply to Splatzz http://forums.thedarkmod.com/index.php?s=&am...st&p=100309 they are anchored links, they jump directly to the post I'm referring to)

Okay here we go. The following are items I've learned to use the system to do, and the last one is one I haven't figured out yet (assuming a way exists). If not, that's what's being requested. That, and flipX, flipY were really the only requests that have been made, aside from the alt-MMB bugfix. I'm certainly not asking that all cases be covered; just these fundamental, important ones. Basically it all comes down to a way to align patches similar to that in the fourth example. If anyone thinks of more, please speak up. Problem 1: Align vaulting to ceiling http://img128.imageshack.us/my.php?image=patchtex1gs8.jpg Solution: MMB on ceiling brush, then shift-MMB on patch. Being near the edge of the brush helps prevent distortion. http://img266.imageshack.us/my.php?image=patchtex2tj0.jpg Problem 2: Align vaulting to vaulting http://img266.imageshack.us/my.php?image=patchtex3mh9.jpg MMB brush, shift-MMB patch: expected result, but not really useful here http://img70.imageshack.us/my.php?image=patchtex4cj3.jpg Rotate the above 90 degrees: not a great result, could be better http://img266.imageshack.us/my.php?image=patchtex5sb1.jpg Solution: Not a perfect solution, but it looks best in my opinion - MMB patch, shift-MMB patch2 (transfers textures), alt-MMB patch (transfers alignment). Minor tweaking and you're done. http://img128.imageshack.us/my.php?image=patchtex6cp9.jpg Problem 3: Align inside of arch http://img266.imageshack.us/my.php?image=patchtex7ev8.jpg Solution: MMB ceiling brush, shift-MMB each patch If you're close enough to the edge of the ceiling, texture is aligned and continuous (not mirrored) across the two patches. http://img70.imageshack.us/my.php?image=patchtex8ms9.jpg If near the center of the ceiling/not near an edge, you'll get mirrored alignment. http://img128.imageshack.us/my.php?image=patchtex9pd5.jpg Both are considered useful. Problem 4: Align front face of arch This is the case of alignment of patch from neighboring patch. http://img266.imageshack.us/my.php?image=patchtex10vx4.jpg For this, I have not yet found a good solution. -MMB brush, then both patches - not aligned -FlipX and/or FlipY of the above - not aligned -MMB patch1 -> shift MMB followed by alt-MMB patch 2 - not aligned -Flipping above - not aligned -Moving toward edge of ceiling brush didn't help -Natural, and then pasting the texture from texture inspector didn't help Each result was some variation of the same problem: http://img128.imageshack.us/my.php?image=patchtex11pa0.jpg Here it is in DoomEd, Natural setting (resized). It's basically continuous inverted, not mirrored. It's not perfect, but in the case of this texture, it works. http://img128.imageshack.us/my.php?image=patchtex12mt9.jpg What I'm hoping is possible in DarkRadiant is behavior such that the rightmost coords of the texture on the left patch can be used to determine the leftmost coords of the texture on the right patch, and the texture continues with the same alignment from there.

Agreed, it's better than in a bugtracker entry. Yes, that's exactly what I am talking about - that it picks up some coordinate from the left patch and continuous from that point on the right patch, so the transition is seamless. Just as if they were two coplanar brushes right next to each other. It seems the options are: 1. no alignment at all 2. mirrored alignment (this can be achieved by copying a patch and rotating it) 3. continuous alignment - only possible through having a special surface all patches can be pasted natural from, or the functionality requested here. So yes, for this case, this can be done by just pasting natural both from the ceiling brush, but this is more for general cases not covered by this simplistic example. If there is no plane to take a suitable paste natural from, or the patches are different, or whatever else authors might come up with, being able to pick up the rightmost edge from the left patch, and continue it in the same direction, same orientation, as the leftmost edge of the right patch, that would be golden. I'm planning to put together pics for the other thread which will present and inquire. Edit: anyway this was about flipping, sorry for getting sidetracked. I'm not clear how the coords are not shifted on flipX or flipY. It seems like they're not. I'm trying to think of a test case to prove it either way; do you have one?

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.

I am making more textures... http://www.ttlg.com/forums/showthread.php?...226#post1558226 (Yes, they are 1024s : )

I played around a bit with copying over the textures from other patches (similar to the way the PasteNatural works with brush>patch), this is issue #116: Before: After pasting the texture from the left to the right patch: What's actually happening is not that perfect as it may seem. The requirements for this to work are currently that the patches have to share at least one control vertex and the target patch has to be textured very similar to the source patch (this means that both are stretched and rotated the same way, such that a simple texture shift is enough to make the transition seamless). The distance in texture space is calculated and susbtracted from every target control vertex, hence the difference disappears for the shared control vertices. It's some kind of assistant that helps shifting the texture into the right position. I'll look into it a bit more deeply tomorrow and see what I can come up with.

To be honest, I find it a bit stupid to force the mapper to create a brush first. But I think that this workflow should be supported to facilitate the migration from DoomEdit to DarkRadiant. @New Horizon: Was there anything missing in the tutorial? Should I add something?

Just tried it. So if you really need a perfectly sized patch, you could draw the brush, delete it, and then create a patch out of nothingness. Interesting, I did not know that.

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.

Until I read this comment, I was under the impression that the only way to create a patch was from a brush. I just tested, and apparently you can create a simple patch mesh from nothing, which just creates a square patch at the origin.

For what types do you mean exactly? You mean the end caps/inverted bevels? (Besides, I never needed any brush to create a patch, therefore I never missed that option. I never quite understood why I'd have to create a brush first and then a patch out of it, if I can create it from nothing in the first place.)

Huh, the personification of the forums appears at last! Happy birthday, dude!

I noticed that the simple patch mesh has the option to remove the originating brush (entry #120 - I didn't want to just open it back up since it's not my entry, and maybe you are done with it). Can we have that ability for all types? Or, since the others don't include an intermediate dialog, could it be a global user preference? I find that I never need the brush after making a patch from it.

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

I thought that torch versions of animations were being specified using the animation override functionality I developed. See http://forums.thedarkmod.com/index.php?showtopic=5201 (Edit: The contents of that post are now on the wiki as well, here: http://www.thirdfilms.com/darkwiki/index.p...ttached_objects .) If so, it doesn't really matter whether you use a prefix or a suffix from the POV of coders. Do whichever is more convenient for you. As for different styles of animations for different AIs (peasants etc.), wouldn't you just create a new .def file for the other AI?

Not a bug, this is correct behaviour, because the content of the texture clipboard gets overwritten when you click on the brush to pick up the texture. For the Alt-MMB to work again, you'll have to MMB on the source patch again to pick it up. It may be worth to point out that not the actual texture coordinates get saved in the clipboard, but a reference to the source brush/patch. It depends on the destination object, what information is drawn from the sources. Glad that helped, I already committed the changes to SVN.

Thanks! I was not looking forward to the full process (at this time at least). [Edit: note that everything below is before downloading the new build] Who am I kidding about stepping off though... I'm obsessed. I think I just nailed one of these down to my relief. Two doorway arches Open DR fresh between each load of the map. Case #1 1. MMB to pick up the right (yellow) arch texture (unsupported) and the coords, 2. Shift-MMB the left arches Result: They become textured with the right texture, three stones high. So, it carries the texture, but not the coords. As stated. But it almost works, so it's tempting. Case #2 (reload DR) 1. MMB the rightmost right arch to pick up the coords 2. Alt-MMB the rightmost left arch to paste the coords. 3. Shift-MMB to paste the texture (unsupported? user could also get the texture from the Texture Inspector) Result: Texture is not transferred (if I understand correctly, this is correct behavior - Alt is coords only), but the coords are. Nice. Success! Learned about user error: Alt is for coords only, and for now at least, shift and ctrl are not intended for patch-patch operations Learned actual bug (I think): Alt is apparently not cleared for use again until DR is restarted (you hinted at this above), though there is some weirdness; I can copy each side of the arch, so I can get away with it twice, but as soon as I attempt a shift or ctrl-MMB, I can no longer copy coords with Alt. I don't know if this means it breaks the functionality, or if it breaks the patch somehow (probably the former). How to see this: MMB any of the brush pillars, then shift-MMB the arch. Now, texture coords can no longer be pasted from the other arches. Attempting to do so has no effect. I'll make some official entries about this and the requests at some point today.

Okay that probably explains much. Make sure to see my previous post and edit (we're posting at the same time ) where I indicate some possible real issue with the Shift-MMB from a brush mode. That and the alt-mmb acting wonky above it might be the only 'real' (or at least serious) bugs I guess. I'd definitely like to be able to compile, assuming it's not some giant ordeal... Please say there's some tiny command line compiler and I can use WinCVS to get the source? I don't have any microsoft compilers installed on this system and would not like to (although, I suppose I could see about putting it on my work/test machine). Edit: I remember that post; it was about seeking a corner, right? Will that cause the texture to warp if the source brush is small, but not if the brush is large? Anyway to get around that programmatically? (the mapper could just oversize the brush, clone the texture, and then downsize the brush again). The second issue in the edit might be the same, but it's almost certainly more serious in result, and I'm not sure how a mapper could fix that. Edit: workaround: user can make a cut in the brush at the patch edge and texture it again to fix the warp.

This can be explained by the way the Shift-MMB searches for nearby brush winding vertices to retrieve the texture coordinates from that point. I already explained that behaviour with a picture in another post, I'm pretty sure this applies here as well?

First of all, thanks for testing, SneaksieDave, this is appreciated. I think most part of the undefined behaviour can be explained easily: if you click on any brush during DarkRadiant runtime, the Face you clicked on is remembered (in some sort of "Texture Clipboard"). I just checked in the code and discovered, that the face is even remembered if you load an entirely new map (resulting in a nice crash if you try to paste the texture onto a patch ;-)). I will fix this and I believe we have to postpone further testing, as most of the weird stuff will presumably be gone after my changes. SneaksieDave, would you be willing to setup a DarkRadiant compile environment so that you can compile directly from source? This way you wouldn't have to wait till the next release and we could carry on testing. Additionally, I will have to take care that users get more feedback than they currently do, as everything else is inferior design, I have to admit.

greebo: check this one out! http://208.49.149.118/thedarkmod/maps/5arch.zip The curvature on those patches results from a normal flat brush texture (shift-MMB). If I drag the ceiling brush larger, the curvature goes away next time the texture is applied. Some kind of math problem? http://img463.imageshack.us/my.php?image=flatwarpuz4.jpg Edit: here's another weird one. All four of these patches are textured exactly the same: with shift-MMB copied from the ceiling. However, one of the four (the one all the way to the right) is twisted, and I can't think of a reason why. This was after completely restarting DR. http://208.49.149.118/thedarkmod/maps/6arch.zip

Do you intend to copy the texture coordinates only? So that a 3x5 patch could copy its texturing from another 3x5 patch, but the actual geometry of these two is different? If yes, this feature already exists, if not, I still don't get what you mean here. I would try to texture the left one (as you did already) and then apply the same shader to the right patch. Then I'd clone the texture coordinates with Alt-MMB to the right one. If it still doesn't fit, we now have the flip texture commands as well. Please give me the map, I'll try to do it if I have some spare time. I think I know what you experience here, but I'm not entirely sure. Keep in mind that the Shift-MMB texture pasting does not work for the constellation patch>>patch (you can't project a patch onto another in a straight-forward, well defined way as it is possible with brush face planes). You can do some copying and pasting using brushes as "middlemen", but this really depends on the situation. Please send me the map if you want me to investigate this. Well, where is the point in implementing a feature as substitution for something that's done in 3 secs? Why not do it this way in the first place?

I guess it depends on how far you guys are willing to go. IMO, having it always prioritize (as with DoomEd) non-brush entity selection first is most desirable. But, assuming this change comes with a hotkey toggle(?), it's definitely a nice and needed stand-in, in the meantime (or in the event that the full support never makes it in). Maybe the 'full' version is another for the suspended pile? Hopefully there's a way to distinguish 'suspendeds' so that they don't get lost with 'closeds'?