News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Because 
In 3.3 you lose cross-editor compatibility and have to convert the textures to wad3?

...I still use it though :) 
Texture Luck 
Sock uses an old version of Radiant, I don't know how it works there, but the texture lock in new(er) versions produces decimals in the offset values which are not supported by standard QBSP. This can lead to textures getting misaligned by 1 unit in-game while looking perfectly right in the editor. Got to keep this in mind. 
WackyCraft 
When I say 'cut and paste brushwork' I do not mean texture lock/rotation. If you look at the architecture of my maps they are consistent, each arch, door or pillar is the same size because I cut and paste the brush shapes and then apply the texture afterwards.

I created the textures based on the brush shape so I only need to nudge the texture surface until it fits. This approach really makes a room/area feel like it is designed to fit together. When the texture and architecture are in harmony, the scene looks and feels better. 
Netradiant 
Coming back to this after 9-10 months.

Anyone know how long the netradiant site has been down? http://dev.alientrap.org/wiki/7

My version is dated march 1 2012, but there is a bug with the 3-point clipper that crept into that version. Just wanted to know if there had been a newer build since then. 
GTKRadiant 1.6.3 
Move to the latest version, it has better support and there is a coder actively working on it. They are always looking for people to offer feedback and get stuff fixed.

http://www.quake3world.com/forum/viewtopic.php?f=10&t=48330&sid=590f6d83bfd40da9dfdae6ea9aedaa98 
 
 
Ah, looks like they finally added a workaround for the foreground/background issue. Though I'm pretty sure there's still no fix for the NextView button/shortcut not working on the floating window layout. It's been there for years. Will have to stick with Gtkradiant 1.5 for another while...

Kinn, the old download directory is still accessible here, but there's no newer version. There appear's to be some slightly newer build by Ingar dated July 2012, not sure how many fixes it actually contains (if any). 
Cheers 
Ok, thanks chaps - negke, good to know the old download page can still be accessed. I couldn't find it through google or anything. The Ingar build contained 7 trojans according to Kaspersky - probably false positives but...eh.

I'll stick with my current version I think. The clipper problem is minor-ish. (Basically, the "1, 2, 3" number labels on the clip points don't display anymore, which makes 3 point-clipping a game of chance more than anything). 
 
Kinn, I always Shift-Enter the clipper unless I know for sure which side will be removed. 
Scampie 
yes, that's ok once you have the correct clip plane - problem with netradiant's bug (and it's only an issue with 3-point clipping), is that if you lay down the 3 points in XY, then change to XZ (say) to shift the points in Z, because the points are not labelled 1-2-3, then often you lose track of which point needs to move where in order to get the desired clip plane in the first place. It just slows the process down and makes it more annoying. 
Ah 
I get what you mean now. that sounds like a real pain. 
Dead Monster Floating 
I have just noticed that a dead Imp 'floats' a couple of units above the ground. Comparing models in QME, I can see that e.g. the Hknight and the Imp final death frames are both on the grid, and also the eye position is -24 for both.

What determines the final resting place of a monster? 
 
don't really know what the eye position is, or if it does anything.

the 'bottom' of the monster is determined by the bounding box set in the QC.

This is -24z for all monsters (unless you are playing around with non-standard bounding boxes)

As long as the bounding box is set normally like it is for small and large monsters, then any vertex on the model that is 24 units below the origin of the model will be on the ground. 
Necros 
Yes, that was it - looks like a typo in QC as the z was -34. Thanks. 
Texture Query... 
Has anyone come across a texture set that even remotely evokes the Australian bush or outback? 
HL1? 
I think I saw it converted somewhere. 
Guide For Radiant 
Is there any guides on how to setup GTKradiant for quakeworld? which version should I use? 1.4, 1.5 or 1.6? 
This Tutorial Is Pretty Good: 
 
Why are brushes stored as planes and not verts + tris? Was it only to on save filesize? 
Probably Because It's A Better Way To Define A Convex Polyhedron 
with a list of planes 
I Think That's The Main Reason 
On top of that, enumerating vertices and adjacency information is considerably more complex than simply giving a list of planes. And of course there's much more that can go wrong. 
 
Oh,so this is a case of it being the best way to represent the data then? I guess it's only easier for puny human minds to think of it I'm terms of verts and faces. :) 
Well 
From today's point of view, it certainly isn't the best way. We all know the problems associated with this data representation. But in 1996, it was a different case because in QuakeEd, brushes were mostly manipulated by manipulating their faces. I'm not even sure it had vertex manipulation at all. 
Isn't It Still The Best Way? 
Given a list of triangles, you've got no idea whether it's even a valid brush (convex polyhedron) without doing loads of maths.

With a list of planes - by definition, the brush is simply the intersection of all the inside half-spaces. Easy peasy. 
 
But with modern computers, those maths should be trivial? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.