 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
yes. in my misc_stupidity i screwed up the files. :(
here are the correct links (some moderator please change them in the top post. thx): Screenshots: http://www.quaddicted.com/component/option,com_docman/task,doc_details/gid,936/ Download: http://www.quaddicted.com/component/option,com_docman/task,doc_download/gid,936/ I don't know how, I didn't see any errors besides "No DM Start" in qbsp or light. oh well. :( DLing now.
how do you always find such things so easily? just by taking a look at the ent file or are there special features in your engines? (if not, it would be a useful addition, or for the compilers at least)
btw. regarding vis, generic is the bogeyman this time! :P You all have my blessing.
Zwiffle's was amazingly enough (he is a terrible man after all) my fave, because I love jumping puzzles, and the layout was cool. Generic's map created a stack overflow in the last room. The drain map was visually cool enough to be good. The other map was really cool with all the breaky bits, but some of the bits could have been marked better. Too little ammo though... that help me find them. The rogue brush ents detection is newly added to my next engine version. It's very interesting to see how many released maps that have this problem and how much trouble it has cost mappers/players during the years.
In Zwiffle's map (or any map with this issue), just fire your RL or NG near origin (0 0 0) and see what happens Qbsp can't detect this generally, as the only one who knows the score is QC. really interesting pack! clever gameplay setups, proper atmosphere and funnage and the lack of fucking boring horde combat!!
my pure demoniac blessing to creators! sm_120_neg|ke not enought amo...nd crash when i get the suit
sm_121_neg|ke ohhh fuck so many stuff to read quit :\ map look great! sm121_generic look�s great but crash in spwan part sm121_zwiffle also crash :\ but the maps at least look real good! So far i only played sm120_neg!ke e sm121_neg!ke...
man, both are amazing!!! They dont look like a speedmap at all o_O and they are very, i mean, VERY tough!!!! I died several time, but i'm brazilian and i never give up =DDD sm120 crashes when i jump into biosuit... so, i cant finish the map :( but sm121 is perfect ;) congratulations ;) look really nice. Zwiffle, from the pic it looks like something I really wish I could play, and from the errors, it sounds like something I would make.
generic: looked good - yeah rubicon2, please! i also had a crash the first time i played the map - it occurs when all crates in the final room explode at once. you should have made them barrels, too. regarding the size of the map, it really is a crime you didn't fix the leak...
zwiffle: yay, u da man! nice map. i particularly liked the wood bits. the jumping at the end was ok, although i fell down a lot because of the one gap in a dark spot. funny shambler ambush. neg!ke: i couldn't get all three towers in sm121 to work properly - they were all supposed to be destroyed like the one where you have to shoot all four supports. everytime i tried to change anything on the others, the game would crash with stack overflow, even though they are exactly the same. i even tried to change the order in the map file, but to no avail. :/ trinca/tribal: at first, i was going to lash out at trinca for using a crap engine, but the crash (without an error message, of course) in sm120 occurs in win/glquake as well. apparently, these engines don't like the suit's and the door's bounding boxes to spawn within each other, or something like that.. dunno. in sm120_neg!ke is ye olde SV_TouchLinks engine bug, related to the e2m2 easy skill crash and several others. The sm121_generic stack overflow is just because most engines actually have a too small progs stack. I couldn't reproduce any error in sm121_neg!ke nor could I kill the last vore, I take it that Neg!ke didn't find a solution to this.
Neg!ke, as none of these issues should happen in my engines, when you actually had the stack overflow in sm121_neg!ke, did you get the same behaviour with them? Also, do you have a bsp that exhibits the problem? the vores can only be killed by squishing them with the tower tops. in some rare situations one of them teleports in too early (with the scrags) - is that what you meant by 'the last vore'? - or is at least activated when it shouldn't. possibly when the fiends are killed to quickly.
then it's impossible to finish the map; but most of the time it works fine. the crash doesn't happen in your engines, even though the towers aren't behaving correctly, either. i have a fastcompiled bsp exhibiting the problem here (just copied the working tower and changed the targets)- shall i send it to you? the strange thing is that, in theory, it should work perfectly with the copies, but for some odd reason it doesn't. and even if it doesn't crash, all four supports explode at once anyway, which is not as intended. compressed if possible ;)
With the last vore I meant that I managed to destroy the pillars beneath and thus the first two (or three?) vores could be killed with my RL, but the last one behaved like before; unkillable. I had to noclip up and inside the tower and splash the bastard with some quad rockets, nothing survives that neg!ke - I'm using Joequake engine (dunno the version, but is not the last one ;P)
aguire - what is calling the evil SV_TouchLinks thing??? Can i delete it on Quark?? Cause i really like this map! o_O About the other two maps... zwiffle - very cool and well done, but the final was kind of anticlimax. After i killed the shambler i had to jump all those bricks again ;P generic - love the rubicon textures, but the map feel really small and crashes at the tarbabies area ;/ Wow! Besides the crashes, this was one of the coolest pack ever (i loved the destruction theme) Hugs ;) The SV_TouchLinks function is called inside the engine when certain things happen in QC and the original code has several bugs that cause either engine crashes or freezes (it gets stuck with looping sounds).
AFAIK, it's an unfortunate design that requires careful interaction between engine and QC to avoid crashes. My engines and DarkPlaces have fixed this issue, but most others are vulnerable for it. I don't know exactly what has to be done to avoid the problem from a mapper/entity perspective. It probably has something to do with triggers that fire off in an "unfortunate way" and thus kill the engine. Maybe someone else can explain it better Zwiffle's was the best of the pack despite Neg!ke's excellent curiosities.
Sorry for the bad VIS, but I left a trigger_counter out in open space :( As for barrels, I intended to use them throughout the board but kept getting QC errors when Fiends and Spawns bumped into them :| I used a func_wall shaped like a barrel with a rectangular trigger around it and a info_notnull using barrel_explode inside of it. The trigger set of two relays: one to trigger the info_notnull and the other to kill the func_wall. There is a probably a better way of doing this...anyone? As for the stack overflow, I didn't encounter it 100% of the times that I tested it, 1/1 ;P P.S. BRING ON RUBICON 2!!! generic: that's the way to go, even though one relay (killtarget) would have been enough already.
the (0 0 0) trick for detecting crashes caused by rogue brush entities is neat. good to know. btw. guess what, sm121_neg!ke does not work with darkplaces (surprise surprise!)... btw. guess what, sm121_neg!ke does not work with darkplaces (surprise surprise!)...
Darkplaces has a nasty habit of making items disappear, particularly ones that are in enclosed spaces. AguirRe: Do you have any idea what would be the best way to sort this problem out? If you need any other items to test, try the silver key in sm28 and the secret armor in sm82. There are other culprits as well, but keys are the worst...
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |