Roblot
#11212 posted by :( on 2011/06/12 17:13:42
Well i try everything and i see everything and again same problem :(
Roblot
#11213 posted by :( on 2011/06/12 17:17:32
Man i delete the Arch and it works fine but how i can do arch's and curves when i try and maps just.....failed
Curves
#11214 posted by madfox on 2011/06/12 18:47:04
I tried the curves from czg in Quark but the possibiliy for skewing is rather detached.
From the first example everything is right
one
When I start skewing
two
happens and I'm broke. Quark starts warning for leaks whlile WC1.6 compiles well.
So I had to do the thing with substracting and this ends in bad lightning.
three
Thanks Rj
#11215 posted by necros on 2011/06/12 20:31:35
good to know at least that i haven't been missing something obvious. :)
for individual brushes i just use VM.. just a case of selecting all verts at one end and either dragging or nudging using the arrow keys
yeah, this is what i do. but it's a lot slower than just grabbing the edge and dragging it. in radiant, it's one step: click anywhere outside of the brush near the edge, and drag.
in wc it's multiple steps
select all the vertices, then click + drag.
also, WC's obsession with control points is annoying. i prefer radiant's 'click anywhere in this area' method of moving. i mean, obviously, vertex manip uses control points too. but you can avoid having to use it by having the ability to simply drag out faces of a brush.
to be fair, i'm still not as familiar with WC as i am with radiant, so i'm sure a bit of 'slowness' or clunky feelings i have for WC is still due to that, but even factoring that in, i still find radiant faster.
otoh, i do like how WC doesn't complain about a brush until later. radiant runs it's 'brush legality' checks while you're manip'ing vertices. it's technically more accurate since it'll never let you screw up, but it also stops you from making a shape that would be legal but requires moving through an illegal form first.
WC will just let you do whatever so in general, it's easier to make super complex geometry out of single brushes.
doom3's radiant is even worse for some reason, because it won't complain, but you can actually rip brushes apart (like, the faces become unconnected somehow). very weird.
MadFox
#11216 posted by JPL on 2011/06/12 21:23:48
It certainly comes from the "famous" floating point feature support that QuArK is suffering from...
Except if you have some time to waste, you can inspect all polygon corners' coordinates and try to realign it on grid.... but not sure whether it will solve the issue... though... experiment ;)
:( + Practice = :)
#11217 posted by roblot on 2011/06/13 00:05:52
Mans, you just need more practice.
:( + Practice = :)
#11218 posted by roblot on 2011/06/13 00:07:51
Mans, you just need more practice.
Sure
#11219 posted by madfox on 2011/06/13 06:55:55
One of the maps suffered leaks in Quark6.1, while starting it up with WC1.6 gave a good outcome. It only shows that with the same compilers the editor always is the weak link.
I just find it odd to see those examples and trying them out only ends up with peeling out the manual where I can find my purpose to the buttons. Sometimes they're there, others not.
#11220 posted by necros on 2011/06/13 08:16:24
the more i think about it, the less likely i think that the floating point stuff is the issue.
a little while ago, i found that qe3 worked better with floating point enabled. aguirre's bsp was fully able to cope with decimals with even the most complex tri-souping.
i think it might be that quark is mangling the brushes in some other way that may not be immediately obvious.
Is there a full guide somewhere to getting radiant set up and working for Quake? I'm curious to give it a try. I'm very comfortable with WC atm, but if fiddly manipulation is better in radiant it'd be nice.
For All Quark Users
#11222 posted by roblot on 2011/06/13 13:58:03
It's Quark's export to .map software code that is messin around wit your minds. It does not copy and paste the map coordinates from the .qrk file to .map
I opened func_city_04-13-11.zip in the Bsp editor with all brush coordinates exactly as would be seen in radiant/qe3. Then I opened the Quark revised func_city_04-15-11.zip. If you look at the alpha windows, which were not edited at all in Quark (only exported and saved), you'll see they are messed up. On top of that, Quark basically took quite a few on-the-grid brushes off the grid also. These files are in the Speedmapping Thread.
Wouldn't simple copy and paste code fix it?
Quark
#11223 posted by Drew on 2011/06/13 17:14:59
seems to be pretty shitty as a level editor. Who uses it? Madfox, trinca -- who else?
All The Noobs
#11224 posted by negke on 2011/06/13 17:25:04
JPL, too... Bring on the inquisition!
It seems it's a matter of proper configuring. The established Quark users here seem to have no problem with floats. So it's probably some bad default setting.
Most editors have a snap-to-grid function. This should take care of these things in one quick swipe - selecting the whole map and snap. Though there's still a small change some vertices might snap wrong and invalidate the whole brush.
#11225 posted by Spirit on 2011/06/13 17:57:35
Quark is the most user friendly and feature rich editor out there. Period.
It fails sometimes on non-cubic brushes though. It is also rather slow and Windows only.
I Use QuArK
#11226 posted by kaffikopp on 2011/06/13 18:08:45
I actually think it's a pretty good editor with a pleasant and user-friendly interface, and the tree-view is very handy, but because of some annoying quirks I'm contemplating on switching. Tried out WC with the Quake adapter but because of an extremely finicky setup (like needing Quake installed on the c: drive and I already have it installed on d:), I'm gonna try out radiant. Shame though, as the skew/vertex manipulation features are quite easy to handle in WC.
...although I still couldn't bloody figure out how to create those support beam things along a many-sided curve with correct width and perspective, the brushes always end up slightly disproportional and with an odd angle, even when using skew. It's fine and dandy when only working with 12-sided cylinders, but from 16+ it starts getting problematic.
#11227 posted by kaffikopp on 2011/06/13 18:22:05
All right, I finally figured out how to skew with QuArK, but how the hell do you skew a single brush? The bounding box with the middle selection handles that allows you to skew (like in this screenshot MadFox posted only appears when selecting multiple brushes.
Have You Tried Intalling It On The D:?
#11228 posted by RickyT33 on 2011/06/13 18:24:10
Worldcraft I mean. It's not a difficult editor to set up. I deleted the prgram All_wads_To_HLWads.exe in favour of using TexMex to convert wads to Half-Life format. It's worth downloading the Hammer 3.5 executable, and dropping that in place of the Worldcraft .exe.
But as much as the QuakeAdapter makes it easy, fast and convenient to get you started, there is nothing stopping you from running Worldcraft from any DIR. You can easily configure it, and although I'm sure at the time Quakeadapter was put together it's compilers were the best current compilers - well, they aren't anymore. I have long since replaced them with better compilers (with the exception of TXQBSP which is *THE* best compiler. evar.)
I compile my maps from the command prompt anyway. Worldcraft gives the full location of the wad files in the .map file header too, so you can export your .map file to anywhere on your HDD and compile it from there, and as long as you leave your wads where they were when you were building your map, the compiler will find them.
If I were you, I would try running Worldcraft again.....
And there's always .BSP editor........
If That's The Case
#11229 posted by necros on 2011/06/13 18:32:00
would copy pasting the same brush twice at the same spot, skewing and then deleting the spare work?
Yeah That Worked
#11230 posted by kaffikopp on 2011/06/13 18:50:39
Still didn't make it much easier to work with though unfortunately, as when I'm dragging vertices in one view the editor always seems to compensate for it, like here where I tried to align the vertices along the curve in the top view and the lower edge got dragged downwards. That was just an example image that I threw together to show what happens and not a serious attempt at creating a curve, but this is what happens no matter what I try, and skew didn't seem to work around this either. Oh well, time to try out WC again then I guess, where this is unproblematic...
#11231 posted by roblot on 2011/06/13 19:17:47
I think Quark is also a great editor, but has some purposely corrupt coding is in the export to .map - This problem is easy to solve with copy and paste. The arches in func_city_04-13-11 are set at 2 unit resolution, something trinca said he avoided. On export, Quark goes through "extra software mutilation code" to get to it's .map file.
So forget the float precision, Quark doesn't even let you get 2 unit precision on angled brushes.
So..,
#11232 posted by madfox on 2011/06/13 23:25:04
I work with Quark since it was an early Qmap version in the late 98, so I'm very contributed to it. Skewing with one brush only goes by setting angle of a brushside.
But then you miss gridclipping of course.
My simple outcome is when I make a map In Quark with complicated brushes the leak error grows.
When I import the same map into WC1.6 and it compiles well with the same compilers it reduces Quark in compare to the WC1.6.
I'm doing with QRadiant and it is a RTFM job to get familiar with.
My interest grow to BSP which has an update to 96, since I learned to know it in QBSP94b.
Berntsen:
#11233 posted by metlslime on 2011/06/14 23:47:47
sorry i didn't reply earlier, but it appears necros did a pretty good job of explaining everything you asked.
No Worries
#11234 posted by kaffikopp on 2011/06/15 01:53:23
Yeah necros got me on the right path (thanks again), just fiddling around with different techniques at the moment.
Also got Hammer 3.5 to work with Quake, had no idea it was even compatible, so thanks for the tip Ricky! Although I did encounter something strange... made a test map, saved as .map and it compiled fine, closed the editor and later when I opened the map again it was completely empty. I guess it's not much of a problem as I can save as .rmf just fine, just found it a bit odd.
And bear with me here, but how do you make the extra parameters for the compile tools work in Hammer? In the advanced compile menu I wrote "-soft -extra 4 -gate1" without the quotes as a parameter for $light_exe, but it doesn't seem to do anything. Light 1.43 by Bengt Jardrup.
I Think You Have To Put The Commands Inside The Quotes
#11235 posted by RickyT33 on 2011/06/15 02:17:06
I would keep to using the .rmf format rather than the .map format. The .rmf contains a lot more data than is outputted into the .map file, like vis-groups for example, as well as containing the extra texture information generated by the valve 220 protocol. This is a pain if you plan on using other editors to make your map, because the data seems to corrupt when loaded into editors which dont support the 220 protocol.
The good thing is that the Hammer editor's texture lock feature works really well - you can really speed up texture alignment because of it because you can clip, copy, paste and most importantly rotate as much as you like, and the textures stay aligned.
Correction:
#11236 posted by RickyT33 on 2011/06/15 02:22:27
You have to press F9 to compile your map from the editor, and that is where you add your commands. You have to press F9 then click on the button "expert".
|