Hm..
#5658 posted by necros on 2006/12/04 14:16:27
can you force qbsp to split the brush the way you want by first shaping the brushes in the proper pattern, then doing a texture shift of 1 unit difference on each brush so that qbsp doesn't combine them?
Just For Fun
#5659 posted by Mike Woodham on 2006/12/04 14:19:36
I removed the 3 brushes that gave me a curved corner, and this was the result:
---- WriteBSPFile ----
Before After
10568 10559 planes
32563 32164 vertexes
13300 13015 nodes
3107 3106 texinfo
25959 25429 faces
24486 25105 clipnodes
7356 7261 leafs
32165 31634 marksurfaces
119337 117378 surfedges
60330 59343 edges
145 145 textures
Increased clipnodes and decreased marksurfaces.
http://img71.imageshack.us/img71/8720/marksurfaces3ys1.jpg
If anyone has not yet fallen asleep, what have we learned here?
No, I don't know either. Oh well; plug on, plug on.
Necros
#5660 posted by Mike Woodham on 2006/12/04 14:28:47
The thing is that these are pretty much single brushes: the wall behind the ammo is one, the ceiling is one the two faces are one etc.
Is there an optimum size that qbsp likes to find? (although I would hate to map to specific sized brushes, so perhaps I don't want to know that)
I'm just going drop some more monsters in and then call it a day.
TreeQBSP Users
#5661 posted by aguirRe on 2006/12/04 14:34:33
Thanks to ORL, I've found a bug in Tree when having >32k clipnodes that corrupts the clipnode information.
Hopefully I've fixed the bug now, but I recommend switching to TxQBSP permanently as it doesn't have this bug.
AguirRe
#5662 posted by negke on 2006/12/04 23:36:03
but there is no way to have opaque water and solid sky with txqbsp...
AguirRe
#5663 posted by Spirit on 2006/12/05 00:08:06
TxQBSP even for QuArK users? I remember TreeQBSP was recommended for us (if I am not wrong).
Spirit
#5664 posted by JPL on 2006/12/05 00:49:16
TxQBSP run fine even with QuArK... It is just an external program to call from QuArK, and has nothing to do with the editor. Maybe only the saved map format could have an effect (i.e V220, etc..) and I'm not sure about that point.
FYI, I'm currently using QuArK 6.5.0-alpha2 with aguirRe's TxQBSP, aguirRe's VIS, and a aguirRe's modified TyrLight ... and all the stuff works fine ...
#5665 posted by Trinca on 2006/12/05 01:25:55
i got same as JPL but QuArK 6.5.0-alpha8 new version of quark :\ suck :((( dont compile my base map :( give lots of errors :( leaks everywehere and say stuff like maxsufarces limit bla bla bla :) errrr i will keep this version a lottttttttttt
Trinca
#5666 posted by Spirit on 2006/12/05 01:32:42
There was something wrong with the new version, they released a bugfixed build.
JPL: It was something with the map format QuArK writes, maybe with the .12345 floating point stuff or something. Dunno.
#5667 posted by Trinca on 2006/12/05 01:36:15
thks Spirit_ i think i will stick to this version a litle wile :) is perfect for me!!!
;) i dont have problems at all, despist other poeple say Quark owns!
;o)
ban worldcraft :p
TxQBSP
#5668 posted by aguirRe on 2006/12/05 01:49:43
can have opaque liquids, just add -nowatervis. I don't know what you mean by solid sky, both compilers use CONTENTS_SKY for sky.
Tx was originally the *only* compiler for QuArK so it'd better work with it ... ;)
Door Sounds
#5669 posted by Mike Woodham on 2006/12/06 02:16:14
I haven't full vis'd my map yet and get plenty of packet overflows, which I'm not too concerned about.
But would this also account for occasional door opening sounds playing continuously: not every door and not every time?
Yeah,,,
#5670 posted by metlslime on 2006/12/06 02:28:04
packet overflows often result in dropped sounds
Metlslime
#5671 posted by Ekim Mahdoow on 2006/12/06 02:53:59
Thanks, I'll carry on not being too concerned then.
Rocks Rock
#5672 posted by efdat on 2006/12/10 00:48:05
just a short question: does anyone know a good tutorial on making good looking rocks? (i don't mean terrain via triangle method, which i already use) i mean rocks like in kona's maps for example. thanx
More Qc
#5673 posted by Mike Woodham on 2006/12/10 10:50:13
How might I emulate ai_forward(x); without using the walkmove function?
I want to move a monster in its forward direction x units where the direction has to be found AND he may be stuck in a wall (which is where the walkmove function (correctly) exits with FALSE).
I guess I can change self.origin but am stumped on how to calculate the new origin taking an unknown direction into account.
Any offers?
.
#5674 posted by necros on 2006/12/10 10:56:50
if you set the movetype to MOVETYPE_NOCLIP, does it still abort? with that movetype, the monster wouldn't collide with anything, so walkmove would possibly not abort?
Collision Of Your New Monster
#5675 posted by Preach on 2006/12/10 11:09:55
You've said that the monster may be stuck in a wall at the start of the move, but how should it end the move? Is it ok for the monster to, for instance, be stuck inside another wall? Or inside other entities, possibly including the player? If you're doing some kind of ghostlike creature, that doesn't care about intersecting anything, then the crude way to emulate walkmove would be
makevectors(self.angles);
setorigin(self, self.origin + v_forward * x);
but that's going to do no collision checking, and also move your monster in discrete steps. Of course, in basic quake walkmove moves a monster in discrete steps, but in engines with motion interpolation this usually gets smoothed out. So a better way might be:
makevectors(self.angles);
self.velocity = 0.1 * x * v_forward;
assuming that the monster is going to think in 0.1 seconds time. You must make sure that the following think function either resets the velocity or gives it a new one.
Both of these functions are going to plow the monster straight forwards, so make sure they face the right way first(possibly with ai_face();)
For the velocity one you'll also need to give the monster a movetype that accepts velocity(eg MOVETYPE_NOCLIP). Finally, these functions don't think about the vertical, and the monster won't follow a floor(how could it if it's in a wall...). So there's still a lot to think about.
Necros
#5676 posted by Mike Woodham on 2006/12/10 11:17:54
Yes, I did try changing the movetype but the walkmove function ignores that. I can't fault that as once the game is underway you wouldn't expect to find a monster in a wall.
.
#5677 posted by necros on 2006/12/10 11:29:09
what exactly is needed? when you say it needs to find a direction, you mean it needs to be using AI to track towards the player?
Append:
#5678 posted by necros on 2006/12/10 11:30:10
if you just want it to move forward in whatever direction it's facing, preach's method will work absolutely fine, btw.
Preach
#5679 posted by Mike Woodham on 2006/12/10 11:32:18
I can ensure that the monster will move into clear space and that he will be on the floor even if he is partly in a wall, and I only want him to move in his forward direction. I can also ensure that he will not collide with either the player or another monster while he is moving.
I will move him only one or two units per animation frame and I have time to ensure that his animation will be complete before any interaction is required.
I'll play with the setorigin version and let you know how I get on.
Thanks both of you.
Hey Efdat,
#5680 posted by HeadThump on 2006/12/11 08:41:22
your inquiry kind of got lost up there. I assume you mean the effect Kona commonly uses that blends rock material with building surfaces. This is done the same way that landscapes are handled in Radiant (without the terragen plug-in), except using a vertical surface instead of a horizontal and the end is tapered where you join the surfaces.
I recall a tutorial being linked on QeRadiant.com on how to accomplish this technique, but the site that I was looking (leaf-node) for is no longer available.
The way it is accomplished in Radiant (doesn't work in 1.5, you have to use
earlier versions) though is to make a square or rectangle and duplicate it.
Point your cursor on the side you want to manipulate on the duplicate block, press the left mouse button and cntrl key together and pull in the direction you want it to go. From there it is a matter of aligning several blocks together in a pleasing manner.
HeadThumb
#5681 posted by efdat on 2006/12/11 14:14:04
thanks, i'm gonna try to port those instructions to QuESt (the good old :) i'm afraid that that's the way i'm already doing it (vertical triangles) and i simply have a lack of creative imagination for rock forms. i often have problems with working from a simple brush to natural forms. i thought there might be some kind of standard method that could help me there...
Efdat
Don't expect too much from yourself. You don't have to use too many triangles to make it look good. Use pretty large triangles. Make some wedge-shaped faces and some pentangle-shaped... some rock pillars... make some slanted floors and ceilings... just no 90 degree angles. If there are places where the seams look bad, cover it up with a pillar or something. Let the textures and lighting do the work; don't make your rock too detailed and don't light it up like a Yule tree. Break up walls horizontally or vertically into several brushes. Another idea is to build a framework of pillars and iron beams, and put the rock between those. It will look as if the pillars are set into the rock. Small, shallow pools of water are helpful to cover up less-than-imaginative rock formations, too.
I'm making rocks atm for my dm4 remake (I settled on mine theme) and I have those problems a lot.
Mine levels in Q2/Ground zero are really pretty inspiring. I often wonder how little you can get away with.
|