Quark doesn't mess up brushes on non-90� rotation. As that tutorial in particular shows it works fine, but wouldn't work in any editor I know - Radiant, WC or BSP - the rotated brushes would be slightly distorted and unaligned. Apparently Quark has better precision.
Also Quark has 3-point float texture coordinates keeping the textures aligned even with rotation.
I'm not a quark guy, don't know what else it does better. 

is also very well implemented. 

You're talking about two different things. I'm not sure about BSP, but neither WC nor Radiant support floating point coordinates at all. That's why brushes get distorted when you rotate them.

Quark allows floats for the plane points that define a plane, but that comes with its own set of problems. It can cause microleaks. It's not a problem for pipes, but as soon as you have brushes with floating point coordinates which are supposed to seal the map, you can run into all sorts of problems. But maybe Quark fixes these problems somehow?

The texture alignment thing is actually because Quark implements the Valve 220 map format, which later versions of WC also support. 

and that's all I'm going to say about that.

When I started this map I made a promise to myself that I wouldn't exceed any of the normal Quake engine limits. I figured if I had no limits, I'd probably never finish the map (been working on it since 2007, so maybe that logic was flawed).

I've been re-texturing the map and in the process I made a few (very few) changes to the brush work. I'm absolutely certain that the changes reduced the number of actual brushes and visible faces, but the marksurfaces increased from 31763 to 31892. That's over 100! I only changed like 6 brushes. Very annoying.

Some adjustments to the geometry are unavoidable in order to work with the new textures, and I'm probably less than halfway done at this point. I sure hope I don't hit the limit before I finish the re-texturing. 

I think the issue is that the number of marksurfaces can be affected by the order in which brushes are compiled into the map. It's an unstable algorithm. Deleting a brush might move another one higher up the compile limit, where it doesn't fit as efficiently.

Has anyone ever tried permuting the order of the brushes in the compiler, either according to some design (like sorting on the x axis or largest to smallest volume) or even randomly? Given how much faster bsp is than vis, I'm sure that running the former a few dozen times with different orderings would not be a big burden. If you have a target like marksurfaces in mind, you can then take the ordering which maximises it.

I suppose what with the map format being basically text, you could even do it with some kind of script. Generate a bunch of permuted map files, compile them all in turn, and keep the one with the best output... 

Yes, the order seems to matter. Already ranted about this for my MCE map. There were times where I had to move newly inserted brushes further up the list to bring the count under the limit. But it's also about the brushes' 'relationship' between one another, so to speak.
For, at other times, moving the monster teleporter room up and down in 8-unit steps would influence the marksurfaces.

Even supposedly neat or clean brushwork sometimes turns out to be counterproductive in this sense. It's really strange and really annoying.

The QBSP in rebb's BJP mod features an experimental switch that changes the algorithm somewhat which can reduce the marksurface count considerably. In my case, it was around 1000 lower - I didn't notice any issues this may have introduced. 

that -forcegoodtree switch you mean?
seems to work. 

 

hi, not the proper thread but haven't found any better

Quake Gpl exploit for my own commercial game:

1)what if I use Quake original �knight� model base and animations(idle,stand,attack,..) on my own model ??
frame coordinates numbers are proprietary assets?!

2)And, a bit paranoic I know, should I delete original Quake references (frame names, monster names, sound wav,..) from .qc files ??

ps:
of course with my game I would do myself all graphic assets(monsters,textures,levels)

tHaNk 

One quick question. How do i make a liquid brush that moves, like the one at the start map of Scourge of Armagon?

Everything i tried until now makes the brush solid. 

1)if you only change the tex set and keep original animations or even base models, I don't think so.
If you make your own mmonsterarium, own animations and textures, why not

2)For code I think it smart to write your own, rather than keeping originals.
New monsters are reliable when standing on own ground.

ps:
don't forget your own weapons and callibration. 

First level of Scourge Of Armagon - The Pumping Station -

Tell me where are the liquid brushes that move? 

it's one of Hipnotic's feathers in the qc.
you can use it by using the progs.dat from the Scourge of Armagon,
or be clever and extract it from the hipnotic.qc and use it in your own mod.

Source Scourge Of Armagon => hipnotic.qc
http://quakeone.com/navigator/
download the Hipnotic DevKit. 

all you need is the HIPWATER.QC and add it to your own qc file.

If you open the start.bsp you can see it added as:
model func_bobbingwater 

But for now i'll have to pass on using it. I'm an almost complete newbie, the hipnotic.fgd that i got from Quaketastic isn't loaded by WC, and this is for SMP_170, and i'm short with time already.

For the next time i promise that i'll check better the list of entities in the Forge, that entity is there and explained.

Madfox, check 12914 again, i said start map, not hip1m1 map. :) 

/*QUAKED func_bobbingwater (0 .5 .8) ?
Used to emulate water. To use, create a thin water brush and center it
on the water line of the body of water to bob. The amount of the bob
is the depth of the brush.

The hipnotic func_bobbingwater QC code is NOT moving water. You can create moving liquids but you will need a special QC/entity and extra functions in the client.qc file. 

if I wanted to stagger when monsters teleported in would I be best using trigger relay or something? I tried putting a delay key on trigger_teleport but it didn't seem to work :-/ 

I have a really complicated way of teleporting monsters into a fight in the map I'm working on. They're on a door that moves sideways slowly when triggered and they're separated by small walls that keep them from moving. As the door slides out from under them, they fall into the teleporter brush. Sounds complicated but I can teleport in pretty much any number of monsters with an adjustable delay using just 4 entities. Can be tricky to make sure they don't telefrag each other though because they all go to the same teleport destination. It could be set up to use multiple teleports though. 

@Cocerello - I compiled the hipwater.qc file with the bobbing thing, and original Q1 v106Qqc a new progs.dat.
I made a map with
classname func_bobbingwater
and copied a polyhedron tex +water02 in it.
It works fine and you can find the progs.dat down under.

@Sock - I'm not sure what you mean?
I compiled the hipwater.qc with old v106qc and proqcc, and played with a classname func_bobbingwater, and all goes fine.

you can find the hipwater progs.dat here 

I used the Pox Extras moving water in FMB-BDG2 that I released recently, and it was quite effective for giving the effect of flooding an area. There were some issues regarding viewing the surface from within the moving brush i.e. when you're swimming under the water, but this was eventually fixed within the map quite easily.

Search for 'moving water' in the Mapping Help thread for some details. 

@MadFox, func_bobbingwater is not a liquid, it is just a moving brush model with a liquid texture. If the player touches this entity they will fall through it.

@Mike, This is why I wanted to see your qc source, I was curious to know what stuff you used. I had a look at the Pox stuff and the func_water is very interesting. I like the idea of switching gravity to emulate being inside of a liquid, I have a different solution luckily! :) 

Is great, we included it in RMQ as well.

func_watertrain and func_water not only work, but also have other controls like giving the player drag or force (flowing river) and a custom c-shift for mud / blood / whatever. 

Sure, the pox mod has these advantages also.

But it doesn't have the easy-way of extracting one qc file and add it to your own. At least there are three other files involved, so the tweaking gets harder.

I used the func_movewater in several maps but it only works for small sized brushes.
Also sad the watertexture doesn't animate.
I made a special texture for it.

Adding the pox mod to my own map included a large quantum of other funcs I didn't need.

And afterall.., I got curious after Cocerello's question and then I started investigating.

Didn't knew the water effect of the hipwater.qc was only a fake for eyecandy. 

In the original Quake they used a bunch of trigger relays with delays (in e1m7 for the gibs fountain effect in the episode closing scene). To see it being used you can download the released map sources from Romero and see how they timed it. It's mostly set up in the room that the player cannot get to. 

The Pox moving water is not animated the same as standard Quake but it does move.

I used a brush that was 2496 x 960 x 272 without any problem.

I didn't use the 'mangle' (current) as the player has to turn several corners whilst under water.

The easiest way to use the Extras is to incorporate them all if you don't want to fiddle around. I think my progs.dat ended up at 750 - 800K, and I had most of the Extras in there even though I ended up not using much of it in the game.

I thought it worked quite well (although that's only my opinion). I don't recall anyone making any comment about it, so it must have been acceptable to everyone - can you imagine someone here NOT saying something if it was tosh?