 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
that I already gave up on that grey/blue perssp3 map since it involved the exact same scenario JPL is describing. :) Good luck man.
I've now compared the original ne_sp06 bsp with one that I've run through my new light -onlyents feature.
The QC coded new lightfade entities still seem to work as the original but now the source entities actually get their correct style set which they didn't originally. There are also two switchable lights (targetnames monspawn7 and necros1, GL and silver key) that now works, whereas they don't in the original. I don't know if you manually disabled them (by invalidating their style) or if they got accidentally disabled by doing a qbsp onlyents run but maybe you can clear that up? on the light util, i haven't had the chance to try it yet as i haven't been mapping these past couple of days, when my map has finished vising (8 more hours, whee!) i'll try it out.
The QC coded new lightfade entities still seem to work as the original but now the source entities actually get their correct style set which they didn't originally. huh? the thing with those entities is that the style key was set manually by me in the editor instead of letting the light util do it. There are also two switchable lights (targetnames monspawn7 and necros1, GL and silver key) that now works, whereas they don't in the original. honestly, i have no idea... it's probably a bug... i never made much use of the lightfade ent even though i thought it was really cool at the time... :P the only ones i remember working (and remember putting in) are in the long hall way at the start where the brown shamblers come out, and in the small bloody room where you get ambushed by 3~4 or so fiends. ok, and here's my guess on how the switchable lights work... you put the ent in with the flag set with only the targetname and a trigger to activate it... light comes along, calculates the area of effect of the ent, assigns it a style key and goes away. in the game, depending on what flags were set, the qc then decides what intensity letter (from a (darkest) to m(brightest) (past m is overbright i think)) to assign to the switchable light. when the light gets trig'd, qc changes the style of the light to a different letter, the lightstyle command tells the engine to upload new data to that particular style. yeah. i still don't know if i'm just repeating stuff you know already or not,... i thought it was worth saying. lates entities still work because you manually put their style keys into the entity section and they don't conflict with other switchable lights.
Since you assigned them styles 63-64, the risk of interference is minimal. Light will not remove any style keys but may reassign them as required. You only have 2 "normal" switchable lights, those I mentioned above. The spot over the GL should turn off when grabbing the weapon but it doesn't in the original. The one triggered by the silver key is more strange. A light is supposed to appear in one corner of the big dragon arena when you grab the key down the river (far away). I can't see how anyone would notice that. And the lightfade ent I checked was actually the one just before the "brownies" appeared and it works in both versions. Your description of switchables seems basically correct, metlslime described something similar. I can't comment on the details though. Thanks for the ne_sp06 tip. This new Light feature is a bit hard to test. hm, last times when i have enormously sized leak (forgot to insert a brush) qbsp reports the leak, creates pts but when i start the map everything is gray. but i still heard the sounds etc. only compiling with -hull 1 option helped me to see the map and find the huge sized leak. is that normal? looks like huge leak confuses qbsp :)
did that happen in fitzquake? i had a similar problem with a map of mine where all i could see was the void (either HOM or grey if gl_clear 1), but i could still move, shoot and hear things like monsters waking up and doors moving...
sometimes and I'm not sure exactly why. I have a theory that it's related to the hull filling (FillOutside).
Did you perhaps use the -noents option when it happened? I had to insert some dubious code to prevent some other bad behaviour when using that option with a leaky map. You know the No entitities in empty space My guess is that if hull 0 leaks and qbsp can't make out what's inside or outside, then the filling will run amok and remove the whole hull. The other hulls can very well be OK so you can walk around but you can't see the actual hull 0 (entities should be fine, though). If you're using the noents option, try removing it next time it happens. If not, I don't really know i don't think it's a compiler problem.
that problem only happens in fitzquake. when i had that problem, i went into tyr-glquake and i could see the map fine. also, when i sealed it off, the problem went away in fitzquake. metlslime and i were trying to track down the problem but it never got very far. i found just keeping the map sealed kept me out of trouble. the map didn't even have to be vised. (also, at this point, unvised, the max wpoly is around 13000 and fq still handles that) i didn't use -noets option.
but i've got one idea, that leak was under the water completely, maybe this is the reason of the weird qbsp behaviour? It wasn't "previously used", that's why it is amusing. ;) I can't think of any maps where you need to swim through lava except e1m8 and rrsp1.
I don't think that liquid would change anything but you could try adding the option -solid which will remove all liquid brushes and see if anything changes.
What about TyrQuake, same or different behaviour? TyrQuake is so far the most robust engine I've seen so it's very good with leaky, troublesome maps. But FQ is IMO the obvious choice for actual playing. Update on the crashing map: I loaded the map file into QuArK, fixed a broken brush that probably occured in the conversion process and then rebuilt.
Suddenly, the map doesn't crash anymore in FQ, not even without fastvis! There are packet overflow aplenty and entities disappear now and then but it doesn't crash. Hmm, this is weird it's likely to be a visibility issue; too much is visible from some angles and that probably includes both architecture and entities. The architecture (or rather, layout) is too interconnected, which looks nice but comes with a price tag.
If you perform a fastvis, it will printout the position in the map where the highest # leafs are visible. This is a place that you should check out with TyrQuake and the r_draworder cvar enabled. I'll read your email and get back to you. The idea was to jump to catch the pentagrm, climb into a well, and fall into a lava "bath" to progress into the map... so without invicibility pentagram, you die immediatly..
Anyway, yesterday night I tested the method given by distrans (thanks distrans), and I had some problems to perform what he recommended me... (sorry distrans) but I solved the problem with another turnaround.. Perhaps I used some bad method (I'm a beginner in Quake mapping)... Perhaps there exists a method to preserve item position with an additional field, in order to avoid "gravity" effects... Bye http://www.cdrom.com/pub/idgames2/planetquake/quakelab/float.zip
This is the tute I mentioned for floating entities. I think all the Quake Lab Links, at least the cdrom ones would be dead.
Just change the URL by adding fileplanet.com/dl.aspx? to the front of the file path, eg http://www.cdrom.com/pub/idgames2/planetquake/quakelab/float.zip would become http://www.fileplanet.com/dl.aspx?/planetquake/quakelab/float.zip same thing as what you do with alot of the other broken PQ links How stupid I am... I didn't read the text file
Well I think it gives you a tutorial type thing on how to acheive floating things,It also contains a
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |