 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
to stop a weapon/item from rotating (minus QC, of course)?
Thanks in advance, Neg!ke :) 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |