 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. 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...
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. 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. 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! 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 OTOH FitzQuake supports colored lightning, aguirRe's engine doesn't. you just need to put both Concerning DarkPlace, AFAIK it supports colored lights, but needs On my side, I genrally use 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... 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?
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.
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 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! standard command prompt (a dos box). Also tried Worldcraft process window with -nocount
I was refering to the light tool command line you typed in the prompt "DOS" window.. Did you add a -lit option ? What is the light tool you are using BTW ?
Tyrlite 0.99e
light -lit -extra <file> I also have a copy of Tyrlite 0.99c but havent tried it, I wouldnt have thought it would be much different It says: lighting face ##### out of 11### (ish) gets to about 5000ish then says: Error color 0 < 0 Maybe you can do several things:
First is to test the light tool without -lit option, to see if it has any effect Second is to check all your light in the map file (e.g, open the Third is to try another light tool that support colored lights: maybe it can come from a bug of tyrlite... but I don't really think it could be that... Kepp us informed please ;) im gonna try hmap2 (lordhavocs) stuff aswell, although im not sure if it'll work with the color values already in the map cause they gave an example color in readme as '1 0.6 0.4'
Although its supposed to support halflife light ent fields '255 255 255 300' - last figure is 'light' level (brightness). Ill see... Are there any other color supporting light tools you know of? Before I post some shots of 'successfull' tyrlite rendering on my level, I would like to say some things:
AguirRe - your tools rock! Maybe its because I work too much detail into my maps, but your tools handle them all perfectly where others wont! I get the best looking results with your light tool. Other tools supposedly even offer extra8x8 lighting options, but on my maps they give crappy looking results. Yours (always run with -extra4 -soft) give really good looking results. Either of your bsp tools compile my maps where others wont, same for your vis! Its just a shame that you light tool doesnt support coloured lighting. Have you ever considered creating a version of light that does? Im sure it would be the best light tool ever made for Quake! First of all I would point out that the bug I reported before still occurrs as before when I use the command
-extra When I dont it works OK but gives the following effects on solid entities: http://shub-hub.com/files/images/RickyT23color.jpg http://shub-hub.com/files/images/RickyT23color2.jpg Notice also the harsh black areas in the second shot. This sort of effect is continued throughout the map, in certain areas. The first shot shows some func_walls which arent being hit by the colored sunlight cast. On the other hand areas outside where the sky colour is being cast DO look OK! Anyone got any idea why solid ents are doing this? Hmap2 (lordhavocs) tool also will light the map if I change the _color values to '1 0.1 0.1' for example, but the weird effect occurs not only on solid ents, but also on some world areas. For Tyrlite im using '230 40 40' or suchlike.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |