 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. 1. It's not generally computer speed dependant, but I guess some variations could occur.
2. No, it's only engine protocol packet size dependant, std size is 8000 bytes. Fitz and Joe should have the same problems as both use the std size AFAIK. I don't know why you're seeing a difference. 3. Usually the problem is too many [active] entities in view. If you can't reduce visibility, you'll have to reduce entities. I don't know if there's a difference in various entities as such, but some entities spawn other entities (edicts, e.g. HK missiles), which makes removing them more effective. 4. I don't know if torches add up to the packet limit as they're static entities. In any case, you can modify the entity section and just do qbsp -onlyents without redoing vis each time you test. Btw, are you using std progs or a custom one? Using a custom progs could be the cause of packet overflow (e.g. ejecting many shell cases). OTOH, using a custom progs can also help you to reduce edicts by removing corpses, delaying spawns etc. Let me know if you need help investigating this issue. At the moment I don't have the time to check out your suggestions. But thanks a lot.
Some additional info: I don't use any special progs.dat. In software joequake there is no overflow, in joequake-gl the problem starts to appear and in fitzquake the problems are getting bigger. If I kill all the monsters with genocide (it is an impulse command) then there is no packet overflow in any place. There are many gibs in this map because GL is the main weapon. Maybe using a progs.dat with corpse removal would solve the problem, but I don't like this idea. Is packet overflow in two places in a level a realy bad thing? I remember that I was getting some warnings when compiling with -onlyents after some entities were removed/added, but I will check it out. IMHO, having "massive" packet overflow warnings in some places in a map dicrease its quality. AguirRe helped me for CDA: there was a lot of packet overflow warnings at the very first release, and using a spawn64-like progs.dat helped to limit the number of entities the engine have to manage, and then help to avoid packet overflow... Believe me, it works fine, and furthermore you could add more monsters in the map... ;)
you could of course have each monster in the concerning area fire trigger_relays that in turn killtarget the monsters. this way, at least their heads would be removed which might possibly reduce the packet overview a little (however, it would also remove their corpses if they are not gibbed, which probably looks weird. maybe delay values could help).
dunno if this would make much sense, just an idea...
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |