:) 

care to share? 

:) 

Now, this is how I got it to work, there is most likely a better way to do parts of it, especially selecting the group after it has been made, but at this time I do not know it.

First you got to copy the "funk_group" section from your Quake3 "entities.def" file which gets installed with GTK, just paste that into your quake.def file. (This, as I mentioned above, is what I thought I had read.) Then when you are in GTK, you just select the brushes you wish to group together, then either right click and select funk/func_group, or, hit the N key and bring up the entities dodad, select func_group from the list, double click it.

Then to select it, hit the L key to bring up the entities list, expand func_group, select it, click select, and it will be selected for you to work with. (If you have multiple func_groups, you could give each a name or something to identify them, I just put "name" in the key feild and then call it whatever the "value" feild, Then you can identify them individually in the entities list (L key) window). I do not know why I can not just select the group by selecting 1 brush, but I do not seem to be able to do it that way

When you want to change it back you just select one of the brushes in the group/or the group itself, right click, select "ungroup entity" and the brushes will be changed back to worldspawn. Or you could use the java version of sleepwalkers map converter and do it as mentioned above. I use the old non java mapcon which does not have the -groups switch.

It is a lot quicker than it sounds, and besides that, it is the only way that I know, so until I find a better way, it will do for me. 

Thanks, much appreciated. 

is there any way to get faster compile with tyrlite ? takes way too long already (no -extra and only ~50% of the light are there)
I`m on slow pc ;/ 

Besides getting a faster PC and or having less lights or faces in your map I don't think there's a way... ;)

Well, if it takes that long you can always ask someone in #tf to compile it for you I guess, there are some people with quite fast machines, aren't there? 

ok, i need some dudes to beta test nesp09...

you`ll need a custom engine on this one, any one that has the edict limit bumped will do (PanQuake, TomazQuake). The engines that I know that don`t have bumped edicts are: FitzQuake and MHglquake.

i suggest the use of Panquake -- practically identical to the original glquake (just make sure pan is disabled).

if you need any help getting these, just ask.

so if your interested, email me:
necros -at- planetquake -dot- com

nb: serious people only please... 

Does anyone know why the upper part (there are two parts) of a Q1 custents func_spawn entity is visible before it is triggered ? It is then non-solid but otherwise works as expected when triggered (i.e. becomes fully visible and solid). 

it`s because the model is getting set, but the falltofloor part hasn`t been executed at this time.

not sure though, i`d have to check, but i know what you mean.

incidentally, is there any particular reason why sometimes when a post gets eaten, you can go back and it`s still there? (like now) but other times, the post is no longer in the box? 

incidentally, is there any particular reason why sometimes when a post gets eaten, you can go back and it`s still there? (like now) but other times, the post is no longer in the box?

We Fremen have a saying: metl created Func_Msgboard to test the faithful. One cannot go against the word of metl. 

Tell me of your home world asshole. 

lol. 

We Fremen have a saying: metl created Func_Msgboard to test the faithful. One cannot go against the word of metl.

Right Kell, but also have to remmeber the prophecy:
One will come, the voice from the coders world, bringing the holy bugfix, an addslashes() function, which will cleanse the bugginess and bring us out of darkness. 

...but YOU also have to REMEMBER the prophecy...

Ahhh, they're all over! Someone make the typos go away! Release me from this pain! 

Thanks for trying to help, although I still cannot figure out what is going on. I tried to follow your droptofloor (which I assumed you meant) lead, but there are too many things happening in the qc code for me to get the actual sequence of events.

What I do not get is why this particular two-part model does not work when a one part model like the soldier works fine. It is probably some error in the original qc code that has never been looked into and I am too inexperienced to locate the cause.

If you (or anyone else) figure out the cause of (and hopefully the cure for) this error, I would appreciate the information. 

what are you talking about? :)

i`m not sure what you mean by `two part model`. what makes a soldier.mdl a `one-part` model? 

 

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.