Bug that renders Constructor useless

#1 That looks like it is snapping to the grid. The only thing I can say is it's usually best to avoid vertex editing, but to instead use slicing and the Size Bounds tool. But that aside, If you turn off grid snapping it should work.

#2 Doesn't messing with corner verts create malformed brushes in any BSP editor? Unless you even out the other side to make it more BSP friendly.

#3 Knife/slice that sucker instead of messing with verts, or rotate/transform the face itself. Vertices are tricksome beasts. "Snap to grid" can sometimes be your enemy. Have you tried manually editing the position(s) with the transform tool instead of the axis gizmo?

#4 Vertex editing works great in QUARK, so i had become accustom to useing it. Bringing that experience to Constructor, have never caused me any problems. But be sure to leave grid snapping turned ON if your vert editing in Constructor, least your model turns on its creator someplace down the road. If you find the grid snapping pissing you off, set it to as low as 2. When building BSP its never a good idea to turn off the grid. And if your brush is not aligned with the grid your model will probably fail someplace later as it grows more complex.

#5 Vertex editing should not have to be avoidable- it should merely be fixed! Slicing it and editing the verticies positions with the transform tool are other ways to do it that produce the same end result, so using the axis gizmo doesn't create malformed brushes... And anyways, using the transform tool does the exact same thing. And knifing/slicing it is pretty impossible to do as well considering the tool works less than 5% of the time.. it generally only works on the z axis, but that may not be the axis I need sliced.

So, stop trying to rationalize this and give me alternate methods, Quark can do it perfectly, just accept it for a bug, and hopefully it can be fixed in the next version ;) Until then, I cannot use constructor because plain and simple, there really is no way around this bug. Jaimi, I would also point you in the direction of it being related to the snap to grid function, because turning it off stops this from happening: I do need it to snap, though, so..

#6

Quote:And knifing/slicing it is pretty impossible to do as well considering the tool works less than 5% of the time.

Sorry, but they work all of the time for me. I actually use Slice more often than any other tool or CSG operation available

I don't think anyone was trying to rationalize anything, I know I was only trying to suggest a possible workaround -- your "alternate methods". I personally can't duplicate the results shown in your video -- maybe it's a Mac version problem? If you use the same decimal increments for everything when using the Transform tool then you shouldn't need to use "Snap to grid", I hardly ever have it turned on myself.

Despite it's occasional quirks Constructor has worked great for me, more so than the headache that Quark left me with, but then we all need to find and use the tools that work the best for each of us.

#7 Yikes, talk about being blunt...

Its not a 'bug' I do Vertex Editing with Constructor all the time, and never experience what you mention unless the brush is off the grid. The funny thing with Constructor is sometimes you can have a brush at .00001 off the grid, and Constructor will round it UP not down. I assume this is to keep all other verts in convex alignment.

A question, being i cant see the brush your working on in the other view ports from the video; are any of the other corners previously vertex edited? Is it a rectangle or wedge shape?

On a side note, if you know QUARK, use it for building geometry, and Constructor for 'fix up' and exporting. Is what i do, just because I have used QUARK for near 10 years now. I still find many of Constructors features very useful, so do not mind switching to Constructor to finish up my BSP work.

#8 It happens to me in windows 1.0.51 as well. For me, it's the opposite: constructor has been a nightmare, I can't believe I still use it some of the time. It fails at the simplest of things. Well, I use it mostly because I'm in mac a lot of the time =p

#9 Sorry i edited my post right as you posted, so will reiterate my question for clarity:


A question, being i cant see the brush your working on in the other view ports from the video; are any of the other corners previously vertex edited? Is it a rectangle or wedge shape?


And i agree, I find building geometry much easier in QUARK, but Constructor makes placing lights, positioning textures and exporting so very easy.

#10 @Caylo: It is rectangular. Looking in the .map, all the verticies coordinates are whole numbers. In the next release, perhaps the brush reset tool can fix the problem, because I tried vertex editing on a newly created brush and it worked just fine. I guess for now I'll just delete and remake all the brushes that are doing this. Odd.

UPDATE: I think I figured out when/why the bug occurs. It seems to occur when the actual brush's position does not line up with the grid. I am currently fixing up another builder's map, and let me just say everything is messed up. I redid a lot of it, thinking that would fix it, however in the process I had to make .001 adjustments to the x/y/z coordinates to line it up. Thus, it bugged out. However, if the exact same brush is lined up with the brush grid, vertex editing works just fine. Can this issue be fixed in the next build? I know a lot of it is the builder's fault, but Constructor is still to blame for messing up, regardless.

#11 'It seems to occur when the actual brush's position does not line up with the grid'
Isnt that what was already suggested?
And how is it Constructor at fault?

#12 Not specifically, no. You thought it could cause errors later on when it grows more complex, but that's all. Constructor is at fault because the two problems are unrelated- just because a brush is not snapped to the grid does not mean that all the tools to modify the verticies should break..

#13 @PerishingFlames - It's just snapping the vertexes to the grid. Not trying to be snarky, but what do you want it to do - use relative grid coordinates? That would seem to be more problematic, as then each brush would have trouble lining up. Perhaps being able to disable snapping on the various axis?

#14 "Perhaps being able to disable snapping on the various axis?"

Indeed. =) I would just figure that it would only move the verticies on the axis I am moving it on.

#15 "I would just figure that it would only move the verticies on the axis I am moving it on." is what it does, unless doing so force the brush to be non convex, is when it auto corrects the problem.

#16 ..Anyways =p

Sorry if it sounds like I'm attacking anyone- I just don't understand why it was made as it is. In my mind, moving brushes should snap to the universal grid (as it does); however, moving verticies should snap as if the actual brush were a grid (a corner is basically made the new origin), thus the issue I am having would not occur. Does this seem logical to you guys too? I don't see any reasons why one would want moving verticies to always snap to the universal grid if the brush itself is not aligned on the grid. It's basically win-win, because if all brushes align to the grid, nothing is changed, really.

So, please forgive me for calling it a bug. It is more like a lack of a beneficial feature.

#17 Ok, I have this fixed in a kind of weird way. It doesn't snap off axis now, but it does constrain the move to grid units (but not to the grid). eg - if your vertex is at 0.25,1,1 and your snap is 1, then moving on the x Axis will move it to 1.25,1,1.

Constraining to the grid will take me a little extra time, but should be doable.

#18 That's exactly right. It should constrain the move amounts to the grid units, but not the universal grid.

#19 My only concern with constraining to a local grid is if we don't constrain to the universal grid, then it's harder to line things up. Perhaps I should make it so the behavior is selectable, but that means a UI change, and that will be much more complicated.

#20 Would that only apply if you are doing the equivalent of moving an entire face? I don't see how that would complicate things if you are only moving one edge (two verticies), basically to delete that face (think triangular prism).