 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I don't know how skip works, but you could try running vis after skip. If the vis data set is large (>1MB, e.g. when fastvis), skip might have capacity problems.
There are probably numerous references to skip in this very thread, but I'll explain it again, since I'm in a good mood. In fact, since I'm such a nice guy, I've uploaded it to my site here: http://than.leveldesign.org/files/remove_skip.zip (26kb)
The skip removal tool is a small utility made a long time ago by Tyrann. It was never officially released, and I recall him saying he lost the source code to it. As it works fine as it is, I guess he never bothered to write it again and update it. Anyway, the skip tool removes all surfaces from the visible hull of a BSP. The original intention of this was to remove surfaces that could not be seen by the player, such as those in high up places above where the player can reach, on the unseen sides of doors etc. This is probably still the main use. However, this also allows for a few cool tricks (creating invisible doors for one), that you can find out about by reading the previous posts in this thread. I just noticed I made a rather large mistake in my explanation:
Anyway, the skip tool removes all surfaces from the visible hull of a BSP. Should be: Anyway, the skip tool removes all surfaces using a texture named "skip" from the visible hull of a BSP. i have found that at about 10000 brushes, you start to run out of clipnodes, no matter how much you clip brushwork, just because the amount of areas that are present take up so many of the clipnodes.
careful! I had exactly the same type of lighting artifacts in the secret map of Contract, towards the end of its construction:
http://kell.leveldesign.org/screenshots/contract-blotchy.jpg I was using Tyrann's lighting util by then, but to make use of entity compression for the secret map, not skip. I don't think skip was even in the version I was using. Maybe it's just a knave thing o_o I have tons of arches that can be clipped, so if I run out, I will try clipping them. There's also not much rock in the level (there is a bit, but not like something like februus or czg07) so perhaps I'll be ok.
Anyway, as I said, the lighting glitch was fixed by using skip before light. I will try it before vis next time and see what happens. Wtf is entity compression? Wtf is entity compression?
It's not really compression, but it reduces the amount of entity text present in the compiled bsp by removing key/value pairs from the light entities which are not needed after the lighting stage. WC - try the most basic tool included - "check for problems" You�ve probably already done this, but if not; with Q1 it seems to be alot more finnicky and can find illegal entities, though with visgroups yor best bet is removing all before you try deleting a single part of one group - buggy behaviour (WC 1.6a) tends to seemingly randomly hide / delete depending on the order you originally did stuff in . . . 20 versions ago
either way - looking forward to the release I'm sure everyone who knows the answer will tell me this map is basically doomed, but I'm trying to figure out a reason for this weird occurence. DuBSP is reporting that my map has leaks. What's unusual about it is that: 1) it only reports the leak while filling, but not while generating hulls. 2) it refuses to generate a pointfile, even when using -oldleak. I'm in the process of isolating parts of the map and compiling them individually but, maddeningly so, it always seems to be a different entity reached while filling.
For anyone feeling curious/helpful, here's the compiler dump. DUBSP Disunion Level Compiler by Eric 'Riot' Lasota Based on TreeQBSP v1.62 by Greg Lewis. Input file: manatees.map Output file: manatees.bsp ---- LoadMapFile ---- *** WARNING 06: No info_player_deathmatch entities in level 2439 faces 410 brushes 35 entities 50 unique texnames 627 texinfo Processing hull 0... ---- Brush_LoadEntity ---- 383 brushes ---- CSGFaces ---- 2277 brushfaces 3088 csgfaces 1580 mergedfaces ---- SolidBSP ---- 2052 split nodes 832 solid leafs 1221 empty leafs 0 water leafs 3329 leaffaces 3096 nodefaces ---- Portalize ---- 1221 vis leafs 3309 vis portals ---- FillOutside ---- *** WARNING 10: Reached occupant at (-112 352 88), no filling performed. ---- MakeFaceEdges ---- ---- GrowRegions ---- Processing hull 1... Processing hull 2... Processing hull 3... ---- WriteBSPFile ---- 490 planes 9800 3533 vertexes 42396 2130 nodes 51120 627 texinfo 25080 3226 faces 64520 1701 clipnodes 13608 1294 leafs 36232 3467 marksurfaces 6934 12835 surfedges 51340 7955 edges 31820 50 textures 451444 lightdata 0 visdata 0 entdata 3037 2.359 seconds elapsed Bytes used: 4108697 thanks for looking. That when sealed (i.e. no openings to the grey void but only the mystery leaks) the map DOES create a workable
i had something like this i ne_marb... basically, it was some complex geometry in the terrain area (where the shore is that leads to the cave) that was messing it up. you couldn't atually see any leaks but it was there... basically, i just ended up redoing a fair amount of brushes in that area to a much simpler look as it is now.
so that would be my only suggestion: find areas that have complex geometry (terrain, complex trims, etc) and try removing them and replacing them with simple placeholders. When the problem goes away, you know you've found the culprit(s), and can simplify/fix/remake/whatever sorry i can't be of more help. one last thing, i'd suggest trying out aguire's bsp compiler, it might have more luck on complex geometry ...by actually generating a pointfile so I could track down the leak. Thanks to biff, bal, and necros for suggesting it. Still a mystery why there were no leaks detected while processing the clipping hull but at this point I don't particularly care. :)
Is it possible for you to rebuild the fr3n1m3 map using my qbsp? It's got those annoying tjunction sparklies. Or if you'd send me the zipped
I asked for a link to yours and got txqbsp and treeqbsp. Whatever I used, it worked. But what am I SUPPOSED to be using? I hate those sparklies just as much as you. :)
my compilers, you don't have to do anything special; they both default to tjunction padding (= no sparklies). It's some of the old compilers (e.g. dubsp) that default to no tjunctions (= sparklies).
But I was under the impression that I already WAS using your compilers. Is this the wrong URL or something?
http://user.tninet.se/~xir870k/ my initial request above was for the released fr3n1m3, which as far as I can see has the sparklies, i.e. it's either built with an older compiler (e.g. dubsp, which you also asked about before) or using my compilers and adding the -notjunc option (definitely not recommended).
The URL is correct, sorry for the confusion. How do make elevator buttons that move with the elevator?
so how is done now? some trick as in half-life, like a fake button on the lift and triggers at the corresponding spots in its extended positions? but how could it be done (preferably without hacks) that it only works when the lift is in the right position? maybe with a skip/clip door blocking the trigger that was just used after the lift starts moving, while unblocking the other... a very basic question... I'm guessing some sort of crazy setup with trap_spikeshooter logic gates would do the trick. Still you can't make the button move first then move with the elevator though.
using a really huge button that moves outside the playable area when pressed. I might do something similar but better looking in the next map just for the heck of it.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |