with some obscure func_illusionary/info_notnull model technique, whereby the acutal weapon (if it is supposed to be picked up) would be placed in a hole underneath it, with an illusionary + clip, or maybe a skip wall, only deep enough that its bbox stays some units above floor level. the weapon then has to killtarget the fake model when upon pickup.
might not work with a func_wall, for the item would likely drop out of the map. maybe a fast skip door pushing it up and thereby also making the floor solid would work better in this case.
of course this could also be done by having the weapon being pushed into the player from a hidden closet the wall, or let it drop from the ceiling (model-item dropping does not work with darkplaces, though), but these solutions would be even more visible to the player... 

I not sure I understand, Neg!ke. Perhaps if you made me a sample map with some examples...or even a "complete" SP map with a few examples...or how about a 8-map Q1 Episode full of examples, then it would be clearer :) 

Ok, I've just been looking through the source and readmes on Aguire's site, and have found a list of Quake engine limits. However, I am not sure which of these are increased, and which aren't. I have a fairly good idea, but could someone be so kind as to correct me:

// Data-restrained limits
#define MAX_BSP_MODELS 256
#define MAX_BSP_PLANES 32767
#define MAX_BSP_NODES 32767
#define MAX_BSP_CLIPNODES 32767
#define MAX_BSP_LEAFS 32767 (8192)
#define MAX_BSP_VERTS 65535
#define MAX_BSP_FACES 65535 (32767)
#define MAX_BSP_MARKSURFACES 65535 (32767)
#define MAX_BSP_TEXINFO 32767

The bracketed parts are the limits of standard engines as far as I can tell. Perhaps some of the other limits have been increased. Aguire, please correct this list if it wrong ;)

Currently I got this output from my last compile:

---- WriteBSPFile ----
11217 planes 224340
36426 vertexes 437112
16427 nodes 394248
3923 texinfo 156920
29246 faces 584920
31759 clipnodes 254072
7357 leafs 205996
35086 marksurfaces 70172
130679 surfedges 522716
66440 edges 265760
87 textures 1258432
lightdata 0
visdata 0
entdata 152870

Tyrann's skip tool is taking out a couple of hundred faces, but that's not enough considering what I am going to be adding.

I still want to make the map run in Fitzquake, winquake and glquake (currently it works in all three, no problem), but I have a couple more important areas to add, so perhaps it is impossible.

I am not too worried about clipnodes, because I haven't really done the clipping yet, so a lot can be saved there.

What the hell is going on with marksurfs though? The map is working fine, despite exceeding the marksurfs limit.

The numbers on the right hand side are the size of the data, right?

Metl: Any chance of a version of Fitzquake with increased surface and clipnode limits? I've don't even care if it doesn't support the new protocol, so long as it loads my map ;) Thankfully, the map still looks decent in bjpquake. 

Lucky, as soon as I go over the marksurfaces limit on my map, it crashes fitzquake. Fortunatly I've been able to lower them quite a bit thanks to aguirre. 

got any marksurf lowering tips? wtf are marksurfs anyway? Just surfaces? What are faces then? same? 

generic: i forgot illusionaries can't be killed, so the model thing has to be done with the info_notnull/modelindex trick. i would have sent you a sample map already, but i have no idea how to get the modelindex to work. so if anyone was so kind to tell me how to find out the right number, i'd be glad (what's the command in aguirre's engine? how do i find the number in darkplaces if counting the modellist doesn't help?). bleh.

jpl:
about your trigger_push problem. :)
could it be that the malfunctioning trigger had angle "0"? with "360" it would have worked.
i could have thought of that possibility earlier... 

I also have problems with marksurfaces and have all but given up on my current map because of it.

And they're only showing 33k and it crashes Fitzquake 0.80 - clipnodes are still under 30k.

And I haven't added all the intended trims yet.

And I haven't finished the final battle area.

And I have already split the map in two.

Jeez... 300+ monsters waiting to die! 

I still don't quite understand what they are, and the tips aguirre gave me were really specific to my map, so probably wouldn't help you.
Best bet is probably to try pestering aguirre about it, he's wonderful for map fixing. =) 

Well, I don't know. I just finished the final build of the map concerned by this issue (it's ready for release, I will post it friday evening).. I changed the wind tunnel into a "walking" tunnel... sorry for this...
Anyway, thanks for the tips: I will try to make a test and see if it helps. 

Well, it's pretty weird effectively. In "Castle of the Dark Ages" map, I had 35k marksurface / 31k clipnodes (if I remember well) and the map didn't crash at all... It sounds to depend also of your PC performances as well... though...

The last possibility you have (if you don't want to change too much your map), is at least to add a note (in txt file) to player stating that only aguirRe's GLQuake will support your map.

Good luck. 

generic: ok, i suck. i had the numbers right already, but it didn't work because of the think/nextthink fields preach used.
unfortunately, it didn't work out (or at least i couldn't get it to work properly): either there is a model that can't be removed, or a model that still rotates. check the useless test maps here: http://negative.net.tc/files/wtest.rar
so i have to give up on this :/

mike: stupid idea maybe, but what about creating new textures - walls that already have trims, details etc. - to reduce brushes and therefore possibly marksurfaces (dunno if they are even related) 

than: The various Q1 limits are today a pretty complex issue. In general, you have various tools and engines, file and protocol formats and even bugs that all cooperate to make things difficult. Also, the network protocol isn't just for "networking"; it's always in use since the engine is built with a client-server design. Even demos are completely protocol bound, as they are in fact just recorded server network messages.

I'll just try to comment on your qbsp printout. The only limits you're close to or exceeding are the clipnodes/marksurfs, both must be <32k for normal engines. Clipnodes I've commented in my ToolTips, but marksurfs are more difficult. Search this thread for numerous comments. And yes, the rightmost qbsp printout numbers are lump sizes in bytes (not very useful for most people).

neg!ke: The standard engine command for model printout is "mcache". I'm not sure it'll give you what you're after, though. 

You do suck on so many levels :p but I will download your crappy test map anyways (because I tend to download anything you do :) ) and continue to turn in my speedmaps late ;)

Thanks for all the effort anyways but I have already come up with a separate solution. I never really needed the items to "work" -- I just needed them to sit still and look pretty :p 

the elusive marksurfs limit, it doesn't depend on computer speed or anything similar. When the limit is exceeded in an engine that hasn't fixed the 32k bug, engine internal memory is trashed.

As with all memory trashing scenarios, it may or may not affect functionality depending on how the memory is used at that time or later. Since IIRC this particular memory is on the Quake heap, it may help to change heapsize. 

As I understand it, marksurfaces are just polygons. So basically every visible brush face in your map is one or more marksurfaces. It becomes more that one marksurface if:

- It is bigger than 240 pixels in x or y texture directions
- It is intersected by another brush/surface
- A t-junction lies on one of it's edges

Two ways you can reduce the number of marksurfaces are to do with textures. You can combine them as suggested by neg!ke (i.e. reducing the number of brush faces in the first place). Or secondly, you can scale up textures in places if appropriate, to reduce the amount of surface subdivision taking place. 

JPL: I use Fitzquake080 as standard, which is great for everything except synconisation of flames and use of music files direct from the HD. I am not sure that aguirRe's engine is used by enough people.

neg!ke: I try not to use trims combined in textures because we get the "painted on trims" rant from Shambler everytime! And I've probably said that too loud, Shhhh, he'll wake up.

Tyrann: I just did a test on the smaller of the two maps -

First, an oft used texture (ground1, which is normally 128 x 128) at 64 x 64:-
11016 planes 220320
31312 vertexes 375744
12616 nodes 302784
2670 texinfo 106800
24475 faces 489500
26354 clipnodes 210832
6924 leafs 193872
30786 marksurfaces 61572
113476 surfedges 453904
57059 edges 228236
133 textures 1915296
lightdata 0
visdata 0
entdata 72453

and then the same texture increased to 256 x 256:-
11016 planes 220320
31312 vertexes 375744
12616 nodes 302784
2670 texinfo 106800
24475 faces 489500
26354 clipnodes 210832
6924 leafs 193872
30786 marksurfaces 61572
113476 surfedges 453904
57059 edges 228236
133 textures 1996896
lightdata 0
visdata 0
entdata 72453

Only the texture lump changed: marksurfaces stay the same.

Still, just looking through the map again has roused my interest. I might chop out one of the side-rooms and at least try to release something playable. 

No, that won't make a difference. What I was trying to say is that you could set the texture scale in the editor higher than 1 (i.e. stretch the textures). 

I stretched a rock texture to 2 x 2. I am not sure which texture I got rid of (by accident) but it still doesn't help marksurfaces although some of the figures have changed:-

11016 planes 220320
31285 vertexes 375420
12751 nodes 306024
2665 texinfo 106600
24640 faces 492800
26185 clipnodes 209480
7001 leafs 196028
30882 marksurfaces 61764
113902 surfedges 455608
57276 edges 229104
132 textures 1926132
lightdata 0
visdata 0
entdata 72453

Mind you, I think the rocks look better now! 

I don't really see how that could cause a marksurface increase like that, but it may not result in a reduction if the polygons aren't that large to start with. I agree that rocks/grass do tend to look better with a higher scale when there's a lot of it - I'm currently using a 1.5 scale on mine. 

If anyone is using this plugin to manage Q1 PAK files, you might be interested in some improvements I've been working on lately.

I'm currently not considering a public release, so if you're interested, just email me. 

http://www.celephais.net/board/view_thread.php?id=4&start=1736&end=1737

P.S. Yes, this means I finally coded a way to specify a range of posts. Thread paging is a little bit closer. 

About texture scale in relation to marksurfaces is very useful, upping the scale of sky textures, and trigger texture (I have lots of very large trigger_hurt brushes in my map) can lower the marksurface count considerably.

I still fail to understand why these limits still exist, but that's probably just because I'm stupid.

Oh, and metl, I luv you. 

Had a bash at this, think I've got a good fix, at the least there are some interesting ideas that result from it. It's not possible to make the actual nailgun model stop rotating without modifying the model file, the rotate flag can't even be overridden in QC. So what this map does is creates a bsp model that approximates the nailgun, and has that in the map. You'll want ogro's texture wad if you want to see it in all it's glory.

http://www.btinternet.com/~chapterhonour/weptest.map

Ok, so I'll explain what all the entities do. The func_wall in the second room is just there to make the compiler compile the brush entity we need, so that it has modelindex 2. After the map is compiled you could safely remove this entity with adquedit or something. One thing to notice is that it's been very carefully placed near the origin. This is so its easy to place in the map with the next entity.

The next entity is the one that makes it visible but non solid, the point entity info_notnull. This uses the SUB_regen hack to load a model by it's modelindex. The modelindex is set to 2, so it loads the nailgun model we just made. The model and mdl fields are necessary dummy fields, as long as they have some model in then it works. Why didn't we just use a func_illusionary? Because this way, the entity isn't static, so we can killtarget it. The standard trigger_once kills it when we touch it.

At the same time the player touches the trigger_once, they will also touch the brush info_notnull. This uses the good old trigger hack, so we can make a brush trigger with an arbitary touch function(look at the think and nextthink to see how it works). This time we set the touch function to BackpackTouch, and then the rest of the fields are set to match a backpack that only contains a nailgun(items 4, netname nailgun, ammo_nails 30).

The BackpackTouch function can be used as a trigger in more general situations. You could give it a netname of "weapons" and then set the items field to some sum of weaponflags to give all those items at once. Be warned though, if the player already has any of those weapons the message will skip straight to the ammo summary. A good way perhaps of giving the player weapons on startup would be to use this trigger with no ammo, and netname "\n\n\n\n"(enough backslashes to push the "you got" message offscreen).

You can also set any of the other itemflags, but most of them won't do anything. The powerups flags will tint the screen, but won't actually give the player anything. Similarly the armour flags will only make a cosmetic change. The keys, however, do work as you expect, so you can give those out by trigger. Potentially you could try removing items this way as well, but I haven't got it to work...Anyway, have fun with that. 

 

there are so many holes in quakec, you wouldn't even be able to contain molasses in it! :o

good job on figuring that out, dude!