Ooh
#7435 posted by Spirit on 2008/05/20 21:04:50
Nice trick, thanks.
Hi, It's Me Again
#7436 posted by Spirit on 2008/05/22 13:07:45
I am learning a lot with my rmx map.
Any idea with QuArK's Digger thing sometimes stops working? Eg I just used it to try some window positions (faster than doing the actual brushwork) and then added some brush and boom, three diggers don't work anymore. This happened with another one earlier.
Spirit
#7437 posted by JPL on 2008/05/22 13:29:25
Don't use digger: it is baaaaaaad ;)
Ask rather on QuArK forum here: http://quark.planetquake.gamespy.com/forums/ as it sounds to be more related to QuArK use than mapping issue itself :P
#7438 posted by JneeraZ on 2008/05/22 15:39:17
The digger is only bad if you're excessively anal about your brushes and need to control every single cut yourself.
Oh wait, right, nevermind. Forgot what site I was on for a moment there. :)
Hey
#7439 posted by Spirit on 2008/05/22 16:37:48
I said I just used it to try some window positions, ok!
It's not too important as I can simply put a normal brush there, the digger just looks nicer until I properly brush it. Just thought I would ask.
Did anyone manage to setup those fancy templates that were added recently? The process is simply retarted anmd for me it once half worked but never usable: http://quark.planetquake.gamespy.com/infobase/intro.mapeditor.misctools.html#templates
Spirit
#7440 posted by JPL on 2008/05/22 18:20:01
The problem with digger is that it generates HOM most of the times, and also it basically a hole creator that sucks... just due to texturing difficulty...
Well, I tried to use it in my first map, and I've been adviced by Vondur to not use it anymore, so I did...and it was not a bad advice.. Anyway, perhaps I have to test a little bit more the feature :P but I really doubt it will improve my stuff....
Preach
#7441 posted by ijed on 2008/05/23 15:38:30
Where do I look in order to fix the killtarget / target bug?
- a la Quoth1.
If its not a bug then I'll have to create a new function to handle the extra target?
SKIP Textures
#7442 posted by JneeraZ on 2008/05/23 16:26:56
Can anyone point me to source code for a QBSP compiler that supports SKIP textures? I'm interested in learning about them...
Newskip.exe
#7443 posted by RickyT33 on 2008/05/23 16:40:42
its a post full-compile tool, and it works just fine, Metlslime made it!! I used it for the fuse part of Slave. you just run:
newskip -mapname
all there is to it (just texture skip-able faces with a texture called "skip")
The old skip tool (can't remember who made it) doesn't like light tools, and the light tools dont like it)
I've got it at home, I can post it later but I'm sure if you google "newskip.exe Quake" you'll probably find it somewhere...
#7444 posted by JneeraZ on 2008/05/23 16:43:32
Well, thanks, but I'd rather implement it at the QBSP level so it writes out a BSP file that is ready to rock.
It's Finding Light/vis Tools Which Dont Fuck Up
#7445 posted by RickyT33 on 2008/05/23 17:03:40
when they hit a skipped face. You see it basically removes the faces completely, and from my experience light and vis tools throw fatal errors at you every time :-( , so it can only be done after the process I'm afraid.
Although I can only speak from my level, if you know what I mean ;-P
but if you dont need to vis/light then I guess you could write it into a QBSP tool (?)
#7446 posted by JneeraZ on 2008/05/23 17:20:53
Right. I know the Quest source code is available and they claim to support SKIP textures in QBSP but I was wondering if there were any others.
Killtarget Bug
#7447 posted by Preach on 2008/05/23 18:19:04
Do you mean the one where a monster needs a target in order to fire it's killtarget, or the one where having a killtarget prevents target from firing?
For the former, the code you need to change lies in monster_death_use in monsters.qc. The line that reads
if (!self.target)
return;
should be changed to
if (!self.target && !self.killtarget)
return;
or just commented out, SUB_UseTargets can handle empty strings properly just fine.
The latter problem is a bit harder. The problem is in SUB_UseTargets in subs.qc, find the portion of code that begins
if (self.killtarget)
{
...
}
The do...while bit loops over all the entities, until a return is hit when t is the world entity - which in quake terms means we've gone through the whole list. The problem is we'd like to have it just break out of the loop, rather than return from the whole function - as currently it makes it skip the last portion that checks for targets. Solution 1 is to turn that little loop, everything I cut out from the quote above, into it's own function. Then just call your new function from the same point in the code the loop used to occupy.
Solution 2 is to rewrite the loop so the while condition actually breaks you out of the loop at the right time, without ever removing the world. That would look like:
t = find (world, targetname, self.killtarget);;
while(t)
{
remove (t);
t = find (t, targetname, self.killtarget);
}
Notice how we initialise t to the first found item, and put the while(t) at the front of the loop. This is so that if there are no entities with that targetname, the find returns world, and we skip the first iteration of the loop. Removing world crashes the server, so we really want to avoid that.
#7448 posted by JneeraZ on 2008/05/23 20:20:07
I'm beginning to suspect that I'm the only guy writing tools anymore - aren't I? :)
Willem...
#7449 posted by metlslime on 2008/05/23 21:47:02
There is no compiler that currently supports skip faces, so for now it's done as a post-processing step. Everyone uses either tyrann's original "skip.exe" or my "newskip.exe", which both operate on the same principle -- leave the faces in the bsp, but shuffle them around and lower the marksurface and face counts, so that the game rendrerer doesn't try to render them. Example:
Leaf before processing:
marksurface count: 5
markrsurface array: 1,2,3,4,5
Leaf after processing:
marksurface count: 3
markrsurface array: 1,4,5,2,3 (2 and 3 won't be drawn)
The potential advantages to qbsp support is that it could save lightmaps, reduce light time, lower file size, and reduce the global marksurface count. I don't know how easy or hard it would actually be to write.
I suppose the advantage to the current situation is that you can use any qbsp you want and you don't have to forfeit using skip textures.
P.S.
#7450 posted by metlslime on 2008/05/23 21:48:43
This may be obvious, but if you add skip support to qbsp, you should not do it the cheesy way that our tools do it, you should support it the right way by fully deleting / never creating those faces in the bsp file.
#7451 posted by JneeraZ on 2008/05/23 23:12:48
That's what I want to do, metl. Of course, we'll have to see if my incompetence proves too much for the task.
Skip
#7452 posted by than on 2008/05/24 01:34:42
the old skip tool is a bit buggy and doesn't support skip on fluids. Metls skip tool supports skip, waterskip, lavaskip and slimeskip textures so you can use it for effects like glass using water brushes and glass underwater etc.
It's pretty nice.
Probably best to implement skip at the end so you don't somehow get lighting promblems from missing faces. Still I personally tend to use it only on solidents and water faces.
Willem:
#7453 posted by metlslime on 2008/05/24 03:48:17
here's the thread for newskip, with links.
(part 2 Of Previous Message)
#7454 posted by metlslime on 2008/05/24 03:48:36
#7455 posted by gone on 2008/05/24 16:54:31
are there any up-to-date tuts on lighting for noobs?
Jumping Distances
#7456 posted by Mike Woodham on 2008/05/24 17:41:22
Does anyone know how far those cheating basta...., I mean trick jumpers, can jump across yawning caverns?
-bunny hopping
-grenade jump
-rocket jump
-vore ball fiend swipe
-double grenade mouse swipe back flip triple sulk ho
-etc
...given a flat surface and decent run up.
You Forgot...
#7457 posted by bal on 2008/05/24 17:44:29
Shambler Lightning Jump Surf.
Cheers Preach
#7458 posted by ijed on 2008/05/24 18:29:34
I meant the former, but seeing as you answered both I'll attempt the 2nd when I get back as well, the second solution seeming to be the cleaner way to resolve the issue.
Been away for awhile and get back in a few days, will be nice to be mucking about with Quake again.
@spirit
#7459 posted by rudl on 2008/05/24 19:10:58
Never had that that a digger does not work. But when you have a digger in a group it only affects brushes in it, which is very usefull:
a room= two brushes: one of them is a digger. Group them. Put stuff into that room but not into that group.
|