for any of you experiencing a CM_inline model - bad number error on multiplayer levels, i've done a little experimenting and this is what i came up with:

from what i can ascertain, the error is caused by func_ brushes being flagged as "detail" as opposed to "structural". the detail and structural flagging can be changed by selecting the item, then going to the "selection" menu and selecting either the "make detail" or "make structural" options.

this includes func_group brushes! i didn't think so at first, but apprarently it does...if a group needs to be set as detail, go to selection - ungroup entity, then flag it as detail.

the solution: if you get this error for some reason, select the entire level, go the selection, then "make structural". it'll take longer to compile and your framerate will drop, but it'll work. when you've succefully compiled and run your level, go back and set some of the stuff to detail, but pay close attention that you don't flag any func_ brushes as detail

i hope this helps, that error was irritating me for a long time

I don't think that's entirely correct. Func_group are NOT REAL entities. They are converted into normal brushes during the compile process. I've turn many func_group brushes into detail brushes before and I've never received the error you're talking about.

-- SavageX

------------------
"Never trust a bartender with bad grammar." - one of the many one-liners of Kyle Katarn.

me too.

------------------
saberopus
Jawa_Oasis, Good ol' Nar Bar, Cartoon TC

I think the error only happens in MP.

Uh - I've never got that error and I've done at least 100 plus compiles ... or is this message during the game - I never get an error like this, though.

from what i've seen it doesn't turn up that often, others have experienced the problem though. that's just some information i've gathered on it, i thought you might be interested.

more importantly, the cure for it (making everything structural) doesn't always work...it works most of the time though. it might be something with improper entries on other entities, i'll have to keep trying stuff and see what happens. keep in mind none of this is fact yet, just what i've come across. if anyone has any input let me know

I went to RAVEN on this problem.
The actual problem here lies in the difference between the Quake MP and SP engines. The SP engine has a limit of 500 brush models (func_doors/func_plats etc) while the MP only has a 250 limit.
Therefore if you have lots of doors plats etc made out of multiple brushes, you will hit this limit pretty quickly. The only solution is to lower the number of brush models in your map.
If you are working SP maps you are unlikely to encounter this problem unless you make a really huge map.
MP on the other hand is a different story - I know at least 3 other people who've all had to abandon/redesign their MP maps cos of this limit.

Hope this helps you all.
In the meanwhile - I have just managed to get SAGA gameplay mode working in my map and after a few bug fixes and tweaks it will soon be available to the public, along with my Jedi Starfighter and Sith Infiltrator prefabs.
To check out the pix of the maps and prefabs goto
ftp://68.4.22.173/Monsoontide/JK2/

username: tide1
password: monsoon1

Monsoontide

To be more specific, the limits are 256 and 512 respectivly, and for MP, you could do some coding to get around it, I don't know why anyone hasn't yet.

Oh, that explains why I don't get the error. The only level I made so far is only for SP. I haven't embarked on MP level making yet. I'll keep that brush limit in mind.

BTW... speaking of limits, anyone ever hit the lighting grid limit before? I actually did a few compiles ago. If you ever get the error that you have too many lighting grid numbers, just make some of the brushes use vertex lighting instead of light mapping (This can be done by making func_group brushes use "q3map_vertexlightingonly 1"). This is best done on terrain type brushes. Terrain really doesn't need light mapping anyway as it's usually divided into triangles already. Vertex lighting and light mapping looks no different on terrain. Even if you don't get the error, just make those terrain type brushes use vertex lighting anyways because it decreases the BSP size!

-- SavageX

------------------
"Never trust a bartender with bad grammar." - one of the many one-liners of Kyle Katarn.

I should also point out that the limit does not (I think) affect things like misc_model and misc_model_breakable (which are so much better than misc_model in every way!), or things like NPCs. I know for sure there are SP levels with over 512 entities, so it must only include brush entities.

oh...well, i'm glad i brought this up then, it saved me a whole lot of tinkering and intentionally making mistakes to see what caused them. thank you very much for the help, i probably never would have figured that out myself.

With breakable objects, don't you have to put in a key to make the 'fragments' look like something meaningful? Aren't you limited to only a few kinds of fragments? I've looked at the code for it, though, wouldn't be hard to add another kind of fragment.

You don't HAVE to make it break. Just make it unbreakable and health of 0. They are much less buggier than misc_models. Besides, a lot of stuff should be destructable in your level anyways (I'm talking about SP here).

They also don't need physics clip on them. However, since you aren't clip brushing it, it won't cast a shadow. To fix this, make a rough outline of it with caulk_nonsolid, and it SHOULD have a shadow and still remain with a surface-to-surface hit detection.

does the limit apply to func_glass?

Probably.

Someone please tell us if you find a way around this for MP. I have already reached the limit cause I've been working on a huge level and it is not nearly finished. This really sucks for me because I can no longer progress on my level. Someone please help me!