TrenchBroom 2.1.0 Release Candidate 2
Fixed Link
#2874 posted by ericw on 2018/11/05 00:33:03
@Razumen @dumptruck_ds
#2875 posted by Tribal on 2018/11/07 14:44:54
Yesterday i've found a new Hexen2 custom map (released last month) made by Whirledtsar.
I think this is the first HX2 map made in TrenchBroom that i ever played =D
download:
http://hexenworld.org/a-new-hexen-ii-map-the-tyrants-tome/
my playthrough:
https://www.youtube.com/watch?v=k9ZgnXO88PU
#2876 posted by Qmaster on 2018/11/08 14:36:54
I mean don't get me wrong, I'll be the first to axe every wierd wall but that was ridiculous. Are hexen levels always that obtuse? Never played it.
@Qmaster
#2877 posted by Tribal on 2018/11/08 15:20:36
I played Hexen2 in 1997, so i don't remember if you had to do it on the original maps. But on the custom maps, people usually hide secrets behind destructible walls (or bellow the beds, or behind a bookcase, or inside a statue, etc) so you have to axe everything to find them. When something is destructible there's a particular sound that it makes when you axe it, so it's not that hard to know if you can do it or not... but it's just boring :P
TrenchBroom 2.1.0 Release Candidate 3
@ Tribal
#2879 posted by Razumen on 2018/11/13 06:52:09
Looks interesting, I'll have to give it a spin.
@Qmaster Original H2 wasn't really obtuse with its secrets, mostly they'd be hinted at in some way. Generally I find hiding secrets behind things with no hint at all that there's something there just bad level design, even worse if progression relies on it. No way in hell I'm going to go hitting every wall to see if it's breakable.
@Razumen @Tribal
#2880 posted by whirledtsar on 2018/11/17 21:06:37
Razumen - that looks excellent! The lighting is very nice and the setting looks very interesting. Can't wait to play it.
Tribal - thanks for playing the map, hope you enjoyed it! Yeah, the progression is a bit cryptic, but I'm the kind of guy to destroy everything breakable on principle so it didn't occur to me that it could be a problem for others.
TrenchBroom 2.1.0
Specifying Skin And Model From Dfferent Folder/pak Directories?
#2882 posted by Razumen on 2018/12/27 03:14:17
Does anyone know how to do this? Hexen 2 has paks in a different directory for mission pack monsters. I thought copying over the pak file to data1 would be a bandaid solution, but it just crashes Trenchbroom. Do I have to specify an absolute path for these special entities or is there a cleaner way? The vanilla entities load their models fine in TB.
Also, is there way to specify the skin to use for each model, H2 has certain monster variants that use the same model but different skins. Not as big of a deal as above if I can't, but would be nice.
Not too familiar with the FGD format.
RE: Specifying Skin And Model From Different Folder/pak Directories?
#2883 posted by Razumen on 2018/12/27 04:04:31
Nevermind about the skins, figured that out.
You Need To Add The Mission Pack Directory As A Mod
And you need to create a new fgd for the mission pack. You can reuse the existing fgd by including it. If you do create an fgd for the mission pack, please make it available to us so that we can include it.
You might get lucky if you google for it, maybe someone has already created one.
@SleepwalkR
#2885 posted by Razumen on 2018/12/27 15:47:07
Thanks! I must've missed that part of the manual.
TrenchBroom 2019.1
Get it here as usual: https://github.com/kduske/TrenchBroom/releases/tag/v2019.1
This release contains experimental Quake 3 support. You can load Quake 3 maps with shaders. But patches and brush primitives are currently dropped and md3 models are not displayed in the editor.
Wow - It Was Close To Release!
Time to find my old maps!
How Stable Is Valve Format (on Linux) These Days?
#2888 posted by anonymous user on 2019/01/27 12:54:03
I haven't touched TrenchBroom in well over a year and am out of the loop, but now I'd like to slowly but surely get back into mapping, if real life allows.
When I last used TB, I kept running into problems with texturing. Using Valve format would often result in bizarre problems and I had to convert everything I was working to Quake format, but even then, copying and moving brushes would often result in completely messed-up texture properties. This was one of the reasons why I gave up on mapping for a while, as it was incredibly time-consuming to have to manually fix the texturing on individual brushes; it almost defeated the purpose of copy+paste.
I don't know if there are any differences between the versions of TB for the various OSs, but those of you using TB on Linux, how is texturing in TB these days? And how stable is Valve format in the latest iteration of TB?
I apologise if this sounds like one of those things one could find out for oneself, but I am reluctant to go through the same process again of needing to restart or redo hours (or days/weeks/months) of work and completely spoil the fun of mapping for myself ... again.
I'm Not Aware Of Such Problems
There have been a few changes and fixes for Valve 220 texturing last year, but I'm not sure if these are related to what you are describing. Did you submit bug reports for these problems?
What's My Problem ?
#2890 posted by Jaeon on 2019/01/27 18:48:20
http://www.speeed.ga/pic/why.jpg
I cannot get the map to compile.
The directory has full permissions
Thanks
Well, export map has no map name?
I haven't used the built-in compiler in a while but the manual says:
Exports the map to a file. This file should be different from the actual file where the map is stored.
Thanks For Responding, SleepwalkR
#2892 posted by anonymous user on 2019/01/27 18:55:37
I guess I would have submitted bug reports (I have submitted a few over the years), but my memory is a little hazy; as I said, I've been out of the loop for a while.
I do remember using ericw's tools to convert a few maps to Quake format the last time I was actively mapping and I think it was on either ericw's or your advice, since at the time, the were some problems with Valve format and regular Quake format was a lot more stable.
I seem to recall that when using Valve format, selecting a bunch of adjacent brushes and giving them the same texture values wouldn't work and would result in horribly misaligned faces (e.g. with rockwork or even just fairly simply architecture, like a brick texture wrapped around a tower).
But I also remember that even when using Quake format, textures wouldn't stay properly locked or would come out weirdly flipped when I moved copied brushes around (I think especially when flipping them). This was especially annoying when I had spent a lot of time fiddling with exact angles and X/Y values to get textures looking right on angled surfaces, only to find them completely messed up when I copied and moved the brush in question somewhere else.
I'm sorry that all of this is rather vague.
Jaeon
#2893 posted by bal on 2019/01/27 19:48:08
You've set up your compile so that it does absolutely nothing, you need to specify what each tool has to do.
Go into the Trenchbroom help (F1) and look at the Compiling Map section, there's an image suggesting how you should set up compiling.
It's Impossible To Say
without having proper steps to reproduce. But the fact that noone has submitted bugs in the issue tracker tells me that there are not a lot of people who experience such problems.
Hmm
#2895 posted by Drew on 2019/01/27 20:56:14
probably something stupid, but
having an odd issue with TB Version 2.1.0 RC1 release
started dinking around in a map. Was going dandy. Was compiling with Necros GUI. Dandy. Then I noticed changes made weren't making it into the compiled map. Stopped for a bit. Turned PC off. now when I try to load map, I get notification "unexpected end of file".
windows 10 home
Pls let me know if any input to resolve. Not a big deal with this particular map as its tiny
#2896 posted by anonymous user on 2019/01/27 22:27:19
the fact that noone has submitted bugs in the issue tracker tells me that there are not a lot of people who experience such problems.
Fair enough. :) Thanks again for responding. Well, I guess worst case scenario is that I do run into these issues again, in which case I'll submit bug reports.
Please Do
We are usually quick about fixing those. Thanks!
|