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. 

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)?