Than
#4924 posted by aguirRe on 2006/04/06 02:56:33
I put in that error check to prevent bsps with corrupt node trees from generating an engine stack fault (which is probably why Fitz crashes). It indicates that the bsp node tree is too deeply nested.
The amount of nodes and leafs from your printout is not over any limit yet, so either the bsp has become corrupt somehow, your map is too complex or I'll have to increase the tree depth limit (currently 4096 and 8192 seems to generate stack fault).
I'll need the zipped bsp to investigate further. Btw, which qbsp/vis/light versions are you using?
The RVis max leafs printout is not a warning or error; just to help you locate the spot where many leafs are visible from and thus is likely to be slow in-game.
Aguire
#4925 posted by than on 2006/04/06 03:37:37
The tools I am using are mainly Tyrann's, since I never had any problems with them (except Tyrlite) and so I am only using your light. I will try your other utils tonight, after I make some more adjustments to the area that possibly caused the problem.
Why do you think light crashed? Is there a max number of lights (surely it is impossible to cross that line).
If I can't get things working by tomorrow morning, I will send you the zipped bsp. Cheers for offering to help =]
Light Crash
#4926 posted by aguirRe on 2006/04/06 03:56:59
Since Light also loads the bsp node tree to do raytracing (check point-to-point visibility), it'll probably crash for the same reason; stack overflow. I haven't put that check into Light yet, my engines have the most robust file loading code.
Yes, please check with my TxQBSP to see if there's any difference. You shouldn't need to run vis/light before loading the bsp into the engine, as they don't touch the bsp node tree.
Temporary Fix
#4927 posted by than on 2006/04/06 06:24:48
I blocked up a window in a lift shaft and it fixed the problem. The same lift shaft has got some serious visibility issues (well, the r_speeds go to around 1300 when you ride it because I can't get it to split horizontally and the rooms at the bottom and middle are both visible at once), so I am not surprised it helped. I am going to be working away on this area tonight, so if it fucks up again tomorrow I'll mention it. Fingers crossed.
Aguire...
#4928 posted by than on 2006/04/06 08:56:39
your vis program does not compile the level. I get this error:
************ ERROR ************
LoadPortals: portalleafs 5692 exceed bsp leafs 3281
This was using your modified treeqbsp.
Tyrann's rvis+ seems to be handling it fine using the same bsp'd map I tried with your vis. It also works with Tyrann's qbsp.
Note that I have not seen any visual problems with the map recently, and it seems to work fine in all respects (aside from the recent compile problems).
The map is compiling happily now, hopefully it will finish without fucking up.
You Know, Than
#4929 posted by aguirRe on 2006/04/06 11:41:48
You've repeatedly asked for help with more or less odd questions or bug reports regarding my tools or engines.
Each time I've tried to figure out what you're doing and each time I've asked for some material so I can investigate what happens. Each time you've "fixed" it yourself and each time you've refused to send me the material I've asked for.
Maybe you should actually do the right thing now? I need the zipped map+wad to be able to reproduce the problems you describe.
You Know, Aguire...
#4930 posted by than on 2006/04/06 17:29:59
you're right. Sorry.
I've encountered another problem now. Light isn't working. I will send the .map and wad :)
Thanks
#4931 posted by aguirRe on 2006/04/07 03:25:12
I think I've found the culprit; the remove_skip utility trashes this bsp, probably because it's so big. This causes subsequent tools/engines to fail. More info in email.
A Small Idea About My Map
#4932 posted by Elvis on 2006/04/07 06:42:58
just a thought
how would it look if i made the weapons and pickup markers a litle higher just above the ground and such the smallest i could make them?
and also make them look abit more alike in general not based on the ground that they are in
.hack//crash
#4933 posted by negke on 2006/04/07 08:13:37
for some reason quake crashes when the player touches a specific info_notnull trigger, while the other notnulls work fine.
what does this error message mean:
http://www.negative.net.tc/quake00.jpg ?
Aguire
#4934 posted by than on 2006/04/07 08:29:19
sorry for tbhe drunk email and also drunkness evident in this post. I will compile the map sans remove skip, but do you think that some kind of remove skip functionality could be implemented into your tools in the future? It would be reallt great if you could add that. xxx ;)
Neg!ke>
#4935 posted by czg on 2006/04/07 08:57:42
The function you are trying to call with the notnull tries to precache a sound, but this is only allowed in the entity spawn functions that are called when the level starts.
Only functions that don't contain any calls to any of the precache functions can be used by the notnulls.
R_speeds
#4936 posted by Spirit on 2006/04/07 09:05:15
I'm on a shitty connection and too lazy to search... What r_speeds would you consider ok for a new map? About 800-900 seems to be nice to me (yes, I just read nico's posts about the "new huge maps"). Yes, I finally decided to map and No, it's a small and not outdoor level. :)
...
#4937 posted by negke on 2006/04/07 11:08:47
thanks.
again, i was too hasty posting that without proper searching/thinking.
it was indeed a sounds field i forgot to remove (even though on a different notnull).
Remove Skip...
#4938 posted by metlslime on 2006/04/07 14:29:27
I would also like to see skip support implemented in qbsp. The current utility is fairly rough and doesn't really delete the polygons from the bsp file, only references to them. (I believe it simply reorders the marksurfaces list, and then shortens the marksurface count for each leaf so that the last few surfaces occur after the "last" marksurface.)
It's been a while since I looked at it, but I remember having to change the rendering in fitzquake .80 to fix the problem of skipped polygons being rendered in .75 :)
More...
#4939 posted by metlslime on 2006/04/07 14:30:15
The other advantage of course is that true surface removal would actually reduce lightmap usage, while the current method does not.
Well
#4940 posted by Kell on 2006/04/07 15:45:29
if it is implemented better, should it also be renamed caulk, since that's what it's called in the Q3 engine, and skip is something else...?
�_�
Remove_skip
#4941 posted by Tyrann on 2006/04/07 19:01:07
Metl's explanation is right and yes, the tool is very rough. It would be nice to redo the util properly (and call it caulk this time), but I don't think I'm going to find time to do it anytime soon.
Probably A Dumb Question:
#4942 posted by necros on 2006/04/08 11:20:12
it's illegal to use q4 textures in d3?
Well, Of Course, But
#4943 posted by HeadThump on 2006/04/08 14:06:10
so are all the Daikatana\Hexen\Q3 textures we use for Quake maps.
It is illegal in the sense that someone, Raven in this case owns the copyright, but don't really expect your nation's equivelant of the FBI to come breaking down your door.
I mean they could, if you take the warning screens on DVD's seriously. Traditionally this has been a matter entirely concerning civil law, but legislation on copyright law in the past few decades has steadily shifted these matters towards the criminal law.
For a new game like Quake 4, someone may take notice; the worst you should expect though is for a lawyer to get his paralegal to right you up a cease and desist order.
Yeah,
#4944 posted by necros on 2006/04/08 15:24:47
i was almost certain it was like that. :P i was just hoping i wouldn't have to start making textures T_T
thanks :P
If I Was Going For The Q4 Look
#4945 posted by HeadThump on 2006/04/08 16:20:30
and I wanted to avoid making some from scratch, I would consider using Sock's Tech series, maybe the Evil Lair Q2-style, and add Normal maps and Luma to those textures using the Gimp.
Actually
#4946 posted by necros on 2006/04/08 21:40:13
it was just a few of the really nice rusty trims from the levels with that fat sitting thing that punches you, and the bloody/gibbagie floor textures where all the zombies are.
the hell textures for d3 are seriously lacking in staple textures, like a nice 64x64 tile texture, any type of light fixtures, and the only really good wall textures are those big and small brick textures. plus the trims are limited to ones that are 32 high.
atm, i'm working on filling in those gaps, but i'm not the greatest at texture making, and not that mine suck outright, but they just don't match the same quality of the original d3 ones. :(
OOoopppss
#4947 posted by JPL on 2006/04/09 00:54:17
So I broke the law using Daikatana textures in my 2 latest maps .... Wow, I was not aware of that... But as our maps are not designed for commercial use, but only for fun, I guess they cannot do anything....
OTOH, I would like to extract HL2/Doom3 textures and see if it is possible to convert them for Quake. Is there anybody who already attempted to do that ? And is there any methdology advice I need to know ?
Textures
#4948 posted by Kinn on 2006/04/09 03:05:15
JPL et al - Generally, using assets from other games is always illegal.
But - from experience it seems that ripping textures from old games for use in Quake (e.g. Hexen2, Dkt, Q3, Rune etc. etc.) is "ok" only because no-one seems to care - technically it's still illegal.
On the other hand, I think it's safe to say that ripping textures from modern games (HL2, D3, Q4) is likely to land you in a world of hurt.
|