The txt editor I use is notepad++

http://notepad-plus-plus.org/

Better, worse? I'm pretty happy with it. 

glitchunter - those strings of numbers are the coordinates of the brush in your map, XYZ.

Once you know where it is open up the editor, find it and delete it.

Salvaging the brush, or deleting directly in the .map file can lead to headaches until you've got a solid grip on how everything works. 

Is there a fixed limit to the number of frames a sprite can have? Or, can I use all of the frames to draflam2.spr if I introduce some kind of time control into the frame sequence in the .qc? (I am not clear why 20fps)

I haven't tried anything yet, I have just seen the sprite working in Fimg.exe. 

I'd assume that the main limit you'll hit is the quake networking protocol. You set sprite frames in the same way as you set .mdl frames, and unmodified engines can't set frames higher than 255.

I think the 20fps is just the speed that the explosion animation looks realistic at - if you played it at the quake standard of 10fps it would look like a slow motion replay. It's not hard to do in QC but you do have to set the nextthink time manually rather than using the shorthand animation notation. 

255 is actually quite a high limit considering the average length of a sprite used in quake. Technically this means you could optimise by combining all the sprites in a mod into a single sprite with no performance hits. Mods or maps which are only a couple of precaches over the stock limit might find that valuable. On the other hand, this would save you a scant 2 model slots in id1 quake, so the mod does have to be in that sweet spot...

cf. www.alistapart.com/articles/sprites 

that url was just one character too long

http://www.alistapart.com/articles/sprites 

http://www.mediafire.com/?bbnrhzd2lphvrty 

Line: 527
( 2277 85.56250 -6.50000 ) ( 2277 85.56250 163.50000 ) ( 2277 -67.18750 -6.50000 ) blue p 72 -5 0 -1.19336 1.32813

excess symbol "p" after texture name (blue). after removal of the character I have opened normal 

interesting... texmex will actually let you rename a texture with a space in it and qe3 doesn't complain about both loading, applying or saving...so looks like both quark and qe3 do that.

any others? 

Played around and got a good result. The longer it goes on, the worse it looked so every other frame was the best compromise. 

ok, well long story short - I've 3-4ish years worth of doom3 mapping rotting on my harddrive which will never be finished or released. It was kinda built in a Quakeish way/scale, so.....

Doom 3 stores the brush info in a totally different way to quake. Does anyone know of an easy-ish way to get the brushes from the doom3 .map into a quake .map?

Obviously the only valid things are the basic brushes. I don't care about texture info either. 

well, you can export d3 brushes as .obj and iirc, you use maya, so maybe you can import the obj file and then you will have some more options? 

sounds messy as i'd then be looking at a mesh -> brush converter.

i'll probably just have to write my own converter that reads a d3 .map and processes the brushes into quake format. Was hoping someone might have already done this but it looks like no-one has. 

see if you can get in contact with Lunaran, he's written all sorts of .map format converters in his day, he may have a python script laying around that does it 

tbh though, now that i think about it, by the time I've nerfed all the detail, filled in the bits that used to be covered by patches/models, and retextured everything, I may as well have just built the blimmin thing from scratch anyway... 

Is this 'fixable'?

I have it in an earlier FMB map where I use a trigger_once to killtarget a trigger_push. I know that FQ intercepts the bug and there is no crash, but not everyone uses FQ. 

I mean is it fixable via the editor in some way - I need both triggers, even though the trigger_once is only there to accommodate speedrunning shortcut merchants; 'normal' players won't experience any problem anyway. 

The engine problem is removing an entity during a touch function - this is illegal but in fact quite hard to always prevent. We can make a special bit of code for this case though. Instead of directly removing the entity in the killtarget code:

1. Set the targetted trigger .touch function to SUB_Null so that it can't be touched any more. This renders it effectively inert without breaking the link list.
2. Set .think = SUB_Remove and .nextthink = 0.1 to tidy it up later. This way we'll be safely in a think function when the removal occurs.

The trick is to detect when we can remove directly and when we need this trick. The safest thing is just to special case it - make a new special kind of entity which performs this "slower, safer" removal on killtargets, and just use it here when needed. 

Fitz displaying a sv_touchlinks warning every now and then doesn't automatically mean the game will crash with other engines.

Preach: If SUB_Null is supposed to disable the touch function, why does it work so flawlessly in all my hack triggers? What is it I fail to understand about the functions here? 

SUB_Null is just an empty function. setting .touch to SUB_Null just makes the touch function do nothing at all (as opposed to not having a touch function, if you want to make the distinction). 

I phrased that badly, but in my defense when I wrote that half of the sentence I was going to set .solid to SOLID_NOT. I then worried that this might stomp on some other part of the engine's collision code by leaving the entity in the wrong linked-list, so I decided that replacing the touch function would be safer.

Word of caution: This method might fail when dealing with a shootable trigger. In theory you could shoot it in that window between the touch being removed and the think executing. This might then stomp over the think to be executed with the trigger_reset function instead. In this case you'd also need to reset .damagetype and/or .th_die when you prep for removal.

Don't even get started on how hard it would be to remove a monster like this - things like the monster getting woken up in the split second before it gets removed would be enough to spoil things. This would of course be a very obscure bug because of the small window of manifestation, but it would be hellish to diagnose. 

I followed Scampie's tut for pipes but stranded at this region.
I'm using GtkRadiant 1.5.0 and as long as I try to submerge the horizontal phase everything turns right with ctrl-U.
If I try the turned region the merge doesn't work.

http://members.home.nl/gimli/curves.jpg

What do I do wrong. or is it my window32 and no64? 

If it's touch that causes the problem, why not just use a trigger_relay to kill the trigger_push?

I've done it that way before without problems, not sure if I had a delay in it or not though. 

Yes, a trigger_relay with 0.5 delay worked. Thanks all. 

I updated the qbsp and light sections of the quaddicted map compilers page. http://www.quaddicted.com/tools/map_compilers