 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
yes, you can do it that way, however, when the player is too far away from the sound emitting entity, if it is not an ambientsound(), the game doesn't bother to keep track of it in some way, so the sound will stop playing. (i think this happens when the ent's volume reaches 0 from attenuation) so when you get near to the ent again, the sound won't play.
another hacky way of doing it would be to have a looping sound. find out the exact length of the loop up to the second decimal. ex: length = 2.39 seconds. use the play function to start the sound, and keep restarting the sound every 2.39 seconds without the autoloop feature. the sound will be interrupted if the player goes into the console or menu or whatever though. also, if host_framerate isn't 0, then the rate at which the sound is called will be different as well. you could also leave the autoloop markers in the soundfile in, and keep overriding the sound on it's own channel everytime but that's just ugly. Thanks again. The best solution I guess would be the one in your first post, which incidently I wouldn't call particularly "hacky" - it's just making use of an already existing network message that is otherwise unused in the QC.
Nothing in aguirRe's Tool Tips
Can someone give me an explanation. I have just run into this error after adding the final brushwork to FMB100. The brushes are not important and I can leave them in or take them out (although it looks much pretier with them!) It is only a warning and I can not find any problem in the vicinity of the brushwork e.g. random clip_brushes, non-solid brushes etc. But I would like to understand what is happening. I think I remember getting this in Bastion at some point; is it associated with any hull in particular? IIRC, it didn't seem to cause any detrimental effects when I had it.
The first thing qbsp does to a brush face in the map file is to transform the three points into an infinite plane. These three points are all on this plane with only minor float precision offsets.
If I understand it correctly, qbsp then starts to figure out how this plane is limited (clipped) against the other planes in the brush. In this process, more points (vertexes) will appear in the positions where the planes meet. When these new points are checked against the original plane, they might be slightly off and when the distance exceeds a certain limit (0.05), a warning is printed. In my latest compilers, I've added an automatic healing of such points, i.e. adjusting them to the plane. It appears to help a bit, but I'm uncertain of the theory here In any case it's usually rather easy to find the problem spot and align the vertexes, at least in hull 0. In qbsp, I get a warning during LoadMapFile:
*** WARNING 03: Line 60471: Brush with duplicate plane would it be possible to print the origin/location of this brush, so that I can chase it down? AFAIK it's an editor error; you shouldn't be able to produce such a thing. Therefore I doubt that you can fix it manually in the editor other than deleting/recreating the entire brush and hoping the editor won't do it again when generating the map file.
Also, at the time of discovery, the location of the brush isn't known yet. The extra plane will just silently be dropped with no side effects. and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.
In QuArK I can do that and I guess GtkRadiant has something similar. Btw Kinn, your choice of emoticon is a bit odd and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.
Hmmm...I don't think I can do that. Can any other Hammer users confirm this? your choice of emoticon is a bit odd lol, the wink? I dunno, it kind of makes sense to me, almost as if qbsp is taunting me with a wry "I know something you don't know" warning, without actually telling me the source of the problem. ^_~ I thought the little guy was leaning down to his left side to snort a line. I guess your interpertation makes more sense.
The classic examples of that would probably be Mixed face contents or Bad contents.
Somewhere in your 10k brush map, there is something bad. Go figure I've just downloaded the latest version and it seems to have support for Quake1. It loads
Does anyone know how this is done - there is nothing in the Help files on Quake1 texturing. Place the
For what it's worth, I would use GTK 1.4 or earlier rather than 1.5, a bit more messing around to get it set up, but far less buggy etc, and IMO, just better to use. I have a similar problem with GTK1.5. I have the
When I asked about it, they said to include the path to the Thanks, that's a start anyway.
Zwiffle: are you compiling from within GtkR or are you using some sort of 'tweak'? I am still using BspEditor with BspBuild and have no problems apart from using the 3D view, which is extremely slow (I have a decent system). Also, you have to be careful not to hold your finger on the forward/backward key because the keyboard buffer fills faster that the screen can draw and there seems to be no way of stopping it moving once it's started. Hence, I am looking at changing editors. Ok, i'm using quark and don't know how to get a "quake" key to turn into a key card.
It depends on worldtype value into the worldspawn of the map
"worldtype" "#" // Describes time of environment (changes appearance/name of keys) // 0 == Medieval (medieval) // 1 == Runic (metal) // 2 == Present (base) You can take a look at http://www.gamers.org/dEngine/quake/QDP/qmapspec.html for further details about QuakeC specifications..
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |