Mike
#12188 posted by necros on 2012/10/27 22:30:54
Yes, for the most part. If those lines were not commented, it would stop shooting when you were out of sight.
Also, the vermis' 'eyes' are actually at '0 0 25' relative to the monster's origin (about where that bulb is near the middle of it).
also, it uses visible() in it's run function to determine is enemy_vis is set but then enemy_vis is never actually used.
Looking back, I was a pretty shitty coder back in the quoth days. :(
Ehhhhhh Blow Me :P
#12189 posted by Fern on 2012/10/28 00:29:22
No seriously I was going to do that anyway...
(even though this is AFTER snapping all brushes to the grid)
Yo Fern
#12190 posted by Preach on 2012/10/28 00:36:14
Hook a fella up with your unlit and lit .bsp, not just for rubbernecking, I'll see if I can help, honest!
Yo Preach
#12191 posted by Fern on 2012/10/28 06:49:33
No can do. Made a few modifications and utterly destroyed it. I *could* theoretically go to the most recent backup but I don't much feel like reconstructing so much work just to recreate the error it inevitably led to.
For your amusement though, here's what it looks like now. Amusingly enough, the number of errors actually GROWS when I remove brushes. wouldn't you expect the other way around?
http://www.suspenlute.com/stuff/raep.jpg
Hmm
#12192 posted by Preach on 2012/10/28 08:19:55
That looks a bit like what happens when you have 0-volume brushes and they end up stretched to infinity. There's an error checking command in worldcraft/hammer which will find brushes like that. Have you tried using an alternate compiler and see if you get better results from it?
Ferndur
#12193 posted by negke on 2012/10/28 09:33:08
I just don't understand why or how Light should cause an error like that, because it only generates the lightmaps data and adds it to the bsp, but it doesn't affect any entities or clipping hulls. Normally, anyway. I take it this is BJP's light tool with no additional compile flags?
Yeah....
#12194 posted by Fern on 2012/10/28 14:48:10
that pointfile is also going through a solid wall btw.
negke: for what it's worth it was with -extra -light 37 but that shouldn't make a difference
preach: I tried LordHavoc's kit and got even worse results than before
everybody: this map had over 300 warnings when I finally gave up. I'm just going back and trying to get it under 50 or so and then seeing what happens so trying to help with this problem is now superfluous, thanks though.
Fern
#12195 posted by JPL on 2012/10/28 15:42:29
If the pointfile is going trough a solid wall, it means that you have a misaligned poly somewhere around... and certainly by something like a 0.000001 delta: those are the most critical to resolve unfortunately... as almost invisible in the editor (you may have to check all poly coordinate to find it.... QuArK behavior) :(
OTOH, what you can do is to try with aguirRe TxQBSP.exe and add "epsilon -0.01" option, and check what it looks like ingame (without running vis and light)? The -epsilon option change a little bit the way collision detection and poly expansion processing
is performed AFAIK, and sometimes it gives interesting results.. The default epsilon value is 0.05, (like standard BSP compiler), and reducing the value increases the precision, hence helps to detect HOM and misaligned polys..
Let us know whether it helps ;)
Bob-Toolz
#12196 posted by wakey on 2012/10/28 17:49:19
Maybe Radiants Bob-Toolz Brush Cleanup could help too.
JPL
#12197 posted by Fern on 2012/10/28 20:14:54
-epsilon 0.01 is default
Fern
#12198 posted by JPL on 2012/10/28 21:01:07
Try both bigger and smaller value...
Quotes from txQBSP readme...
.....
TxQBSP 1.11 (Feb 16 2005)
1. Improved handling of complex maps such as terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.
All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".
The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.....
hence my mistake on epsilon default value...
Note I solved some issue in my previous huge maps using this epsilon option (i.e in Gateway to Hell, I had a hard time to fix a leakage onto a stair step, that was misaligned by 0.000001)...
Experiment ;)
Well...
#12199 posted by Fern on 2012/10/30 05:57:22
JPL: low epsilon values seem to help with various issues, but light still moves the monsters around.
Preach: I did find a lit/unlit version for your perusal so you've got mail
.....
#12200 posted by Fern on 2012/10/30 11:33:59
txqbsp with epsilon 0.00001 and hmap2 - light makes everything work again. Maybe I can still be lazy with this after all :P
Fern
#12201 posted by JPL on 2012/10/30 17:00:52
May I suggest you contact directly aguirRe in order to get direct feedback from him ? I guess he could be of a real help to understand what is exactly the issue, even though he is not involved as he was some years ago. I am pretty sure he would not be reluctant to help you... give it a try and let us know ;)
Quoth Monsterjump
#12202 posted by mechtech on 2012/11/04 14:32:08
Is there an easy way to make trigger_monsterjump trigger once?
No
#12203 posted by negke on 2012/11/04 14:39:55
But you can killtarget it after use, maybe even by the monster itself. (*)
(*) Not sure if Quoth fixes this, but normally, unlike other entities, monsters can't just have a killtarget, they also need a dummy target for the former to work. In this case, both could point to the trigger_monsterjump.
Triggers
#12204 posted by mechtech on 2012/11/04 18:47:40
I used a trigger_once killtarget
trigger_hurt, trigger_monsterjump and trigger_push could use more control. Quoth has better control for trigger_hurt. Be cool if they had playeronly/monsteronly, target and count.
Monsterjump
#12205 posted by ijed on 2012/11/04 19:41:02
Has a lot of potential - ONLY_MELEE for example.
Count is a good idea, and I always liked the Drole Rage thing as well.
Oh,
#12206 posted by ijed on 2012/11/04 19:42:32
And just being able to toggle monsterjumps on and off would be cool.
Taking the melee only thingone step further this would allow for climbing fiends.
Just sayin :)
Texture
#12207 posted by Fern on 2012/11/05 00:03:21
I could have sworn I saw an animated texture of burning coals but I can't remember what map or .wad it was in and cba to check every one right now. Anybody know off the top of their head what I'm talking about?
#12208 posted by necros on 2012/11/05 00:05:24
you're not talking about the doom texture with the kind of veiny glowing hardened lava?
That's What I'm Using Right Now...
#12209 posted by Fern on 2012/11/05 00:21:29
but I don't think so
Make One?
#12210 posted by ijed on 2012/11/05 01:13:58
It�s pretty easy to get the colours right with photoshop and the curves set that Kinn did, not sure where to find that though.
Wasn�t there a glowing coals tex in one of Tronyn�s older projects?
Rapture
#12211 posted by ijed on 2012/11/05 01:21:39
It was called. Not sure about the texture though. Just remember that the last level was a no monsters credits thing with some rocks in glowing lava for the player to clamber around on.
Might have to play that one again...
Here�s the link to the curves as well, courtesy of Quaddicted: http://www.quaddicted.com/files/tools/photoshop%20curves.rar
Ahhhhhhh
#12212 posted by Fern on 2012/11/05 03:14:34
thank you
|