you need to copy and paste line 527 so we can see what's wrong with it. 

that is to say, in the .map file. 

can't whenever i try to buld it cancels the build with the error. 

you need to open the .map file in a text editor that displays line numbers (such as TextPad) and find line 527. 

you can open the .map file in a text editor (eg. notepad); i believe this is what necros and willem are referring to. you will see blocks of text that look a little something like:

{
( -2608 -520 640 ) ( -2608 -520 704 ) ( -2608 -608 704 ) wizmet1_2 0 0 0 1.000000 1.000000
(some more lines like the above)
}

each chunk between the squiggly brackets is a brush and each line is a face. so whatever is on line 527 will be the problematic face 

..which is basically what kinn said. crosspost :| 

have been super helpful for me in the past. 

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.