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
Drew 
Too much Doom? Linedef tag 48! 
BspEditor Update 
http://www.bspquakeeditor.com/

Support for high-res textures and sky_boxes.

Dropped support for BspBuild (boo... ) so I won't be upgrading. 
Speaking Of Hi-Res Textures... 
Are there any tutorials on using 24-bit TGA's in Quake? It seems like some refuse to tile correctly.

If not, how do disable/override using 24-bit textures in FitzQuake?

Spanks! 
 
3 point clipper looks cooler in bsp than radiant. :( 
Origin Brushes 
Anyone know of a compiler for Quake 1 that supports origin brushes? There's talk on the inside3d forums of one existing, so it'd be great to have a copy. 
Preach: 
that would be great to have if it exists, and I think it is at least possible that origin brushes could be supported, but I don't know offhand whether the quakec func_rotate_* code would have to modified to work correctly with it. 
Rotate_object 
At the moment a rotate_object with a target uses the matching target entity as it's origin vector. Then all the brushes are moved that distance in the opposite direction so that they line up again. That's the same effect as the origin brush would have, so the hipnotic code would work straight away. Still might be worth revisiting that code though... 
 
That's the same effect as the origin brush would have

Well it's not just the actual pivot point that is important. It's also the default placement of the brushmodel in the world, which affects things like texture alignment and dynamic lights -- both of which are incorrect the way we currently do rotating brushes. 
If Someone 
Could find the time to streamline / rebuild from scratch the shitty rotating code it'd be nice.

It doesn't have to be easy to build a rotating object, but it should be possible in, say, a speedmapping session.

I suppose AguirRe is the one to ask about compiler compatibility. 
Ah 
I see what you mean now. In terms of default placement when you load the map, it'll load in the right place, you wouldn't have to fiddle with the origin any. In terms of whether the texture alignment/lighting would be correct, that would really depend on how it was written. The most straightforward way of doing it would just use the hipnotic code straight away, except it would calculate the origin value based on the origin brush instead of the targeted entity. So it'd have the same problems. You could rewrite the whole thing - and if you were bothered to do that you might as well add origin brush support at the same time. But I wouldn't want to... 
Aw . . . 
Heheh ;) 
I Know, But I'm Allergic To Programming 
 
Oops Wrong Post 
 
Say... 
I need a Q1monster that can walk, but also swim.
Would this be a holdup to the walkmonster_start code?

I mean, I can't put both in a qc-script?
Or something like a fly/walk monster? 
kell and i toyed with this for a bit and it's definatly possible.

i would recommend you make a new ai_run function. in it, you need to check the pointcontents() of some point (i used the origin) in the monster to check every frame if it is in a liquid or not.
if it's not in the water, you need to remove the FL_SWIM flag (and likewise, add it if it's IN water). the FL_SWIM flag is what lets fish and stuff move around in water. apart from that, there's very little that needs to be changed, although i'd recommend adding a new trigger_jump type brush entity to help the monster make the transition between water and land, unless you want to build ramps all the time. 
. . . 
Sounds like the Nehahra Jagger. 
Thanks 
for your answer, necros. Fact is my qc knowhow isn't bigger than a mouse, and even that I could make hardly go walking.

If I look at the ai_run function I haven't a clue where to begin.
There's a FL_SWIM flag in the monsters.qc where the options for moving monsters is specified.
So I guess making a new ai_run function isn't enough. 
JPL Or Anyone... 
What is the best way of doing coloured lights?

What light util is best (does AguirRe's support coloured lights?)?

To my understanding a light ent needs to have the key;

'_color'

with a value of something like

'255 0 0' - pure red
'0 255 0' - pure green
'0 0 255' - pure blue

Fitzquake is a good engine to use? Any others?

I have tried experimenting but when used a method like the one described above, Darkplaces seemed to show the lights as being rather ugly incorrect 'rainbow' type effects?!!

What am I doing wrong?

Note - I am aware that there are supposedly two types of bsp coloured light info files - a bsp30(?) with the info stored within the file, and a 'lit' file which would go alongside a bsp29(?), and that bsp29(?) is compatible with non-coloured light supporting engines.

This is what I know (or what I think I know), any help mucho appreciatado! 
RickyT23 
The field you are adding are correct (i.e _color <R> <G> , R/G/B values in 0-255 range)
Also, try to be as smooth as possible: I mean that strong colors generally kills the map, giving it ugly rendering.

You also need a light tool that generates .lit file (like Tyrann's light tool as example: check out http://www.disenchant.net/utils.html )

OTOH FitzQuake supports colored lightning, aguirRe's engine doesn't. you just need to put both .bsp and .lit file in the map directiry, and it is done...
Concerning DarkPlace, AFAIK it supports colored lights, but needs .bsp file using bsp30 format, and bsp29 + .lit file are not correctly handled..

On my side, I genrally use .bsp in bsp29 format with its .lit file: it can be independently loaded on different engine that support (or not) colored ligths... and I don't use DarkPlace at all: it sucks IMHO... just a question of taste... and FitzQuake is the reference engine here... please be "corporate" :P
 
OMG 
I completly forgot that <bold> </bold> story... gasp :( 
Hmmm.. 
I have much experimentation to do later! Thanks for the info - I know it sounds like I already just about knew what I was doing, but for some strange reason I havent managed to successfully create a coloured light yet!!

Its finding the right mix of colours to get a good looking light I guess.

Hmmm, I wander if the map I'm creating will run on fitzquake, cause I know AguirRe's engine will handle big maps, and my map is currently quite big (not as big as The Sickbase though)! I guess thats why you made Five Rivers Land three maps rather than one... 
Yellow? 
How do you get a shade of yellow using RGB configurations??! Green would have to be used with both red and blue I 'spose, but to what degrees? 
Not Sure For Quake 
But typically green would be 0 255 0 and yellow 255 255 0. That should produce very bright colour, so lower the 255's until you get something that looks good. 
For Color Choice 
Just use your prefered image tool (e.g Pals2Go, PSP, Paint, etc..) or this link http://www.visibone.com/colorlab/big.html .. ;)

For yellow, I use personally RGB as 255 255 220, sometimes 255 255 200.. Lowering all the fields will pull the color to "grey"... and decrease its strengh actually... It is far better to play with delay and wait value... though...

Let's experiment: this is the best way to go :P 
Well.. 
I experimented some last night, and managed to get some coloured lights working in a small map, but when I put some in my larger map (3mb) tyrlite gives the error message:

"color 0 < 0"

about half way through the total number of faces!

Yes I was using a command prompt. I tried making sure that none of the color values were 0, but that didnt make any difference!!

before that I was getting another error message that said something about a 'stack overflow', something like 'drawskycolor'. Anyone got any clues?

JPL - That website you have linked to is very usefull! Thnx! 
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.