awesome scamps...

I have to say I really should get some pipe prefabs made up (especially if I do any more base maps). It'd be nice to have a 2d brush shaper/rotator tool like in UED. 

I didn't see anything wrong with the tutorial's end result though. Quark users should check out:

http://quakeone.com/forums/quake-talk/other-games/5783-hexen-ii-community-work-discussion-90.html#post127434

follow the links, could be useful. Grid at 1 unit shouldn't be a problem. I'm making brushes at 0.2 units max thickness, all on grid for .bsp models. 

i didn't know arghrad had phone shading:
Arghrad's Phong shading feature allows smoothing on rounded shapes. Two conditions are required to obtain this effect:
- each face must have a light value >0
- the texture must be wrapped without break

I think better criteria would be to have some critical angle on which phone shading would be applied (let's say 45 degrees). I wonder if that could be added to other light utilities? 

that's how q3 light tools do it.

Arghrad works but is very manual, you can effectively make any edge "soft" or "hard" by carefully setting adjacent faces to have the same or different light values. 

Apparently Quark doesn't fuck up on rounding float-point like most other editors do.


Necros: Q1rad does that (essentially a HL light compiler made to work with Q1 BSPs) 

yeah that�s neat! 

i was hoping to get that functionality in a modern light util though... i'd really like to keep all of aguirre's enhancements as I couldn't do lighting without them. 

Quark has the same problems with floating point coordinates as other editors, unless it knows magic ;-). What does Quark do better than other editors? 

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