#15066 posted by necros on 2015/07/31 22:43:29
Can't be... I have just 2 func_groups and one is rock and one is sky...
New Tack
#15067 posted by necros on 2015/08/01 05:58:20
Anyone know what steps I need to follow to do a q3bsp for Darkplaces? Is it just a mapper of using a regular q3bsp compiler and feeding the results into DP?
#15068 posted by - on 2015/08/01 06:30:57
I believe it is actually as simple as that. You make a Q3 .bsp, shaders and all, but use Q1 entities (use actual detail brushes instead of the hacked together func_details!). The .map format is slightly different iirc, so you'll need to make sure you're using q3's .map format so the compiler will accept it!
To Be Clear
#15069 posted by - on 2015/08/01 06:31:48
I mean q3's .map is slightly different than q1's .map!
#15070 posted by necros on 2015/08/01 06:37:30
aye, i remember there is directory paths and such in there... i think i can get by with using aguirre's map converter which goes both to and from q2 format (which I think is the same as q3 map format?)
as for shaders............. yeah... no clue about that as i never made a q3 map. i guess i'll track down a q3 compiler, i think q3map2 is the current standard? and go from there.
Why does most Quake-based editors use colored boxes for entities? I can understand for things like lights and whatnot, but I think visual aid is important too like knowing which direction the info_player_start and monsters are facing on the spot.
Func_detail Or Func_wall?
#15072 posted by adib on 2015/08/01 07:42:32
What's the difference between them?
#15073 posted by negke on 2015/08/01 10:35:19
Pika: I wouldn't say "most". It depends on which editor you use; some can be set to show either boxes or 3D models. In Radiant, for instance, it's simply a matter of editing the def file to include paths to the individual mdls.
While it's nice to have the models shown in the editor, it can have disadvantages depending on the implementation. In Quake, it's all about the entities' bounding boxes, and if an editor displays ONLY the model, correct placement becomes awkward. The result is monsters stuck inside walls or items falling out of the level.
adlib: Func_wall is a dynamic map entity which can be used to block off areas on certain skill levels or game modes; it can be removed mid-game, and it doesn't block light and vis. It also starts a texture animation when triggered if the right one is applied.
Func_detail is only for the compiler. It creates detail brushes/architecture that is disregarded when processing the visibility information and is turned into world geometry afterwards. It's a means of speeding up the VIS process, and it needs compiling tools that support it, otherwise you'll get a lot of disappearing stuff in-game.
Necros
#15074 posted by - on 2015/08/01 13:16:12
Q2 and Q3 (and Q1) .map are different too! Q2 has some extra fields for surface properties per face which Q1 and Q3 don't!
#15075 posted by necros on 2015/08/01 20:51:45
ok, it was very simple actually, compiled, used quark to convert the map to q3 format (literally just copy/pasted from the q1 map into a new q3 map)
q3map2 is actually much worse than the q1 compilers in terms of handling insane geometry. looked like maybe 5% of the faces were missing in the q3 map.
oh well, looks like it's time to call it. it was a fun experiment, but just not meant to be... maybe i'll use this mesh for a doom3 map or something.
...?
#15076 posted by Kinn on 2015/08/02 01:17:16
Please don't tell me you were using the brush version of your terrain in the q3 version.
Yeah...
Going for Q3BSP and not using meshes would seem a little pointless. BSP is not the way forward for terrain.
#15078 posted by necros on 2015/08/02 07:41:20
i never made a q3 map before so.... i wouldn't know.
ericw told me about some misc_model thing though... which is apparently some magical way of turning a model into world geometry!
Qbsp Request For All Tool Programmers
#15079 posted by necros on 2015/08/03 02:25:34
-haltOnLeak
Stop compiling immediately after writing the pointfile and exit with error code != 0
This lets people detect %errorlevel% in batch files.
Thanks!
Also
#15080 posted by necros on 2015/08/03 02:34:28
because it was annoying me:
https://github.com/necros0/ne_q1CompilingGui/tree/master/Compiling%20Gui/Compiling%20Gui/bin/Release
just grab the exe file. hard codes the START /B /I /WAIT /BELOWNORMAL into all the compiler commands, so everything always has below normal priority.
At some point, i should probably make some per-compiler thing to choose what priority you want, but... meh, this works.
#15081 posted by - on 2015/08/03 02:45:21
I was under the impression that you can't tell if there is a leak until you traverse the entire tree, thus why QBSP doesn't end early when it finds a leak.
#15082 posted by necros on 2015/08/03 03:01:03
when qbsp writes the leak file, is that not 100% a leak? usually what I do is I watch the output until it says 'writing point file' then once it's done, i Ctrl+C and plug the leak.
#15083 posted by - on 2015/08/03 03:34:07
Oh, I see what you're asking for now, ignore me.
I was thinking you just wanted time savings by ending the compiler earlier, but most of the hard work has already been done. QBSP has fully processed and portalized the tree when it detects the leak... but you just want an option to return an error to the console at that point so your batch file can detect it.
#15084 posted by necros on 2015/08/03 03:36:17
that and so i don't have to actually sit there and watch the output (which I sometimes miss) waiting for 'leaked!' :P
Disregarding the current map, I rarely seal until the end where I do a leak plugging session. But it gets tiring to have to watch console output hoping it won't leak. Dunno if others do it that way or not though...
#15085 posted by - on 2015/08/03 03:40:12
Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them.
#15086 posted by - on 2015/08/03 03:40:12
Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them.
#15087 posted by Rick on 2015/08/03 03:46:31
I never work on a map that leaks.
#15088 posted by JneeraZ on 2015/08/03 11:34:33
Sometimes you have to, Rick. Large scale retooling of areas or you're trying something out, etc. Leaks aren't an issue until you want to release the map, really. Only thing they do is slow down your lighting builds...
Hm
#15089 posted by ijed on 2015/08/03 16:27:02
I prefer to keep a map sealed as well.
There are so many ways a map can get weird phantom leaks, I like to keep the obvious ones plugged.
For tests I do the big box method - a giant box or two to remove areas from the compile, or just plug holes while I put other areas together.
Really it just depends on which brand of OCD you subscribe to.
#15090 posted by Rick on 2015/08/03 16:28:08
I agree, when doing major structural changes it's hard to avoid creating leaks, but once things are rearranged close enough it's time to plug any leaks.
So I guess said that wrong. I just meant that I don't start with a bunch of brushes and stuff floating in the void, I build with sealed areas from the beginning.
|