 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Yeah, rectanglar is the wrong word really, I realised once I posed that. Triggers have to be cuboids, not cubes, which means that you can have sides of different length, as long as all the faces are perpendicular to one another. Basically as long as you make triggers from just one regular brush, and don't rotate that brush(other than 90 degree turns), then what you see in the editor is what you'll get in game.
I followed all your advices guys, I even took as example what metlslime did in his Antediluvian map (thanks for the sources, it was very interesting), and I have now at least one of my two wind tunnels that works fine, but the other continues to "glue" the player... i.e: "touching" the second trigger_push make the player progress very very slowly.... and I still don't know why... Did anybody already experiment this strange behaviour? Any idea to solve it?
it's because the player is pushed straight into and along one of the (wide-angled) corners - if the wind tunnel is a pipe, that is. in this case simply clip off the corners and it should work better.
I keep a 16" distance between two seperate trigger_push.
http://members.home.nl/gimli/Image01.jpg http://members.home.nl/gimli/Image02.jpg Well, I already have a 96" distance between each trigger push. I think the issue comes from something else but I can't determine what's really going wrong... The more frustrating thing is that I have exactly build the same pipe architecture in paralell and this one works perfectly... Well... Player will have to walk a little bit as wind tunnel are horizontal ;)
Thanks a lot for your advices :) 96" is 1.5 x time player size, I think that's a bit too far. At least 32 would do.
Can't you just copy/paste the pipe, and renew the func_push? Unfortunatly it's not enough... I made several tests, made some copy paste, remove, replace the trigger_push by a new one, change the pipe architecture, etc.. etc.. but it didn't work at all.. Only on on two is workig fine as of today.. I was unable to solve the issue...
And I suspect something else, as I found a massive HOM in the map at the very begining... I don't know if HOM and trigger_push bug have any relations, but I'm afraid there is.. I will try to solve the HOM first, and then will see if it helps for trigger_push... Thanks for your advices: as I already said, at least I have one wind tunnel that works fine... ... try:
a) Raising the push speed of the the trigger_push to double what you have it set at now, or probably more successfully... b) I'm assuming the player jumps up into the first (vertical) wind tunnel which throws them into the horizontal trigger_push. On the return, why not have them drop into the horizontal wind tunnel (this will work if the trigger_push is shaped close enough to the floor of the tunnel) and return at the same level which they left. This second one got me around the sticky tunnel problem on an unreleased map. Like you I couldn't get the player to just walk into a horizontal trigger_push and have it work properly. I�ve no experience with using trigger puch in Q1 but know a bit about the Q2 version - which act alot differently, because of the physics code.
but: why not use a clip brush - angled so that the player is bounced / slides in the direction of the horizontal, which then throws them along the tunnel to where you want. I don�t know if this will work - the old proverb "experiment" probably rings true. You�ll probably have to mess with the push speed and the angle of the invisible brush for a while. mind you - you could combine clip brushes with multiple low speed trigger_push�s to give the illusion of the player not walking along the horizontal wind tunnel; just a thought. I�ve no experience with using trigger push in Q1 but know a bit about the Q2/3 version - which act alot differently, because of the physics code(s).
but: why not use a clip brush - angled so that the player is bounced / slides in the direction of the horizontal, which then throws them along the tunnel to where you want. I don�t know if this will work - the old proverb "experiment" probably rings true. You�ll probably have to mess with the push speed and the angle of the invisible brush for a while. mind you - you could combine clip brushes with multiple low speed trigger_push�s to give the illusion of the player not walking along the horizontal wind tunnel; just a thought. Well, I tried both what you suggested, but I still continue to get "glued" ingame in this part, even if I removed the second wind tunnel (the one that works perfectly...) I guess there's somethig else there... I have to investigate what is the issue...
BTW, could it be the massive HOM I mentionned previously (still not fixed) that impact trigger_push functionality? t's really weird.... Anyway, I have in mind a turnaround, but the player will have to walk a little bit more in this cramped pipes part.. sorry.. ;) Thanks for your help guys ! hom and push issues shouldn't be related. the hom might be caused by misaligned brushes - check if all brushes in the concerning area are properly snapped to the grid.
as for the push, you could upload that part of the map, so we can take a look at it. otherwise i have no idea, strange thing... I solved the HOM issue yesterday evening, but it didn't solve the trigger_push issue, as it was expected. So I decided to change the way to progress in the pipes: no trigger_push anymore, just some "sas" doors to open in order to progress... with some surprise behind each one... >D
Thanks a lot for all advices ;) Is there a simple utility to convert wav files to avoid the "sound is not looped" or "is a stereo sample"?
I�d like to know this too. I�ve experimented with basic old windows sound recorder, which generally works.
I don�t know much (next to nothing) about sound editing but if you go into properties and the option that�s probably called "convert now" (I�m using spanish XP and don�t know the translations that well) you can change the Kilohertz to something that quake recognises - but like I say there seem to be some sounds that it will never recognise, and when it tries to use them quake crashes or doesn�t play em - just the standard dud sound message. I can�t remember exactly what I was converting em to, maybe 16bit stereo? (which was wierd cos it was a higher quality than the recording had been before). Does anyone know the specific system used? See part 4 of the link below... It sounds the sound is 8-bit stereo... Maybe there exist audio tools that can convert sound to 8-bit
http://www.gamers.org/dEngine/quake/spec/quake-spec22.html I hope it helped.. on my way out so can�t check yet, but; windows sound recorder everyone has already - why I asked for the specific sound bit / type that quake requires, cos there�s more options for conversion in there that I haven�t used yet.
anyhoo, probly I�ll check those programs also. 11khz, 16bit mono, but you can also use 8bit.
and soundrecorder more than suffices for doing conversions. however, if you're converting down from 44khz or 22khz, it might not always sound good with soundrecorded, and a better sound software might be needed to play around with the sound to make it better in 11khz. i got the alloc_hunc error again.
Thought it had something to do with too much textures in the wad file, but i forgot. So I lowered the texture rate, but still got the same error. Forgot the map ,and later played it with ordinairy quake batch -winmem 32 as proof and it played fine. 1616 polyhedrons 279 entities. I have an serious problem with "packet overflow" warnings. I have run fullvis on my map and unfortunatelly there are some places where I get this warnings on higher skills. I have some questions:
1. Is this warning computer speed dependant? 2. Is it possible that it appears only in gl engine? (it appears in fitzquake but not in software joequake). 3. Since I can't reduce the visibillity in this part of the level I have to reduce the number of entities. What are the best things to remove? (torches, flames, monsters, anything else). I guess removing the GL would be most effective, but I won't do this :) 4. There is an big amount of lights (torches and flames) in that open area, can their sound cause problems with packet overflow? Is there a possibility to remove the sound from a light_flame? I would test it all out by myself, but full vis takes too much time (25h) on my old comp. :( I was using aguirRe's winquake during development, but it doesn't give any errors about packet overflow (even if it would I would ignore this since the level wasn't fully vised). I think now that it is better to always test the map with standard engines and use the enhanced versions only in case of crashes or problem hunting.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |