Thanks, Willem - that's it: "WARNING: No valid wadfiles in worldmodel" from qbsp.

How can I get qbsp to find the right wads?

(I'm on Vista, which might be part of the problem.) 

spike's version, right
and where can I find his site? 

I think he's on inside3d but I've never actually talked to him. 

Uhm, edit worldspawn in WC or a text editor and add "wad" "..."? 

It means that worldspawn will point onto a single wad file... But unfortunately, when you use different textures from different wad files, you will have to concatenate it before it works... hence more work...

Other solutions is to use a proper editor: QuArK owns this very well you know.. I guess it is the same for other editors ;)

So rather than editing the worlspawn, I would suggest to run the compiling processes from the editor itself, that may embed the proper wad generation with the necessary textures... safiest way to go I think ;) 

Editing the field manually, you can still have it point to multiple wads. And WC was one of the first editors to support this.
I assume the textures show correctly in the editor, so what if it's indeed some Vista issue? Maybe simplifying the paths could help. 

Dunno actually, I've never tested such feature, manually at least... I'd rather prefer to stick to something I'm sure it is working ;) 

One thing is very bad about Quark's texture handline though. It re-renders all the textures each time you open the texture browser. And it does not let you properly use it during that. This means that you will have to wait several seconds (for bigger wads) until you can select a texture. 

Spirit put file links... mine is fast... 

and i always have lots of wads instaled! 

key "wad", value "wad1.wad;wad2.wad" in worldspawn, put all the wad files in the same folder as the .map/compilers. Like negke said, it'll eliminate the possibility of it being misread paths...

(And manually specifying wads is a breeze compared to using an editor that has features you require missing (or has undocumented 'features' you'd rather avoid ;) 

) 

What is with me and the slow portals all the time... 

Thanks for the help. Seems like I can add a "wad" key but the value field isn't long enough to fit the path of more than one wad! Even so, the .map file gets generated with another (presumably worldcraft-generated) wad key, with all of the .hlwads in it, which is clearly wrong.

So how can I get worldcraft to generate the correct .wad names instead of using .hlwad...? anyone? 

Text editor then. No idea how to change it permanently. 

In WC go to Tools\Options\Textures Tab and add the wad files you need. They will show up in the map files automaticaly. Compile should work without problems. Maybe you have too long paths to the wads also. 

This is really dumb - I've had exactly the same setup working perfectly well before.

Ankh - I'm using WC3.3, so I have to specify .hlwad files in it - which are obviously incompatible with Quake. I thought that the quake adapter did some magic so that at compile time it would re-insert the correct wads, but apparently not (or at least, not in my case). 

Because it's pretty direct what happens with WC.

But it's fucking irritating when things don't work as they should.

You should have a folder inside WC called textures with all your wads in there. Inside the editor you go to tools/textures and add the wads that are inside that folder manually.

And you're good.

Tech support isn't easy across a forum - but that should set you right.

The adapter does nothing magical, it's just a collection of tools - most of the legwork is still yours, so patience and experimentation is needed. 

Quake does accept HLWAD - but worldcraft 3.3 doesn't accept wad. It's a big hack, but it does work, at leaast until the tex conversion tool refuses to do the business. 

I'm still working on my map, but when I run it true the Fitz or aguirRe engine with a fast vis only, it runs smooth as can be. Is full vis still necessary in this day and age ?

Another thing, if you get the "Excessive static entities" warning and just ignore it, do you get any real problems ? I don't care about warnings, but are there any consequences ? 

it's a choice you make. if you go over limits and get warnings in fitzquake, then you have to accept that it won't run in some engines.

as for full vis, my opinion is that it's just sloppy not to full vis. it's free performance, since not everyone has a monster machine and the quake engine becomes a lot less efficient at drawing stuff. the performance loss is not linear. 

I agree. It's a basic level designer skill to be able to seal your map and get a good VIS. And necros is right that it's not a linear thing - without a VIS, you're drawing the entire level with tons of extra lightmaps to boot. 

OK, thanks.
I thought it only had to do with speed, so gameplay doesn't become choppy. 

Speed is a large part of the reason but there are other concerns, yeah. 

There's lots of ways to build a map where full vis doesn't have to take weeks. Level of brush detail, turning details into func_walls, making LOS blocking 'doughnut corridors' putting clip brushes inside small holes and so on.

Its finnicky stuff to do, but it makes the map very easy to compile - which is important for betatesting, since not everyone has a powerful machine as mentioned. Some might be emulating in Wine or have other issues.

My Quake machine will have trouble on non-fullvised maps, for example - a decent incentive to keep my maps well built. 

"putting clip brushes inside small holes and so on. "

I don't see how this would improve VIS times. Clip is a collision thing while VIS looks at the rendering side of things, right? If you meant plugging up holes with solid brushes then, yes, that would help... 

the consequence is that some static entities wont appear in game (like torches and stuff)

AguirRe's engine should tell you how many static entities you have and what the limit is (256 IIRC)

Take some out and replace them with other light sources (i.e. light textures) 

Not vis help, but general good building of the map.

For example putting a crate in the centre of the room on the floor or putting a crate in the centre of the room floating 2 units above the floor.

The second one is better (and invisible to the player) because it causes less subdivisions, which also helps compile time. 

 

 

As CZG so eloquently explained, while this will indeed reduce subdivisions of the floor, the saving in VIS time/polycounts will be negligble when compared to the creation of many tiny, tiny vis portals under the crate (which'll slow down you VIS a fair chunk, especially if done with every crate in a level (there should be as many as possible)) 

Fair point - I'll go back to my cave now. 

It's not dumb. It can lower the polycount considerably (depending on the area) and I doubt a few additional tiny portals will slow down VIS "a fair chunk." There's a more definite risk of ugly shadows beneath/around the crates, though.

However, speaking of poor VIS design: I'm now (again) stuck at a slow portal with no progress for a full week. 

 

found something interesting out about the hipnotic rotating stuff.

had never noticed this before, but you can attach ANY entity to a func_rotating_*

as long as the entity's targetname matches the target field of the func_rotating_*, that entity's origin will be continuously updated to match the position and angles of the rotater. i haven't tried, but i suspect it may not work with bmodels because of the way quake handles those, but point entities (even monsters o.0) work.

i was able to build a func_rotating_train which had torches attached to it as it moved about.

the effect is kind of ruined if the rotater actually does rotate though, because the angles of the child entities aren't updated, only their positions. 

clip brushes would help with BSP times as it's already telling BSP what areas to not put hulls. Some of the best ways to avoid high vis times is to avoid small brushes, huge open areas, and overly complex geometry (which is boring to me.)

I've never really understood the entire fretting about vis time other than your giving up use of your machine while vis takes place. Why should it matter if it takes 1 hour or 1 day as long as the map has good game play, is built properly, and looks great?

Most people playing these maps aren't wondering how long it took to Vis. They're having fun hopefully. 

Detail brushes have existed in Quake (1) for a long time.

http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
http://quake.chaoticbox.com/downloads/equakeutils.sit

It's a pity they've never been incorporated into more modern compilers, because they really do work to cut down vis times. I used pOx's eUtils quite a bit back in the dark days of mac quake editing. They even have nifty features the Quest tools don't, like non-solid detail brushes. So you can have your func_walls and func_illusionaries, but they still cast shadows etc. 

The problem is that, these days, people are making maps that don't so much take days to fullvis as weeks.

It wouldn't be so bad if this trend wasn't utterly unnecessary... 

I've ever made has taken more than ~5 hours to compile.

Someone's about to post a warp map compile of 6 hours to prove me a liar.

Remember that this is a mapping forum, on the mapping help thread - this is the place where we complain about vis times. 

In reaction to post #8797 posted by Lardarse:

Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ?

If you look at the work of people like Ijed, Tronyn, CZG, Necros, Kona and Kell(to name a few of the best ever), it's almost all huge. And I like it.

ID's Quake was great, but what these people have made is so much better. Better even than all the crap games you can buy in the stores these days. Works of art that inspire people like me to try and come close to, even without having all the knowledge that they've got. 

The size of the map shouldn't matter though. Proper construction and respecting the engine should result in reasonable VIS times. If you build a gigantic football field with bleachers, well, yeah, that will take forever to VIS but in my mind that isn't proper construction.

You can build a large map and still have VIS be reasonable.

Having said that, my current map is going to be a bastard once it's sealed. I've committed a lot of VIS sins and I know the VIS gods will punish me for it. 

"Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ? "

A map the size of an id1 map that was nicely detailed and well put together would be well received I think. You couldn't duplicate the originals and get away with it anymore but that size of map isn't necessarily a problem, IMO. 

... do whatever you think is cool... And you end up in a 2 month fullvis map :P 

I dunno. I guess I'm of the mind that you have to keep evaluating your 'return on investment'. A map that takes 2 months to VIS isn't necessarily 60 times better than a map that takes a day. It may just be built wrong. 

I agree that lack of skill or knowledge is the bottleneck for people who start mapping. Even people who have been doing it for years could be making things more difficult for themselves without them ever knowing. That's why it is a shame that so many websites dedicated to map making are disappearing. 

ID's Quake was great, but what these people have made is so much better
bear in mind that id's levels was made ~95/96, do you remember, any custom levels of such quality those years? 

If I build a map and people enjoy it, that's my return on investment (your pleasure is my pleasure, in a non-kinky way). I map for fun, not for money. My computer is not a 'resource', it's a hobby.

Sixty hour vis times is fine by me, I'll be doing plenty of other things in the foreground. So, time is not the issue: impatience might be. 

*shrug* Sure, to each his own. I obviously map for fun -- why else would I be making Quake maps? There's no money in it. 

I'm working on id1 remixes now and I find that everything gets slightly bigger - the originals feel very crampt by todays standards.

I tend to add lots more areas as well - my e3m3 is now around twoce the size but started off with a similar layout. I add the extra stuff just because it's fun to have.

A load of times in the id1 maps I'll come up to a dead end or a room just begging for expansion, and can't stop myself. Because it's fun :)

Still fullvising in under an hour in the above example. 

Haha, of course, I get the map sealed and a full VIS takes 3 minutes. WTF? 

 

if a trigger_multiple killtarget's itself, is that the same as a remove() in a touch function? o.o 

killtarget is better because it sets the think function to SUB_Remove, which happens safely in the next think frame. If you remove() in a touch function it happens immediately, which could screw up the linked list of edicts, which can crash the engine. 

thanks for explaining the difference :)

now an even weirder question:

is it ok to build outside the 4096 boundaries if the player is never supposed to get there?

i know from past experience that the visual component of the map will be visible if it's outside the 4096 cube. the only thing that's bad is that the moment the player's pov passes outside, he seems to 'loop' back to the other side.

but the actual collision will still be correct, it just looks as if you're on the other side of the map.

so if i built a sort of skybox (brushbox? o.0) outside the 4096 as pure decoration and clipped the boundaries of the playable area, would it break anything? i've never tried making a full map with a lot of brushwork outside the boundaries, just usually it's a few stray brushes because i was careless. :P 

it's something i've thought of doing too -- should work, as long as the player or entities or anything else but world brushes stay inside teh bounds (e.g. if you shoot a rocket out past the bounds, it will look pretty funny.

If entities/effects/sounds etc go outside the bounds, the only issue really is that they will be rendered in the wrong place. Server-side physics and movement and and stuff will still work fine.

Anyway, you could make a pretty cool horizon/vista out past the bounds, like a cityscape or mountains or whatever. 

excellent! i wanted to make sure there weren't any kind of hidden engine glitches that would crop up.
there's still maybe a matter with vis.exe calculations? i don't know if it cares or not whether the pvs' it's calculating are within any boundaries or not. 

well, it's fairly untested ground, so there are no guarantees, but as far as i know, the only thing enforcing a +-4096 limit is the network protocol, so everything else should theoretically work with the larger space. 

well, i decided to try it out, so i guess we'll see. o.o

i guess the good thing about it being purely decorative is that if it doesn't work, it's just a matter of deleting it without impacting gameplay. 

So if you go beyond the 4096 boundary do you come out the other side like in Pac-Man? 

to be the case unless there are special engines used or summat. 

the squad shadow by making an object above the sky is the same issue. 

Yes, but it's a purely visual thing, your actual location on the server does not wrap around -- just the coordinates sent to the client. 

Are you sure about that? If you jump off an unsealed level and loop a few times, you can still land on the level itself and have proper collision which would imply that you are, in fact, wrapping around in terms of your coordinates... 

Hi,

Does anyone have any information on the metrics / dimensions used for the Quake world ?

I'd like to understand what each unit represents and how big fixed size entities are, in terms of real world application.

Thanks

-Mic 

I've heard it's 8 Quake units is a foot, but I don't know for sure. I just fool around until it looks right. 

It was actually ToeTag that prompted this question as I was wondering what size the grid squares represented and how you knew what size to draw the 'fixed-size' entities etc

-Mic 

Yep, just found confirmation on this page ...

http://toolz.nexuizninjaz.com/shader/shader/section2.htm

Unders the measurements section.

Will now work to this scale.

Thanks

-Mic 

Well, the entity sizes are specified in the .QC files and the models and things that are read in are automatically scaled correctly since the entire editor runs in Quake coordinate space. 

Thanks for pointing me to the .qc files ... that'll come in handy.

You see that's where I get confused, you said above 'I just fool around until it looks right' but now you say 'models and things that are read in are automatically scaled correctly since the entire editor runs in Quake coordinate space' so in order for that to happen you must use some sort of measure/unit size ?

-Mic 

It's a 1:1 mapping. 1 unit inside of a model file is 1 grid unit. That doesn't relate to the real world, it's just how it's mapped within the editor. I use the same scale as Quake which, internally, is 1 unit is 1 grid unit. 

Ahhh ... now it makes sense. Thanks for clearing that up.

-Mic 

8 units = 1 foot doesn't literally translate. The player is 56 units which would equal 7 feet, and can jump 32 units which would be 4 feet.

Even then if you create a room 80 X 80 and spawn in it, it doesn't 'feel' like a 10' x 10' room. 

 

Indeed, if you're asking what I think you are then the answer is 'it's irrelevant'.

The units in Quake don't really translate that well into 'real' units of measurement. It's just an arbitary unit. What you seem to want to know is standard sizes, in which case;

128 units is standard for a medium/small corridor width. It's also the standard height of a floor/storey (ie, there'll be 128 units from floor to ceiling).

64 units is a thin corridor or a large crate.

16 units is the height of a step.

Of course, a lot of these, such as floor height/corridor width can be expanded/contracted depending on the size of room wanted, I'd suggest finding the source files for some maps and having a look at the scale of them in editor (I know Vondur releases all of his, as do various other mappers...) 

Also you can determine in game by some of the textures used the size of a room since most textures are either 64 or 128, unless they were scaled. 

I think in terms of approximation, 1 foot equalling 8 units is about right.

7ft for the player doesn't sound to outlandish. Dolph Lundgren stands about 6ft 6in and I would have expected the player to be about the same physique as him.

And I would also expect someone of this physique to be able to jump about 4 feet.

-Mic 

The reason I'm asking for this is because I'm currently working on an .skp (Google SketchUp) -> .map converter, but the maps when loaded after conversion are too small because SU works in inches & feet and 1 foot doesn't map to 1 Quake unit. Therefore I need some sort of scale to work with.

-Mic 

If you jump off an unsealed level and loop a few times, you can still land on the level itself and have proper collision

this actually isn't the case. if you loop around, the geometry is drawn as if you had looped, but everything is non solid and monsters cannot attack you, even though they look as if they are able to.
any geometry that goes beyond the boundary though, will be solid to you when you loop over. but it won't be visible.

it's like the client is running on floats but the server is running with doubles. 

maybe this is for hl/hl2, but i believe they do 1 unit = 1 inch which works out good for like stair heights and such, but i think the quake player is shorter than the hl2 player. 

even shrter than the q2 guy 

necros

Oh yeah? Weird, I could swear I remember doing that but maybe I never actually tried it. 

it's like the client is running on floats but the server is running with doubles.

Literally, the server is using floats and the nework protocol sends them as 16-bit fixed-point numbers, with 13 bits for the integer part, and 3 bits for the fractional part (so the smallest representable difference is 1/8 of a unit, and the largest possible value is 4095.875) The client converts them back into floats, but of course you've already lost the extra range at that point. 

you can see this 1/8 thing if you stand on a slope (like the beginning of e1m1) and zoom in on the wall nearby. As you slowly slide, your view ratchets forwards and downwards in noticable increments.

When working on protocol 666, i tried various techniques to add range to the coordinate system without increasing packet size. They were all very complicated and still made packets bigger. The simplest is just to always send floats, but this makes packets much bigger and I didn't want to pollute the protocol that way (as it is now, the packet sizes are about the same as 15 until you need to send special data like alpha, 2-byte modelindex, etc.)

I still have plans to support this in the future, I just wanted to get a functional version out and that requires locking down the feature set at some point.

The packet size limit is the toughest part, and there's not much I can do about it (but I should add a cvar so you can attempt larger packets on a LAN, which might have higher MTU than the internet at large.) 

angles are another thing where the precision is incredibly low.

the hanging corpses that slowly rotate in quoth are animated in the mdl because the engine's angles round to like, nearest 5/360th instead of nearest 1/360th degree. when you start doing rotating brushes, and the brushes are large (or are placed far from the origin) it can get incredibly ugly with this gigantic gaps between rotations.

it would be nice to beef up whatever handles angles if possible. 

protocol 666 does have high precision client angles (so aiming your gun is accurate) but not on rotations for entities.

I noticed the problem with hanging corpses but I thought the rotation was a model animation (so they could be static ents) rather than entity rotation. I guess that's a good feature to add to the next protocol.

Though, It seems like something that mappers/modders should avoid relying on, otherwise you'll have the huge ugly bmodel rotations you talk about happening in all other stock engines. I had this problem with a rotate train in rubicon2 and the fix was to spawn it near the world origin. 

maximum distance a player can jump without falling into water, lava, or traps
225 units

maximum distance a player can jump straight up and get up to another object:
42.5 units

maximum distance a player can fall and not be injured:
275 units

minimum gap in the floor spacing, slatted bridge or floating squares of lava:
35 units

maximum height that a step can be before a player must jump:
17 units 

What is a unit ?
I always have trouble making lifts go the right distance, most of it I guess and then adjust.
When you speak of units, how do they relate to the grid in Worldcraft ? 

(makes "shoot myself in the head signal")

FFS, its just been repeatedly explained not a couple of posts previously (like yesterday)

1:1, one grid unit = 1 unit, one 1:1-texture-pixel 

After researching this more, I have come across the Quake Editing Primer at ...

http://gamers.org/dEngine/quake/QDP/QPrimer.html

... which suggests 1 Quake unit is about 3cm or 1 foot is approx 10 Quake units.

This seems to make more sense now, especially with what others posters have suggested above.

The only thing that still puzzles me is the standard height of a step being 16 units. At 8 units equalling 1 foot, 16 units or 2 foot is far to high I feel, and although 1.6 foot (using 10 units per foot) is getting nearer the mark, I feel this is still too high.

5 ft 6 for the player size, and an 80 x 80 room equalling 8ft x 8ft rather than 10ft by 10ft perhaps seems more reasonable.

What do you guys think ?

-Mic 

It also suggests that vertical and horizontal scales are different ...

Vertically : 1 unit = 3cm, 10 units = 1 ft
Horizontally: 1 unit = 2cm, 16 units = 1 ft

-Mic 

I always had the impression 64 units roughly corresponded to 1 meter. Then 16 unit steps would be about 20-25cm which kind of makes sense for the world. The scale for entities is totally different, though.

In the end, it's no use translating RL scale to Quake units - the dimensions of the environment isn't determined by logic, just by the textures. 

The scale in Quake is shot: a 16 unit step/stair just doesn't look right with a player model next to it and larger monsters look ridiculously small when viewed from above. Go with what feels right and don't get too caught up in the unit conversions. 

" the dimensions of the environment isn't determined by logic, just by the textures."

^^ This. Just work with it until it feels right. 

It's a matter of perception. Do what looks/feels right, and adjust from there. 

... to players size, that is 16 units tall if I remember well :) 

When you're dealing with dimensions/proportions in a game engine, you're almost always going to have problems if you try to rely on exact conversion numbers and translation of stuff directly from the Real World.

In FP games in particular, the camera height and FOV are going to differ at least a bit (and often significantly) from what you're used to seeing in real life, so some things will feel right and some won't.

And then there's the problem of stuff being on a small flat screen, rather than actually being in front of you... 

there is a limit after all to how far out you can build. it appears to be 8192 (doubles?) where, anything after that just doesn't draw. 

Hmm, I guess there are probably some client functions that assume the original bounds. For example:

- the far clipping plane

- the skybox size

- the trace vector used to light entities based on floor lighting (was 2000 units in original quake, now 8192 in fitzquake) 

you guys ever go back and play some of your really old stuff?
i was playing nesp09 and i discovered my lame sense of humour hasn't changed at all. 

i guess what i was really driving at was: do you enjoy your own maps after sufficient time has passed that some or most of it is almost like new? 

 

Like when you told me it wasn't possible to use the second (light brown) Polyp skin in Quoth while it actually is? Where we could have been now... 

I've replayed my speedmaps recently. Some are better than I thought, and most are much worse. Pretty much all of them are ridiclously hard - 60 monsters in such small maps, what was I thinking). And the humor in some of them is beyond lame, yeah.

The most obvious thing going on when playing one's old maps is realizing their shortcomings, like Trinca said, and how one would build it differently. 

 

joyfully playing my own map again then seeing it quoted by someone who HAS to do the job. 

Has anyone gotten Wordcraft/Hammer to run well on Linux? 

Getting it to run on windows - no joke.

It's got a very nice interface but if you're looking for editors I'd suggest going for another one, maybe QuArK. Which is multiplatform AFAIK. 

It is not and it is an editor that makes it too easy to screw up (and likes to do that by itself just to annoy you). 

I've had no problems with it on windows. I know Radiant works on Linux but I've been using WC for years and it's what I'm comfortable with.

I have Quark but it runs slower than WC. I'm just wondering as I'm looking to switch to linux. 

I'm still looking for a solution to the 'no 3d selection' issue - There are dll's that can be used but they screw up the texture rendering. 

Radiant and Quest run natively under Linux.

Several others run under wine (pretty well actually), if that floats your boat.

I'll learn Radiant soon anyway. 

I fucking love replaying 90% of my old speed maps. I never get tired of them, and I don't look at them critically (probably because I haven't improved much, if at all). 

Full: 75.01%, Elapsed:307h 39m, Left:482h 54m, Total:790h 33m, 38% 

Is it really worth the full vis? After all the map is very open. 

It'll still have an extremly high polycount, but even if the fullvis can only lower it slightly, it'll be worth it. 2000 is better than 4000. 

your computer will burn :|

make a backup of everything NOWWWWWW 

I wonder what the magic breaking point is for VIS. My latest map has gotten larger and is still VIS'ing in under 5 minutes. It has one huge room in it with lots of detail but even that doesn't seem to daunt VIS... 

It scales up exponentially. A single room (how huge is huge in Quake terms) might work, but if most or all geometry is inside a single volume like in a space map, it creates a multitude of portals. There's one for every little edge and slope and all they also affect each other.

http://negke.quaddicted.com/images/coag_prt1.jpg
http://negke.quaddicted.com/images/coag_prt2.jpg

Note the portal jungle in the upper half. 

CDA seems near the magic breaking point, if anything.

That suggests if your map is one large sandbox with all structures open to it, and some triangle mesh etc perhaps, you might have good chances. 

wow, just saw those numbers. You love pain, right. 

get the urge to leave... 

Multithreaded VIS on 8-core Nehalems will make this problem pretty much go away. Remember, id had to use the most badass Alpha hardware available in '96 to compile their Quake maps.

or you know, detail brushes. 

or use Doom 3, no more vis. 

yeah, whatever you say about the lighting, the visibility system in doom3 is badass. 

What system resources uses Vis anyway ?
Does it help to have lots of memory and a good processor or could you just as well run it on a Pentium 1 from the old Quake days ? 

VIS process needs memory and a fast processor to limit its runtime.
It is based onto a recursive algorithm (a kind of "turtle" algorithm)... the faster the CPU will be, the less consuming the VIS runtime will be.. Having GBs of RAM will not help, as I don't think the process needs it... though...
But in anyway, VIS process is the evil one in the Quake map building flow :( 

Also, VIS benefits greatly from multithreading since each leaf can be processed independently of each other (which is how id ran theirs on their Alpha machines). I've enabled this in my Mac version of the tool but I don't think any Windows versions exist like that. 

I'm not exactly sure bout the implementation, but it seems it could be faster with multi core processor indeed.
I already discussed this topic with aguirRe, and he told me that ID indeed had their first VIS process running onto multicore Unix machine, but it has never been ported to Windows in this way: Window VIS tools are single CPU only, and AFAIK.. unless somebody has a specific tool on his own ;) 

The code is in there - it's just #ifdef'd out. All a Windows programmer would have to do is define "_alpha" (or whatever the symbol) is in preprocessor symbols of their compiler and fix the errors that spit out. It was really pretty simple on Mac.

I've not done much multithreading on Windows so I can't say how closely the structures and such relate to what id wrote on their Unix machine but it can't be more than a few hours of hunting around some documentation to find equivalents. 

...care to do me a little favor? 

Haha ... I might take a stab at it. Which VIS do people use? Point me at some source code and I'll take a crack at it this weekend but no promises... 

I didn't mean compiling the vis tool, though! 

negke already in 90% 

Full: 76.65%, Elapsed:359h 37m, Left:885h 2m, Total:1244h 39m, 28% 

negke

Oh, well, the best solution long term would be to get a Windows version with multithreading working. I could run it for you, yes, but that's painful. :P

To be clear, this?

http://user.tninet.se/~xir870k/visbjp.zip 

 

somebody provided be a vis tool that is supposed to run 40% faster than Id's original one... but I never tested it as I did not trust the guy that much: anyone who wants to benchmark it can send me an email: I'll provide the stuf.... at your own risk :P 

... I also have the source... 

Can someone hook me up with a .PRT and a matching .BSP file so I can run some VIS debugging? 

...you can generate them yourself from the BSP. Use for example BspInfo (delivered with aguirRe's visbjp suite) and the -prt flag. 

Ha! So you can, awesome. Thanks! 

 

...but it comes with zero assurances of it actually working or not corrupting data. :P

I took some of my lunch hour today to see if this could be done quickly.

http://files.getdropbox.com/u/161473/Vis.zip

That should be a multi-threaded version of BJP VIS. When you run it, you'll see some additional text appear like:

"Using X threads."

The X will be however many cores/processors you have in your machine.

The percentage and progres stuff is all kinds of messed up and I don't have time to fix it today - lunch time is over! But I'll take a look at that in the future once the basics are nailed down.

Anyway, try it, run some side by side timings and let me know if I'm crazy or if this actually works.

The best way to see it work is to start up your Task Manager and look at the processor activity. All of your cores/processors should be pegged at 100% when this is running.

Thanks! 

swapping to your vis for all my vising needs. i'm seeing 100% cpu usage, so it appears to be working fine. i'll let you know if anything weird happens.

you are currently on my list of people made of awesomeness for this, btw. ^_^

damn, i wish i had a quad core though. :( 

The part that scares me is if the map will load into Quake when it's done. That's something I can't test here. :) Let me know, plz! 

Despite it may load, it also can generates HOMs and leaks.... wait and see :P 

I don't see why it shouldn't load into Quake. After all, all you changed was the resource management. The actual vis calculation and state file handling remains untouched.
I'm running a test at the moment. One hour of willemvis vs one hour of regular (single-threaded) vis. The time estimations would help here, but whatever. No idea if there's much of a gain. I don't have a real multicore machine, just one of those p4-hyperthreading dudes (I was always suspicious about this being a possible bottleneck). 

How many threads does it say you're using? If it's more than 1, you should see SOME improvement. 

I also renamed the EXE for easier use.

http://files.getdropbox.com/u/161473/WVis.zip

Give that a shot if you want the time estimates to be useful. 

 

So I guess now, whoever has the most cores/processors on their machine needs to become a VIS mule for the group. :P 

Yes, there's definitely some improvement (with 2 threads) - I'd say it's at least 40% faster. I was so dumb as to accidentally close the window just now, so I can't tell the exact difference, unfortunately. But still, your version is useful for running at night when there're no other programs running beside vis. Thanks for offerning your lunch break. 

offering the sacrificing 

well, i've been using it all day with fast vising. it is faster, but it's hard to tell just how much without doing a proper full vis.

i have a second map that's in the final stage so i'll do a couple of test runs of full -level 4 vising on it, one with and one without multithreading for a proper comparison, but assuming there isn't a fundamental difference in what vis is doing in -fast vs without -fast, i'd say it's creating .bsp files that are perfectly fine. :) 

how you managed to improve this blocking up tool, Willem!
If I count all vis time I made since I started mapping in '97 I could have learned C+ and have dived into it... too late I guess. 

"i'd say it's creating .bsp files that are perfectly fine. "

Sweet! i guess it's good to go then. 

link is 404? 

Sorry, the file moved. I've made it permanent here:

http://www.quaketastic.com/upload/files/tools/windows/misc/WVis.zip 

2 Core AMD works!!!
Test map 60 sec vis down to about 36 sec.

Base vis is crazy fast 

It looks like the WVis times are rounded to the nearest minute?

This was on a Core2Duo E6850 (3 GHz).

Original VIS run:

---- Vis 2.31 ---- Modified by Bengt Jardrup

File: c:\quake\id1\maps\wish16.bsp
2929 portalleafs
8356 numportals
State file out of date, will be overwritten
testlevel = 4
ambient sky disabled

average leafs visible: 192
max leafs visible: 646 near (-608 352 592)
c_chains: 39836161
visdatasize: 219 kb compressed from 1049 kb

Elapsed time : 6:52

WVis run:

---- WVis 2.31 ----
Modified by Bengt Jardrup
Multithreading enabled by Willem

File: c:\quake\id1\maps\wish16.bsp
2929 portalleafs
8356 numportals
State file out of date, will be overwritten
testlevel = 4
ambient sky disabled

Using 2 threads.


average leafs visible: 192
max leafs visible: 646 near (-608 352 592)
c_chains: 39880904
visdatasize: 219 kb compressed from 1049 kb

Elapsed time : 3:00

I just did this, so I haven't actually looked at the map in the game. If I see any problems I'll post them.

The only difference in the log is the c_chains (no idea if that's important). I ran the full BSP, Light, Vis each time with no change to the actual .map file 

I guess this is the recursive linkage made in between volumes. As in bsp process there's a volume expansion process that defines where are each faces / leafs, I think it is almost the same for vis process except the tools creates a chained list of volume in order to process them recursively (i.e from this volume, process the faces, and check what are the others visible volume not in the list, etc...) and determine which volumes (and then number of faces to render per volume) are visible from a given position.
This is how I understood the system in very "rough" way.. and maybe I'm wrong :P 

Yeah, I'll check the rounding but I didn't really change anything there that I can think of. Hmm... 

Progress in Quake map building, after all these years ! Nice work !

Quick question about something else:

Does it really make a lot of difference if you make your curves just by cutting them with a circle, or if you use the vector manipulation to make them more or less the same size and triangles ? If anyone has some more info (on the web, maybe ?) about vector manipulation, please let me know. 

http://www.quaketerminus.com/hosted/happymaps/curv_tut.htm

Learn those ratios by heart, use them. The ratio used in the above tut is 0:2 2:4 4:2 2:0 if that makes any sense. There are other possible workable ratios but that one's always worked for me.

As far as constructing said curves, the 2-point clipper will probably give you less headache (and fewer invalid brushes) than trying to vertex manip everything into place. 

I remember someone else having a problem awhile back with this ... I have some spots in my level where creatures turn black despite the floor and the walls around them being lit perfectly fine. Is there an easy workaround for this? I'm running FitzQuake... 

If they're passing over a sky brush then they'll always appear black unless the sky brush has a normal, solid brush inside it.

If they're appearing black when passing over normal lit floor then there's an issue with the origin of the monster.

They take no reference from the walls. 

But what can I do as a mapper? Just rework the brushes in the area until the engine stops having an issue? 

Maybe it's a known issue. 

The screenshot would just be an enforcer standing a well lit ledge but he's black. If he moves to either side a little bit, he lights up. I guess I'll just play with it. :) 

Doesn't sound like any issue I know about. 

 

the problem i believe you're remembering was mine where i had torches and stuff fulldark even though the ground under them was nearly fullbright (or overbright even).

i think i understand what causes it. i suspect it has to do with FQ's lighting interpolation, but only on maps that are unsealed.

the problem usually happens in corners or along walls, never in the middle of a room.

i believe this was because the sides that made up the bottom of the wall brush and the side of the floor brush were fulldark and the interpolation was getting messed up.

i've found that sealing maps so that those faces are removed tends to fix it.

if you have an enforcer on a ledge, is it possible there are faces in the area that are messing up the interpolation?

from what i recall of how metl explained it to me, FQ doesn't just look at the floor directly beneath the model to light it. 

The map is definitely sealed but there might be some dark polygons in the area. I'll take a closer look... 

Thanks a lot for that link, Grahf ! 

from what i recall of how metl explained it to me, FQ doesn't just look at the floor directly beneath the model to light it.

I haven't actually figured out this bug yet, but the fitzquake interpolation should still be looking just at the same floor polygon as glquake. The difference is that when you trace a line down and it hits between lightmap samples, glquake picks the nearest one and fitzquake blends between all four.

Again, since i haven't figured out this bug, i can't say in what way fitzquake is doing it wrong. 

No prob Ron, I'm welcome to pass the info along. Thank CZG actually, he wrote it.

Actually, it's worth mentioning that the tutorial I linked to in #8923 was written specifically for Worldcraft. The more advanced methods, of bending a hollowed pipe, simply do not work in editors such as Radiant. I beat my head against a wall for a while until Speedy told me the solution: the pipe itself can only be 8-sided, but you can bend it around a 12-sided curve. So there you have it, in case anyone was wondering. 

 

page was inspirating me to a new map!

http://members.home.nl/gimli/quake00.jpg 

???? 

not sure, but does it metch:

http://members.home.nl/gimli/dummi.jpg 

or post your hat. 

im not comprehending what i think im supposed to :S

i think my brain has gone to warp stage 

That's nothing.

In my occasion I never know what to think
when adding a post and the toppic grows
dead for weeks. 

someone needs a model animation but has only the smd format.
It seems something to do with the Team Source SDK Model Source File.

I can only use 3DS or DXF files but he tells me the file in Milkshape or Max3d will only transport to these extentions without bones.

As I need to animate them it's usefull to keep the bone structure.

Is there a solution to this convert error? 

it's been a long long time since i was converting hl2 format models...

i believe there's a 3dsmax plugin that imports SMD files directly.

http://www.chaosincarnate.net/cannonfodder/cftools.htm
get mdldecompiler here.

this lets you decompile the mdl file into all the seperate pieces to get the smd, which, afaik, is just the mesh with vertex weighting.

then go here:
http://www.wunderboy.org/sourceapps.php
and pick up the 3dsmax smd importer to directly import the mesh into 3dsmax. this should preserve vertex weighting. 

for the links, necros!
I didn't realize it were hl2 models as I only came to HalfLife1.

I earlier overcame to the stunning effect when importing an enforcer it meshed up the bullit inside its gun, so I didn't understand were my extra triangle was left after exporting.

I only have 3D Studio MAX R3.
I hope the converters can handle this old version.
I could install Milkshape to get the bones preserved as modelling can get messed up when I start adding them myself. 

Ninety-two percent.
Oh, woes! Will you ever stop?
Space maps suck to VIS. 

You're into the slowest part of the process.

Really looking forward to this map, and won't be the only one - if its any consolation. 

that map i posted about a couple of weeks ago... estimating 1351 hours, and that's *with* willem's multicore fix. -_-

i suspect i will have to rework it. :P 

TreeQBSP v2.05 -- Modified by Bengt Jardrup
Mac port by Willem
Input file: leamondetest1.map
Output file: leamondetest1.bsp
*** WARNING 03: Line 45756: Brush with duplicate plane
[a bunch of duplicate plane errors removed]
Title: "Lea Monde"
31430 faces
5229 brushes
1023 entities
117 unique texnames
3703 texinfo
*** ERROR 37: Failure seeking to 1694052352 in file rt_gnosis_q1.wad
29 warnings
Elapsed time : 0:01
Peak memory used : 5.1 MB

So as you can see, qbsp is spitting out this bizarre error as it is loading my .wad files. I have 4 wad files I want to use, which are all in the same directory as qbsp. My wadfiles are fine, that is, they loaded with no errors into a wad editor. The above "failure seeking" error is generated when only one or two of my wads is specified in worldspawn. The number it fails to seek to varies with the number and order of wads listed in the worldspawn's "wad" key; sometimes it has been negative, but it is not random - for any given order and number of wads, the number spit out will be the same. If all four wads are listed, I get this:

qbsp(3538) malloc: *** vm_allocate(size=2690650112) failed (error code=3)
qbsp(3538) malloc: *** error: can't allocate region
qbsp(3538) malloc: *** set a breakpoint in szone_error to debug

If I am reading that vm_allocate() right, it is trying to allocate 2.6 gigabytes of memory, which I don't have. My machine has 1.5GB of physical RAM, and I got this error with 1.1GB available. I'd have thought that OS X's virtual memory management would have taken up the slack, but apparently not. Also, I was unable to reproduce the out of memory error just now, which confuses me further, but reinforces my intuition that it's a cover for something else going on. The failure seeking error is persistent however.

Oh, and the weirdest part is that if I remove the "wad" key from worldspawn entirely, the errors go away and the qbsp finishes. But I don't think it's going to look very pretty without textures. The map itself is pretty big, ~5200 brushes, but that ought not to matter because I'm getting these errors before the meat of the qbsp process even starts.

Lastly, if I ever do get this thing compiled, it has a painful lack of visblocking. You guys are scaring me. 

this is sort of a long shot, but it's all i can think of.

looking at the bsp info above, 117 unique texnames meaning 117 unique textures. this is a lot and i know there's a limit to how many textures can be stored (or is it a limit on how much memory can be used in textures?)
and the limit may only been in the engine itself, not the compiler, it's just that when you said that removing the wad key (and hence not loading any textures) makes the problem go away is what made me think of it.

try making a test map and replacing most (or all?) of the textures with a single one and see if that does anything... 

The number of textures isn't the problem here (there have been maps with twice as many). There seems to be something wrong with the WADs, some that your editor doesn't mind but QBSP chokes on. Try merging them in TexMex or at least save each of them to a new filename in case there're some faulty bits somewhere. 

ijed: Just as any new map is appreciated and looked forward to. Keeping you informed about the process is actually a double-edged affair, since it kind of renders me as a fool for going through such a hassle for so little gain, both in terms of VIS results and the quality of the map - which is not to say it sucks, but it got out of proportion some 500 hours ago. :D

necros: Keep in mind the time esimations don't stay constant throughout the whole process. If it says 1300 hours in the beginning, you can bet it'll go up dramatically at a later point and especially towards the end. Better add a digit. 

yep. i'm currently running a test with vis -level 1.
if that's enough to keep things smooth, i can stand not having super accurate vis calculations.

there's something wierd though, because i seem to be getting strange behaviour with the timer.
elapsed time is incorrect saying 34 minutes when it has been running for over 2 hours...
the estimate at level 1 is only 3 hours, but if the timer isn't working, than likely nothing it's outputting is correct... i'll see what it's like tomorow, i suppose... 

But this is a big negke space map. 

maybe the elapsed time readout is based on actual cpu tics used for vis, not real-world elapsed time? 

i doubt it because that doesn't really make any sense for aguire to code it that way. besides, i've used his vis for lots of maps and never had anything weird like that happen.

trying again with -level 2 and it seems to be working properly now. 

I put one texture on all brushes in the map, "wad" = "knave.wad" in worldspawn, and still this:

*** ERROR 37: Failure seeking to 471762432 in file knave.wad

I imported the whole map into a new file, and still the same. I even tried on a completely different map. If there are no wadfiles in worldspawn, it will compile. If there are valid wadfiles specified, qbsp will fail. Either there is something really fucked on my end, or there is a problem with the Mac port. Sorry to bother you all, I'm gonna go bawww at Willem now. 

If that WAD file is loading into your editor correctly then there's no reason it shouldn't work in QBSP. Weird. 

Which editor are you using ? 

it's gtkradiant 1.4 on mac os x 10.4. I convert the map file to q1 format with sleepy's java map converter. I would be using Willem's excellent Toetag, but it rendered my stupidly big map at molasses speeds on this old hardware.

In qbsp's source code, warnerr.h, I see that there is an "errSeekFailure" which is obviously what I'm getting. When and where would this be called?

I've tried several wads, most straight from quaddicted and a few I've assembled myself, all giving the same error.

Actually, I just had the horrifying thought that it could be failing to seek because my hard drive is dying. Yikes. Though I haven't noticed any other similar problems. 

Oh, I didn't realize it was a Mac port. In this case you, can put all the blame on Willum. Is there any other compatible QBSP you could try, perhaps with a Windows emulator? Doesn't MacRadiant save to .map or why do you have to use that converter? 

Indeed, the editor is not relevant, however for some reason, sometimes during .map generation, it can generate weird stuff.... anyway, the fact it is a Mac porting is certainely the issue.
You may should try with TxQBSP instead, or move to a PC... :( 

The fact that it's a Mac port should actually have very little to do with it. I use that version of it all the time and it works fine for me. I can't imagine what the issue is here...

Definitely try another version of QBSP and see what happens. If it's my fault, that's fine, I'll fix it - but I'm having a hard time buying it at this point in time. :P 

 

Grahf

Email me the MAP file and the WAD you're using (preferably something reasonably small) and I'll try compiling it myself. Should be easy to track down what's going on... 

 

Ahh OK, grahf has a PowerPC machine. I don't believe these tools are set up for big/little endian swapping. I believe the tools are currently Intel only.

I'll put that on my task list. :) 

I had a feeling that might be the cause of my problems. Thanks for looking into it anyways. 

I'm working on it. It might be easy and it might not be. I'll know more by the time the weekend is out. For now, you could compile in a Windows machine by using Parallels or something ... or just use a regular version of QBSP for now. 

I have a door but the angles 135 and 315 don't seem to work. Am I stupid ????

And how can I make a trigger that makes another trigger operational? 

1. not sure, can't say i recall having any problems with those angles.

try 134 and 314? could just be those specific angles or the door could be linking with others. check that each door's bounding box isn't intersecting another.

2. short answer, you can't.
long answer, you can.

make an info_notnull but as a brush entity. (make it a trigger_once and rename classname to 'info_notnull'.

make a 'think' key and set it to InitTrigger.
make a 'nextthink' key and set it to '0.5'
make a 'use' key and set it to 'trigger_once' or 'trigger_multiple'
now set targetname.
set up any other relevant stuff like message or delay or whatever.

when you trigger this thing, it will turn into a normal trigger but will not do anything before. 

1. 134 and 314 don't seem to work properly either.
I uploaded a testmap where I have this problem:
http://www.quaketastic.com/upload/files/misc/door.map.zip
2. Thanks I will try that :) 

try fudging it by giving the broken doors negative 'lip' values. 

That seems to do the trick :) 

you know what would be wild?

make a program that will load a bsp file that has had it's vis information calculated and somehow allow you to manually set which portals are visible from other portals. 

make a program that will load a bsp file that has had it's vis information calculated and somehow allow you to manually set which portals are visible from other portals.

Pure nightmare !! 

Or how about a program that would let you directly edit the light map? Could be useful for fixing those odd errors you get sometimes or just for creating some interesting effects. 

not really directly editing, but it would be awesome if you could both assign a bitmap image as a light pattern on a spot light as well as be able to specify 'noise' on both sunlight, minlight and normal lights. 

Probably the best way to create a program for editing the lights would be a custom engine. Just add the ability to "paint" by applying a dynamic light to the scene which gets written to the lightmaps fully. Then add the ability to save those back into the bsp. Only problem is that you'd have no way of restoring those edits to the bsp next time you compiled. Unless you recorded a demo of yourself doing it... 

 

Whenever someone says, "wouldn't it be cool if quake had..." chances are decent that pOx's eUtils has done it.

http://quake.chaoticbox.com/

I quote from the readme:

Tyrlite+ contains support for OpenQuartz ( http://openquartz.sourceforge.net ) LIGHT noise extensions. These allow you to apply noise algorithms when lighting a level to break up common color-banding problems, or acheive more "organic" looking lightmaps. The following attributes have been added to the eUtils Quiver defs for all lights:

"Noise Level" (_noise) accepts a floating point value from 0-1.0 (0 is no noise). You can "overexpose" the noise with values greater than 1.0, but the effect is usually undesireable (values of 0.5 or less are best for subtle effects).

"Noise Type" (_noisetype) can be set to 0 (Random), 1 (Smooth), or 2 (Perlin).

"Noise Resolution" (_resolution) controls the size or scaling of the effect. Higher numbers make the end effect larger (lower detail).

"Perlin Noise Persistence" (_persistence) This controls the perlin noise decay per octave.

You can use the "-noise" switch from the commandline to add random noise to all lights, but note that you cannot currently use noise on Global lights (Sunlight or Minlight).

Too bad it doesn't do noise on sunlight, pretty sweet otherwise though. Presumably you could get the code straight from OpenQuartz, but their hasn't-been-updated-in-five-years website wasn't terribly helpful. 

i guess you could rephrase my above post as 'wouldn't it be cool if someone haxored pox's stuff into aguirRe's utils? :P 

wouldn't it be cool if it was cross-platform? 

I thought all the id code handled byte swapping, could be mistaken though. 

we've discussed this before, but i have no idea where it went...

i wanted to implement this for my next map, and i was thinking:
send console command save ne_autosave
and in a config file bind f8 "load ne_autosave"
f8, afaik, doesn't do anything and it's both close and seperate from f9.

opinions? 

can you use stuffcmd to load the game as well as save it? that would be better. (i.e. when user hits "jump" or "shoot" while dead, instead of doing the normal thing, the quakec would trigger a load then.) 

this is for quoth, so no qc modifications.

but yeah, i don't see why you couldn't do that.

in void() respawn:
if (coop)
{
// make a copy of the dead body for appearances sake
CopyToBodyQue (self);
// get the spawn parms as they were at level start
setspawnparms (self);
// respawn
PutClientInServer ();
}
else if (deathmatch)
{
// make a copy of the dead body for appearances sake
CopyToBodyQue (self);
// set default spawn parms
SetNewParms ();
// respawn
PutClientInServer ();
}
else
{ // restart the entire server
localcmd ("restart\n");
}

it would just be a matter of replacing the restart command at the bottom. 

I need someone with UnrealED3 (the UT3 version) installed to take a brief look over a map I have been slowly working on for a loooong time now to help me decide whether I should continue slowly building upon it or whether I should just put it out of it's misery.

Download it HERE. 

As I'm making a frogman model I'm confronted with a strange qc compile habbit.

I reconstruckted the model on the enforcer qc, this means I used the shoot section to evaluate its harpoon action.
As I compiled the arrow suddenly blasts to the sky.
I couldn't find a reason for it, so I changed the
org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 16';
from the model_fire section into
org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';
and now the model shoots somehow left to the player, but not exact aiming its goal.

What I don't get is that they both seem to harm the player.
Also if I change the -24 a measure further the arrow shoots in the ground.
It seems impossible to aim it straight to the player.

Another strange habbit occurs on the model that's in the water.
It is the same subroutine I use for as the land model.
Only the land model shoots an arrow, the watermodel only shoots but there doesn't appear an arrow in water.
Does this mean the conditions for a model to spawn is different than on land? 

have you called makevectors(self.angles) before using the v_ unit vectors? 

as I thought this part was the positioning of the shooting angle of the model itself, it didn't make sense to me the arrow shoots straight to the sky.

void() harpi_fire =
{
local vector org;

self.effects = self.effects | EF_MUZZLEFLASH;
makevectors (self.angles);

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

Launchharpi(org, self.enemy.origin - self.origin);
};
 

ok, that bit looks fine, now you need to check if launchharpi is correct. 

It's the same as the enforcer, but I must admit it is not a usual qc.
It is a combination of two models, who will be going to be melted as a water and a land model.
So the problem might as well lay in another part, although both of the models use the same Launchharpi.


void(vector org, vector vec) Launchharpi =
{
local vector vec;

if (self.classname == "monster_enforcer")
sound (self, CHAN_WEAPON, "enforcer/enfire.wav", 1, ATTN_NORM);

vec = normalize(vec);

newmis = spawn();
newmis.owner = self;
newmis.movetype = MOVETYPE_FLY;
newmis.solid = SOLID_BBOX;
newmis.effects = EF_DIMLIGHT;

setmodel (newmis, "progs/pioen.mdl");
setsize (newmis, '0 0 0', '0 0 0');

setorigin (newmis, org);

newmis.velocity = vec * 600;
newmis.angles = vectoangles(newmis.velocity);

newmis.nextthink = time + 5;
newmis.think = SUB_Remove;
newmis.touch = harpi_Touch;
};
 

i see a potential problem here. you have a variable 'vec' being passed into the function, and you also have a local variable 'vec' being declared at the start.

remove the local variable and that may fix your problem. 

I'm not so familiar with the stats although I'll believe you.
Remove the local variable, is that

//vec = normalize(vec);  

No, this:

//local vector vec;

Then you'll be using the variable you passed in rather than the local one. 

yeah, the normalize(vec) is actually very important. normalize makes whatever the vector passed in a unit vector.
that is to say, the vector is reduced from whatever it was so that it's total length is 1.
this is how you can then multiply vec by an arbitrary number to create consistent velocity (ie: projectile always travels at 600 units per second). if you didn't normalize, the velocity of the projectile would change in relation to how far apart you and the enemy are. 

I included it in the qc, but I wondered. I always thought that the

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

positioned the point of shooting from the monster, where the last three numbers were the actual position of its gun.

With these coordinates I get a shooting frogman which shoots its arrow 24 units above its gun, but the arrow goes left above me.

http://members.home.nl/gimli/frogman.jpg 

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

assuming makevectors has been run, the above line will set org to a position 30 units in front, 8.5 units to the right and -24 units up (all monsters are 24 units above the ground, so -24 will make it right on the floor).

the reason it's shooting nuts is because when you call launchharpi, you are calculating the trajectory with self.enemy.origin - self.origin but your spawn point is at org.

in order for it to work correctly, the function call should either be:
Launchharpi(org, self.enemy.origin - org);
or:
Launchharpi(self.origin, self.enemy.origin - self.origin); 

It might as well be above my hat but it seems to work.
I just get a little confused by the -24 as it still shoots above the players head.
It reminds me at the moment I placed the new monster in game and it flew 24 units above the ground.
I decided to lower all frames. So it is this difference that shoots the arrow overhead. Can't think of a way to overcome this now. 

 

just take -24 off.

it's shooting up because you are doing:
self.enemy.origin - org

think of it this way:

self.origin = '0 0 0' (you)
self.enemy.origin = '128 0 0' (monster)

this would be both the monster and you being at the same height.

but now, you are calculating:
self.enemy.origin - org
let's forget about v_forward and v_right for now.
that makes org = '128 0 -24' because the math is: '128 0 0' + '0 0 -24' = '128 0 -24'.

so think of it like the enemy.origin is the gun which is -24, so it has to shoot up towards 0.

removing -24 from the vertical element will make the monster shoot straight horizontally.

remember shamblers, how their lightning goes downwards or droles shoot at the player's feet. the drole shooting at the player's feet was completely unintentional and was a by-product of the spawn point of the drole missile (which is above the origin of the monster, so it shoots downward at the player which is the opposite of what's happening to your monster). 

if you want the monster to shoot from it's feet, then change the trajectory vector.

instead of Launchharpi(org, self.enemy.origin - org);, do Launchharpi(org, (self.enemy.origin + '0 0 -24') - org); which will make the monster shoot at your feet too. 

Thanks for your clear explanation!

I understand now how this positioning works.
I just couldn't understand why the arrow kept shooting above the monster, although the cooordinates were right.

Then I realized when I imported the monster into Qmle it was 24 units above the ground.
So when I put these models back in game the arrow shoots right.

Now I need to know how I can lower the model 24 units and keep their original shooting point.
It sounds kinky, but it seems Qmle imports models rather rough.
One moment they are exact on the 0'0'0 axis.
But after playing in game they suddenly drop 24 to 48 units down the zero line.
Also it seems as if there is no difference between the zero line and, let's say a multiple above or below. 

all monsters' feet are at -24 units. 

Noone has UnrealED3 (UT3) installed? 

Heh - my first time ever looking at UnrealEditor. The level looks pretty smart, You obviously blocked it out with the brick texture. I never work like this, although I know a lot of people do. I actually dont think that the red brick texture should be used anywhere in this map. I think if you went for some tech-style textures (metal panels etc) which would go with the trim. The trim (the meshes and stuff) look like they are out of a spaceship, or an oil-rig or something.
I think you would find that the level would start to materialise into something which looked a bit better-themed if you slowly went through the map and replaced all of the brick textures, with dark metal panels and suchlike.

The layout looked prety interesting - multi-tiered, and nice interconnection. So I would say you should finish it for sure. Just do more with tech-style texturing and good old brushwork :D

Nice work 

Tell me, what features do you like and what parts do you not like. anything goes.

It will be implemented in Erlang with plugins written in Erlang. The newest release of Erlang includes wxWidgets and OpenGL so I decided to learn how to use wxWidgets. 

I'd say these are the important features:

Good Cameras
Decent Texture System, with texture lock and multiple WAD support
Ease of use entity listing (def, fgd, whatever)
Ease of install / setup
Slice Brush Tool
Vertex Manipulation Tool
Prefab Library

Probably some stuff I'm forgetting there. 

Viusal (named group) hiding is nice as well. 

| Good Cameras
Is that good camera controls? Ability to change camera positions quickly? i have an idea (look below)

| Decent Texture System, with texture lock and multiple WAD support
I consider multiple part of the virtual file system I will have to make.
Texture locking is for moving brushes, correct?
And what kind of User Interface controls are needed, tagging textures and using that to browse sounds usefull for instance.

| Ease of use entity listing (def, fgd, whatever)
I already started with using a fgd file to see how i can make my own format: http://3spire.com/quake.txt
it is based on Erlang terms and can be loaded easyly, will this format work?
Configuration will also use this kind of file, so that it can be loaded easily.

| Ease of install / setup
I plan on using the same install system of Wings3D

| Slice Brush Tool
| Vertex Manipulation Tool
These should be able to be done with plugins

| Prefab Library
Also done with plugins, so that the prefabs can be configurable

| Visual (named group) hiding
I would like to be able to provide multiple views into the same map as represented as named tabs. Each tab can control visibility of each brush/entity and the positions of the 3d camera and 2d grids.
Another idea is to make brushes and entities each belong to multiple layers, and hiding/showing layers are per tab as well. 

QuArK does some things really well.

-I LOVE the interface (how you create and edit things) and could never get into the major brainfuck that are the radiantish editors (Blender is easier...). Not to mention not having a mess of lines but just dots for the grid. So such an interface would get my love.

-All the texture alignment features (apart from locking I think).

-grouping things in folders, also being able to hide those.

The texture browsing is badly implemented, vertex editing is plain horror.

So Vertex editing is what I am after the most. Especially if you could then triangulate for new edges. 

Cameras - all of those. Extras like 'walkthrough mode' and so on are just a waste of time, although a feature I'd like to see is 'mangle readout' so that placing camera entities inside the level becomes easier.

Yeah, texture lock means it doesn't move when you move or rotate the brush - not an easy technical challenge. Changing projection options between local / global is useful as well.

Tagging isn't as useful as it sounds, even though it does seem like you're going for an 'all wads on the HD' approach (which is great). I say this because wads are usually named in a fairly logical fashion - the ones that aren't tend to be not very good. For me such a feature would be an extra. If the texture listing is alphabetical then you're probably good.

Having said that a 'currently used in map' toggle would be good. Worldcraft is a popular editor (I use it as well despite the bugs) which has a very nice texture system - you couldn't go wrong by copying it.

For an entity list remember that it needs to be editable by mappers who may not have any coding knowledge - the simpler the better.

Tabs = win. Especially if they're user editable.

And finally, make everything you can customisable as far as the interface goes. Nobody works the same way, so the easier it is to turn the grid from lines to dots or chocolate drops the better. For example :)

Like with most 3D editors, ease of use and end user customisation options tends to win out over powerful functionality. 

'Worldcraft has a nice texture system' that's only true if you count not having to convert the wads (in 3.3 at least, 1.6a has shitty texturing). 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

I think strong brush manipulation tools are key for working with large and complex objects - actions like flipping, rotating, scaling are very helpful and save time for the mapper.

Also, it's probably not a must have feature but I really love 3-point clipping. 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

this is the first thing that came to me mind.

as grahf said, good brush manipulation is a must. rotating groups of brushes by arbitrary angles (with intelligent vertex snapping onto the grid). more powerful automation of texturing over curves (being able to propagate texture alignment as if multiple faces were a single one, for example). mixing between the straight forward regioning of gtkr and vis groups of WC.

basically this late in the game, it'd take a lot to make me switch editors. 

I have always wanted to create a mapping program, but the interface bits is my more immediate concern.

I would like to get this to a level of making maps for Nexiuz.

I also would like to model the editor to be more like Wings3D, where there are commands that can be done on vertex, edge, face, object.

And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object.

for curve texturing, that sounds possible with the internal representation of the brush I have decided to use. And it annoyed me as a mapper that I had to manually adjust texture offsets to get them to match.

This is not the best time for me to start a project (getting married in a month and I travel alot) but this will defiantly sustain my attention. 

"And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object."

This is something that I wanted to do for ToeTag but, brother, it's a bitch. If you can get it working it'll be great but I haven't found a nice, reliable way to break down meshes into convex chunks yet.

Although I haven't tried my octree idea yet... that one had promise. 

In fact, if you've got a handle on things like how to do texture locking and breaking down meshes and that sort of math in general - we should get together and maybe do a cross platform version of ToeTag or something. 

concave, not convex, right?
That feature would be a true killer feature. 

dunno if this is what you mean, but it would be awesome if you essentially build a 3d mesh out of n-sided polys just like in 3ds max and the editor would automatically split ngons into tris. afterwards, it would look at the face normal and whichever direction is closest, north, south, east or west, it would simply extrude the face backwards, keeping it parallel.
ie: you make a collection of faces that face upwards, it would extrude the face down allowing you to make cool trisouped terrain easily. the same could be applied for caves. 

Madfox looks very nice the frogman :) 

Type of advanced brush treatment you're describing isn't in any bsp editor I've seen (anyone else?) so if you need testing then let me know.

I'm pretty busy so testing to destruction I probably can't do, be an update a week wouldn't be a problem. 

http://groups.google.com/group/maperl 

 

Yeah, all the mappers are here. :) 

all editors are there....

preach, you've got email. 

Does Toetag work in Linux, since Apple's current operating system is mostly Unix based ? 

Would using a GPU for VIS be a possible (and sensible) idea? 

"Does Toetag work in Linux, since Apple's current operating system is mostly Unix based ?"

No, it heavily relies on Cocoa and Objective-C. The underlying OS isn't really a factor. 

Radiant is probably your best bet, either the venerable GTKRadiant or the somewhat newer fork NetRadiant. 

What went wrong with your building outside the limits experiment? I don't remember :P

I'm thinking of a similar sort of thing, a brushwork skybox. 

99.60% and it takes longer than forever even on a quad core machine. At this rate, I estimate it will be done in around five days. However, the problem is that I will be out of town for a month tomorrow (I'll still have a computer available, but a slow one).
So, does anyone here by chance have a really fast machine and is willing to help me out? Willem, that 16 core thing of yours - would it be possible to use it for this or is it only for work stuff? 

ijed: absolutely nothing! you can build outside the +/-4096^3 playable area to your heart's content, just don't ever let the player walk past that boundary because they 'loop' back to the opposite side of the map (like in pac-man) but the collision behaves as if you hadn't looped back.
also, don't let the player shoot projectiles past the boundary because they loop back too. if this is for RQ, it would be a good idea to place triggers along those boundaries to remove projectiles.
also, as a side-effect to this looping, you can't place any point entities outside the boundary, but bmodel entities are ok.

there is a hard limit though. you can't build past +/- 8192. anything beyond that doesn't get displayed at all. in fitzquake, it looks like you have farclip on-- it's just cut off at that point and you see the void (or hom).

this behaviour is attributed to the fact that the coordinate system of the server runs on variables twice as large as that of the client. 

Play russian roulette: Set up a script that zips and uploads the file in 120 hours, then shutdown the pc. 

negke

I could try and run it but it IS a work machine. I can't tie it up endlessly with a VIS process... 

with 16 cores, just keep like 4 for you and the rest for vis. :P

well, unless it's used for cg rendering or something and let me tell you, 16 cores rendering would be pretty damn badass. 

 

are you could just make a script upload the file every few days along with it's .vis file to the same spot and you can keep checking to see when you have a complete map by starting the vis process up on your slow machine. 

there is a hard limit though. you can't build past +/- 8192. anything beyond that doesn't get displayed at all. in fitzquake, it looks like you have farclip on-- it's just cut off at that point and you see the void (or hom).

this behaviour is attributed to the fact that the coordinate system of the server runs on variables twice as large as that of the client.

this is not quite right. Both server and client use floats for their coordinate system, but the network protocol uses a special 13.3 fixed point format when sending coordinates. This means 13 bits devoted to the integer part of the number, and 3 bits devoted to the fractional part. So the precision is 1/8th of a quake unit, and the highest possible number is 4095.875 (lowest is -4096)

so when a client is rendering anything with coordinates that come from the server, it will never be outside that range. But the server side location and physics are actually working, just what you see is wrong.

The question of how far quake can draw world polygons should just be covered by the gl_farclip distance, which is configurable in some engines. Not sure if there are any other factors besides that. 

I made a google group because this forum is not very efficient, its only one thread. 

oh sorry. when we were talking about it before, it was a little complex so i guess i forgot some of it.

i'm not really sure what was happening regarding that 8192 hard limit, but that no matter what gl_farclip setting i set, i could never seen beyond, what i was guessing would be 8192 units away from the origin.
there was a solid cut off with just void at that point that didn't move at all. 

hmm, must be some other cause then, maybe the vis tool uses some distance limit? Does it show up with r_novis 1? 

Willem: Hm, I see. Don't want to cause you any trouble of course. I just want to finally get this thing out for good (and as soon as possible, not only in October). Maybe you could at least let it run during a lunch break for an hour or so to see how much progress it makes? I would then continue from there.

Spirit: Indeed, but I don't like the idea of leaving the computer on for such a long time when I'm not around. 

negke

Sure, email it to me or put it up somewhere I can download it. I'll run it overnight or something if you want... 

 

if anyone is still interested, my solution to my problem above with long vis times was simply to remove all the terrain into a seperate map. that map will only get a quick vis, leaving the left-overs of the original to get a full vis (which only took 20 hours vs 700-1200~, lol). 

What does that mean? Can you have separate maps like that for release, or is this just a way to let you iterate without killing yourself? 

I am confused about what you said.. Is it really possible to fastvis only one part of a map, and then fullvis the rest of the same map ? How do you do that ? 

Having a .bsp placed in the map as a model? 

sorry for the confusion, i just meant that i split the map up. the first portion has enough terrain to connect the interior areas, but i reworked gameplay such that the majority of the terrain could be removed and placed in a seperate map to be played linearily after the first.

terrain seems to be a serious vis killer. all those odd angles and varied planes really fucks the BSP process up resulting in thousands of extra portals or whatever. since the terrain section is mostly wide open anyway, and vising would have limited to no effect, that map will just be fast-vised. 

i would be incredibly bad-ass if you could, for example, modify qbsp so that if you cover an area with a 'fastvis' textured brush, any portals (or whatever they are) that are touching that brush are ignored in the full-vis process. :P 

Maybe placing bsp's as entities could work. How it'd not get screwed by vis (flickering entities) would probably depend on dividing it up into chunks with some trial and error though. 

lighting something like that would be a nightmare though. :S 

depends on the engine i guess. with a shiny swiss army tool like darkplaces it should work fine. for some fun copy some map to progs/player.mdl and do chase_active 1 plus chase_back 3000 (or something like that). a piece of cake for dp.

proper lighting (for the "external" objects "in" the terrain map) would hard though,yeah 

Where can I find a suitable add new weapon qc?
I searched at Inside3D but all there is are modified already ingame weapons. 

It's just a matter of finding the right tutorial:

http://www.inside3d.com/showtutorial.php?id=60

This one is about adding new weapons. You do have to pay attention to some of the slight cheats they have to use. One is that rather than setting up a new key to press for the weapon, they make it so that pressing 2 twice brings it up. They also don't make a new entity in the map for it, which is something I expect you'd do if you're making a custom map. 

Building http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qeu03.zip on modern Linux is easy, just remove the lines containing the del and coff2exe references.

And now I'll continue the search for a commandline mip2saneimageformat tool. Could not get MIP2BMP.EXE from http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qmaphack11.zip to work with Dosbox. 

Niels Froehling's QuakeTools-library would be an epiphany but compiling is just not possible without a tremendous amount of work I guess. http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qtools0.3-src.zip 

the right tutorial indeed, but after covering all errors I just keep
drawing 2 untill I too error.
Seems as if replacing v_shot.mdl is an easier way for testing.

Strange to conclude these tuts are so wicked in error messages.
Although they added my EathQuake. 

i've been trying something new. essentially, working only from the top view, i'll drag out brushes 32 units high of varying width and length creating floors. i create a significant portion of the map at a time in this manner and i specifically try *not* to pay much attention to the size of those floors, other than keeping them on a 32x32 grid for texture alignment purposes.
i'll make the decision that, say, a generic hallway is 192 units wide, but everything else goes. a room can be any dimension (and any combination of brushes to create the final shape).
after doing this, in a side view, i'll semi-randomly move connected sections of floor up or down up to 256 units (in either direction).

this can lead to some pretty weird and convoluted shapes with that sort of 'tumor growth' mapping look. 

pics to demonstrate, please? 

I just installed GTKRadiant to try some Quake editing, and I set up the paths all right, but it won't load any textures other than the SHADER NOT FOUND one. When I look in the console it says:
Texture load failed: "textures/"
Any hints on what could be going wrong? 

In the latest version of GTKR 1.5, I just put the .WAD files in C:\Games\Quake\id1 and point the editor to C:\Games\Quake for the game engine path. 

How do I extract the WADS from the PAKS? I've tried several programs but I can't see any .wad files anywhere... 

the wads aren't in the pak files at all, but you can get the textures from the individual BSP files.

But you can also get the wads here: http://www.quaddicted.com/wads/ (look for "quakewad" i think") 

Downloaded the quakewad file and put it in id1... Now works perfectly! Thanks! Although you need to rename the quake101.wad to quake1.wad. 

What light program and command line options? How many light entities? (relative to the number of brushes maybe, just to give perspective). Do you use minlight or skylight or both? How long does it take to run the light part of compiling the level.

I'm real curious about this cause I read a post where Than said the Plumbers Carry Shotguns level took about 25 seconds to light, and my current map is taking almost 10 mins for a high quality pass. There were 2758 brushes and 16621 faces at the time of this run:

----- Light 1.43 ---- Modified by Bengt Jardrup

Extra 4x4 sampling enabled
Soft light 3 enabled
Soft distance 16 set
File: c:\quake\id1\maps\wish16.bsp
Using minlight value 15 from worldspawn
1079 entities read, 625 are lights, 13879 faces, 3.9G casts
4 switchable light styles

lightdatasize: 467 kb

Elapsed time : 9:58 

Many of my maps have taken double that (like 20 mins) in the past.

Plumbers Dont Wear Ties is a detailed map, but not too detailed, but also its not really that big. Its a realistic scale, and its condensed, but its not very big compared to say the Warp maps or Marcher Fortress. Load Bengts engine and load the Plumbers map and type into the console "lightmaps" and try it with your own map too. Lightmaps are if you like "X amount of texture worth of light info", so the bigger the map (so long as the texture scale is 1:1) the more lightmaps.
Also if you have plenty detail in your map that wont help the speed (but it will make the map look sexier :).

I wouldnt worry about it too much! 

I probably should have mentioned I used a Core2Duo e6850 (2x 3.0 GHz) with 2 GB RAM.

I wasn't worried really, it just seemed like 25 secs was way low for a map like that. I ran id's e3m1 this morning with the same settings as I used for my map and it took 2 mins 14 secs.

Anyway, I'm still curious how other people light their maps. 

this is my understanding of the issue...

When you have multiple lights with inverse falloffs hitting the same surfaces over a long distance, the light time tends to go up. With inverse and inverse square falloffs, the light level never completely hits zero, so if a light using those formulas is in a wide open area, all the surfaces within line of sight of that light have to be calculated, even if the light level only increases infitesimally.

APSP2 was a fairly narrow and cramped map, so while it was detailed, none of the lights had to cast very far.

The extra 4x4 sampling and soft stuff increases the time as well. But thankfully, light calculation time is not painfully exponential like vis, it seems to increase fairly linearly. 

Rick: are you sure Than didn't say 25 minutes? to me, that would seem more realistic for a map of that size with the amount of lights present. but maybe he just has a monster machine...

grahf: aguirRe and i had a discussion about this kind of phenomenon with inverse square lights. mostly it was regarding how using that delay type with switchable lights could quickly run up to the max lightstyles on a face warning.
he implemented the 'fade gate' command line. essentially, it will cut the light off once it's light level has been attenuated below a cutoff point.

setting -gate 1 on aguirRe's light util will cut down on lighting times by a large margin because it's disregarding a lot of lighting that wouldn't even be seen.

back to Rick: as for light utils and settings, for preview compiles, i use:
light -gate 1.0 -fast -soft
and final compiles is:
light -gate 1.0 -soft -extra
i don't use extra4 though, because that is just insane and will take millennia to compile. aguirRe recommends -fast -soft -extra4, but i haven't tried that yet.
it's really worth your time to look through all the info aguirRe has on how to use his tools: http://user.tninet.se/~xir870k/readmevis.txt the lighting tool has a huge amount of options in there. 

Yeah, extra4 basically takes about 10x as long on my maps, so for a quick look I don't use it, with just -soft it'll light in about one minute.

I did read through all that documentation and it was very helpful, I've been experimenting with a lot of the new stuff.

I wasn't real clear on the Gate thing, but now I think I understand it. I'm also not certain exactly how the -softdist is supposed to be used, but it seems like I get a lot fewer of those abnormally dark faces when I use that option. The documentation (I think)indicated using small numbers like 3 or 4, but I've been using -softdist 16 

i guess it's impossible to change the player model's angle without having to use fixangle = 1 (thus changing the angle the player is looking?

it seems i will have to replace the player with an invisible sprite and then make a dummy model that follows the player's position in order for me to get the results i want? 

but you probably need to use an .mdl, otherwise there might be engine issues (i know the weaponmodel expects to be a mdl, not sure about playermodel) 

i got it working with a sprite so seems everything's ok.

btw, your chase camera is kind of wonky and is prone to being shaky at times. it seems to pick up on stairs and angled floors in front of the player, where the crosshair is pointing or something. just fyi :)
i've also noticed a bug with the camera where, if you are looking down, and the camera is higher than the player, and you enter into a tunnel where the ceiling is lower than where your camera is, the camera goes psycho and starts moving in huge arcs outside the map. (this is with chase_up set at 32, which is higher than the default) 

yeah, it kind of sucks. I sort of stopped trying to fix it once i realized it's pretty much a gimmick and Quake is better in first-person mode anyway :) 

Cannot compile in GTKRadiant 1.5 for Quake. Anyone know how to fix this for GTKRadiant 1.5? 

Try the "search on this page" option while vieuwing all posts of this thread upwards with the word GTKRadiant. 

but helpfull. 

just looking around at the quake sources.......

how the fuck did they get any of that to even compile? o.0 

I know it's easy to point and laugh at the original Quake maps but those guys built some pretty cool levels with technology that was changing on a daily basis. That's tough to do. 

Not to mention the primitive tools. QuakeEd was ... pretty rough. 

i'm not laughing. i'm serious. the original qbsp was incredibly finicky which is what taught me to map with incredible precision making sure everything lined up properly etc etc.
looking at maps like e2m2, it's almost like divine luck or arcane power that would have allowed it to compile without exploding. 

But when you look at it you can see that they're at the minimum level of compilability.

Which means each of those maps must have undergone loads of iterations to reach that level, probably starting with something resembling Escher vomit.

Like Willem says, after ten years of trial and error with bsp it's impossible to make a comparison. 

I constructed a terrain map with triangles.
After fitting all polyhedrons well tight the light seem to cast all kind of rare shadows.

Is there a way to avoid this odd behaviour? 

depends.

if you're using aguirRe's light
i found -soft will make these shadows a lot. even if the faces are perfectly connected. obviously, not using -soft is a solution, but not a good one. if this is a preview compile, and you have -soft and -fast, usually not doing -fast will reduce it.

it's always there though, afaik. smooth transitions of angles like terrain don't seem to go over well with any of the quake tools. :P 

one thing, you can try using _anglesense 0.1 on lights hitting the terrain (and _anglesense on your worldspawn for sunlight). setting angle sensitivity way down like that will make light not attenuate much on different angles. this makes it look very shitty and weird (faces not really facing the light will still be bright as if they are directly facing it) though, so it may not be a viable solution (i haven't tried it) 

I made a polyhedron from a cube and cut of a pyramide on top.
After some punctual accurasy it can be used for terrain maps.
Point is that after placing it on grid and changing the topangles also replaces the cube foot after forcing it to grid.
So if I don't force to grid the lightning looks well.
After forcing it to grid the slopes cause black shadows.

I will try your light options. 

anglesense either, but according to AguirRe it will give a softer, more diffuse lighting effect.

shadows on triangle geometry are always a problem - AFAIK they cannot be solved 100% - but I've never had the problem. So far. 

My map compiles with no issues, but when i goto open it with my client i get an error of "too many static entities" any ideas of what this means? 

Not to state the obvious, but you've gone over the static entity limit for Quake. You'll either have to reduce the number of static entities in the map or play it on an engine that has a higher limit... 

whats the limit then? I'm running ezQuake as a client... I've looked around and most sources said its a limit of 128 is that true? then i noticed a post by rick earlier and by reading his post it said that he has 625 light in his map... how is this possible i think mine is 172 if im not mistaken... 

yes, 128 static entities is the limit.

not all light are static entities. essentially, only an entity with a model can be made static, so this only includes flames and torches. normal lights with no entities are not counted.
try to replace your torches with normal lights and use light textures instead if you can. 

damn.... kinda defeats the mood of the map im creating.. looks awesome with all the torches... thank you for the help... 

one more thing... is the 128 limit going to effect my backpack and flags too? because they have a model attached to the entity... 

you could look into other custom engines, i suppose, although curiously, a fair few custom engines which do have bumped up limits still have the old 128 static entity limit.

both fitzquake and aguirRe's glquake allow many more static entities, but as you're using ezquake, you may not be satisfied with those engines because they stick pretty closely to the original glquake. 

cross posted, re: 9096

there's 2 types of entities in quake.

static and dynamic. dynamic is most types of entities like monsters, items, doors, triggers, etc. these are also called edicts, and you can have a maximum of 600 edicts in a map.

the only reason torches are made static is because they never move, and never interact with the environment in any way. 

Correct me if I'm wrong.

1. You can't trigger a trigger_monsterjump.

2. A trigger_once can't have a killtarget or it won't trigger it's actual target?

3. Clip brushes can be part of a func_door and will push monsters.

4. The model limit is 256. 

1. nope (trigger_monsterjump has no use function)

2. nope
killtargets are processed first, before targets are.

3. i know it definitely pushes the player, so probably monsters

4. yep 

Well, I though clip brushes didn't affect monsters since they won't cross gaps filled with them. Maybe that's a game logic thing though. 

that happens for a different reason. ai decides how it moves based on the visual hull (hull 0) while collision is based on the respective hulls (1 and 2). a monster could walk over a clipped service and wouldn't fall, but the ai decides not to. 

For a clip brush to be part of a door it seems like the clip brush has to be surrounded by regular brushes, or maybe the door model has to be bounded by real brushes. Something like that. I had a door with two regular brushes at the ends of a long clip brush (looking from above) which pushed some scrags upward and it worked. I removed one of the real brushes and then it didn't work. 

but i believe that the clip brush must be within the mins/maxs bounding box of whatever bmodel. 

Clip must be 'inside' the normal brush model or they won't collide.

BBOX explanation - the space is defined on the grid with three negative and three positive numbers. so -1 -1 -1, 1 1 1 gives you a 2sq cube.

All objects work like that, including triggers. So don't expect a L-shaped or diagonal trigger to have an Lshaped or diagonal area of effect.

The only trigger that can be triggered in standard quake (I think) is trigger_teleport - useful for the classic black box monster spawning or auto-porting the player when a condition is met (eg. kill an enemy). 

I made an elevator in the corner of my map to bring you to the top of this little bunker, but it seems to always start moving upwards just before you get on... Is there a way to decrease the 'sensitivity' of it so i can get on first? 

func_plat activation trigger is based on mins/maxs of the bmodel in question. the only alternative is to use a func_door + trigger_multiple combo instead which would allow you to set a custom trigger size (or change the func_plat). 

This has been covered before I'm sure, probably in this very thread, BUT...

I've downloaded GTKRadiant 1.5 for my Windows BootCamp partition and it's running fine ... except I don't understand where to put my WAD files so it can see them. Any hints? Their documentation is equal parts missing and abysmal. 

OK, after reading way back in this thread I see I need to put WADs into Quake/ID1 but that seemed to be crashing GTKRadiant this morning when I tried that on a whim. I guess I'll try it again tonight. Weird. 

It sounds like you're using a door (which is triggered as soon as its touched) instead of a plat (which triggers when you reach it's center).

Give the door a name and make a trigger_multiple to make it start moving. Put the trigger_multiple right on top of the door/plat and make it 32 units smaller in the X and Y directions that way the player will have to be completely on before they touch the trigger.

You'll probably want the delay before reset time on the trigger to be long enough for the door to complete it's travel up and down. 

does the ai use the visible hull? bug or feature? 

But its the cause of fish and scrags sometimes going through walls, although the bugs are slightly different. 

It was an odd shaped platform which seemed to be the issue... So I went with the basic square shaped one instead. 

If your platform was a Z shape for example, then Quake would just draw a big square bounding box for the trigger. Slightly smaller than the Z, but not following the shape. 

Sorry for the string of noob-ass questions, but I'd really like to be building something by tonight.

Do GTKRadiant users typically compile from a command line or do you go through the trouble of telling the editor where to find your compile tools? If you go through the trouble, how do you do it? Is it a hassle? 

not gtkr, but i use sikkpin's qe3 which is essentially very similar.
i never use the menu system, although i believe it's the same thing. i have one of those gamer keyboards, and i have a macro to compile my map bound to one of the keys.
before i started using qe3 (and before this keyboard) i was using gtkr1.4 and i'd just keep a command prompt open in the background and what i wanted to compile, i'd just switch to it and use the previous command button which would launch a batch file. 

As necros said, just use batch files for compiling, the in editor menu gets a bit trippy when compiling for Q1.

Also, you might want to try using GTK1.4 and mapconv, there's a tutorial how somewhere on necros' site [ http://necros.planetquake.gamespy.com/gtkrq1.html ], the interface/creation flow was changed quite a lot in 1.5, for the worse in my (and a fair few others') opinion. You may prefer the 1.5 interface, but I'd suggest trying out both versions and making your own call... 

I set up the in-editor menu. It's pretty easy, you just edit the XML file sitting in the q1.game folder. The one thing I can't figure out how to do is copy the BSP to the right directory and start the game up. So I need a command line open for that regardless...

Oh, and here's a story for the stupid. I set everything up last night and I made a small test room with a light. It compiled, loaded into the game, everything was grand. I then booted back into OSX to resize the partition I gave Windows because it was too small (FYI, 15GB is too small for Windows Vista and a Quake editor). While doing this, I misunderstood something and ended up killing the Windows partition entirely.

So ... I re-created it and reinstalled everything AGAIN. Only this tims I allocated 32GB. Let's hope that'll be enough. 

windows partitions need about 10gb (or more maybe, for vista?) just for the OS itself and then you're gonna want at least 2-4gb for your paging file.
you never really notice that when you're setting it up on a native windows machine, but when you're splitting between mac and windows, it becomes noticeable. mind you, mac isn't exactly a lightweight either; i spent a couple of days cleaning out all the useless software on my macbook, but i needed about 80gb for my macos partition to be able to work comfortably.

anyway, on the subject of gtkr, i personally hated the 1.5 version of the program. they changed fundamental UI stuffs in there which made it a lot slower to use (eg: operations that used to take 1 key press now would take 2), so even though 1.5 supports q1 natively, i found it harder to use than to just save a q3 .map and have a batch file that runs a converter first (aguirRe's, i believe, is the most up-to-date) and then compiles.

as for batch files, just make a bunch of them (for different compile levels) and put them on your start menu (or get rocketdock which is essentially the mac dock for windows) and you can just click the appropriate one and never have to touch a command prompt. 

My c: is 80gb 

Yes, I'm gonna keep on beating that dead old horse. 

I'm thinking about installing Quake and GtKRadiant on this new Linux box I've got.

Can anybody point me in the right direction? 

the gtkradiant based off 1.5 that the darkplaces/warsow? guys use. 

Is there a way to make it so I can launch FitzQuake to check out my level without it resizing every window on my desktop? Or is this just a Window wart that I have to accept? 

OK, I guess the answer is to run GTKRadiant in a non-maximized state. That seems to reduce the amount of swearing I need to do each time I test the map... 

if it's fitzquake 0.85, you can run it windowed but with a -height and -width equal to your desktop -- this will fill the screen completely but without your desktop actually switching modes, which might help. 

Ahh. that's something I hadn't thought of. OK, will try, thanks! 

setting sunlight?

good value for day time light?

I don't understand the angle situation. I've just never bothered to. Can someone give a simple explanation of how they'll work? 

No, but just read AguirRe's docs:

http://user.tninet.se/~xir870k/

More and more concise information than you'll need. 

 

Thanks Ijed. I can't believe I haven't read through that stuff already!
Kind of confused about the implementation of 'second suns'.
My basic understanding is that I just put _sunlight2 in worldspawn with a lowish value and it will lessen ugly shadows? 

or take one sun and lighten those ugly shadows with a light.exe -light 15 so the deep darkened places keep their luminance for a degree of 15. Helpfull, while it diminish placing lots of extra lights.
^v^ 

it's really not _sunlight2, it's _sunlightarea_minlight.
it's a different minlight for areas that the sun hits. 

Thanks guys, I think I actually get this now. 

I confirm that this solution to Hammer 3d window selection issue works:
http://www.celephais.net/board/view_thread.php?id=4&start=8179

I have put this file into the hammer directory and the problem on my laptop is fixed.
http://rapidshare.com/files/138119760/atioglxx.dll

Great! I can continue now. 

I just wish there was a similar fix for Nvidia cards. 

It works, but if I look at a face and not all of its verticies are visible in the window then the projection screws up, aligning the last UV coordinate to any other visible vert.

That's a bad description. Basically the UV's are all fucked up. That's better.

And Orl, there will be such a fix for your card, AFAIK Nvidia is much better supported, although to be honest I didn't know there was a WC problem.

What the DLL does is disable stuff, you'll notice there wasn't one there beforehand. WC checks if one exists and if so uses it in favour of the onboard library.

Does anyone have the knowledge + inclination to make one that forces software mode on? In WC1.6a there was an option for this :P 

Maybe I don't understand the problem with UV's that you described, but try to enable Texture Filtering in 3d options window. After enabling this option the textures look ok for me. 

If it works my mapping time will double. 

And Orl, there will be such a fix for your card, AFAIK Nvidia is much better supported, although to be honest I didn't know there was a WC problem.

Unfortunately, I very highly doubt there will be a fix. Basically the problem is, using any Nvidia drivers after version 182.50 in Worldcraft 1.6a in software mode, the 3D view is completely garbled, making it impossible to see anything.

And yet, even the older Worldcraft 1.1a's 3D view works perfectly fine with the latest Nvidia drivers... strange.

For whats its worth, I'm running Vista SP2 with an 8800gt. 

That works; turning off filter textures. Can't believe after pissing about with all those different (non) solutions I missed that option.

So the dll + filter off solves it for me - thanks!

Orl, have you tried 3.3? It might sound like a ballache to switch, but the texture lock alone makes it worth it. The renderer changed a fair bit (which is why I and others have had problems) but maybe its worth a try so you can map. 

textures and wc 3.3

does anyone else have problems converting texture files (not just because of overly large textures) with Bakers wad converter?

I think RT23 had some issues with that too - or maybe he helped me with mine... It's all foggy... ...what year is this? 

But the wads you wanted were weird

I never had that problem until I tried to convert that WAD which you were saying you couldnt manage.

Cant remember if I had to use texmex or wally as well as the supplied util. Its all on this thread somewhere, lol!

Most textures convert fine, it would seem to be some wads which dont (!) 

I hope somebody here can help me.I have make some small maps and trying different stuff they compile right and start. But the lighting isn't just right... I don't know what's wrong. I downloaded the original quake one maps in a .map format and there is the same problem.

The map E1M1.bsp for example. Some corners and the first double door left is way to black. On the door you can't even see the textures....
Many places are pretty same as in the game but when i started the original map in the Pak0.pak not through Worldcraft everthings is normal.


I use fitzquake085.exe for the game and the Quakeadapter tools for compiling and testing.

What tha hell am i doing wrong ???
Please reply cause i want to make a real map and not test maps anymore, and that's the only problem that prevents me from getting starting.

sorry for bad english i am from germany! 

Open the .map file in a text editor, find some of the light entities and copy the text and post it here.

or upload one of your map files and ill take a look if you like.

Also take a screenshot of the Run Map window you get in Worldcraft when you press F9 "to run the map" and another screenshot of the "tools -> options -> Build Programs" window.
Seeing those might help too..... 

Some corners and the first double door left is way to black

Maybe you use the wrong light options?
With Aguier's compilers you should have good results with let's say:
light.exe -dist 0.6 -range 0.6 -light 15 -soft

http://user.tninet.se/~xir870k/ 

the converter doesn't convert any of my wads. I could try to convert id.wad and it wouldn't convert.

actually...

"Error creating HLWAD: c:\program files\worldcraft\textures\id_base.hlwad ... details ...No log exists."

So, I guess I'll have to convert them with Texmex? I don't really even know how to do that - anyone have links to more info on this?

Oh, and good luck bobbbybob - i'm sure you'll figure it out if you follow Ricky's advice. 

I dont really understand how the tool was made.
I mean what is .NET framework, cause I dont know if the tool uses anything like that or even anything different or what-haveyou.
Its pretty weird that it dont work for you.
I have loads of hlwads on my HDD.

http://www.mediafire.com/imageview.php?quickkey=rjm5lvzf3i3

If you would like me to mail you any of them I will do happily :D 

I get the same error. No solution yet.

BobbbyBob, post a screenshot - map data could help, but it sounds like you've got something badly configured somewhere in WC.

The screenshot will clarify the problem. 

"Error creating HLWAD: c:\program files\worldcraft\textures\id_base ...""

Are either of you using Vista or Windows 7?

The qconverge command line utility expects to be able to write to the folder it is in.

And come to think of it, the QuakeAdapter expects to be able to create a .bat file to execute.

I know with Vista the idea of having write-access to any given place isn't exactly a certainty. 

and converting txtures via texmex, don't have a texture problems at all,

maybe it's time to switch to hammer editor to you guys? ;) 

Vista. It occurred to me that the security crap is most likely blocking the thing from working. Turning it off spams error messages so I was about to try converting in a 'non-secure' (aka 'non-fucked') folder last night but got caught up in something else. 

Might be helpful to some for a better understanding why things sometimes take so long.

Courtesy of BJP:

OK, this is just my interpretation of how vis works, it may not be correct.

Apart from its normal bsp building from the map, qbsp also generates the portal (prt) file. This is done by dividing all the empty volumes (player space) in the map into smaller pieces, called vis leafs. The more complex solid architecture, the more leafs you get.

These leafs are just convex polyhedrons (like brushes) with at least four sides (the simplest pyramid). All the sides of the leafs are the vis portals ("doors between leafs"), but I'm not sure if the sides against the solids are also counted or it's just the sides between the leafs.

When calculating visibility, all these leafs have to be checked against each other to determine which ones that are visible from a certain leaf through all of its portals. It's assumed that the player can be in any of the leafs (no matter how small they are) and look in any direction.

To make things worse, visibility is checked twice for each portal, one in each direction (back and forth). I don't know why this is.

It should be noted that this "leaf visibility" calculation is a simplified variant of the more realistic point-to-point visibility, which would probably take even longer time since the position granularity is higher. The leaf visibility method also increases engine overdraw, i.e. it'll have to render stuff even if it's actually occluded, thereby increasing r_speeds.

Since all leafs have to be checked against each other, this is a variant of [at least] an "n x n" (n being # portals) problem, which will scale very badly as n grows. This is the main reason why more complex maps take so extremely long to fullvis.

In fastvis, vis first makes some simple analysis and determines which leafs that can be trivially rejected as being invisible and all others are marked as "potentially visible", i.e. need more calculations using fullvis. If you just run a fastvis, all the potentially visible leafs will be rendered by the engine as visible, slowing things down. When building a map to be fullvis-time-effective, it's probably vital that fastvis can trivially reject as much as possible.

In fullvis, vis goes on to the significantly more complex algorithm, where it "flows" through all the potentially visible paths, checking if there's a way through. This work is divided so the simpler paths are calculated first, since they will probably be used in the more convoluted paths later. This is the main reason why vis slows down so much while running, it has left all the heavy parts for later.

The division also lets vis manage the multithreaded aspect by having several threads doing different paths (but still the simpler ones first). I can't say though if it's guaranteed that all simpler paths have been done by all threads when the more complex ones are about to begin. In my version (and most others), that's a non-issue, since the paths are all done sequentially by one thread in the right order.

With increasing # leafs and portals (which you can read at the beginning of the prt file), you can probably realize that the amount of calculations grows very quickly. 100 portals will generate 40,000 "work items", for 1,000 portals it'll be 4,000,000, 10,000 portals is 400,000,000 and so on. I don't want to think about 100,000 portals ... 

Hi thanks for the answers.
Ricky, here are the screenshots and compile logs.
http://rapidshare.com/files/302918736/quake_screenshots.zip

With light.exe -dist 0.6 -range 0.6 -light 15 -soft it's like no rad / fullbright.

But I didnt' know that you can configure the light.exe thanks for that info MadDog. Maybe someone know how to set my light settings right.If not, i will put some more light enities and a higher brightness value in my maps. This will work i think...

The lighting in the compiled originals quake maps have irritated me. 

Well I need that actual light entity information, you have sent me the information for somebrushes with a light texture on them.
The light entities will be at the bottom of the document (the .map file that is) and will look like:

{
"classname" "light"
"light" "200"
}

As for the command line options well I would use (for a map the size you have) -extra4 and nothing else.

But yeah you can use a "wait" key in your entities to make the light spread out further or be more concentrated.

A wait of >1 will make the light more concentrated, i.e.

{
"classname" "light"
"light" "400"
"wait" "2.5"
"origin" "blah, blah, blah"
}

And a wait of <1 will make it go further, i.e.

{
"classname" "light"
"light" "200"
"wait" "0.3"
"origin" "blah, blah, blah"
}

You can also use "delay", but Im no expert on that one. I seem to remember delay of 2 being nice effect. 

That's a door that's fullblack? If it a door or other entity (func_wall or whatever) then it fullblack because the origin is outside of the world.

This means that it doesn't start inside the vis'd (lit) space.

Select it, the red X in the centre is the origin - if that's outside of the lit space (inside a wall, like yours seems to be) then the whole thing won't be lit at all. So make a recess for it to fit into or make it smaller so the origin is inside the world.

It's worth remembering that although entities look like they're normally brushwork in many ways they behave like point entities.

In other words, they only care about where their origin is when it comes to light and vis. 

Those were missing from the above post.

Also 'brush entities' as opposed to 'entities'.

Having a baby is the greatest thing in the world, but your head is all over the place for lack of sleep. 

Its an optimisation (AFAIK) of AguirRe's that the compilers don't light all brush entities no matter where they are, like id's did.

Definately a plus, but also shows another b0rky map feature common in the originals.

Mind you, very easy to be aloof ten years+ after the fact. 

Thanks for the help! The last post is what i wanted to know. I found it weird that the original quake maps had different lighting when starting in Worldcraft. Thought it was a problem in my Worldcraft configuration or something.But that explains it all.

And i am not sure if you notice that the in_game_screenshot.JPG was a screenshot of the original E1M1.bsp not mine small testing maps.

Anyway Big thanks! 

That's why I said that AguirRe (who's compilers come bundled with the wc3.3 adapter) made optimisations that id didn't.

If you used their compilers it'd work without showing the door black but take alot longer. and run very slightly slower in game I think as well. 

you lucky father and happy mother.

apparently the same goes for a good map:
Having a map is the greatest thing in the world, but your head is all over the place for lack of exit. 

silver_key-gold_key-exit.

change-feed-sleep.

Now that's a nerd comparison. 

PakExplorer: 'explorer' type view, limited to 8 character filenames. sucks.

PakScape: 'explorer' type view, not limited to 8 character filenames. converts all upper case chars to lower case and progs.dat is case sensitive. sucks.

DZip: not limited to 8 chars. doesn't change char case from upper to lower. is NOT an 'explorer' type view, just a long list of crap so very difficult to organize pak files. (as it's primarily for zipping demos anyway).
sucks.

are there any other pak file programs? one that doesn't limit file chars to 8 or change the case around and that has a proper way of displaying files so as to be able to organize things well? 

That is one thing QuArK can do very well. 

there is a pak plug-in for total commander. It satisfies my needs for exploring pak files. 

i was under the impression that both of those could only open and extract files from paks? 

Nope, QuArK let's you save just fine. 

I have just tested and the tc plugin is creating pak's as well. Very straightforward 

Pakker 

thanks :) i wasn't able to check myself today.
wasn't able to find pakker though, but i should be able to use quark as i've already got that. 

http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/pakker10.zip 

so, i made a few pathetic textures and im trying to get texmex to put them in a wad, like i did once before i think, but now when ever i try to import it gives me "was ignored" on all the textures

the textures are in .bmp format and i believe they are 8 bit color

...i don't get it any clues? 

i remember that happening, and don't really recall why it did, but i'm pretty sure if you convert your bitmaps into 24bit targas, the problem should go away.

it might have to do with the 8bit bitmaps not having the correct palette (it's not enough for it to be 256 colours, it has to be the correct 256 colours). 

Are the bitmaps compressed? That might be it. 

Your texture, then 'paste image as new mip' in TexMex. 

those both worked :D

... i don't know how to compress bitmaps so i dont think i can decompress them :S 

I'm working on a terrain map. I use triangle shapes to lift the corners to equal heights and then use force to grid 1 to fit the brush.

Sometimes the brush takes the grid on a counter line and it is possible to move the brush back into its original position, gaining a clean, converted brush.

Othertimes it gets out of grid and causes the vieuw to get out of position.
http://members.home.nl/gimli/align.jpg

The first method , without forcing to grid, brings a well compiled map with errors, caused by the compiler with warnings and heling points. But a fitting brush order.

The second , with force to grid and reposition, brings a misaligned map with less errors and a better compile log, and a rather blurry brush fit.

How to avoid the process and which would be best suitable?
I never minded thes misalignements, I'm already glad the compiler takes it. But then again, the small difference could change vistime considerably. 

when i make terrain in qe3, i just do my terrain mapping in 3d view after copying and pasting all the triangular shaped brushes i need.
i keep the grid on 16 (or 8 if i need fine details) and just pull individual vertices up or down depending on what i need in the 3d view.
this usually creates good results for me. 

It would be really ace if editors allowed you to select say, 4 brushes and lock 4 vertices which all interleap with a simple keyboard shortcut, then you just drag the locked vertices into the appropriate position as one, and then "ungroup" them. 

or when you rotate a group of brushes. why do editors persist in snapping vertices to different points when they were initially sharing the same one...

also, why does firefox keep underlining 'vertices' like i'm spelling it wrong. what a bastard. 

As I read, I think my failure is caused by using the 1 grid option in force to grid. It turns out to become a disordered 0.x grid position that hardly can be healed. 

Which editor do you use? I forget..... 

your terrain generator program should automatically snap to grid too, so i don't know why it would change again if you snap to grid in the editor. 

... it could be that, unless you are zoomed into the maximum, your manipulation on the different brushes is just not lining up and not that it is actually off-grid.

I would not go below 8 for snapping unless I was trying to fit the terrain to an object that was not on the same grid reference, and then I would definitely zoom right in.

I use BspEditor and can zoom to 1600%. At that level it needs a very distinct mouse movement to move one unit and snapping acurately is easy. At the standard zoom (75%) it is impossible to line up brushwork in single unit movements even though the editor is 'snapping'. 

I use Quark63. It took quiet long before I could sahape a terrain map.
I don't use a terraineditor. Maybe a silly way I come up with.

I started with a triangle brush. Made it as precise I could. As long nothing happens to the brush it stands on grid with integers.

Then I turn the grid to 1 and force the outcorners to the 1 grid point. Of course the origin of the brush gets disordered so I have to force the whole brush into grid again.
That's my startpoint with terrain mapping and it compiled well.
Now I can make a terrainmap of all the triangle brushes. All goes well untill I lift the outpoints of the brush to level it with another brush.

From there the two outcomes appear in Quark.

Some brushes after distorted flip to a decimal but after resizing the brush with 1 the force to grid puts it exact 1 gridpoint aside. So I can easily rearange it untill it fits its origin.

Others get distorted and will never line up with the others. They will fit on x and y-axe but not in the lenght.

So I was thinking. Maybe I shoul force to grid only on a 8 or 16 grid. 

The wonders of QuArK. This is just normal behaviour from my experience... 

I am no terrain expert and it is difficult to make suggestions without knowing what you are trying to achieve. But... if you are doing anything on a large scale, then use a terrain generator and do all (most) of the modelling in that and then import it into the editor.

I did a large lump of terrain in FMB-BDG in the form of a cavern. It was over 1000 units in each direction made up a few thousand triangles of 64 units. It took about 30 minutes to do in the generator - I dread to think what it would have taken in the editor.

http://img178.imageshack.us/img178/5075/fmbbdg16bu3.jpg

You can probably make it out in this screenshot.

When I had finished, I ran the BspEditor Brush Merge and got it down to about 900 brushes (from memory). 

1 - select the brush tool, set it to "wedge" shaped (triangular prism)

2 - select a suitable texture

3 - quicky make about 4 or 5 wedge shaped brushes

4 - in the "top" view I use the vertex editing tool to move the corners of the brushes into whatever shape I want, usually on a grid not smaller than 16x16

5 - I switch to a "side" view and move the verticle edges of the prisms up and down to shape my terrain

Notes:

Nothing ever goes off grid. The editor is set to "snap to grid" and whatever the grid size may be, the points of my brushes snap to them.

Aligning the textures better is as easy as selecting my brushes and setting the attributes back to 0 (i.e. rotation, movement x, movement y, x scale, y scale), then click a button which says "to world", which tends to look OK.

You can use this method to make overhanging rocks and other intricate shapes.

It is quite time consuming but looks good in the end! 

I've just checked that old map and the cavern is 3000 x 3000 x 800 high. 

Is there anything similar to aquire's engine for q2? I was messing with q2 map, just made the first area, nothing special so far, 2 entities (start and light), but when i load it to the engine, the game just freezes and i see q2 using 99% of cpu. Wtf? 

i couldn't get the standard q2 engine to run either. there's quake2 xp and quake2 evolved that i know of. 

Quake2 envolved doesn't run it either 

but i dont want to peruse 9192 posts for the answer

how do you make monsters not move or attack even with the player right in front?

i tired clip brushes and making secret trigger button but those didn't work :? 

Put them inside a func_wall made out of clip brushes, but whose corners (BBOX extents) have a tiny normal brush inside.

Those normal brushes tell Quake that the clip brushes are there.

Then remove the func_wall when you want them to be active.

Never actually tried it, but should work. 

are the non clip brushes supposed to be in the Func_wall or out of it, because it dosent work when there in it and when they're out i get this error:

*** ERROR 13: Line 2131: Entity with no valid brushes or textures

1 warning

Elapsed time : 0:00

Peak memory used : 1.8 MB

!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!
Build failed, because it did not create the (+BSP) file: C:\Users\alex\Desktop\q
uake\tmpQuArK\.\maps\mstart.BSP 

That's why he said to include a tiny, real brush somewhere within the func_wall entity. Quake won't complain if you have at least something in the entity with a texture on it. Hide it in the map itself by making sure it's inside of a wall or something. 

 

Remember those wicked jumppads in some Q3 maps that had you fly in a curve? The same is possible in Quake. Pretty obvious, but I only just thought of it again.

Take a look at this test map: http://www.quaketastic.com/upload/files/misc/pushtest.zip

The trick basically involves pushing the player towards a curved clip surface that determines the direction of the flight. The clip curve has to be fairly smooth so the player doesn't fall down prematurely. In the test map the small jump (1/4 of a circle) has 8 faces, the large one (3/4 of a circle) has 24. The map is pretty crude (but you'll get the idea) - it takes some experimenting with the pitch angle and the push speed. The larger such a push is (radius and distance), the uglier it becomes, because the clip wall and the pitch have to be a lot higher.

Now there aren't really that many situations where such a push would be useful. Imagine perhaps a castle with push-connected towers. Or a deathmatch map, although then one has to take into cosideration that NQ and QW handle the speed values in different ways.

At any rate, such a push can at least make for some funny wheee! effects. 

What about making a map where you fly along wind tunnels between different rooms and use keys to unlock new tunnels? Mebe with some water. And in brown... 

... antedeluvian map ? 

i has...have these new stuff in my progs that need entities placements on the map, but im finding that when i add an entitiy like ambient_drone i can't changeit, to something like ambient_front242. but i remeber doing it before somehow :S

the only solution i have is to edit it in the .map with a text editor but i find this somewhat of an out of the way solution

...i wonder if this makes sense 

why don't you just add the entity,
click on the object list,
and change your classname to monster_xxx? 

search and replace function? 

quark won't let me change classnames and i don't know why is what i meant with that paragraph and a half

and its kind of annoying because i could do it before i think 

QuArK lets you change classnames easily. Either slow double left click in the tree or edit in the detail view. 

A VIS error I could not find any documentation about. Does anyone here know what it means ?
It's a real error, not just a warning, no VIS is preformed. 

probably vis is trying to finish a partially-completed job, but you've changed the bsp since then. I think you'd just need to delete the state file, but i don't know what the filename would be (never used that feature myself.) 

I didn't know about this feature at all.
Anyway, reading your reply made try and just rename the map,that worked ! Thanks !
I've just switched to the WC 3.33 version so I might come back with some dumb questions later ... 

... aguirRe's tool tip does not mention this error :/ 

I think you just have to delete the vis file to that map your compiling and aguirre's vis will make a new one. I get this while updating and changing texture names in a wad file. 

While betatesting my level I came up to some errors I forgot how to avoid them.

First there's the monster count eror. I assumed they were caused by the fish, with its double swimmonster_start in the qc. Strangley it didn't help help deleting it, because I still get a double fish count.

Second is the strange habbit of some zombies.
Their heads seems to run on while being killed, which is rarely difficult to trace while they're in slime.
I got the effect earlier with bones. I can't find a reason for it. 

Do I remember breakable (not exploding) crates for Q1?

If so, does anyone know where I can get the qc/mdls from, if available? 

Mounds don't :-) 

Supports as well - Quoth's are simpler to use though. 

Quoth code not been released so I'll look at Extras 

Ahem.

What extras has is model swapping and emissions. So you can swap a mesh in the map for a broken one (external bsp) and spawn a spray of emissions at the same time - these can be sprites, models or other external bsps.

It's not really tied up into a ease of use package though - you'd need a few seperate entities for it to work. 

Emissions are well worth having - a very powerful tool. 

Do you want our source? It's got extras inside, but also alot of other stuff. We're not supporting it (heavily commented) though, so you're probably better off with base extras. 

I appreciate the offer but I really only wanted breakablecrates for one specific event and it would have been easy to add it into my own modified progs.dat. Also, I don't want to go the effort of creating the models and things.

I'll just have to think of another option. 

mike, what's your email address? you don't have it listed here. 

mikewoodham at msn dot com

Funny, I've been coming here since the one before but never actually 'joined'. 

mapconv by SleewalkR

any links? 

Oooops...

I just realised that the e-mail sender will show as Dooby Pollocks instead of me, so your filters may think it is spam. 

it wasn't caught as spam, but it did confuse me for a second. :P 

what are the references to see if a bsp is vised level 4? 

is it a stupid question? 

How do you run this program? I never used it yet. 

So stick your bspinfo.exe and your bsp file in some folder on your c:, take a command prompt into that dir and type:

bspinfo mapname

Cant remember if it tells what level vis was run at, but it definately tells you the size of the visdata 

Will look into it 

I didn't see any -level 4 confirmation in bspinfo.exe, but while vis.exe is running you should see:
testlevel = 4
...and you'll have it! 

bspinfo formally gives the same info that has bsplog.txt has, only there's no map to compile.

I wondered if there was a way to see how a level was vised. 

r_showtris 

that's what I was looking for. 

I found Sleepy's Java Mapconverter in the devkit of tigger's unfinished "industri" project. Link:

http://prdownloads.sourceforge.net/industri/mapcon_java.zip

Quite a useful tool, that.

Oh, and about breakables: Nehahra had breakables, lots of them. You can trigger em, give em health, have them throw many kinds of rubble, etc. func_breakable, func_sobject, and func_mindcrime were the classes, iirc. Amazingly I still have the Neh QuakeC source in a folder. Since Planetquake now sleeps with the Rotfishes, I'll up it somewhere (quaketastic), if anyone wants it. It looks extremely old (dated 2001) so I doubt Mindcrime would mind. 

they can't be walked on, only downside. 

thank you. 

I would be interested in the source for Nehahra - if you can let me know when you are uploading it, I will watch out. 

http://www.quaketastic.com/upload/files/single_player/mods/NehQCsrc.zip

Glad that my obsessive packrat tendencies came in handy. 

Didn't know it had been released. 

It's pascal, I remember the dev tool stuff.

Can it be c+p'd into regular Qc? Not enough of a coder to know. 

And it says:

More than a year after the release of Nehahra, I am releasing the "QuakeC" source code to Nehahra. I have placed QuakeC in quotes because it is not what you would call true QuakeC, but a Pascal-Hybrid. The compiler/decompiler was created by Armin Rigo, a set of utilities called ACCQC.

I have included in this archive REACC.EXE, which will compile a progs.dat from the .QC files. The error messages are in French. Sorry. :)

So yeah. Good luck with that, guys. Pretty sure this came from planetquake.com/nehahra at some point in the distant past. 

Hello all,

I've been itching to create a map using the darkplaces engine, and since gtkradiant 1.5 has this option available 'out of the box' I went ahead and used this instead of Worldcraft 3.3.

I can compile a map and run it no problem, but here is my dilemma:

Not all of the textures load into gtkradiant. I've downloaded and installed the
rygel-dp-texturepack-high.pk3 and it is installed to:

C:\Program Files\Quake\Id1

The textures show up fine in darkplaces and in dpmod but only a certain few are showing up
in gtkradiant, and it is only like 5 or so that show up.

Can someone please provide me with specific directions on how to get all the textures to
load or show up in gtkradiant 1.5?

If I have to, I would be willing to use an older version of gtkradiant as long as I had
specific directions on how to set up darkplaces in it.

Thanking you in advance,

Protocol01 

Doesnt Radiant require a .WAD file in order to view the textures? Rygels pack would be irrelevant especially in the instance of any editor because the textures which are "replaced" and "upgraded" by that pack all come from the originals which came from the WAD format used to create Quake.

The bottom line is that if you dont have the Quake wad file loaded into your editor then you wont be able to compile maps with all of the textures available from Quake.

The wads are somewhere within:
http://www.quaddicted.com/wads/

probably quake.wad or quake1.wad

The ting is there are loads of wads there for the Quake engine, and may have not been "re-made" by someone and have no hi-rez replacement. But that shouldnt meen you shouldnt use them because you can achieve many different themes with these wads and you dont have to worry that they wont load up in the end user's engine of choice. If you wanna use mega-hi-rez textures then use Source or Cryengine or Unreal Engine 3 or IdTech4 or something.......

[rant]
Merry Christmas BTW ;) 

i think its http://www.quaddicted.com/wads/id.wad that you need to load into your Radiant editor to work

bare in mind I have never used that editor, I always used Worldcraft, but I would have thought that this form of texture handling would be fundamental 

Personally I find GTKRadiant 1.5 to be stupid and terrible, whereas version 1.4 is excellent. As you have discovered, Protocol01, 1.5 has a real problem loading external texture sets. I don't know why. If you had Quake 1 .wads, then they should in fact load from the id1 directory.

Version 1.4 cannot natively load .wads but it has no problem with TGA's and JPG's. Seriously, try exactly what you were doing except using 1.4 and you'll probably have no problem.

Have a look at this guide for a reference on setting up Radiant for Q1:
http://industri.sourceforge.net/howto.php

Hmm, Ricky is probably right though, that you need to texture your map with the original quake101.wad. Then if there are TGA textures in the appropriate game directory with the same name as ones in the map's BSP, they will be replaced at runtime. The BSP needs those texture names and coordinates so it knows what to replace, and the ones from rygel's pack are far too big to fit into the bsp anyway.

Unless... what exactly do you mean by "mapping for darkplaces?" This has always kinda confused me. Which features and game are you trying to use? Cuz if you were trying to use Q3 or HL bsp support, then a lot of what I just said would be irrelevant. 

Thank you RickyT23 and thank you Grahf both for helping me. I guess I just assumed that radiant would have been able to read directly from the pk3 file, I didn't know I was going to have to have the .wad file. I see now that mapping for Quake 1 is VERY different than mapping for quake 3 arena. >.<

As for darkplaces, I mean that I was trying to make a Quake 1 map that could be used with the darkplaces engine.

I will try what you all suggested and go from there, thanks again and Merry Christmas all! 

GTKRadiant 1.4 has a variety of game packs for Q3-engined games, but none for Q1. In the guide I linked to in my previous post, what you are basically doing is building a Q1 game pack from scratch and script files to trick the editor. The single most important change is in the .game file, "default_scale=1" instead of .5 as is used in Q3. You still don't get .wad loading, so you export that to jpg/tga and load those instead. Then after making a map, you run the .map through a map converter to get it into Q1 .map format so that your compile tools can read it. It's all kind of a hack, and adds several extra steps to the mapping process, but it does work.

Radiant absolutely can read and load .pk3's from the base game directory, assuming the directory structure is laid out like Q3's. This is how Radiant loads external textures and models, after all.

GTKRadiant 1.5 changed all this by using a totally different (xml-based) file format for the scripts, game packs, map format, etc. There is a Quake 1 game pack, which allows for .wad loading, but I think how it works is that if you are in this mode, it will not load jpg/tga textures. Also, GTKRadiant 1.5 is just a crappier editor generally, that messed up the clipping modes, vertex editing, and brush manipulation compared to the glorious perfection of version 1.4. Gee, I'm not biased at all, am I.

If all this sounds horribly roundabout and complicated (and it kinda is), there is a simpler way. A Q1-specific version of Radiant, developed by Sikkpin, that is based on the original opensourced QE4 editor that id used to make Quake 2. So basically you get all the goodness of oldschool Radiant style, with native Q1 .wad loading support and none of the added cruft like curve patches that is useless for Q1 editing.

Link should be somewhere in this thread:
http://www.celephais.net/board/view_thread.php?id=60225

Something else you might look into is guides on Nexuiz mapping, which uses the Darkplaces engine. Nexuiz mappers use a fork of Radiant called "NetRadiant," and I don't really know how it's different because I've never used it. However I do know Nezuiz maps usually have externally loaded jpg/tga textures, so you could probably find some info in that community on how to make sure they show up in a map, which directory to put them in, etc. 

Gee, I'm not biased at all, am I.
you may be biased, but you aren't alone.

the 1.5 interface is overall slower and clunkier requiring more keypresses to achieve the same goal as in 1.4.

i believe the intent behind the 1.5 changes was to make it more like a professional 3d package. ironically, i felt the changes moved it farther away (i use 3ds max). 

Grahf,

Thank you for the link and information. It was very insightful. I hope to get radiant setup soon.


Radiant 1.5 really sucks in my opinion, they keep messing up all of the features and usefulness, now it is more complicated to get things done, and I'm going to uninstall it and just use an older version.

Thanks guys. 

Any idea what magic do I have to do to get UnrealED (for UT3) to properly take advantage of 4 cores on my new i5 750 rig? For some reason, it only ever seems to use just 1 (even when doing a level build) and I am absolutely sure I read that UnrealED does scale well with multiple cores. 

It scales to multiple cores during lighting rebuilds via Lightmass but UT3 doesn't support that. UDK would though... 

Have an ATI Radeon HD 2400 Series. So have the no select in 3D window bug with Hammer 3.4.
Just gave the new ATI driver a try. ATI Catalyst 9.12 Driver XP x64. Seems to be working. 

Wow, I never thought the quake mapping community was still kicking. I've decided to finish my old quake1 DM level which has been sitting on my HD since early 2003. It's a great and pleasant surprise to see there are still enthusiasts to share mapping experiance with :D

Anyway, as I'm trying to relearn everything I've stumbled across an issue. I cannot get the teleporter to work. Everything seems to be correct but I get this error message when loading the level.

Object error in info_teleport_destination:
No targetname

In the map file I have:

Target_teleporter
Target tele1

and

Info_teleport_destination
Targetname tele1

I use GTK radiant 1.2.x something and Sleepwalkers mapconv tool.

Any ideas?

And a happy new year to all of you :D 

"classname" "trigger_teleport"
"target" "XXXXX" 

Make sure it's all lowercase 

Human error this time :P
Thanks for the replys.

And while I'm at it I might just throw you another question :) I want to make a lift that travels up only when a button is pressed. I get everything to work, but the lift starts behaving differently when connecting the func_button to the func_plat obj. Without the button connected the lift starts in "down" mode and raises when a player walks over it. However, when the button is connected the lift starts in the "up" mode. Then goes down when I trigger the button. AND after that it starts behaving as if it wasnt connected to the button. wtf?!

Any help here would be appreciated. I know it's possible to do this :) For example it works in the "Pinion1" map.

Thanks again guys. 

you have to use func_door instead, not a func_plat 

You have to have a door which travels "up", cant remember the exact map file key/value of the top of my head.

You can have it travel a negatve or positive value "up" to 256 or 512 units. And theres a spawnflag for "toggle" (1 press, door opens, another press it will close). An you can link as many buttons or triggers to it as you like :D 

its either 256 or 512 - thats what I meant 

A door can move as far as you want - there is no maximum value. The distance is determined by its "lip" value. 

thx for the quick response mate.

Sorry for spamming the board but any ideas on why I cant get the quad to spawn in? I use the "item_artifact_super_damage".

Also, while I'm at it.. the map is pretty much ready for some testing. Back in the days it was pretty easy to get some help with that, but how do you suggest I go about it today. Can I use this board somehow?

Cheers 

to quad to appear, item_artifact_super_damage must be placed. w/o any SF

btw, is it your maps safe1 and safe2? 

The item ist most likely too close to a wall or the ceiling (has to be 60 units) and thus falls out of the level. Load the map in developer mode ("developer 1" in the console) and you'll see a warning message if that's the case.

If you're looking for beta testers, post a note in the Screenshots & Betas thread. 

Spy: what do you mean with w/o SF?

Yes, I made safe1 and 2 and 3 is pretty much done now as well :P

Oh, developer mode :) Didn't know about that one. Going to try it out now. 

Thx, that really helped! Found a DM spawn point outside the level which for some reason caused the quad to not spawn.. odd.. but it works now :D 

well, beta is ready now :) Thanks for all the quick responses. I'll make a post on the beta board later. 

So say you had a bunch of quad damages in the room. Currently, they will all rotate exactly the same direction and start at the same angle so they are all perfectly in sync.

Is there a way in QuakeC to start them at random angles or change the rotation speed or do anything, really, to break it up and make it look more natural? 

I'd add

self.angles_y = random() * 360;

to the spawn function. This would randomise the angle they face initially, which should make them look better differentiated.

You could also set .movetype to MOVETYPE_NOCLIP and then give them an angular velocity:

self.movetype = MOVETYPE_NOCLIP;
self.avelocity_y = 10 - 20 * random();

I wouldn't recommend this though, because it entirely eliminates the benefit of the client-side rotation built into the model. You'll have constant network updates of the rotation, which seems a bit excessive for the feature. So I'd vote for option 1, but that's how either could be achieved . 

"self.angles_y = random() * 360; "

Well, I tried that but no luck. I also tried putting that into a one shot think function that executed a second after spawning but that didn't work either. I'm currently thinking that the model is being rotated in the cached model itself and then every time it renders, they all pull from that same value or something? 

I should note that I've created a new item using the quad damage model so it's not the ACTUAL quad damage that I'm dealing with here. If that matters... 

Looks like the rotate flag overrides whatever angle you set in qc or the map. The only alternatives are either to remove the rotate flag from the model, and do the rotation using self.avelocity, or to create several frames within the model each with different rotations of the model, and randomise between those frames on spawn. 

Bah! OK, thanks. :) 

Installed Quake on an old win98 computer.
A little curious I couldn't get higher video resolution then 320 x480.
So I decided to install the update 1.08 but this didn't help.
So I installed the SOA pak to see, which also didn't help.
Then Fitzquake or glquake but they start up like mud.

How do I get my quake off the phone resolution? 

the update 1.08 is dos only
get the 1.06

Try winquake? 

It has something to do with the video option screen.
Normally after installing quake it offers a resolution from 320x240 to 800x600, but for some reason the max only goes to 480x320. 

maybe a dumb question, but just how old is this old win98 computer? it's possible the video card doesn't support the higher resolutions? can you find out what kind of video card it has (if any)? 

well, that last question was retarded... it obviously has some kind of video card, what i actually meant was if it had 3d acceleration of if it was one of those ancient ones. 

It's a mobo I caught out of the surplus and plugged in a disk, a video and soundcard, and finaly I can start a win98 program.
I got all these odd warnings about flipages not correckt screen resolution. I remember in the old 98 it had these errors with darkened screens and garbage messages.
So I'm just on the point Quake starts up well, but only with a max screen of 480x320.
It's not the 3d or something with the videocard, it's only the old dosquake version I can't force to 800x600 resolution. 

to give liquids an angle, a travel direction, like you can do in Quake 2 ?
It would be great to see water coming down or lava floating from one point to another.
Would it be possible to "steal" the code that makes it possible in Quake 2 and put it in a mod for quake 1, or would it involve changing the Quake engine itself ? 

quake2 did it with texture flags, which required a new texture format which the engine recognized.

quake could do it by implementing some sort of shader system, probably. 

I can't do that, that would take considerably more programming skills then I possess.

And I guess it would be impossible to have a liquid texture (*) and combine it with a func_wall (+) one ? 

Just animate one of the water textures. Four frames are enough already. 

Neg, the trouble is that it would look weird in combination with the "real" water, especially with transparent features enabled. 

one trick i've seen is to build a river out of func_trains in an endless loop, with each train having water textures on it.

The "pox extras" mod (which also has some other water-based tricks) had an example map that did this, i think. 

That's a great idea !
I'm going to try it out right now !
Thanks !

And I'll have a look if I can find the Pox mod, I must have missed that one. 

It looks fine with the real water since it's the same texture but yeah, transparency makes it complicated. So your options are: compile the map without transparent water, use the animated texture on a func_illusionary with alpha enabled if the intended engine supports it, or use the regular water texture and greatly increase the scale of one of its planes (by 20-30) - this will create a semi-believable flow-like look, at least on actual waterfalls 

Is it possible to "activate" a trigger ladder? Or does it have to be 'available' at all times? 

you have actually use a func_rotate_train to hack in a ladder that becomes activated.

i'm going to assume you're making a ladder that starts in a retracted position and then through a button extends so the player can use.

first build your ladder and turn it into a func_movewall.
now create your func_ladder brush.

give both those entities the same targetname.

now create a func_rotate_train and set the target to match the movewall and ladder. the func_ladder will move in tandem with the func_movewall. 

you have actually use a func_rotate_train
you can actually use a func_rotate_train

i neglected the mention (although it's implied): make sure to tick the "visible" flag on your func_movewall or else your ladder model is invisible. :P 

A full system for locking and unlocking entities is something I wrote some test code for, right after the last version of Quoth got released. So it's something yet to be incorporated.

If you only need the ladder initially disabled, you can safely use the info_notnull hack. Give your ladder a classnameof info_notnull (as a brush entity) a targetname, and then set

"use" "trigger_ladder"

On firing the targetname event, the entity should spawn up. You can then killtarget it to remove it. By duplicating the ladder entity with different targetnames you could do it a finite number of times(if you were careful). Being able to switch it on and off any number of times is not yet possible, but it will be! 

Ah, that's a clever trick Necros! Yeah, the hipnotic rotating entities allow you to move triggers as attachments. One small warning - the trigger_ladder has an associated "outwards" vector to help push the player onto the ledge above/away from the ladder when they jump off. This does not adjust for the rotation of the entity, so make sure the vector is correct in the final position. Also, don't get tempted to allow players to hang on while it moves! I suspect bad things will happen... 

Necros: I think I have handle that.

Preach: that vector shit IS something I'll probably have to keep in mind - thanks! 

Just out of curiosity, is there any easy way to get a key to activate something other than a door in Quake? 

(without using any hacks, which Im sure other mappers here will be able to tell you about) you can make a door target another item. So you could make a door behave like a button by setting the sounds and directions so it moves like a button, but when you finally get the key you need to open the door, you touch the door and the door moves like a button would and triggers something else. I did this in starkmon IIRC :) 

Just give it a target - everything with that targetname will be activated. 

The question is a bit unclear - you want a key to activate lifts, trains, or whatever?

Do like Ricky says for standard Quake. Use a door that looks like a button.

The clean solution would be to have something like RemakeQuake's item_key/trigger_lock combination, where the lock can be everything. If you're ready to use your own progs.dat, you can rip this stuff from the RMQ source. 

I agree, I wasn't too clear.

What I actually want to do is activate some rising steps (which are really 6 individual doors) a few seconds after the actual keyed door is opened.

I may have been doing something wrong, but I didn't have any luck making a relay the target of the keyed door. I'll go back and try that again.

I'm trying to keep it simple because I'm at the 256 model limit. 

Have the key door target the first stair, but set "delay" to about 3.

Have the first stair target the second, the second the third, and so on, setting "delay" on each stair to 0.5 seconds or so.

Just off the top of my head. Shoot me if I'm wrong. 

Delay doesn't work on doors like it does on triggers. A func_door entity always fires its target immediately. You can either use different speed values for each step, stagger some trigger_relays or add a "use" "multi_trigger" field and corresponding delay values to each step/door. 

Argh, then it's a RMQ thing again. Oh well. It gets confusing.

Listen to negke. 

Why not trigger all the steps at the same time and give them all the same speed? They're all different heights so will stop moving at different times anyway - resulting in a choral sound effect. 

Sometimes the most obvious solution is the hardest one to find... 

I only know because I'm using one in a current map. 

lol. 

I put a keyed door on the floor. It has the lip set so it doesn't actually move. Its right below what was the original keyed door. It's targeted to a trigger_relay and the original keyed door, both named "tryagain". The relay has a delay of 3 seconds and targets the six rising steps.

This works okay. It's not exactly the effect I wanted but I can fool with it from here.

Funny thing, I had the keyed door inset in the floor and it wouldn't get triggered. There were no other brushes overlapping it or anything, it was just like a piece of the floor. I had to move it above the floor to get it to work. I'll have to try that again because I just remembered I also changed it's angle from 0 to "up". Maybe that had something to do with it. 

While testing my level I 've come up to an odd point of setting the skill level.

I counted all monsters and took their health count together. Then I counted all ammunition and tried a relation with their availabillity to match the health count.
But as the TE_DAMAGE of all weapons differs this isn't the right way to handle.

I can count the ogres and enforcers to reclaim their rockets and cells, but as they are also gibbable this is only temperary.

Is there an easier way to gain the outcome? 

Use monstercount / (pi*thumb), then substract the release date.

Or just play the map and add enough items so that you can get through smoothly. Then declare this as Hard and scale down the difficulty settings from there. Then see how the testers do. 

You have to take into factor the players level of accuracy. According to teh games I play, my accuracy = 20-40%. So it is meaningless.

Always just play, play, and play again. Then get l00ts if testing done. :D 

Well I played rather several times only the hard and nightmare are the worst.
So I thought if I

TE_DAMAGE * ammucount = all monsters health + random

could compare it mathly. 

There's too many variables to make an equation of it. Unless you want to get alot more complex than 4 variables.

What negke says works :) 

Wasn't quite sure where to put this :P

TF2maps has finished their TF2 swamp theme pack that contains new models/textures/blah which you can download and use for free, its very high quality stuff!

http://swamp.tf2maps.net/ 

 

Don't know what happened after a qc-script, in game leaves the message:

PR_executeprogram : excessive stack (53 normal = 31)  

bad scripting. 

Doe's anyone know of a texture pack that has some nice alpha channelled hanging vines and overgrowth textures? Or any packs that feature some sort of old abandoned temple theme? I'm thinking more Mayan than Egyptian here, any info would be appreciated! 

the original rtgnosis texture set had a vine/leaves overlay with an alpha channel. 

Sock's Pyramid of the Magicians (pom) level. 

I had totally forgotten about that map, damn its perfect =)

Thank you very much! 

I know this is probly in here somewhere, but...

Is there a guide / howto for editing quake maps in valve source sdk? Is this possible or should I just be using hammer 3.4 (3.5?)? 

Although search for Baker's Quake Adapter for hammer 3.3 - maybe I'm misunderstanding what you want to do. 

My goal was to be able to edit maps in the new hammer, export them somehow, compile for quake with the new tools. I figured I'd ask here first in case there was a tut somewhere.

If it's not doable I am gonna fire up hammer 3.4.

It's been a few years (and a few computers) since I had a mapping environment setup. ;) 

I've been meaning to do it myself since the latest beta version can apparantly show model meshes inside the 3d window. 

It works in Fitzquake, but it doesn't in Qrack.
Why could that be ? 

Could be the engine is Qrap.
What are you trying to killtarget and how? 

Shambler = dead = open gate
The gate was previously closed by another trigger. I want it to re-open (or disappear, that's good enough for me) when the monster is dead.

Qrap or not, it's got nice shiny stuff, I like ;)!

But what I really want is a level that can be played in multiple engines. Except Darkplaces, I've given up on that one, it is not accurate with the placing of items or monster spawns. 

The problem is there's a glitch (or oversight) in the code that prevents monsters from using the killtarget field just like that. You have to give the Shambler a dummy target field for the killtarget to work.

You could probably also just set the "toggle" flag on the gate and make the Shambler target it normally.

Issues with item and monsters in DP often indicate improper placement, e.g. too close to a wall, that other engines ignore. For regular custom maps, any newer DP build should work flawlessly. 

----- TyrLight v0.99e -----
extra sampling enabled
colored output format: lit
BSP is version 29
1128 entities read, 956 are lights.
************ ERROR ************
TestLineOrSky: tstack overflow


Thats a bit of a grim looking one isnt it!?!?

Anyone here have any idea what that means? Had lit like 95% of the total faces when it spat this error :(

Please help! 

Can't help I'm afraid.

How much compile time to see the error? 

AguirRes light tool works though. Doesnt give any clues to the problem. It will have to do for now. 

If you have the C code, you should have a look into it to figure out what's hapening: this is the first time I hear about this particular error... 

a hack to raise/lower the HP of Quake monsters? I think someone mentioned it before, but I am suffering from some intense mental fog at the moment. 

armor, check the progs.dat thread. 

armortype 1
armorvalue xxxx <-- however much extra health you want. 

 

(L4D2 / Swamp Fever / Plantation level)

A question - anyone have any advice /examples on how to make a spiral? Not a helix but a spiral as seen in SPoG's Q2 map (vertical spiral lift bars).

If I figure it out first then I'll post a .map. 

it's not quite SPoG standard but here's a pic of an old speedmap i did years ago: http://isoterra.co.uk/images/qspiral.jpg

basically for that i started with a 12-sided hollow black cylinder (128 units high in that pic), which each 'side' split diagonally (i started with one brush, split it first, then vertexed & copied it round to form the cylinder, making sure the split always went the same way. i then cloned the whole thing and stacked another on top; then it was just a case of deleting half the brushes & a little more cloning upwards

if you can master that then it shouldn't be too hard to work out how to do different shapes & sizes. there is also a much messier way of doing it by fusing 6 4-sided shapes together to make a cuboid and then vertexing the resulting cluster any way you want, but qbsp tends to get upset at large amounts of those! 

dont bite the hand that feeds you (my map)

Find it on the quaddicted.com website, in the singleplayer maps section, type Ricky in the search field. thehand.bsp

The very first corridor you come to the cieling is 1/4 spiral. Infact Slave To a Machine has a spiral in the generator room.

So two maps I made with a spiral. If you look at the maps I jave the .rmf and the .map source availaible if you like. Just email me or message me here and I will send you the sources 

rj:

nice spiral. also as or the 6/4 side cuboid technique - better just make one cuboid into two triangular prisms, then you cant go wrong ;) 

4 sided shapes but got the offset wrong - will give the stack method a try - sounds alot easier tbh. 

It was the cylinder as an offset reference I was missing.

Problem was I didn't want to make an actual spiral but more something like a drill or screw.

Might well have a go at something a bit more ambitious with this. 

A drill might be tricky to do, assuming it's not the size of a room, because the smaller you get, the more difficult (or impossible) the technique becomes. 

rj:

nice spiral. also as or the 6/4 side cuboid technique - better just make one cuboid into two triangular prisms, then you cant go wrong ;)

oh you can. i have done anyway ;p

that's essentially what i ended up with above; it can just be a bit of a headache working out which way to split them sometimes; there are still several four-sided faces that need to keep intact

a full 'vertex block' (unofficial name i've given for the 6x4 brush thing) however can literally be bent anywhere on any axis, providing the result is at least concave. works great for natural terrain.. but probably isn't to be abused too much in minor architectural detail 

was actually in that speedmap pictured above; instead of leaving it as a pillar i tried to make it a full-blown arch with the spiral curving around. i got my head in a mess at the time & ditched the idea but on hindsight it should be easy if you build the curve before subtracting the negative brushes. might try it... i was actually wanting to do a big spirally setpiece as a finale for e2 :) 

That speedmap was one of the first maps I ever played (ran pretty slow...); that and Daz' graffiti maps are some of my favorite ("mapping-wankery-")speedmaps ever. 

Is the size of a room and not supposed to be used for drilling. The limitation of the grid is 2x2 so making a drill of 128 size I wouldn't even attempt - straight to .mdl.

Rj, the spiral made in the way you describe (assuming I'm not missing a step) comes back as invalid solid unless trisouped, though I haven't compiled to check it yet.

I still think back to SPoG - that map was insane for geometric complexity.

Hm, might try to coax AguirRe back to Quake 1 to see what made formations can be tweaked to compile better.

24 sided curved spiral anyone? 

upload a .map of your attempt so i can see if you went wrong anywhere? 

i just opened up the rmf of that map and noticed that wasn't how i did it. each side was actually split into 4 not 2. i'll just upload the thing so you can have a look and pull it apart :) 

http://isoterra.co.uk/stuff/timegate.map
http://isoterra.co.uk/stuff/sm48_xen.wad

just attempting a 24-sider now :D 

Sprials.rmf in the testmaps folder, or there's examples of 24 sided shapes from ctf1rq - with some geodesic domes in there as well. 

The 24 sided stuff is pretty limited.

...I remember I did include some helix' as well though - above the stairs off to the sides in the courtyard. 

i just put up a 24 sider in the same folder. it only goes down to the 4 grid at that size so you could in theory either half the bar widths or go for a full-blown 48 sider if you wanted to show off. you could probably get away with half the bars though at 24/48, i don't think spog's had that many 

Will take a butchers later though, got people starting to arrive. 

Okay - so trying to do something with this not quite speedmap and wondering

how can I go about spawning a key in a map?

I'm working in Quoth, of course. 

I was going to post a hacky way of doing it, but I'll hold my tongue. There's a correct way of doing it, which is to use the info_multispawn with a spawncount of 1, and set the spawnclassname and spawnfunction to item_key1 instead of a monster class.

A full write-up of the info_multispawn entity can be found here: http://www.celephais.net/board/view_thread.php?id=60173&start=257&end=257 

 

Hello again,

I have made a Func_train that goes round, it has 4 path_corners. What I want to do, if possible, is to make a door that opens up to let the train go true. The problem is, I don't know how to do that. Any ideas ? 

At the correct time. Make a trigger_relay entity with the same targetname as the train. When the train gets triggered it will trigger the trigger_relay too. And you make the trigger_relay target the door, but give the trigger_relay a "delay" key with a value of "X", X being the amount of seconds before the door is to open.

Is it "delay" or "wait"? One or the other :) 

Yes, that's right. Though it sounds like the door is supposed to open not only once but every time the train passes it. In this case you have to add a second relay with the same targetname that fires the first relay again after the right delay, so the cycle starts over again. 

Is it possible to make a path_corner trigger the relay or even the door directly? 

But you can make the door trigger the relay. Or itself after the time the train needs to do its round - then you'd have to add the field "use" "multi_trigger" to the door. 

Keep in mind this kind of delay/script may easily run out of sync if the train is blocked by the player or monsters. 

for your suggestions.
I'll try and work it out.
Otherwise I'll just have to bin the whole idea.
It's one of these "but I set my mind on it" ideas ... 

A train. You could set a path_corner at the open and closed positions of the door, and give them a "wait" key of however long you want the door to wait until it moves again. 

that,s how i would want to do it

... 

Ricky, we've got that done on the code end for RMQ - triggering from when a path_corner is hit. 

I'm trying to make a Painkeep map using gtkRadiant. I saw that a while back, the makers of the Painkeep mode released a map makers kit which included custom entities. I'm having a heck of a time finding that kit. Does anyone here know where I can get it? 

I've changes the func_train into a func_door because of the trouble Negke pointed out in #9361.
Everything is working fine, but the "lift" appears completely black. Could that be because it starts out being hidden ? 

Objects will be lit where you position them to begin with.

Solid entities (lifts, doors, trains etc) do not cast a shadow during the light phase though, so in the case of a func_train you can position it wherever you like within the sealed map to get some light on it. It will then be re-located to the first path_corner entity when the map loads.

If its a lift (func_plat) then you need to put a light entity near it to light it in its first position (usually the fully "up" position).

Hope this helps 

Thanks Ricky.
Yeah, it's helpful.
Funny though, I put some Rune fullbrights on the corners and they do show (in supporting engines of course). 

Check the PQ archive at quakewiki.net - maybe they mirrored the Painkeep website.

Ron: Ah, so it's just a lift? I thought it was supposed to be a platform floating through the map. 

Because they're fullbright - basically they ignore lighting completely and always show themselves at maximum illumination.

If the door entity isn't lit it means that it's center (bang in the middle of the bounding box) is inside a solid brush when the light is being calculated.

Try 'Start Open' and trigger it once on map load so its in the right position when you need it. An easier way might be to just give it a recess to fit into. 

Negke, yes, that was the original idea, to have the "lift" go round, and if you stayed on it you'd be moved into a secret area. But the main use was a lift to get up.

Ijed, I did that, create a space underneath, and it worked !

Thanks again, I'll remember to credit you guys when I'm done ;)

2013 or so ...

Only joking, the thing is that I'm always wanting to ad stuff, sometimes causing me to start all over again. The 1st map I ever made used to be quite small. The 3rd remake is quite big now. But also I had to correct a lot of stuff. I used to do a lot of carving, really bad. There should be more information on how to work clean. There is a lot of documentation on how to make a room, but not how to make it as efficient as possible, unfortunately. So before I found this website, I had to learn trough trail and error. 

@negke Thanks for the info - that led me to other Painkeep sites that I didn't know about yet. I've exhausted those and still haven't found what I'm looking for. 

Is a good, and fun, way to map - as opposed to having some rigid plan laid out in advance. 

I'm having trouble getting the textures to display in the texture window when I'm trying to build Quake maps in GTKRadiant...

However, if I set the game to Quake 2, my quake 2 textures show up without any problems, even without the need to extract the files from the paks.

Is there a special way to setup Quake in GTKRadiant? 

Put the texture wads in id1\ 

Do I have to put the textures in a wad file first? There's only 1 wad file in the paks and it doesn't seem to have anything in it... While the "gfx" folder seems to contain all the textures. 

http://www.quaddicted.com/wads/quakewad.zip 

Got it! Thanks! 

Other than avoiding to overlap brushes, is it also necessary to avoid T-junctions when making quake maps? Doesn't seem to matter how careful I am, the compiler keeps reporting "# edges added by tjunctions" in the log...

Take a look at these pics, bear in mind the column or "pillar" is floating.

Avoiding T-junctions:

http://img3.imageshack.us/img3/3360/avoidtjunc.jpg

With T-junctions:

http://img37.imageshack.us/img37/5436/tjunc.jpg

And is there a caulk texture to use when you want faces on a brush to not be calculated when compiling the map? Only thing I found was a "clip" texture. 

It is not necessary to avoid tjunctions. "X edges added by tjunctions" is not an error, that is just normal operation. QBSP ensures you will not have tjunctions in the compiled level by adding those edges. So you don't need to worry.

There is no "caulk" but there is something called "skip" which might do what you need -- see here: http://www.celephais.net/board/view_thread.php?id=60088 

I see.

This skip tool will come in handy! Thanks! 

There is nothing wrong with overlapping brushes. Infact overlapping brushes is what the technology was made for. DO overlap brushes!!!

Having 2 faces at the same place on the same plane isnt a good idea because you have no controll as to which face qbsp will choose. 

not overlapping brushes. even though qbsp doesn't have a problem with it it does help towards neater brushwork in general 

At least in the case of BJP's tools, qbsp will always choose the face of the newer brush, the one that is further down the list in the .map file. 

even though qbsp doesn't have a problem with it

seriously, I remember reading an article about how the technology was devised which had diagrams showing how qbsp can take overlapped rough-shaped brushes and subtract everything outside of the inside space. It was what it was designed for! You can get some really neat effects by overlapping brushes, especially with things like rock work.

Things to watch out for which ARE important:

1 - illegally shaped brushes. No concave brushes please.

2 - corners of brushes being off-grid.

I have discovered that you can have overlap points off grid, qbsp completely re-models the brushwork anyway into wireframe. But having corners of brushes off-grid is a real no-no. Likely to lead to leaks, holes in the clipping hulls, homs etc. 

Anything of grid is a no-no. Basically because qsbp snaps them to grid, which might not be where you were expecting. If you've got a load of stuff like that that's intersecting then you get a mess of unnecessary (and probably invisible) polys, holes in between structures and so on.

The grid is 2x2 though, and you can always spawn in models with a scrap of code for detailed stuff. Not many people realise / use bsp model spawning - which is the mutts nutts for rotating detailed stuff. 

I've made a part of a map that was perfectly playable in normal skill, the skill I test on because I'm a lazy bastard, but can't be done at all on Nightmare, the skill I always play on.
The Shamblers reload too fast for the player to have any chance of getting past them. Does anyone know where I can find the exact difference in skill settings ? 

"There is nothing wrong with overlapping brushes. Infact overlapping brushes is what the technology was made for. DO overlap brushes!!!"

Yeah, I wish this myth would go away but it persists for whatever reason. Overlapping brushes are totally fine and completely acceptable. QBSP will cull away the unseen portions.

"Having 2 faces at the same place on the same plane isnt a good idea because you have no controll as to which face qbsp will choose."

Untrue. It will pick the one that appears last in the MAP file. You can control this simply by cutting/pasting the brush that you want to appear last in the map editor. That moves it to the end of the brush list - unless your editor is doing something where it writes out the brushes in an arbitrary order. In that case, it's a failing of the editor rather than Quake/QBSP itself. 

I've found a new way on how to get by them.
Funny how your own maps can bring out the creative player in you, I guess that's why I love Quake so much. 

Enemies fire faster on Nightmare, that's the main difference you cannot influence. The rest is item spawnflags to make them not appear.. 

Or die!!! 

Anything of grid is a no-no. Basically because qsbp snaps them to grid, which might not be where you were expecting. If you've got a load of stuff like that that's intersecting then you get a mess of unnecessary (and probably invisible) polys, holes in between structures and so on

this. like i say, even if it compiles without a hitch most of the time, having loads of off-grid overlap points still leaves your map more susceptible to random leaks & the like, as well as being not very nice to build stuff on (say if you wanted to cut a cave out of the rockface, or build some architecture into it later on).

but hey, personal preference. i used to do it all the time but have much prefered working with natural terrain stuff since i stopped doing it. much prefer using triangular faces now 

you should never need to test nightmare or find a way of making it easier, it's supposed to be fucking hard :P 

not only should stuff be "on grid" meaning on the 1x1 grid, you should also build stuff so that it fits on the higher grid levels when possible. So if you have a 32-unit-thick wall, try to align it to the 32x32 grid. If you add an 8-unit-wide railing, try to align it to the 8x8 grid.

As for overlapping brushes, this is fine BUT the thing to avoid is having things overlap slightly, when they could just touch perfectly. So if you have two brushes side-by-side, don't just put them so they overlap by 3-5 pixels, make the edges actually line up flush. This is mainly for the same reason as the previous paragraph about aligning to the largest grid size possible. 

What is that information on grid alignment based on? Is that a gut feel thing, or is there a technical foundation behind it?

I'm not challenging you, but I've heard a lot of level design advice over the years that is basically couched in "this is the way I learned to do it". Well, great, but if there's no QBSP related reason to do it... :) 

Mostly gut feel, based on what i've seen, what i know about qbsp, and what i've absorbed from others. I think you are correct to challenge this advice as perhaps more "mapper lore" than solid fact.

Scientifically, i would have to make an entire map the "messy" way and compare it to a "clean" map to have any evidence that it mattered.

But, since brush faces determine BSP planes, it seems plausible that it would make a cleaner BSP if there were fewer unique planes and more nodes that cut along the same planes.

I can say from experience that maps with more orthogonal brushwork compile faster than maps with many angled planes, since i've done both of those types. And i see more (seemingly) extraneous face cuts in areas of maps that have a lot of non-orthogonal brushfaces.

I can also say from experience that when two nearby brushfaces are parallel but not coplanar, it is more likely to create additional cuts on nearby faces. (presumably because if they are coplanar there can only be one cut on nearby faces since there is only one plane.)

Qbsp does do a decent job of merging neighboring faces when it can, this mitigates the problem in terms of raw poly count, but i believe the extra bsp complexity is still there.

More facts on this topic would be useful. On the other hand, I have heard that even John Carmack has been suprised to hear certain results (such as the reported finding that 64-unit walls produced better vis than 32-unit walls.) [citation needed]

In terms of "advice to a newbie" i still feel better advising 'clean' brushwork, since it is proven successful, rather than 'messy' brushwork, which might be harmless but i don't think has the same track record. 

I spent about 1 week making a small test map in ut2k3, for a job application. I built everything the quake way, all clean and lined up on a grid and flush with each other (though of course i used the subtractive brushes to make the initial rooms and some of the smaller alcoves.)

... and had all sorts of headaches with compile errors, geometry errors, etc!

Then i opened up one of the ut2k3 maps in the editor to see how they did it. What i found was: 1. there were only about 15 brushes in the entire map (rest was static mesh), 2. all the brushes were subtractive, 3. and they were all random sized, non powers of 2, off-grid, and slightly overlapping! And of course it compiled perfectly.

I ended up getting a job on a Q3-engine game instead, so it all worked out in the end. :) 

Haha, yeah, we rarely use BSP for anything these days other than floors and the occasional wall. Everything else is meshes. 

really like the term "mapper lore". 

n 

I finished a map two years ago. It was broken and ruined with brushes used on all gridsizes.
When I realized I could never get a clean bsp, as the map started leaking and homming like a rascal, I decided to start again.

I compiled everything clean on grid. It was a repetive thing to me, but to my surprise the map rounded out good.

Then I decided to add a terrain map, which was a construction of triangle brushes ending up in sloped edges. Apart the map compiled well.
When I added the terrainmap I had to realign all brushes to fit them on grid.
And this broke up all my smooth pathway, but it worked. 

It's just good practice to keep stuff neat and orderly. 

please 

but now my smooth terrainmap only imports on rougher brushes by marking all on grid. Or I could ignore warnings.

Ricky.., you played the map. More or less..,
https://homedrive.ziggo.nl/gimli@home.nl/publiek/gimli30.htm

Is there something to do about model skins that keep get mirrored?
I broke an evening to get me a good baseframe,
and now it keeps removing front with backparts. 

http://members.home.nl/gimli/gimli30.htm 

Is this really a MadFox map?! Looks neat.
Though I suggest you change the texture on the railings to something without rivets, a simple brown or gray metal. 

Looks great, MadFox ! 

Railings are dxf files which have no shadows, same as the hillslopes. This makes lighting a little tricky seeing the clear dxf file near a brush. Could have another texture but the hexen2 wad is rather bloomish.

My concern is that the middle low pix is a sloped pathcorner around. In the testmap the pathcorner was well closed, while in this map it suddenly shook all brushes in it.

I had to use "force to grid" for all and now it has more of a stairway. But I wanted to make a map once whith all brushes integer.

When two maps with both integer brushes is put together, is the need to replace the imported brushes back into integer origins normal? 

Is Hammer 3.5 the one that can be coerced to work for Quake1 editing? I can't keep it straight anymore. 

Its the same thing really AFAIK.

Although I have heard of someone using Hammer for Quake ........ 

Is it the same?

OK, if not, where can I get 3.3?

And once I get it, do I need to do anything to it or will it "just work"? 

i'm using hammer 3.5, with out that fecking texture trouble off of WC3.3 

Cool! So I install 3.5 and then this QuakeAdapter thingamaroo and it's all good? 

You need to convert the wads though. It's semi automated - have to put them in the right folder. 

VeniVidiFuzi

is an awesome name :D 

This was discussed above, I know, but I need to ask again since none of the solutions up there are working.

I installed Worldcraft 3.3 and did the QuakeAdapter stuff. It loads up and seems to work but I can't select anything in the 3D view. I don't see anything about hardware acceleration in the Options dialog box so I'm kinda stumped.

Any ideas? 

Ahh, found this note in the help file:

"Note: if you are familiar with previous versions of Worldcraft, you may note the absence of the Hardware Acceleration checkbox. Worldcraft will now always attempt to run in OpenGL mode, and if that isn't available through hardware, it will attempt to emulate it in software."

Buh? Now what do I do? :-/ 

Not wanting to sound retarded, but this is actually a recurring bug. I have experienced it marginally on both my old GPUs, but the majority of the time it is fine.

When it happens, just to verify, when you put the cursor over the 2D view does it become a hand instead of an arrow?

Usually a reboot sorts it out on my PC, and it hasnt happened to me for ages, but others have had the same/similar troubles.

Another thing which may help would be the check you are using up to date drivers / drivers which work..... ?

Also out of curiosity, what GPU are you using? 

Instead of "hardware acceleration" tab, there is one which is imply called "filter textures" or "filtering" or something. I think that does the same / similar thing. 

you don't have to convert wads when you use hammer 3.5? 

yes, you're still have to convert wads for using hammer 3.5, but it's much easier then converting via qadapter 

hardware acceleration was the only thing tempting me to move away from 1.6, but the above few posts don't make that look too promising! 

Texture use is much easier in 3.3.
If you rotate something the textures stay in proportion if you use texture lock. I find the "fit" check box easy as well. It allows you to fill out texture on a brush that is not quite the right size, but close enough to look silly.

Another thing I love is the option of making arches. You get a preview screen before the item is placed, where you can change the shapes and other stuff. It's really cool for making curved hallways.

I found the vertex tool a bit easier to use as well.

So, can anyone tell me what version 3.5 adds for Quake mapping ? 

NOT to look silly, I meant ... 

God, what an atrocity. I grabbed a version of Hammer 3.5 that basically works but I can either:

(A) Have proper texture view and no selection abilities or...

(B) be able to select in the 3D view but the textures are drawing all skewed and such on the faces or...

(C) be able to select in the 3D view with proper texture application but it's horrifically slow

Fuck it, let's see what the BSP editor is like. 

A 3d Driver / GPU issue - you're on ATI I guess.

You need to turn off Filter textures in the 3d View options and paste a .dll into the worldcraft folder.

http://rapidshare.com/files/138119760/atioglxx.dll

Basically if the dll exists then it stops WC from trying to use the hardware and retards it back a few generations. Which works.

Or you can just buy Nvidia :P 

It forces software rendering - visually it looks the same as hardware acceleration, can't say I've noticed it being slower either. 

ijed

Thanks but I tried that. That's what makes it abysmally slow. I'll probably try to set up my other laptop soon (an nvidia machine). The BSP editor seems kinda cool though. Maybe I'll try this for awhile. But, of course, the texture tools are pretty bad. 

Is a pain in the arse to set up - the real reason to use it is the very good texture handling and visually simple frontend.

Vista also hates it with a passion. 

Ahh, being on Vista might be part of the problem them too.

No worries, BSP actually seems to be pretty good now that I've meticulously set up the preferences the way I want them. I don't think it has rotational texture locking which is the one thing I really wanted Worldcraft for. I can get by without it though... 

Now you know why you should have written ToeTag crossplatform in the beginning. 

Spirit

So much work. :)


I forgot my main complaint with BSP - the 3D camera controls. Horrible. So horrible.

But Worldcraft isn't much better, so, no loss there. 

different drivers? 

I can't be bothered, to be honest. I'm done with installing different versions of drivers to make things work. :) Thanks for the suggestion though. 

I've been all over that s@#*

http://www.amd.com/us/Pages/AMDHomePage.aspx

The newest ati drivers are actually pretty neat. Massive performance increases and everything! Got to be worth a try....

See it occurred to me - the hardware accelleration mode of Hammer likely uses the hardware within your computer.

And seeing as you have told me yourself that you never use your computer for gaming then it would make sense that your drivers aren't up to date. I mean they release new drivers every couple of minutes nowadays. And they release these "updates" to operating systems also.

Maybe thats why I never have any real problems with these things - I recognise the fact that I have to take it upon myself to make sure that I am using the correct tools for the job. I cannot entrust this task to Dell or Hewlett-Packard, they frankly suck. Taking value from the end-user product at every possible turn.

So seriously, if you are serious about mapping with an editor which works well and has all of that magical texture locking stuff which makes it about as easy as Lego bricks, then atleast try installing the latest drivers for your GPU. If that doesnt work then fine, stick to the manual and time consuming method, I'm sure its no big deal.

But its got to be worth a try hasnt it?

If you have some kind of horrible OEM GPU in your box then I'm sorry, I cant offer any advice other than dont buy hardware from these big firms who dont give a c@#p about their customers (HP grrrrr.....) 

Look, I appreciate the help but understand that I've been tinkering with PCs for over 20 years now. I understand all about getting the latest drivers and all that jazz. I got it. I just can't be bothered at the moment.

I'll maybe take another shot at it later this week but I've already lost several hours to getting Hammer working and, frankly, I'd rather be working on my brushes. 

Any ideas?

GTK 1.4

(seriously) 

Last time I tried it, GTK was almost as large of a farce as this Worldcraft adventure has been. Does it have a simple installer and does it "just work"? 

about your platform, whilst yelling "farce" and stuff, man. You ask for help then you tell me you "might" try again later.

I dont understand. I defend the editor because I have been using it ever since I upgraded from WC 1.6.

What features does Hammer have that Worldcraft 3.3 doesnt anyway? AFAIK they are extremely similar, the interface and button icons and everything are identical. But the Quakeadapter was meant for WC 3.3, but you used Hammer. Why?

Also, for future reference (for me) please tell me what platform you are using? Im only asking because in the future someone will complain that they have the same problem, and if you find a solution ever then I might be able to help them, or atleast be able to say that this happens with GPU x or OS y, and that using driver z helped, or whatever.

Do ya get me?

I understand that it sucks when stuff doesnt work out of the box so to speak (took me ages to get Bioshock DX10 to run on my Windows 7 rig, and yeah - I was frustrated, tired, had a million other things to be thinking of.

But anyway, if you get a minute, or ever decide to attempt mapping with this software ever again like could you let me know your GPU, OS, driver version and things please :) 

Absolute noob on compilers, but the one time I tried to instal GTK radiant I got lost in different versions my computer didn't like.
Win98 user - Dos fan.

GTK 1.4 worked right away. 

Ricky

Again, thanks, but I'm going to try BSP for a bit and see how it goes. It works. That's all I ask from this stuff. :)

MadFox

I might try Radiant again but I remember a similar clusterfuck with it. Different versions, different feature sets, stuff to install, ... blech! 

What is the problem with the 3D camera controls on BspEditor? 

They aren't UnrealEd's controls, basically. :)

I just have to get used to them I guess. Most Quake editors have clunky 3D camera controls. Any time you require me to use the keyboard to navigate, it's kind of a fail. 

Not sure which version you are using (I use 96b because they dropped support for BspBuild after that) but mouse scroll wheel for movement, and Alt+mouse for 360 looking work fine. I use Shift+ Left Mouse for texture alignment, CTRL + Left Mouse for texture sizing on the fly; and the mouse controls are fully configurable anyway. 

ALT, huh? Will try that (right now it's my middle mouse button). I JUST picked it up last night so I'm definitely open to learning whatever I can about it. 

...and I use CTRL/Alt Left Mouse for texture rotation; especially good for aligning wood textures on spiral staircases. 

I'm still having problems converting my wads into hlwads with the qconverter stuff. I gave up on trying to figure that out, but I'm tired of the vanilla textures lately...

Ricky, I remember a long time ago you offered to give me a few more .hlwads if I needed them.

could you send me the Half life and DOOM hlwads!? 

Since we happen to be on the subject of mapping editors, I feel I need to share this bit of info in case someone else encounters it. I probably am the last person using Worldcraft 1.6, but irregardless.

If you are using an Nvidia graphics card with the latest drivers, and are on Windows Vista or 7, you will experience a garbled 3d view in WC 1.6 that seemingly can't be fixed. This is because it's due to an Nvidia driver fault, and not because of Vista or Windows 7.

Worldcraft 1.6 uses DirectX, NOT OpenGL. WC uses the nvd3dum.dll which is Nvidia's Vista compatible D3D driver. This is the driver that causes the garbled screen problem, at least the current version of it does now. Any version higher than 182.50 of this driver causes the garbled screen.

So in order to fix it, you must copy the nvd3dum.dll from an older set of Nvidia drivers (182.50 or below) and place it in Worldcraft's main folder. This will remedy the 3D view problem.

I will gladly provide the old nvd3dum.dll driver that fixes the garbled screen problem, but again I'm not sure if anyone else out there uses WC 1.6 anymore. Still, I felt it was necessary to share in case someone does. 

I'll see what I got ready.

The HalfLife one needs to be tinkered I think because its too big/has textures which are too big.

But I got the doom ones :) 

but again I'm not sure if anyone else out there uses WC 1.6 anymore

i thought my post above kinda suggested i did :)

i have a nvidia card too, but am only on XP. useful to know if i ever end up getting windows 7 though.

just to clarify, do you mean the normal 3d view or hardware accelerated mode? the latter has never really worked properly for me (can never seem to select the right brush/face/item) so always stick with the standard 

thanks dude, I really appreciate it if you can, but no worries if it won't work out. 

just to clarify, do you mean the normal 3d view or hardware accelerated mode?

That's a good question. Yes, it only affects the normal software rendered 3D view. It doesn't garble the 3D view when using hardware accelerated mode, but you can't use that mode either because you can't select anything in the 3D view, as you said.

But since you use XP, you won't have the 3D view problem regardless. :) 

Open Source Worldcraft - because Valve can't be trusted to make it work. 

I'm using WC 1.6 on Windows 7 with hardware acceleration enabled and it works. My computer is an Intel Core2Duo and nVidia 8800GTS.

This is not the original WC I bought, but a version I downloaded from somewhere (my original WC wouldn't run on Windows 7, I found this one while searching for a fix). The .exe file does appear to be the same though. This version came with a Direct3D dll in the folder that apparently used to come with XP but is no longer supplied with 7.

The hardware acceleration is not perfect though. When selecting in the 3D view it will often select brushes off in the distance somewhere instead of the one you actually clicked on. Re-orienting the view slightly will usually fix this. 

BSP is pretty nice now that I've spent a few hours with it. I really like having multiple window set ups at my finger tips - I've set one up for editing, one for texturing, etc. Slick.

The one thing I don't like is that I don't see a way to hide/show brushes/entities without using groups. That will slow me down once a level gets to be a reasonable size. 

I made a floor that disappears with a trigger_counter>killtarget>floor.
It works fine, but the bodies and items keep hanging in mid air.

Oh, and the floor was a func_wall, I don't know if that's relevant.

Any suggestions ? 

That's the standard behavior when killtargeting funcs. If possible, turn it into a door that moves down quickly (and quietly), with a lip value that makes it move a few units inside the lower floor. 

Why can't it ever be easy ? ;) 

I had to make the door move to the side, I can't make it go down. It works fine, only now all the bodies are pressed up to the wall where the door was last.

I don't think I can win this one ... 

like Negke says, the corpses will follow wherever the door goes.

I'm guessing it can't go down because you've got stuff there?

If there's items then just move them up a floor, if it's monster you can try spawning them in after the floor falls away. 

Or prevent the monsters from walking onto the door, e.g. by placing 'soft' monsterjump triggers around it. 

So IS there a way to hide/show individual brushes/entities in BSP without using a temp group? There has to be, right? 

 

Thanks again, some good suggestions.
But I don't know, maybe I'm bitching too much.
It looks a little bit silly, but it doesn't interfere with gameplay so, I don't know, maybe I'll just keep it like it is now.


Yes, there is stuff underneath, I could try the spawning thing.
The monsters need to be on the door too, it's sort of a battle ground with several layers. 

"OR MOVE THE WORLD AROUND THE ROOM!"

Haha, that would be cool !
I don't know if the old engine could take that much travel at one time though !
Have you ever done something like that ?
If so, please tell me where. 

In a Q2 Lazarus map. In it you can make a mirror plane, but the mirror will only reflect entities (monsters etc) not brushwork. So behind / inside the mirror you have to make a mirror image of your level to create the illusion.

Copying an idea from one of the test maps I made it so the player could break the mirror, at which point the fake world (func_wall) was deleted and the real room behind filled with enemies.

I tried a The Cube type thing once as well.

Neither got further than failed mod / test map.

I think Negke had a speedmap with rising water? 

And moved the world, because id1 water can't move. 

OR MOVE THE WORLD AROUND THE PLAYER!

instead of teleporters..,
player not fixed, we can't do that yet. 

You can hide all entites - it's the icon below the Grid menu in the standard set up 'ent' with a line through it.

Next to that is the hide world button.

But, use Groups they will speed up your workflow once you get used to it.
For instance, here is a list of things that I would put in a Group:-

terrain lumps
lights
monsters
lava where there is a lot of different chunks of it
major building elements such as above ground/below ground; or dungeon/library

In fact I Group anything that I want to work on until it is finished and then move onto the next area and switch off the finished area.

I think the key to using Groups is that you can set them to hide what would otherwise be distracting brushwork in dense areas of the map.

Imagine working on this without Groups:
http://img707.imageshack.us/img707/7963/fmbnearlydone.jpg

Compared to:
http://img36.imageshack.us/img36/1206/fmbsameviewgroup.jpg

Entities off and just the Group I am working on.

Groups, they're brilliant! 

Oh, I'm on board with the group train, believe me. That was an immediate win for me.

I was just hoping for a quick, "I want to work on these 3 brushes for a second". In ToeTag I had a thing where I could select them and with a keypress hide everything else.

It's also nice to be able to say, "This brush is right in the way of what I want to see." There's no way of clicking it and just hiding it quickly from what I can tell.

I guess I'll have to get ninja with the groups and deal with it. :) 

I have to use this utility:

http://www.quaddicted.com/tools/setgamma11.zip

With a number higher than 1 to not go blind with the 3d window. 

That's something I don't like in BSP. It has the worst texture browser I've ever used. It's worse than Worldcraft's and that's saying something. :) 

What kind of things would you do to the browser to improve it? 

At the very least, display the textures in some sort of size relative way. Let a 128x128 wall be 4 times larger than a 32x32 floor piece. I really dislike how they all get crammed into the same size box.

That alone would make it more useful for me. 

QuArK refreshes the textures each time you enter the texture browser. So if you have a big wad you will have to wait many seconds and then scroll down to your texture. Idiotic. 

OK, haha, so it COULD be worse... 

Mike

BSP questions.

1) Is there a way to manipulate verts in the 3D view? Like, drag them?

2) Barring that, is there a way to select a specific vertex and then go drag it in the 2D viewports? It's tough to do terrain with triangular brushes sometimes with the way I perceive this editor working. 

sorry

you can select in 3D and then move in 2D. Very useful.

Heh - I never hide anything when mapping. Probably slows me down a lot. I just dont like the idea of having to be cautious about building into an area which already has brushes there because you couldnt see them.

You should see the 2D views from the side of my current map when zoomed out. White lines, black background, just like a big white blob.
I have to select things just to see where they are :O because when selected they show as red!

Im pretty sure that if I was working with a team of people that they would complain about it! 

 

Not so much for slowing your pc down, but more for selectively getting stuff out of the way.

My maps tend to have visgroups set up like this:

liquids
doors
buttons
details

With adding to the list as needed - the show entities option taking care of the rest.

Makes it alot simpler to build recesses for moving stuff, set up triggers and their areas, block stuff out, etc.

Hiding whole areas I don't bother with so much any more. 

that a shity thing in Quark :| but i love the editor... :)

I usualy dont use big wads...

visgroups? how? never try!!! 

Trinca, log in like normal people ;) 

Texture settings are in the prefs menu: in standard set up it is the tool bar icon, top row, 5th one in from the right (pref). Your settings are in there. If you look at my screenshots from earlier you will see I have textures just as you suggest.

Axedskullglow is 128 x 128 and azwall3_1 is 64 x64 

...select Textures from the drop down menu 

Really? Hell yes! That will be great, thanks for the info!

But no love on 3D vertex manipulation? 

I haven't seen that in 3D (not that I have looked) but I tend to select the face in 3D and then manipulate in 2D. The 3D window updates in real-time anyway.

I have a scroll wheel mouse so I select face in 3D, move the mouse over whichever 2D window is relevant, scroll to zoom in or out, right click and drag to move the view around, manipulate brush using this method.

I have been playing with terrain on and off for ages and I have no problems. 

Selecting a brush in 2D is just SHIFT and left click on the brush's centre x.

You can also change the selected face of a selected brush by left clicking close the the outside edge of the new face. 

OK, just checking. I had 3D manipulation of stuff in ToeTag and it was hella useful. I'll just have to get used to this method for now then.

Thanks for all your help, BTW. It great to have someone to fill in the holes that I can't fill with the help docs. 

Hammer visgroups are groups in QuArK... as far as I know ;) 

thanks JPL 

I was thinking of including some monsters from the mission pack(s).
Is there any documentation showing me what files I need to copy and how to write them into the WC fgd ?
I probably need to make a new pak then too, do I ? 

There is something I can't do at all and that is making new monster models. I don't want to learn it either, I think others can do a better job anyway. But I've got this idea of creating a really tall (bigger than the Shambler) version of an Ogre, carrying a large hammer or axe, that is really fast and crushes a player with one good blow. It would be cool to make him act hostile toward any non-Ogres. Not an end boss or anything, just an occasional annoyance. Dodging, shooting and staying alive would be the way past him.

If you like the idea, I would love to use your skills ... 

Model: open ogre.mdl in QME. Scale it up. Delete the grenade launcher (+shoot animation) and the chainsaw. Paste an upscaled player axe minus the hand and move the vertices of the blades until they resemble a hammer (or simply use the Mjolnir mdl). Align the hammer to the smash animation.

QC: no idea.

I'm not going to do it. :) 

I converted some monsters from DOE and SOA.
It's not such a difficult thing only qc is hard to extract as it worms all around.
I once tried the Gremlin for its weapon thievery.

I'm working on the Old Ogre so I could make something like that. 

where's your ID or email? 

Any help regarding any of these would be greatly apprecciated!

Textures - I am still unable to convert my Wads to HLwads. Does anyone know if there has been an updated version of Bakers wad conversion tool?
If not, what is the best way to go about converting the textures manually?

Curves - I have read and come to terms with CZG's 2 point curve technique. I was wondering if anyone could explain a nice clean way to extrapolate that into more detailed curves, using the arch tool or otherwise.
I usually find it impossible to keep my arches on grid/ at the right angles with the arch creation tool in WC 3.3.

Lights - How do I set spotlights up? Can detailed info be found on the Bengt page regarding that?

Thanks! 

OK, well Im nt going to carry on about the texture conversion, but the other points:

Smooth Arches - I tend to do this by eye, looking from the side.

Lights - so make a spotlight ad the key "mangle" with the value "0 -90 0".

The first 0 can be changed of you want the light to point in a funny angle (it rotates the angle of projection through the x axis), the second number "-90" says to point directly at the floor. This could be -45 for example, if you wanted it to point down at 45 degrees. And the final number "0" is irrelevant, it is just a marker. 

Are you on Vista?

Also, don't use any auto-creation tools in wc3.3 - they're all crap.

This is how I make 24 sided stuff -

http://www.quaketastic.com/upload/files/screen_shots/24sided.jpg

Which should serve for high detail curves.

If you go back in mapping help history a couple of pages you'll find a discussion on twists / spirals. 

I include the subtract / boolean / carve on the list of bad stuff.

It's even better to make your own circles using slice, instead of having to auto-make one, rotate it, then snap it to grid with vertex manipulation. 

... yeah.

Ricky - thanks for that explanation - seems simple enough!

Ijed - I've only used the arch tool once - in sm149 (hence the title "Brushwork of The Damned") and I never plan to use it again!

The aspect that confuses me is making a pathway or maybe a hollow tube that encircles that 24 sided cylinder. tightly. without being leaky or buggy or otherwise shitty.

I understand how to me to skew and clip a path like that around a 12 sided cylinder, but I'm at a loss regarding how to do that around a 24 sided cylinder.

Hope that makes some sense. If not oh well, it's late and my eyes are bleeding. 

Right click on the tool and run as administrator - I think that's how it works. Or turn of UAC.

The jpg I sent shows you how to wrap stuff around a 24 sider though - if you try making pie slices out from the centre (same as for a 12 sided) you'll see it stays on grid.

Does take a bit more trial and error though. 

I'll mess around with it.

It's one of those things - I want to learn how to do it "properly" but it's frustrating tinkering around when I could be making a fun interesting map that just so happens to have crappier brushwork.

it's a fine line, especially considering this is just a hobby. I only want to map for fun.

thanks again for your help guys, I appreciate you taking time to answer my stupid questions! 

http://img693.imageshack.us/img693/2403/24sidedarch.jpg

How close is this to what ijed sent you, Drew? Can provide map file if you want.

I did it like this (in gtkradiant 1.4): Start with 24 sided cylinder, 256*256, using standard ratios. On an 8-unit grid, the ratios are: 2:0, 4:1, 4:2, 3:3, 2:4, 1:4, 0:2.

Then copy it and scale it up 1.5x, and again 2.0x, radiant can do this scaling easily. Then draw imaginary lines from the center to the edges, the points should match up (pie slices as ijed says).

Now... wrapping a hollow cylinder around a cylinder... is possible, but a fucking headache, and it's actually somewhat editor dependent as to what's possible or not. Last time I looked at the problem, it was simply not possible in Radiant to wrap a 12 sided hollow pipe around a 12 sided cylinder, because of, well I'm not sure exactly, but it has to do with how radiant won't let you make invalid concave brushes like worldcraft will. That old "CZG curve tutorial" is somewhat useless in radiant because they handle skewing and group edge dragging completely differently.

However it is entirely possible to wrap a simpler, 8-sided cylinder around a 12 sided one. It should be possible to do the same around a 24-sided cylinder, though I'm not sure if I've ever tried. If you do, make the pieces really big so it fits on grid. In the above screenshot, the arch goes down to 2 and 4 unit grid already. 

But mine's on a bigger grid - the principle's there but like you say, so're the different editor techniques.

Since the finalised shapes from wrapping around are valid have you tried figuring out a Radiant method from a .map made in another editor? 

I remember that I used the clipping tool a lot for wrapping curves. You can use it to cut the wall brushes of a pipe and other shapes very easily simply by drawing them from the center out to a point that is on the grid. The end points must however be chosen so that adjacent clipping lines all have the same angles (e.g. 360 / 24). I think I did that by creating a very large cylinder with for example 24 sides whose vertices were aligned on the grid.

Dunno if this makes sense, but I do remember that making curves was very easy this way. Also, you can extend this method to 3D using clipping planes, but it's obviously more work. 

The clipping lines for any curve brushes extend from the center of the curve to the vertices of the "guide" cylinder.

Also, remember that brush vertices don't need to be aligned on the grid since the brush faces are not defined by the vertices, but by three coplanar points. Radiant handles this very well, as opposed to other editors (QERadiant that is). 

Working with the brushes that make up the curve is very easy in Radiant due to its face dragging feature. 

I see you are using Radiant in Mac OS X there. How did you set it up? I tried it several times, but it never worked for me. Can you give me some hints? Which version is that? 

thanks grahf - I'd appreciate it if you'd send the editor - i'll try it out! 

probably a dumb one, but probably easy to answer.

fade attenuation value? 

Sleepwalker: the short answer:
http://redsaurus.net/gtkradiant/ <-forum

http://www.redsaurus.net/macradiant/GtkRadiant_1.4_1.5_Macintosh.dmg <- should be universal binary installer

The long answer is, the short answer probably doesnt't help much at all. Half that forum is outdated information, the other half is info about useless games like Jedi Academy. The installer and some useful stuff is on there somewhere, though. I'll start from the very beginning because I don't know how far you got.


I am on PowerPC/Tiger and I suspect you are on Intel/Leopard, which is a minor hurdle but not insurmountable. I did have it installed on 10.5 for a while, but this old laptop just didn't get along with Leopard too well.

Install X11 first, nothing will run otherwise. In Tiger this came on the install discs, on Leopard get the latest from http://xquartz.macosforge.org/

OK, inside the DMG I linked to, you find GTKRadiants 1.4 and 1.5, and a Packs installer. There is some documentation in there, but it's not incredibly helpful. Run the Packs Installer; there is no Q1 pack, but it needs to find at least one game to install some files that Radiant needs, so point it at a Q3 installation. Put the Radiants whereever you want on your HD, it will just change the file paths we'll be editing later. I personally hate gtkr 1.5 with a passion, so everything that follows will be for 1.4.

Load that bad boy up and see if it runs. Oops, it almost certainly doesn't. You'll need this: http://www.redsaurus.net/macradiant/MacRadiant14intel.dmg

For more info on getting that to run, I'll refer you to:
http://tremmapping.pbworks.com/GtkRadiant1_4-Intel_MAC
http://openarena.wikia.com/wiki/Mapping_With_MacRadiant
http://alientrap.org/forum/viewtopic.php?p=37611

I don't have an Intel Mac (yet), so I hope that helps enough to at least get the thing to open. The NetRadiant fork may be easier to get up and running, but it's 1.5 based, so bleh.

Quake 1 support section! Once it at least runs, close it again, and do View Package Contents -> Resources -> sw -> radiant14. Hey look, it's the actual Radiant folder, buried in the app package. From here on, the process parallels what Tigger-On describes here, configuring Radiant for Quake: http://industri.sourceforge.net/howto.php

find the games folder, copy q3.game and name it q1.game, change some stuff. Mine looks like:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<game
name="Quake 1 / Nehahra"
gametools= "/Applications / Games / Quake1 / pathofthesoul / MacRadiant14.app / Contents / Resources / sw / radiant14 / q1"
basegame="id1"
enginepath= "/Applications / Games / Quake1"
engine="Fitzquake.app"
prefix=".q1"
default_scale="1"
/>

Adjust accordingly. I added those weird spaces just now so the forum doesnt freak out, but you get the idea. Notice I have "Quake1" not "Quake 1" though, I might have done this because because Radiant didn't like seeing any spaces in its file path.

Now you can put stuff into id1/textures, id1/scripts, id1/maps, etc., just like on PC, yay. I later tried to get clever with project files and point it to a mod directory parallel to id1, which kinda works.

Ah, one last thing. every time you try to open or save a map, the file dialog probably isn't pointing to where you want it, and the GTK file dialog box is pretty shit. In your home folder, there is a hidden folder with the name given in the "prefix" line of the .game file, usually this is ".q3a" but I changed it to ".q1". Inside should be a folder with the name of the basegame directory, which probably will be "id1." Inside that folder, make unix symlinks to your actual working maps and scripts folders. The documentation file in the .dmg we downloaded has a simple method of finding the path, and a contextual menu plugin to make the symlinking easier.

It's worth noting, Sleepwalkr, that I'd have given up at this years ago if it weren't for your java mapconverter - works like a charm in OSX! So thanks for that. 

It's just 1kb, zipped.

http://www.mediafire.com/?qjnimzdjnjl 

Everything Sleepwalker said about wrapping hollow pipes around cylinders is correct. That is exactly how I did it, it's just been a while. 

Awesome, thank you very much for your detailed instructions. I'll surely try this out tonight, hopefully I can get it running finally. Cool to see my old mapconverter is still being used! 

please?

found this whilst i was looking for a quake.pal palette file for Paint Shop Pro, which was interesting:

http://www.studio-erebus.com/studio/tutorials/palettes.html

Scroll down for some quakey stuff....

Anyway could anyone really help me out and point me in the direction for a qauke.pal file, because i cant find a tool to convert palette.lmp to .pal format, or whatever it is im supposed to do here.....

Starbuck, heeeellllllpppppp!!!!!
Metl....? 

1. open a quake texture in photoshop
2. export the palette
3. profit
4. ???

To get a quake paletted texture, open a wad in texmex or whatever, and export it in an 8bit format (gif or pcx should work). The texture has the whole palette embedded in it. 

Grahf:

I don't know if this is true or not, but I I'm pretty sure I remember someone saying that there's a setting in GTKRadiant where you can toggle it to behave like Worldcraft so you can make concave brushes and save a little time on doing curves around curves that way.

Anyone confirm this? 

What does it do with the concave brushes? Carve them up at MAP export time? That sounds ... dangerous. 

there are no concave brushes in WC. If one is made then it's invalid - you can still vertex edit it back into validity though, but for curving stuff I only use slice. Sometimes vertex edit if I screw it up, but that's only to get it back on grid / properly aligned. 

OK, well thanks for the solution Grahf, but unfortunately I left my copy of Photoshop on the bus last week and.....

So no-one here can hook me up with a .pal file with the Quake palette!?!?

Man how this forum has changes :(

(sulk) 

GIMP I think has all or most of the funcionality that Photoshop has and is free. It probably has a palette export option (but I rarely use my copy of GIMP so I don't know for sure.) 

http://www.quaketastic.com/upload/files/misc/quakepal.zip

Found this in my wally folder. GIMP can export palettes, but they're not in the same format as POS it seems.

Anyway. Is this the right thing? 

I think its the right thing, I will try it when I get home! :) 

There's one in RMQ's gfx folder. 

http://ftp.gamers.org/pub/idgames2/planetquake/chopshop/examples/quake/palette.zip 

Blitz: The option is "vertex editing splits the polygon" or something. It doesn't actually help the problem, instead it just sends you to vertex editing hell, where all your faces are split into two triangles, and you still can't pull the vertices where you want them, because even with that option enabled it won't let you make an invalid brush.

The way to do the "pipe around a pipe" thing really is as sleepwalkr said, with clipping and face dragging. Maybe I should make a little visual tutorial.

Ricky: Have patience. Also, I found something quake palette related, nice little index of which color is which colormap number.
http://img718.imageshack.us/img718/1070/quakepalette.png 

Radiant vertex editing should be avoided if at all possible. 

Vertex editing should be avoided period. All you need is clipping and face dragging to shape brushes. It avoids a lot of problems and lets you create shapes that are very hard to get right with vertex editing if you get a little creative. 

Ain't you got Wally installed?
There's a q1.pal in it. 

Guess I was wrong.

This is still the forum I thought it was. Im sorry I ever doubted.....

Actually thanks a lot guys, I have no excuses now ;) 

 

.. I never experimented monster jump: is there any map example "for the same" (<- Indy style wording) :P
Or couldn't somebody explain me how it works ? 

i think that's how the ogres jump down and attack you in....errr...that map...uhh... when the doors shut and the ogres are above you, maybe in episode 3? 

.. I never experimented monster jump: is there any map example "for the same" (<- Indy style wording) :P
Or couldn't somebody explain me how it works ?

e3m7 the haunted halls, 

trigger_drolejump

angle
speed
height

Used as described above to fling enraged droles in a specified direction. Identical to a trigger_monsterjump, set the "angle" key for the direction the drole will jump, "speed" for the number of units/sec the drole will move horizontally and "height" for the number of units/sec vertically. 

I'll check it ! 

I came across an old backup cd with an unfinished map from 2005 on it but I don't have all of the texture wads to with.

Does anyone know what wad has the texture db_rock05?

it must be an outside dirt / rock type texture as the brushes are in an outside area. 

... it is from bulowad (or bulowad2) texture set

Check it out there http://www.quaddicted.com/wads/ 

Thanks JPL!

bulowad2 is the one. 

different versions of the Quake 2 textures?

either in maps or wads or zips or whatever?

Im particularly interested in any quake1 maps which use ported Quake 2 textures. I have the full intention of finding some textures which are better than the ported Quake 2 textures in quaddicted/wads.

I can do my own conversions but my attempts at converting the stock quake 2 textures or the standard hires replacements has had funky coloured results........ 

metl's oblivion? 

is there a waterfall sound in the quoth pack?
what is it called if so? 

That's what I told him. Oblivion is nice. 

There is a waterfall sound, the path to it is

sounds/necros/water6.wav 

Sound is of course singular in the quake directory structure, so I meant to put:

sound/necros/water6.wav

Then again, when you add paths to call sounds you have to omit that directory name anyway. 

Every time I go to the Check for Problems tool I get a list of errors that are no real errors, like this :

"The entity contains keyvalues that are not used in its class. You can fix this error with the Fix button."

I've not tried using the fix button, I'm not sure if the entities will be deleted if I do.

Anyone know how I can get rid of this problem ?
It's quite annoying because the Check for problems tool is quite useful for pointing out mistakes with vector manipulation. 

This comes from the keys which are specified for each class in the FGD file. Its not a "real" problem, and clicking on fix wont remove the entity. Infact clicking on fix wont do anything really!!!

All of the "real" problems are usually at the bottom of the list. I always start at the bottom of that list and work up. You get any illegal brush errors there, or bad textures etc.

One thing which you get in WC is brush models with no volume (no brushes attached) which are often situated at position 0,0,0. You can delete these by clocking on goto error, closing the "find problems" dialogue and pressing delete ;) 

http://games.softpedia.com/get/Tools/Valve-Hammer-Editor.shtml

This link is to a hammer.exe file which you can put in your WC DIR and then just run from there.

Then you can see how similar Hammer 3.5 is to WC 3.3! (its sooo similar i only noticed one real difference - you can load pointfiles and see them in the 3D window. in 3.3 they would only show up in the 2D views). 

Anyone know how I can get rid of this problem ?

just open the fgd file, find the relevant entity (or baseclass) and add any used keys that aren't there.. voila, errors be gone! 

Thanks a lot !
I'll have a look at .5, I take it the Quake adapter will work for that version too ? 

Well that's what I mean. I ran into this file whilst looking for a hammer installer. All I did was drop the only file in the archive (600kb) which was hammer.exe into the Worldcraft directory and clicked on the exe. I had already been using the Quakeadapter WC3.3 setup and this seems to use the same configs and everything.

Its not an installer, its a program.exe file :) 

Will take a look at that.

Don't use the fix button for that error message - what it does is delete all the keys it thinks are broken - so it removes all your entity configurations.

Need to get the RMQ fgd to stop reporting that crap.

In fact the only time you want to use Fix or Fix All is when you get a Texture Axis perpendicular to Face. The rest of the time it's best to just use the problems thing to find it, then fix the thing yourself. Like you've been doing from the sounds of it.

The perpendicular texture thing causes a corrupt bsp - and the chances are you won't even notice it since it doesn't affect all OS' / setups. Its caused when manipulating objects with vertex editing / slice. 

hahaha thanks! 

corps_removal? 

add to def.qc:

void () CorpseThink =
{
self.think = SUB_Remove;
self.nextthink = time + 30 + random() * 30;
};

All monsters in last death animation (ie example shambler):

void() sham_death11 =[ $death11, CorpseThink ] {};