Btw. Where's The Difference
#4861 posted by negke on 2006/03/22 00:12:17
between mipdip and adquedit and why do they look so much alike?
Err.. Not Adquedit
#4862 posted by negke on 2006/03/22 09:09:57
but that one program which is basically the same, only with a different title...
Negilke
#4863 posted by metlslime on 2006/03/22 18:40:21
mipdip and qArt are the same program, but qArt is the name of it after it became a commercial product. It was offered by the same company that offererd qED and qME i think.
Thanks For Clarifying
#4864 posted by negke on 2006/03/22 23:40:52
there was a time when i had to use qart, for mipdip wouldn't start anymore (or i was too dumb to fix it). now, both have been obsoleted by textmex anyway.
Are There Any Way...
#4865 posted by generic on 2006/03/27 16:09:36
to stop a weapon/item from rotating (minus QC, of course)?
Thanks in advance, Neg!ke :)
Yes
#4866 posted by necros on 2006/03/27 16:45:50
edit the model file and remove the 'rotate' flag on them. easy sleezy!
AWWW...
#4867 posted by generic on 2006/03/27 16:57:40
...POOP!
Or
#4868 posted by negke on 2006/03/27 23:58:07
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...
What?!?
#4869 posted by generic on 2006/03/28 06:53:19
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 :)
Engine Limits
#4870 posted by than on 2006/03/28 07:03:23
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.
Bleh
#4871 posted by bal on 2006/03/28 07:11:00
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.
Tips?
#4872 posted by than on 2006/03/28 08:17:31
got any marksurf lowering tips? wtf are marksurfs anyway? Just surfaces? What are faces then? same?
Generic / Jpl
#4873 posted by negke on 2006/03/28 09:44:45
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...
Marksurfaces
#4874 posted by Mike Woodham on 2006/03/28 10:19:28
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!
Marksurfaces
#4875 posted by bal on 2006/03/28 10:47:39
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. =)
Neg!ke
#4876 posted by JPL on 2006/03/28 10:51:26
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.
Mike W.
#4877 posted by JPL on 2006/03/28 10:58:33
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 / Mike W.
#4878 posted by negke on 2006/03/28 11:13:47
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)
So Many Questions
#4879 posted by aguirRe on 2006/03/28 11:36:28
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.
Neg!ke...
#4880 posted by generic on 2006/03/28 11:53:13
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
And To Clarify
#4881 posted by aguirRe on 2006/03/28 11:55:38
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.
Marksurfaces
#4882 posted by Tyrann on 2006/03/28 12:06:53
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.
Thanks
#4883 posted by Mike Woodham on 2006/03/28 13:03:11
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.
Mike
#4884 posted by Tyrann on 2006/03/28 13:50:47
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 Must Be Doing Something Wrong
#4885 posted by Mike Woodham on 2006/03/28 14:14:55
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!
|