a quick way around which requires more work on the mapper`s part is simply to place the spawning entity at the proper height above the ground. the spawn function simply uses the func_spawn`s origin as the spawned ent`s origin, therefore, if you set the proper height, the entity won`t be dropped to the floor at first, but it will appear to be, which is just as good. 

consists of two parts; the upper body and the lower body, each in a separate mdl (servobod and servoleg) file. There is also a separate model for the dead entity (servodie) and finally a head model (h_servo) when gibbed (I am not sure if that is actually possible since the entity is a robot).

Before the func_spawn is triggered, the upper body is visible but non-solid and when triggered, the lower body also gets visible and then it is active and solid.

When dead, the two parts are separated and fall to the ground as expected and gets non-solid again.

I have tried moving the func_spawn entity up and down but it does not seem to help. Another func_spawn just next to this one spawns a soldier and that works exactly as expected. 

it seems to be more a problem in the servo thing`s code... probably the self.nextthink is set too long, maybe one second, so that could be why it`s taking a little while for the top part to get rearranged with the bottom part. i`d look there, if i were you, around the spawning function of the entity. (not the func_spawn) 

to follow your tip, but there is just too much code that I do not understand yet. I will leave it for now, thanks anyway.

Btw, did you get any help on *your* qc problem, the "Precache: overflow" issue ? I remember seing something similar on the old QMap. I might be able to track down some of that info if you want me to. 

' 

well, at the moment, i'm told it has to do with going over the MAX_MODELS limit (of 256) or apparently higher on the engine i'm testing this out on...

but for the life of me, I can't really see what could have caused that error to crop up... there were already over 300~ models including func_, item_, monster_, and i only added a few things in between builds of the map...
unless the previous build was just skating on the edge, and the few things I added pushed it over...

so any help would be greatly appreciated, of course. :) 

I already replied to necros via email before reading this here, but for anyone else who's interested...

You can only have a maximum of 256 _unique_ models in one map. The unique part is important because this allows you to have 20 grunts and they all share the same model, so this only counts as one towards the total.

Where you tend to use them up is with func_door, func_wall, trigger_once, etc. All of these entities (and any other "brush based" ones) will add one to the total count. 

I forgot to mention also that you can't just bump this limit in the source code and re-compile because you'll break the network code. It sends the model number over the net as a byte (8-bits => 2^8 = 256). 

I know that in the dem files and in the code, bsp models are usually * and a number, like "*8". If you had 2 doors with the same model, would they get messed up by eachother? 

the func_spawn stuff...

i dont know if this is what you`re experiencing, but i had an issue crop up when i was doing qc for pbrsp1, basically there was a split second after soemthing spawned in which it was visible but hadn`t gone into being able to take damage/its think state, etc etc. i think i solved it by just putting a line making its nextthink alot quicker. pretty simple actually. i also added code such that spawned entities would go after a path_corner when spawned, in case anyone`s interested... 

problem I have is *before* actual spawn time. The upper part of one two-part model is visible but non-solid. After spawn, everything is fine. I have tried looking into the nextthink/droptofloor/whatnot things but I cannot figure it out. 

the upper part is already there, before the spawn is triggered? (just not solid)? 

... 

maybe post the qc somewhere? would make this alot easier imo 

is available at http://www.planetquake.com/fatty , look in the downloads section. The problematic model is controlled by the srvomech.qc code. 

Can someone answer some q's about r_speeds

1. What is considered "acceptable" r_speeds ?
and wouldn't that be dependant on what system specs were being used? ie, wouldn't high r_speeds for someone on a lower spec machine, not be considered high for someone on a high spec machine, or have I missed the boat all together.

2.What does the info displayed onscreen from the r_speeds 1 command mean ?. Which (if not all) is the important one/ones to watch?

Also, in the Quake console commands file I have, and at "The Forge", it suggests that the following is what will be displayed when the r_speeds command is used

18.7 ms 422/263/127 poly 12 surf

but that is not what I get, I get the following

xx ms xxx wpoly xxx epoly 

xx ms is how many miliseconds it took to render that frame.
xxx wpoly is the number of polygons that is rendered from bmodels. (ie, the world, buttons, doors etc, and also ammo/health boxes) This is also the number that most people refer to when talking about r_speeds.
xxx epoly is the number of polygons that is rendered from .mdls. (ie, monsters, weapons, viewmodel, etc).

The xx ms xxx/xxx/xxx poly xx surf output is in software quake only.

As for what is acceptable r_speeds seems to be variable. In DM, some seem to get pissy if they are over 500. In SP, some think they should stay belov 700, others feel it's fine to go up to a 1000. I know I have sinned a lot on the r_speeds part myself, but what is done is done...
I generally think though that you can justify most r_speeds peaks if the visual gain is worth it. If you can make something excellent looking with 1100 wpoly, then let it be so. If you have made something that takes 1000 wpoly, but looks like crap, forget it. 

I know I have sinned a lot on the r_speeds part myself

[sarcastic comment missing]

If you can make something excellent looking with 1100 wpoly, then let it be so. If you have made something that takes 1000 wpoly, but looks like crap, forget it.

right on. r_speeds average and r_speeds high are different: if your SP map averages around 500 - 600 and peaks only briefly at 1400, that's just fine AFAIAC 

I have made a kinda big map and with a few more boxes Quake III Arena started hanging with "Waiting Snapshot...". I made my map in QuArK 6.3.0 and also put there some portals with "HINT" texture. When i go and check for holes it reports almost about every light. :(((( What should i do? 

if they are too high in a place where there is little or no combat, that is more acceptable than if you have too high r_speeds in a place with lots of combat, where the potential choppiness can hurt your player's ability to fight. 

With the faster machines we have now, doesn't that lessen the need to worry about r_speeds. I have a map which r_speeds (wpoly) "were" (I have adjusted it now) continually up around and above 2000, now, durung play I could not tell any difference between that area, and say, another area where the r_speeds were at a level that would be considered "acceptable" 600/700.
So,...I am just trying to get a grip on why you should worry about it, if it doesn't actually seem to have any effect, except maybe for those with lower spec machines.

I seem to remember a thread about this, but I think it was on QMap :( , I would have liked to have read that today, with my interest in mapping, and not purely as a player, like it was then.
Forgive me if my questions/reasoning is stupid, there's probably a good reason for that :) 

what about a map that averages around 1000 and peaks at 3000 in multiple areas? :o 

it'll probably run fine on recent machines. But very poorly on machines more than a couple years old. 

I put mine back to how it was, even if the r_speeds are not considered "acceptable", I can't see how not dropping below 150FPS at 1600x1200 could be considered unacceptable. Maybe on lower machines, but thats how it goes. I'm prolly the only one who'll ever see it anyway, so who cares.